The evidence request lands six weeks before the SOC 2 window closes. The auditor wants, for a sample of production deployments, proof that each change was tested, authorised, and controlled on its way out, and traceable back to the commit that made it. Your pipeline did all of that automatically, on every commit to trunk. The problem is producing the SOC 2 CI/CD evidence: the gate results are in run logs, the deploy records are spread across providers, and none of it is indexed by SOC 2 control. So an engineer spends a fortnight taking screenshots of Jira tickets and pasting them into a spreadsheet.
SOC 2 CI/CD evidence already exists in your pipeline: the change-management, access, and operations records an auditor asks for. A SOC 2 audit, especially a Type 2, is not about installing new processes; it is about producing that evidence continuously, indexed to the trust services criteria, instead of reconstructing it under deadline. This is the pipeline cut of CI/CD compliance, narrowed to one framework: which SOC 2 criteria a delivery pipeline evidences, what an auditor actually asks for, and how the pipeline produces it as a side effect of running.
What SOC 2 asks of your pipeline
SOC 2 reports against the AICPA trust services criteria, and the bulk of them sit in the common criteria, CC1 through CC9. Most of those criteria have nothing to do with software delivery: they cover the control environment, risk assessment, vendor management, and business continuity. Three families are where the pipeline carries the evidence directly:
- CC8, change management. Changes to production are authorised, designed, tested, approved, and implemented in a controlled way. This is the criterion the pipeline evidences most strongly.
- CC6, logical access. Access to production and to the deployment machinery is restricted to the people and services that need it, and credentials are managed.
- CC7, system operations. Deployments and system changes are monitored, and failures or anomalies are detected and responded to.
Be honest with yourself about scope. The pipeline covers the change-management, access-to-production, and operations slice of SOC 2 strongly; it does not cover vendor risk, HR onboarding, or incident-response policy. Those need other tooling. The value of the pipeline angle is that the change-management evidence, which is the part auditors probe hardest for an engineering organisation, becomes continuous rather than reconstructed.
The three criteria the pipeline evidences
Each criterion needs the same shape of proof: an evidence row that is dated, attributable to a person or service, and queryable across the whole audit period. Here is what the pipeline already records against each.
CC8.1: change management as automated pipeline controls
The classic SOC 2 change-management evidence is a change ticket with a manual approval on it. A continuous-delivery pipeline produces something stronger and automatic: every commit to trunk passes a defined set of gates before it can reach production, the test suite, the security and dependency scans, and any policy-as-code checks, and each gate is recorded against the commit and the deployment run it fed. The control is the automated gate that no change can bypass, operating on every commit rather than a human sign-off applied after the fact or a policy asserted once a year. Where a deployment step requires an explicit approval, it is codified in the pipeline and recorded there, not screenshotted from a ticket board. The evidence an auditor accepts for CC8 is that gate record, dated and linked to the change that passed it.
CC6.1: logical access to production and deploy credentials
For CC6 an auditor wants to know who can deploy to production and how that access is controlled. The pipeline evidences it through the deployment environment's protection rules, the list of principals allowed to trigger a production deploy, and the rotation record for the secrets and deploy keys the pipeline uses. Least privilege on a deploy credential, and a dated record of when it was last rotated, is exactly the kind of operating evidence a Type 2 report is built on.
CC7.1: operations monitoring on every deployment
CC7 covers detecting and responding to problems. A pipeline that records every run, flags failed and anomalous deployments, and shows how quickly a failure was recovered is producing operations evidence continuously. The auditor is not asking whether you have a monitoring tool; they are asking for evidence that monitoring operated across the period and that detected issues were handled. The run history carries that.
Type 2 is the hard part: continuous, not point-in-time
A SOC 2 Type 1 report describes whether controls are designed correctly at a moment in time. A Type 2 report, the one customers actually ask your sales team for, covers whether the controls operated effectively across a period, often six to twelve months. That distinction is the whole game. An auditor testing Type 2 pulls a sample of changes from across the period and asks for the evidence on each one. If your change-management evidence lives as screenshots taken the week before the audit, you cannot produce it for a deploy from eight months ago, and the gap shows.
A pipeline that records the gates, the checks, and the deploy on every commit has the sample covered before the auditor picks it, because the evidence was captured automatically when the change shipped rather than assembled afterwards. Continuous evidence is not a nice-to-have for Type 2; it is the difference between passing on the record you already have and a fortnight of reconstruction.
What auditors request, and the screenshot trap
The evidence request, sometimes called the PBC list, is usually specific: for a named sample of production changes, show the gates that ran, the testing, and the authorisation to deploy; for logical access, show who had production access during the period and evidence of periodic review. The instinct is to reach for volume: export every log and point the auditor at the bucket. That fails both ways. The auditor cannot find the specific approval for the change they sampled, and raw logs rarely carry the attribution the criterion needs.
The evidence that works is small and structured: a handful of rows per sampled change, each dated, attributable, and linked to the deploy it authorised. That is the same evidence-row discipline a good CI/CD audit trail is built on, and it is why the pipeline record beats the screenshot: the pipeline captured who did what, when, and against which commit, without anyone having to remember to. SOC 2 is one framework cutting through that evidence; the related ISO 27001 CI/CD controls cut through much of the same pipeline activity at a different angle.
How CI/CD Watch surfaces SOC 2 CI/CD evidence
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, runs an audit across tests, lint, supply chain, workflow efficiency, flaky-test handling, process hygiene, and cost. Each finding is structured, dated, and carries a rule ID, a repository, a workflow reference, and a state. That is the raw material SOC 2 evidence is made from: the change-management, access, and operations signals captured as they happen rather than reconstructed at audit time.
Be clear about what ships today and what does not. The audit and its structured findings are live, and mapping findings to ISO 27001 Annex A control IDs with a per-standard coverage roll-up ships now. The equivalent SOC 2 mapping, tagging each finding to CC6, CC7, and CC8 criteria, and a dated export to hand an auditor, are roadmap items rather than shipped features. What you can do today is run the audit to see where your delivery-side evidence stands and where the gaps are. Read the audit documentation for what each pillar checks, and the CI/CD for DevSecOps page for the security and compliance companion.
See where your SOC 2 evidence stands
If a SOC 2 audit is on your horizon, the fastest way to see whether the change-management and access evidence is there is to look at the pipeline before the auditor does. Connect a provider and the audit surfaces the process-hygiene, supply-chain, and workflow findings that underpin CC6, CC7, and CC8, with the gaps called out early. The Free tier covers pipeline-run monitoring; the audit sits on the paid tiers, with the breakdown on the pricing page. For the full framework and the evidence-row model, the CI/CD compliance overview covers all five standards.
CI/CD Watch is built by 3CS Technologies Ltd. It started as an internal tool for tracking pipeline health across a mixed GitHub Actions and Jenkins estate. The same engine now powers the SaaS platform.