The screenshot ritual is dying, and not a moment too soon. For decades, internal auditors collected evidence by asking a control owner to log into a console, take a picture of a configuration screen, paste it into a Word document, and email it back. By the time that screenshot reached the audit file, the system had likely changed three times — a new branch protection rule, a rotated key, a redeployed cluster. The artifact was stale before it was filed. In a CI/CD environment that pushes to production several times a day, point-in-time evidence describes a system that no longer exists.
The fix isn’t more auditors or longer fieldwork windows. It’s treating evidence as a build output. Every commit, pull request, scan, and deploy already emits structured signals — pipeline run IDs, policy decisions, signed attestations, artifact digests — that map cleanly to the controls auditors test. The job is to capture those signals as they happen, store them where they can’t be edited, and wire them to the control objectives in SOC 2, ISO 27001, PCI DSS, and the IIA’s Global Internal Audit Standards. That’s an evidence pipeline.
This article walks through how to build evidence pipelines that satisfy both engineering velocity and audit assurance: what controls belong in the pipeline, what evidence they should emit, how to make that evidence trustworthy, and where the model breaks down.
Why Evidence Has to Move Into the Pipeline
The traditional control model assumes a slow, reviewable change cadence. A change request gets logged, an approver signs off, the change is implemented in a window, an auditor samples 25 of 1,200 quarterly changes and traces each to a ticket. That model collapses when the same organization deploys 400 times per day across 80 microservices. Sampling stops being meaningful when changes outnumber audit hours by orders of magnitude, and screenshots stop being trustworthy when the underlying systems are ephemeral.
The DevSecOps response is to embed controls into delivery itself, so that every change generates the same machine-readable artifacts: a pull request record with required reviewers, a pipeline run ID with all scan results, a signed build provenance document, a deployment record tied to the same artifact hash. The evidence isn’t collected later; it’s emitted as a side effect of the work. As one practitioner framing puts it, you stop asking teams to prove a control existed and instead hand the auditor the pipeline output: who approved, what changed, which checks ran, when.
Internal audit’s job in this world isn’t to gather evidence — it’s to validate that the pipeline itself is trustworthy, that controls cannot be bypassed, and that the evidence store is tamper-evident. That’s a different skill set than reviewing screenshots, and it’s what most internal audit functions are still learning.
The Anatomy of a CI/CD Evidence Pipeline
A working evidence pipeline has four planes, each with distinct responsibilities and distinct failure modes.
The control plane defines what must be true at each pipeline stage. These are policies expressed as code — Open Policy Agent’s Rego, Conftest, or Kyverno for Kubernetes admission — versioned in Git alongside the application code. A control plane policy might say: every container image deployed to production must have a signed SLSA provenance attestation, must pass a Trivy or Grype scan with no critical CVEs older than 30 days, and must originate from a protected branch with at least one reviewer who is not the author.
The instrumentation plane is the set of tools that run during pipeline execution and emit evidence: SAST scanners (Semgrep, CodeQL), SCA tools (Snyk, Dependency-Track), container scanners (Trivy, Grype), IaC scanners (Checkov, tfsec, KICS), and secret scanners (Gitleaks, TruffleHog). Each tool produces output in a standardized format — typically SARIF for code findings, SPDX or CycloneDX for software bills of materials.
The attestation plane is what makes the evidence trustworthy. This is where Sigstore (cosign for signing, Rekor for transparency logging, Fulcio for keyless certificates) and the in-toto attestation framework live. An attestation is a signed JSON document that says “this artifact, identified by SHA-256 hash, was produced by this builder, with these inputs, passing these checks, at this timestamp.” SLSA Provenance is one predicate type within the in-toto framework; vulnerability scan results, test results, and SBOMs are others.
The audit plane is what auditors and internal audit consume: a queryable evidence store (often a graph database like GUAC, or a compliance platform like Drata, Vanta, Sprinto, or Scrut) plus dashboards and exception workflows. The audit plane doesn’t generate evidence; it indexes, retains, and proves what the other planes emitted.
The discipline matters because each plane fails differently. A weak control plane lets non-compliant changes ship. A weak instrumentation plane misses real findings. A weak attestation plane produces evidence an auditor can’t trust. A weak audit plane has all the evidence but can’t surface it during fieldwork.
Mapping Controls to Evidence Types
The hardest part of an evidence pipeline isn’t building it — it’s mapping the controls your audit framework cares about to the evidence the pipeline can actually produce. SOC 2’s Common Criteria are written in the language of management commitments; pipeline output is written in the language of pipelineRunId and digest:sha256:.... Bridging the two is a translation exercise.
Internal audit should drive that mapping. The team that knows which controls matter for the SOC 2, ISO/IEC 27001:2022, PCI DSS 4.0.1, and (where applicable) FedRAMP Rev 5 scopes should sit with platform engineering and decide: for this control, what pipeline-emitted artifact is the evidence? CC8.1 (change management) maps cleanly to pull request records plus protected-branch settings plus signed deployment provenance. CC7.1 (vulnerability management) maps to scan attestations with severity thresholds and remediation timestamps. CC6.1 (logical access) maps to audit logs from the SCM and the CI/CD platform itself.
The mapping matters because once it’s settled, the audit conversation changes. The auditor asks for CC8.1 evidence; the audit plane returns every PR merged in the period, with reviewer identity, branch protection state at the time of merge, and the linked pipeline run with its provenance attestation. Sample sizes drop because the population is all changes, queryable. Sampling becomes a verification choice, not a logistical constraint.
Making the Evidence Trustworthy
Audit-grade evidence isn’t just collected — it’s non-repudiable. A pipeline log saying “scan passed” is worth nothing if the log can be edited, the artifact can be swapped post-build, or the build environment can be tampered with mid-run. SLSA, the Supply-chain Levels for Software Artifacts framework now at v1.0, defines a graded build track that addresses exactly this.
SLSA Build Level 1 requires that provenance is generated and made available. Level 2 demands that the provenance is signed, and that the signing happens in a way attackers can’t forge — Sigstore’s keyless signing with Fulcio-issued short-lived certificates and Rekor transparency log entries is a clean fit. Level 3 raises the bar to require that the build runs in an isolated environment the build system itself controls, so a malicious build script can’t tamper with the provenance generation. Higher levels add hermetic and reproducible builds.
For internal audit, the practical level question is which level do we need to defend a control assertion? For most SOC 2 scopes, signed provenance from a trusted builder (Level 2) is sufficient. For regulated financial workloads under DORA, or for software shipping into U.S. federal scopes governed by NIST SP 800-218 (the Secure Software Development Framework, SSDF), Level 3 is becoming the working assumption. GitHub Actions’ built-in artifact attestations (generally available since 2024) and Google Cloud Build both produce SLSA Level 3 provenance with no custom builder work.
The harder problem is the long tail: the bash steps in custom workflows, the in-house build agents, the vendor pipelines that don’t sign anything. Those gaps are where an evidence pipeline quietly degrades to a logging system, and where a thoughtful auditor will probe.
Where the Model Breaks Down
Evidence pipelines fail in predictable ways, and internal audit should know the failure modes before relying on the output.
The exception sprawl problem. Every real pipeline has waivers — “this CVE has no fix yet, accepting risk for 30 days.” Without time-boxed expiry, exceptions accumulate until the policy is theatrical. Mature platforms make exceptions first-class objects with required fields (justification, owner, expiry, compensating control) and a reporting view that internal audit can query directly. If your platform allows permanent exceptions, the policy is whatever the exceptions say it is.
The “scanner ran” trap. A SARIF file proves a scanner executed; it doesn’t prove the rules were appropriate, the codebase was fully covered, or the findings were triaged. Auditors have caught up to this. Expect questions about ruleset versioning, false-negative testing, and triage SLAs — not just whether the scan ran.
Trust in the build platform itself. Provenance is only as good as the platform generating it. If admins can edit pipeline definitions without review, push self-hosted runners with arbitrary code, or rotate signing keys without dual control, the cryptographic chain has a soft link. Audit the CI/CD platform’s own controls (RBAC, runner isolation, secret management, audit log integrity) with the same rigor applied to production.
Evidence retention windows. SOC 2 Type II covers a 6- to 12-month observation period; some standards require multi-year retention. Pipeline systems often default to 30- or 90-day log retention to manage cost. Without a deliberate retention policy that exports attestations to immutable storage (S3 Object Lock, Azure Immutable Blob, or a transparency log), you’ll arrive at audit time with a hole in the record.
The compliance-platform double-truth. Tools like Drata, Vanta, Sprinto, and Scrut centralize evidence beautifully — and in doing so, become a second source of truth that can drift from the pipeline. If the platform says a control passes because an integration scraped a config two weeks ago, but the live system has changed since, the platform is now misleading the auditor. Treat compliance platforms as indexers of pipeline-generated evidence, not as the evidence itself.
What Internal Audit Should Actually Test
The audit testing model changes when evidence is pipeline-generated. The questions to ask:
Can the policy be changed without review? Pull the Git history of the policy repository. If the answer is yes, every downstream attestation is suspect.
Can the pipeline be bypassed? Look for direct-push paths to protected branches, force-push permissions, deployment paths that don’t go through the standard pipeline (manual kubectl apply, ad-hoc Lambda updates, console deploys). One bypass path nullifies the population.
Are signing keys controlled? For non-Sigstore deployments, look at how signing keys are issued, rotated, and revoked. For Sigstore deployments, look at OIDC identity provider configuration — keyless signing trusts the IdP, so a compromised IdP issues valid signatures.
Is the evidence store immutable? The Rekor transparency log gives strong tamper-evidence by design. Internal evidence stores need explicit immutability (write-once buckets, append-only logs) or the chain is breakable.
Does the population reconcile? Pull the list of artifacts deployed to production from runtime (the cluster, the registry) and reconcile against the attestation store. Anything in production without a corresponding attestation is a finding — and is exactly the kind of thing screenshot audits never caught.
FAQ
Do we need SLSA Level 3 to satisfy SOC 2? No. SOC 2 doesn’t reference SLSA. But SLSA Level 2 — signed provenance from a hosted builder — is the cleanest way to produce evidence that survives auditor scrutiny of CC8.1 and CC7.1 controls without lengthy explanations of how your custom logging works.
How does this interact with PCI DSS 4.0.1? PCI DSS 4.0.1, with the future-dated v4.0 requirements now mandatory as of March 31, 2025, leans heavily on bespoke and custom software inventory (6.3.2), engineering training (6.2.2), and authenticated vulnerability scanning. Pipeline-generated SBOMs and signed scan attestations satisfy these cleanly when mapped explicitly.
What about AI-generated code? This is the open question. AI-assisted commits are still attributable to the human committer in current SCM models, so the change-management evidence chain holds. But review depth on AI-generated changes is a control quality question internal audit should be asking now, before frameworks formalize it.
Should internal audit own the policy code? No — engineering should own it. Internal audit should review it, test it, and validate that changes to it follow the same rigor as changes to production. Audit owning policy code creates the same conflict-of-duties problem as audit owning system administration.
The Shift Worth Making
The internal audit function that walks into 2027 with a screenshot-and-spreadsheet model is auditing a snapshot of a system that no longer holds still long enough to be photographed. The function that has co-built an evidence pipeline with its DevSecOps counterparts has something stronger: a continuous, queryable, cryptographically verifiable record of every change that touched production. The first version is rough. Mappings are imperfect. Exception workflows leak. But the trajectory — from periodic assertion to continuous proof — is the only one that scales with how software is now built.
Start with one control, one pipeline, one signed attestation. Map it end to end. Reconcile the evidence against production. The first time the audit conversation moves from “let me get back to you with the screenshots” to a query returning a signed JSON document in two seconds, the case for the rest of it makes itself.
