Why CI/CD Pipelines Fall Within ISO 27001 ISMS Scope
Continuous Integration and Continuous Delivery (CI/CD) pipelines are not merely engineering conveniences — they are information processing facilities that handle source code, credentials, cryptographic keys, and production deployment authority. Under ISO 27001, any system that processes, stores, or transmits information assets must fall within the scope of your Information Security Management System (ISMS).
For auditors and compliance officers, the critical question is not whether CI/CD pipelines are in scope, but whether the organisation has identified them as information assets, assessed associated risks, and applied appropriate Annex A controls. Failure to include CI/CD infrastructure in the ISMS scope is itself a non-conformity.
This article provides a comprehensive mapping of Annex A controls to CI/CD pipeline environments, with specific guidance on what evidence auditors should expect and what gaps commonly arise.
Comprehensive Annex A to CI/CD Mapping
The following table maps each relevant Annex A control domain to its CI/CD pipeline relevance, with specific evidence expectations for certification auditors.
| Annex A Control | Control Objective | CI/CD Relevance | Evidence for Auditors |
|---|---|---|---|
| A.5 — Information Security Policies | Management direction for information security | CI/CD pipelines must be governed by documented security policies that address automated build, test, and deployment processes | Approved CI/CD security policy; policy review records; management sign-off; policy communication evidence to pipeline administrators |
| A.6 — Organisation of Information Security | Internal organisation and mobile/teleworking | Roles and responsibilities for pipeline security must be defined — who owns pipeline configuration, who approves deployment rules, segregation of duties between development and release | RACI matrix for CI/CD operations; job descriptions referencing pipeline responsibilities; evidence of segregation between pipeline configuration and code authorship |
| A.8 — Asset Management | Responsibility for assets, information classification, media handling | Pipeline components (build servers, artifact repositories, secret vaults) are information assets that must be inventoried and classified | Asset register including CI/CD infrastructure; classification labels applied to pipeline artifacts; data handling procedures for build outputs |
| A.9 — Access Control ★ | Business requirements, user access management, system/application access | Pipeline access is a critical control point — who can modify pipeline definitions, trigger deployments, access secrets, or override quality gates | Access control policy covering CI/CD; user access reviews for pipeline platforms; evidence of least privilege; MFA enforcement records; privileged access logs for pipeline administration |
| A.10 — Cryptography | Cryptographic controls and key management | Pipelines handle signing keys, TLS certificates, encryption of secrets at rest and in transit, artifact signing | Key management procedures for pipeline secrets; encryption standards for secret storage; certificate management records; artifact signing verification procedures |
| A.12 — Operations Security ★ | Operational procedures, protection from malware, backup, logging, vulnerability management | Pipeline operations require change management, capacity planning, environment separation, comprehensive logging, and vulnerability scanning of pipeline infrastructure itself | Change management records for pipeline configuration; separation evidence between build/staging/production pipelines; pipeline execution logs with retention; vulnerability scan results for CI/CD platform; backup procedures for pipeline definitions |
| A.14 — System Acquisition, Development and Maintenance ★ | Security requirements, secure development, test data | The most directly relevant control domain — covers secure development lifecycle, change control procedures, security testing integration, and acceptance criteria enforced through pipelines | Secure development policy; pipeline-enforced change control evidence; automated security test results; acceptance gate configurations; code review records linked to pipeline triggers |
| A.15 — Supplier Relationships ★ | Information security in supplier relationships, service delivery management | CI/CD pipelines depend heavily on third-party components — plugins, base images, package registries, cloud-hosted CI services, and open-source dependencies | Supplier register including CI/CD service providers; third-party risk assessments for pipeline tools; SLAs for hosted CI/CD services; dependency provenance records; supply chain security policies |
| A.16 — Information Security Incident Management | Management of incidents and improvements | Pipeline compromises (secret leaks, supply chain attacks, unauthorised deployments) must be covered by incident management procedures | Incident response procedures covering CI/CD scenarios; evidence of pipeline-specific incident drills; post-incident review records; escalation paths for pipeline security events |
| A.18 — Compliance | Compliance with legal/contractual requirements, information security reviews | Pipeline configurations and deployment records serve as compliance evidence; pipelines themselves must comply with regulatory requirements | Compliance requirements register referencing CI/CD; audit trail of pipeline configurations; evidence of regular compliance reviews of pipeline operations; records of regulatory change impact assessments on pipelines |
★ Denotes the most critical control domains for CI/CD environments.
Critical Controls for CI/CD: A.9, A.12, A.14, A.15
A.9 — Access Control
Access control in CI/CD environments presents unique challenges that auditors focus on intensely. Pipelines often require broad access to deploy across environments, creating a tension between operational need and least privilege. Key areas of scrutiny include:
- Pipeline identity management — Are service accounts used by pipelines individually identifiable and subject to access reviews?
- Secret access scope — Can a pipeline job access only the secrets it needs, or does it inherit broad credential access?
- Human override controls — Who can bypass automated quality gates, and is this logged and reviewed?
- Separation of duties — Can the same person who writes code also approve and trigger its deployment to production?
A.12 — Operations Security
Operations security for CI/CD requires auditors to verify that pipeline infrastructure is treated with the same operational rigour as production systems. Common audit focus areas:
- Change management for pipeline definitions — Pipeline-as-code changes must go through formal change control
- Environment separation — Build, test, staging, and production pipelines must demonstrate logical or physical separation
- Logging completeness — Every pipeline execution, approval, override, and configuration change must be logged with immutable audit trails
- Vulnerability management — The CI/CD platform itself must be subject to vulnerability assessment and patching
A.14 — System Development and Maintenance
This is the cornerstone control domain for CI/CD. Auditors expect to see that the pipeline enforces the secure development lifecycle rather than merely documenting it. Evidence must demonstrate that security testing is automated and mandatory, that change control procedures cannot be circumvented, and that acceptance criteria are defined and enforced before production deployment.
A.15 — Supplier Relationships
Modern CI/CD pipelines have extensive supply chain dependencies. Auditors increasingly focus on whether organisations understand and manage the risk from third-party pipeline components, plugins, base images, and hosted services. A Software Bill of Materials (SBOM) and dependency provenance tracking are becoming baseline expectations.
What Certification Auditors Specifically Look For
During a Stage 2 certification audit, auditors examining CI/CD environments typically request:
- Documented scope — Explicit inclusion of CI/CD infrastructure in the ISMS scope statement
- Risk assessment coverage — CI/CD-specific risks identified in the risk register with treatment plans
- Policy alignment — Security policies that specifically address automated development and deployment processes
- Control implementation evidence — Not just that controls exist, but that they are effective and operating consistently
- Continuous improvement — Evidence that CI/CD security controls are reviewed and improved over time
- Competence records — Evidence that personnel managing pipeline security have appropriate training and awareness
Common Gaps in CI/CD Environments
Based on audit findings across organisations, the most frequently identified gaps include:
| Gap Area | Typical Finding | Risk Level |
|---|---|---|
| Pipeline not in asset register | CI/CD infrastructure absent from information asset inventory | High |
| No access reviews for pipelines | Service accounts and pipeline credentials never subject to periodic access review | High |
| Missing change control for pipeline config | Pipeline definitions modified without formal change management | High |
| Insufficient logging | Pipeline audit trails incomplete, mutable, or not retained per policy | High |
| Third-party risk not assessed | CI/CD plugins and services not included in supplier risk assessments | Medium |
| No incident scenarios for CI/CD | Incident response procedures do not cover pipeline compromise scenarios | Medium |
| Security testing optional | Quality gates can be bypassed without documented justification and approval | High |
| Secrets in pipeline logs | Sensitive values exposed in build logs without masking controls | Critical |
Next Steps
For a deeper understanding of ISO 27001 certification requirements for CI/CD environments, see our related resources:
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- Dual-Compliance Architecture
- Core CI/CD Security Controls
- How Auditors Review CI/CD
New to CI/CD auditing? Start with our Auditor’s Guide.
