You have been handed a list of ISO 27001 Annex A controls and asked to prove them for the software-delivery side of the business. These are, in practice, the ISO 27001 CI/CD controls: the Annex A items your pipeline activity can actually evidence. The controls are not the problem: your team already reviews changes before they merge, runs security scans on every build, and records who deployed what. The problem is producing that as evidence an auditor accepts, indexed by control ID, dated, and covering the whole audit period rather than the changes you happen to remember.
The 2022 revision of ISO 27001 moved secure development from a footnote into a substantial block of Annex A, controls 8.25 through 8.34, alongside the change-management control 8.32 and the vulnerability and access controls that flank them. Your CI/CD pipeline already performs the activities those controls describe. The work of an ISO 27001 audit on the delivery side is mapping that pipeline activity to the specific control IDs, and being honest that the pipeline evidences a slice of the standard, the secure-development and change-management slice, not the whole of it.
This is the pipeline cut of CI/CD compliance, narrowed to one standard. The framing here is an evidence checklist: which Annex A controls a software-delivery audit touches, and what in the pipeline proves each one. The records that prove them are the subject of the CI/CD audit trail.
What changed in ISO 27001:2022
ISO 27001:2022 reorganised Annex A into 93 controls under four themes: organisational (clause 5), people (6), physical (7), and technological (8). For a delivery audit the technological theme is where most of the work lands, and the secure development cluster from 8.25 (Secure development life cycle) through 8.34 is new in substance compared with the 2013 version. If you last looked at ISO 27001 under the old structure, note that the 2013 "A.12 operations security" material now lives inside the clause 8 technological controls (logging at 8.15, monitoring at 8.16, capacity at 8.6), so a checklist written against the old numbering will not line up with what a 2022 auditor works from.
The practical consequence is that the pipeline is now squarely in scope. Controls that used to be satisfied with a policy document now expect operating evidence: that secure coding was applied, that testing ran, that changes were controlled, that vulnerabilities were managed. Operating evidence is exactly what a pipeline produces as it runs.
An ISO 27001 evidence checklist for your pipeline
The cleanest way to organise the mapping is by the families of pipeline activity an auditor probes: access, change management, segregation of duties, audit trail, and secure development. Each names a class of activity that maps to specific Annex A control IDs, and each has a corresponding piece of pipeline evidence.
Access (8.2, 8.4)
Who can write to source, trigger a deploy, or hold elevated pipeline permissions. Control 8.4 (Access to source code) expects write access to be controlled, which a protected-branch policy plus a record of force-push attempts evidences. Control 8.2 (Privileged access rights) covers the tokens and workflow permissions a deploy job runs with; least-privilege deploy and release tokens are the evidence. Common gap: a deploy workflow running with a broad, long-lived token nobody has reviewed.
Change management (8.32, 8.4)
Control 8.32 (Change management) is the one that maps almost directly onto pipeline activity: every change is reviewed, tested, and approved before it reaches production, and emergency changes follow a controlled path too. The evidence is the dated chain from commit through review to deploy. A skipped CI run on a production change, a hot-fix branch that bypasses the normal gates, or a force-push that rewrites protected history are each a change-management finding, and a force-push also implicates 8.4. Common gap: approvals recorded as chat messages rather than as workflow artefacts.
Segregation of duties (5.3)
Control 5.3 expects the person who writes a change not to be the only person who approves its deployment. The pipeline evidences this when the approver identity in the deploy record is distinct from the commit author, and an environment rule that blocks self-approval is the enforcing control. The presence of an independent reviewer is partial evidence here; rubber-stamped or self-approved deploys are the gap. Small teams hit this honestly, and the answer an auditor accepts is a documented, enforced rule rather than a claim that it never happens.
Audit trail (8.15, 8.16)
Controls 8.15 (Logging) and 8.16 (Monitoring activities) want the actions affecting production captured, retained for the period the framework requires, and queryable on request. The pipeline records most of this already through the provider audit log, the run history, and the deployment record. The question an auditor asks is whether the retention window is long enough and whether the trail can be produced indexed by control rather than chronologically. Common gap: workflow logs purged after the default retention window, with no off-provider copy.
Secure development (8.25, 8.28, 8.29, 8.8, 8.24, 5.17, 5.21)
The largest family, and the one the 2022 revision expanded. Each control has a pipeline activity that evidences it:
- 8.25 Secure development life cycle and 8.28 Secure coding: a required build and a defined test regime evidence a controlled SDLC; static analysis (SAST) and a security linter evidence secure coding.
- 8.29 Security testing in development and acceptance: the SAST step and the acceptance-test gate map here directly; disabled or flaky tests are an effectiveness gap in this control, not a separate concern.
- 8.8 Management of technical vulnerabilities: software composition analysis (SCA) that obtains and evaluates known CVEs in dependencies on every change.
- 8.24 Use of cryptography and 5.17 Authentication information: secret scanning that catches credentials and keys committed to source.
- 5.21 Managing information security in the ICT supply chain: dependency scanning and pinning third-party CI units to a fixed revision are partial evidence; the control is broader than any single scan.
What auditors actually check: evidence, not controls
Having the control is not the same as being able to prove it. An auditor checks that the control operated across the audit period, and wants that as structured, dated, control-ID-indexed evidence rather than a narrative of what the team usually does. For 8.32 that means an evidence row per production change: the commit, the reviewer and timestamp, the pipeline run, the destination environment, the outcome. For 8.29 it means the scan and test records for every change in the window, not a screenshot of the last green build.
The dominant pain teams report is reconstruction: rebuilding six or twelve months of evidence under deadline pressure because it was never captured in an auditable shape. Producing it continuously, as the pipeline runs, turns the audit request into a query. The control-ID index is what makes that query possible: the same deploy record evidences 8.32 for ISO 27001 and the equivalent change-management criterion for other frameworks, so the activity is recorded once and projected onto each control it supports.
What the pipeline does not cover
Honesty about scope is what keeps this credible with an auditor. The pipeline evidences the secure-development, change-management, vulnerability, testing, and capacity controls. It does not touch the organisational, people, and physical controls that make up most of clauses 5, 6, and 7: risk assessment, supplier relationships beyond the ICT supply chain, HR security, physical access. A tool that claims to prove ISO 27001 from the pipeline alone is overselling. Pipeline evidence is a slice, a strong and continuously produced slice, of a standard that is broader than software delivery.
Mapped against the four Annex A themes of the 2022 revision, the split is stark: the pipeline carries most of the technological theme, a handful of organisational controls, and none of the people or physical controls.
| Annex A theme (2022) | In pipeline scope | What the pipeline evidences, or why not |
|---|---|---|
| Organisational (clause 5) | Partial | A few controls only: 5.3 segregation of duties, 5.17 authentication information, 5.21 ICT supply chain, 5.32 intellectual property. Policies, risk assessment, and broader supplier management are out. |
| People (clause 6) | Out | Screening, awareness, and HR security have no pipeline signal. |
| Physical (clause 7) | Out | Secure areas and equipment have no pipeline signal. |
| Technological (clause 8) | Strong | The bulk of the evidence: 8.2, 8.4, 8.6, 8.8, 8.24, 8.25, 8.28, 8.29, 8.32, plus 8.15 logging and 8.16 monitoring at the product level. |
How CI/CD Watch maps findings to ISO 27001
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. For ISO 27001 specifically, each mapped finding now carries the Annex A control IDs it produces evidence toward, findings can be filtered by standard, and a per-standard coverage roll-up shows how many mapped checks are clear, with the scope caveat above stated rather than hidden.
Some pieces are deliberately not claimed yet. Compliance-specific checks (signed-artefact inventory, approver evidence on every deploy, secret-rotation cadence) and a dated PDF export for handing to an auditor are roadmap items, not shipped features. What ships today is the mapping of existing audit findings to ISO 27001 control IDs and the coverage roll-up. Read the audit documentation for what each pillar checks and how findings are classified, and the CI/CD for DevSecOps page for the security and compliance companion.
Map your pipeline to the ISO 27001 CI/CD controls
If an ISO 27001 audit is on your horizon, the fastest way to see where the delivery-side evidence stands is to run the audit against your own repositories. Connect a provider and the audit surfaces the secure-development, change-management, and vulnerability findings mapped to their Annex A control IDs, with the gaps called out before an auditor finds them. The Free tier covers pipeline-run monitoring; the audit and the standards mapping sit on the paid tiers, with the breakdown on the pricing page. For the wider framework this sits inside, the CI/CD compliance overview covers all five standards and the evidence-row model.
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.