ISO 27001:2022 reduced Annex A to 93 controls, and roughly a dozen of them — 8.25 through 8.32 plus 8.9, 8.19, and the supplier controls 5.19–5.23 — directly govern how your build pipeline is configured and evidenced. If you're preparing for certification or transitioning from the 2013 edition (the deadline is 31 October 2025), the engineering work concentrates in a surprisingly small set of clauses. This post maps each one to the specific pipeline artifact an auditor will ask to see.
How Annex A actually works
Annex A is not a checklist you must fully implement. Your risk assessment drives which controls apply, and the Statement of Applicability (SoA) documents each control as applicable or excluded, with justification. In practice, no auditor will accept excluding secure development controls from an organization that ships software — so treat 8.25–8.32 as mandatory in effect. The 2022 revision merged the old 14 domains into four themes (organizational, people, physical, technological); everything pipeline-relevant sits in the organizational (5.x) and technological (8.x) themes.
One structural note: the certification audit tests your ISMS clauses 4–10 and the Annex A controls your SoA declares. Stage 1 reviews documentation; Stage 2 samples operating evidence, much like a SOC 2 Type II window.
The secure development block: 8.25 to 8.31
This is the core cluster:
| Control | Title | Pipeline evidence |
|---|---|---|
| 8.25 | Secure development life cycle | SDLC policy, security gates defined per stage |
| 8.26 | Application security requirements | Security requirements in tickets/specs, threat models |
| 8.27 | Secure system architecture and engineering principles | Architecture review records, design docs |
| 8.28 | Secure coding | Linter/SAST configs, coding standard, review checklists |
| 8.29 | Security testing in development and acceptance | SAST/DAST/SCA reports per release, test gates in CI |
| 8.30 | Outsourced development | Contracts with security clauses, review of contractor code |
| 8.31 | Separation of development, test and production environments | Environment configs, IAM policies proving prod isolation |
For 8.29, the strongest evidence is a pipeline definition file — .github/workflows/ci.yml, .gitlab-ci.yml, Jenkinsfile — showing scanning stages that block on findings, plus retained reports. A stage that runs semgrep ci or an SCA scan and fails the build above a severity threshold is worth more than any policy paragraph, because it proves the control operates without human discipline.
For 8.31, auditors look for hard separation: developers should not hold standing write access to production. Show them the IAM policy diff between your dev and prod roles, or your break-glass procedure if emergency prod access exists.
Change management and configuration: 8.32 and 8.9
Control 8.32 (change management) is the pipeline control auditors sample hardest. Expect a request like "all production changes from the last quarter" followed by spot checks: was each change reviewed, tested, approved, and traceable to a requirement or ticket? Branch protection on your default branch — required reviews, required status checks, no force pushes — turns this from a documentation exercise into a query. git log --merges --since="3 months ago" cross-referenced with PR approvals is a complete population.
Control 8.9 (configuration management) covers the pipeline itself: who can edit workflow files, runner configurations, and deployment credentials. A common finding is CI secrets accessible to every repository contributor. Scope secrets to protected branches or environments, and document the runner hardening baseline (ephemeral runners, pinned action versions by SHA rather than tag — uses: actions/checkout@8f4b7f8 instead of @v4).
Supply chain controls: 5.19 to 5.23 and 8.19
The 2022 revision added 5.23 (cloud services security) and sharpened 5.21, "managing information security in the ICT supply chain." For a software organization, 5.21 reads as: know what components you ship, assess their risk, and monitor them. A generated SBOM per release — CycloneDX or SPDX out of a tool like SBOM Studio or syft — plus continuous vulnerability correlation covers the technical half. The organizational half is a documented process for evaluating new dependencies before adoption: license, maintenance status, known vulnerabilities.
Control 8.19 (installation of software on operational systems) extends this to deployment: only approved, tested artifacts reach production. Signed container images verified at admission (Cosign plus a policy controller) is the cleanest implementation and produces verifiable evidence by design.
Building the evidence trail without extra work
The pattern that survives audits: make the pipeline generate its own evidence. Retain CI logs and scan reports for at least the audit cycle (12 months is safe). Emit an SBOM and scan report as build artifacts on every release tag. Keep the SoA honest — if you claim DAST under 8.29 and only run it twice a year, say so, because the auditor will find the actual cadence anyway. Teams already doing SOC 2 can reuse most of this; the control mappings overlap heavily, and platforms like Safeguard export the same scan and remediation evidence against either framework.
Budget-wise, expect the certification audit itself to run 10–25 auditor-days for a mid-size org, with surveillance audits annually and recertification every three years. The engineering lift is front-loaded: once 8.29 and 8.32 are enforced in CI, they stay enforced.
Frequently asked questions
Which ISO 27001 controls apply to CI/CD pipelines?
The core set is Annex A 8.25–8.32 (secure development through change management), 8.9 (configuration management), 8.19 (software installation), and 5.21 (ICT supply chain). Your Statement of Applicability confirms the exact scope, but excluding these is rarely defensible for a software company.
Does ISO 27001 require an SBOM?
Not by name. But 5.21 and 8.29 require you to manage and test the components you ship, and an SBOM is the accepted mechanism for demonstrating component visibility. Regulations that reference ISO 27001, like the EU Cyber Resilience Act, do require SBOMs explicitly.
What changed for developers between ISO 27001:2013 and 2022?
The 2013 development controls (A.14 family) were consolidated and modernized into 8.25–8.31, and new controls were added for cloud services (5.23), configuration management (8.9), and data leakage prevention (8.12). Organizations certified under 2013 must transition by 31 October 2025.
Is ISO 27001 certification pass/fail?
Effectively yes, but nuanced: auditors raise nonconformities as minor or major. Minors need a corrective action plan; an unresolved major blocks or suspends certification. A handful of minors on a first Stage 2 audit is normal.