CI/CD compliance

A team is six weeks out from its first SOC 2 audit. The engineering manager has been asked for evidence that every production deploy in the last 90 days had a reviewer recorded, that no secrets are in source control, that the test suite ran on every change. The data exists; it is scattered across GitHub Audit Log, the CI provider's run history, the artefact registry, the secret-scanner output. None of it is indexed by SOC 2 control ID. The week before fieldwork starts the team is writing scripts to reconstruct trails the pipeline already recorded.

That gap is the CI/CD compliance problem. The pipeline produces audit evidence as a side effect of running. The effort sits in capturing it in a shape an auditor accepts: dated, structured, queryable, indexed against the control framework the audit is run against. What follows covers the five families of pipeline-relevant controls, what an evidence row looks like, how the major standards cut through pipeline activity, and where the discipline sits alongside the related cluster topics.

The compliance question CI/CD answers

CI/CD compliance asks whether the pipeline's activity can be produced as audit evidence against a recognised control framework. The pipeline records change approvals, build artefacts, test results, deployment outcomes, and access events as a side effect of running. The gap most teams hit is not capture; it is structure, retention, and indexing against the control IDs an auditor requires.

Two trends turned this from a niche concern into a cross-industry one. The first is the depth of pipeline integration in modern compliance frameworks. PCI-DSS v4.0 (effective March 2025) added prescriptive requirements under Req 6 (secure software) and Req 11 (testing) that read like a pipeline checklist. ISO 27001:2022 expanded Annex A to include secure development controls A.8.25 through A.8.34. NIST SP 800-218, the Secure Software Development Framework, is now a US federal procurement requirement. Compliance frameworks have caught up with how software is actually built.

The second is the shift in audit posture from reconstructed evidence to continuous evidence. A SOC 2 Type 2 audit covers a period (typically six to twelve months) and asks for evidence across that period, not a point-in-time sample. Reconstructing six months of change-management evidence under audit deadline pressure is the dominant pain teams report. Producing it continuously, as the pipeline runs, removes the deadline.

That continuous-evidence posture is what governance-and-risk (GRC) platforms have monetised over the last five years. The CI/CD-anchored version of the same idea is different in shape: instead of a workflow tool that orchestrates evidence collection from many sources, the pipeline produces the evidence as one of its outputs, in a shape downstream tools can consume.

Five families of pipeline-relevant controls

Mapping pipeline activity to control IDs is easier with a working taxonomy. Five families cover most of what auditors check on the software-delivery side: access, change management, segregation of duties, audit trail, and secure development. Each names a class of pipeline activity that maps to specific control IDs across the standards.

Access.Who can land changes on main, trigger a deploy, read a secret, or read pipeline logs. The pipeline records the identity behind every integration, every deploy, and every workflow_run via the provider's audit log. The control evidence is the record itself plus the access policy at the time the action ran. Common gaps: stale admin accounts on the CI provider, service accounts without ownership records, personal access tokens with no rotation schedule.

Change management. Every code change is reviewed before integration; every production change has an approver recorded. The pipeline records the commit SHA, the reviewer (where review is enforced), the workflow that ran, and the destination environment. The control evidence is the dated chain from commit through to deploy with the reviewer captured. Common gaps: hot-fix branches that bypass review, deploy paths outside the standard pipeline, approvals recorded as Slack messages rather than as workflow artefacts.

Segregation of duties. The actor who writes the code is not the actor who approves the deployment of the code. The pipeline can enforce this structurally (deploy workflows that require an environment approver, environment rules that block self-approval) and record it (the approver identity is distinct from the commit author in the audit log). Common gaps: solo engineers shipping their own changes to production, sole admin who can approve any deployment, emergency break-glass procedures with no follow-up review.

Audit trail. Every action that affects production is captured immutably, retained for the period the framework requires, and queryable when an auditor asks. The pipeline already records most of what is needed; the auditing-of-the-audit-trail question is whether the retention window matches the framework (SOC 2 typically wants 12 months, PCI-DSS wants 12, ISO 27001 wants longer for some controls). Common gaps: workflow logs purged after 30 days on the default GitHub plan, no off-provider backup, no tamper-evidence on the trail itself.

Secure development. The pipeline runs the controls that produce software meeting security expectations: lint, static analysis (SAST), software composition analysis (SCA), secret scanning, container image scanning, dependency pinning. Each control fires on every change and produces a structured finding. The control evidence is the run record plus the finding shape. Common gaps: controls present but with failing gates disabled because they blocked too often, findings that fire but have no triage owner, scan output that lives in workflow logs rather than as structured exports (SARIF, CycloneDX).

What an evidence row looks like

An evidence row maps one pipeline activity to one control ID with the fields an auditor accepts. For a SOC 2 CC8.1 change-management row, that means the commit SHA, the approver identity and timestamp, the pipeline run ID, the destination environment, and the deployment outcome. Five evidence row shapes cover most pipeline-relevant audit requests across the major standards.

The shape of the evidence row matters more than its format. An auditor accepts a CSV with the right columns; they accept a JSON export; they accept a dashboard view that produces the same data on demand. What an auditor does not accept is reconstructed evidence from screenshots, narrative summaries of what the team usually does, or partial records that cover only the changes the team remembers.

The control-ID column is what turns a pipeline activity record into compliance evidence. The same pipeline run record contributes to several control IDs: a deploy workflow with a recorded approver evidences CC8.1 (change management) for SOC 2, A.8.32 (change management) for ISO 27001, Req 6.5 (test before release) for PCI-DSS, and so on. The pipeline produces the activity; the compliance layer projects each activity row onto the control IDs it evidences.

The continuous-evidence posture means this projection runs as the pipeline runs, not as the audit approaches. When an auditor asks “show me the change-management records for production deploys in Q2”, the answer is a query against indexed data, not a fortnight of reconstruction.

The pipeline cuts of each standard

Each standard touches CI/CD at different points. ISO 27001:2022 Annex A puts secure development and operations in scope (A.8.25 to A.8.34, A.12). SOC 2 trust services criteria target access, change management, and operations (CC6, CC7, CC8). ISO 42001 governs AI-assisted development specifically. NIST SP 800-218 (the Secure Software Development Framework) and PCI-DSS v4.0 prescribe pipeline practices directly. Five different cuts of the same pipeline activity.

ISO 27001:2022. The 2022 revision moved secure development from a minor reference to a substantial Annex A section. The cluster from A.8.25 (Secure development life cycle) onwards covers the activities a pipeline already performs: development life cycle controls, change management (A.8.32), and the secure coding and testing practices that flank them. The full cluster walkthrough lives in the spoke.

SOC 2. The trust services criteria with the strongest pipeline mapping are CC6 (logical and physical access), CC7 (system operations), and CC8 (change management). CC8.1 in particular maps almost one-to-one to change-management pipeline activity: every change is authorised, documented, tested, and approved before promotion. The auditor wants evidence the controls operated effectively across the audit period.

ISO 42001:2023. The AI management system standard, published October 2023. The pipeline-relevant clauses cover AI system lifecycle governance, change controls on AI-assisted code, and audit-trail requirements for AI-generated artefacts. Strong cross-cut with the AI-assisted development cluster: the same DORA-amplification thesis that argues AI quality tracks pipeline quality is what ISO 42001 is asking organisations to govern.

NIST SP 800-218 (SSDF). Four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). The strongest pipeline overlaps: PS.2 on software release integrity, PW.4 on reuse of well-secured components, PW.7 on human-readable code analysis, and RV.1 on ongoing vulnerability identification. The SSDF is voluntary but referenced by US federal procurement guidance under Executive Order 14028 and the OMB self-attestation memorandum (M-22-18, later extended by M-23-16).

PCI-DSS v4.0. Published in March 2022, with the deadline for full compliance with all new v4.0 requirements set to 31 March 2025. Made the secure software requirements (Req 6) and the testing requirements (Req 11) more prescriptive than v3.2.1, particularly around code-review evidence, change-management controls, and continuous vulnerability identification. For fintech and payment-handling teams these are baseline.

Compliance as code

Compliance as code is the discipline of producing structured, queryable, continuously updated audit evidence as a side effect of running the pipeline. Instead of capturing evidence after an audit request lands, the pipeline emits findings in open formats (SARIF for security, CycloneDX for software bills of materials, in-toto attestations for artefact provenance) that downstream tooling can consume directly.

The practice borrows from infrastructure as code and policy as code: instead of describing intent in prose and hoping the team enforces it, the rule is expressed in a file the pipeline reads and acts on. For compliance the rule is “every production deploy has an approver recorded”; the policy is the pipeline configuration that enforces it; the evidence is the audit-log record of the policy operating on each deploy.

The win is in the structure. A SARIF-formatted security finding has a defined schema with severity, location, rule ID, and remediation pointer. A workflow log entry that says “security scan: 3 issues” does not. The downstream compliance layer can query the SARIF archive by control ID, by date range, by repository, by rule. It cannot query the log entry the same way.

Auditor-ready CI/CD

Auditor-ready CI/CD means producing the day-one artefacts an audit asks for without scrambling. Signed build artefacts, approver records on every production deploy, secret-rotation evidence within policy, structured findings export, change-failure-rate trend, deploy-frequency report. Each is something the pipeline already produces or can produce with a one-line configuration change in the workflow file.

The cost of not being auditor-ready is borne in the fortnight before fieldwork. Engineers stop shipping to hunt for evidence. The compliance lead writes narrative answers in place of artefacts. The audit produces recommendations that boil down to “capture this evidence continuously next time”, and the cycle repeats. Being auditor-ready collapses that fortnight into a query.

Day-one artefacts vary by standard but converge on a short list: a signed-artefacts inventory (proves Req 6.4.6 for PCI-DSS, PW.7 for SSDF), an approver chain on every production deploy in the audit window (CC8.1 for SOC 2, A.8.32 for ISO 27001), a secret-rotation policy and evidence of its operation (CC6 for SOC 2), a security-finding export by rule and date (PW.4 for SSDF, Req 6.3 for PCI-DSS), and a DORA-metrics report demonstrating recovery time and change-failure rate (CC7 for SOC 2, indirectly across all five standards).

Where CI/CD Watch fits

CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, surfaces the audit findings, DORA metrics, and pipeline health signals that compose into compliance evidence. The audit feature runs checks across tests, lint, supply chain, workflow efficiency, flaky-test handling, process hygiene, and cost waste. Each finding is structured, dated, and queryable.

The shape matches what compliance evidence wants: every audit finding has a rule ID, a repository, a workflow reference, a timestamp, and a state (gaps, clear, dismissed). The audit run record is itself an audit artefact: the date the check ran, the pipeline state at the time, the rules that fired and passed. Each finding now carries the control IDs it produces evidence toward for ISO 27001 and NIST SSDF, findings can be filtered by standard, and a per-standard coverage roll-up shows how many mapped checks are clear. Scope-conditional standards (ISO 42001, PCI-DSS), dated PDF report export, and compliance-specific rules (signed artefacts, approver evidence, secret rotation cadence) are roadmap items.

Read the audit docs for the canonical reference on what each pillar checks, how findings are classified, and how the evidence the audit produces composes against the five control families. See pricing for what each plan tier unlocks.

FAQ

Read on

The five families of pipeline-relevant controls, the evidence-row shape, the standards-by-standards cut, and the auditor-ready checklist all compose into a single continuous-evidence posture: the pipeline produces audit evidence as a side effect of running, and the compliance layer projects that evidence onto the control IDs the framework cares about.

For the canonical product reference on the audit feature CI/CD Watch ships today, read the audit docs. For the buyer-facing companion aimed at security and compliance teams, read the CI/CD for DevSecOps page. For related reference topics, the related-topics grid below covers the canonical reference pillars in the other clusters.