ISO 27001 and CI/CD Security

ISO 27001: The Foundation Framework for Information Security in Software Delivery

ISO/IEC 27001 is the most widely adopted information security management system (ISMS) standard in the world. For organisations operating in regulated industries, ISO 27001 certification frequently serves as the baseline upon which additional compliance obligations — such as DORA, NIS2, SOC 2, or PCI DSS — are layered. When CI/CD pipelines form the backbone of software delivery, they fall squarely within the ISMS scope and must be governed with the same rigour as any other information processing facility.

This hub page provides a comprehensive guide to aligning CI/CD security controls with ISO 27001:2022 requirements, preparing for certification audits, and building an evidence base that satisfies external assessors.

ISO 27001:2022 Overview

ISO/IEC 27001:2022 specifies the requirements for establishing, implementing, maintaining, and continually improving an ISMS. The standard follows a risk-based approach: organisations identify information security risks, select appropriate controls to treat those risks, and demonstrate ongoing effectiveness through monitoring and measurement.

The standard consists of two core components:

  • Clauses 4–10 (Management System Requirements): These define the governance structure — context of the organisation, leadership commitment, planning, support, operation, performance evaluation, and improvement. They are mandatory for certification.
  • Annex A (Reference Controls): A catalogue of 93 controls organised into four themes — Organisational, People, Physical, and Technological. Organisations select applicable controls through a Statement of Applicability (SoA) based on their risk assessment.

Certification is granted by accredited certification bodies following a two-stage audit process, with ongoing surveillance audits and a full recertification cycle every three years.

Why CI/CD Is in Scope for the ISMS

CI/CD systems are not peripheral tooling — they are information processing facilities that directly handle some of the organisation’s most sensitive information assets. Pipelines process source code, manage credentials and secrets, produce and store build artifacts, orchestrate deployments to production environments, and generate operational data that constitutes evidence of control operation.

Under ISO 27001, any system that processes, stores, or transmits information assets within the defined ISMS scope must be subject to appropriate controls. CI/CD pipelines meet every element of this definition. Excluding them from scope would create an unacceptable gap in the ISMS, and experienced auditors will specifically examine whether delivery infrastructure has been appropriately addressed.

Furthermore, CI/CD pipelines represent a high-impact attack surface. A compromised pipeline can inject malicious code into production, exfiltrate secrets, or bypass every other security control in the organisation. The risk assessment process should recognise this and ensure proportionate controls are applied.

Key Annex A Controls for CI/CD Environments

The 2022 revision of Annex A restructured controls into four themes. The following controls are particularly relevant to CI/CD security and should be addressed explicitly in the Statement of Applicability.

A.5 — Organisational Controls

  • A.5.1 Policies for information security: The organisation must maintain a set of information security policies, approved by management, that cover CI/CD operations — including acceptable use, access control, change management, and secure development.
  • A.5.8 Information security in project management: Security requirements must be integrated into software delivery projects from inception, ensuring that pipeline security is designed in rather than bolted on.
  • A.5.19–A.5.23 Supplier relationships: Third-party CI/CD components — including SaaS pipeline platforms, shared runners, open-source dependencies, container base images, and external plugins — must be governed through supplier security policies, risk assessments, and ongoing monitoring. This includes maintaining a Software Bill of Materials (SBOM) and conducting Software Composition Analysis (SCA).

A.6 — People Controls

  • A.6.1 Screening: Personnel with access to CI/CD systems and production deployment credentials should be subject to appropriate background verification.
  • A.6.3 Information security awareness, education and training: Developers, DevOps engineers, and platform teams must receive role-specific security training covering secure coding practices, pipeline security, and the organisation’s ISMS requirements.

A.7 — Physical Controls

  • A.7.1–A.7.4 Physical security: Where self-hosted runners or build infrastructure exist on-premises, physical access controls must be documented and enforced. For cloud-hosted CI/CD, the organisation must verify that its provider maintains adequate physical controls (typically through supplier assurance).

A.8 — Technological Controls

This is the most extensive control area for CI/CD environments. Several controls introduced or restructured in the 2022 revision are directly applicable:

  • A.8.2 Privileged access rights: Pipeline service accounts, deployment credentials, and administrative access to CI/CD platforms must follow the principle of least privilege, with regular access reviews.
  • A.8.4 Access to source code: Source code repositories must be protected with appropriate access controls, branch protection rules, and audit logging.
  • A.8.9 Configuration management: Pipeline configurations, infrastructure-as-code definitions, and environment settings must be managed through version control with change tracking and approval workflows.
  • A.8.15 Logging: All CI/CD activities — builds, tests, deployments, access changes, configuration modifications — must be logged with sufficient detail and retained according to the ISMS retention policy.
  • A.8.16 Monitoring activities: CI/CD systems must be monitored for anomalous behaviour, unauthorised changes, and security events, with alerts directed to appropriate personnel.
  • A.8.25 Secure development life cycle: The organisation must define and apply a secure development life cycle that integrates security activities — threat modelling, security requirements, secure design review, security testing — into the CI/CD workflow.
  • A.8.28 Secure coding: Secure coding practices must be established, including code review requirements, use of approved libraries, and automated enforcement through pipeline gates.
  • A.8.29 Security testing in development and acceptance: SAST, DAST, SCA, and other security testing must be integrated into pipelines with defined pass/fail criteria and evidence of remediation.
  • A.8.31 Separation of development, test and production environments: Environments must be properly segregated with distinct access controls, separate credentials, and controlled promotion processes between stages.
  • A.8.32 Change management: All changes to pipeline configurations, deployment processes, and production systems must follow a documented change management process with appropriate approvals and rollback capability.

The Certification Audit Process

ISO 27001 certification involves a structured two-stage initial audit, followed by ongoing surveillance and recertification:

Stage 1 — Documentation Review

The certification body reviews the ISMS documentation for completeness and conformity. For CI/CD environments, auditors will examine whether pipeline systems are included in the scope statement, whether the risk assessment covers software delivery threats, and whether the Statement of Applicability addresses the relevant Annex A controls. They will also review policies covering secure development, change management, access control, and supplier management as they relate to the delivery pipeline.

Stage 2 — Evidence and Effectiveness

The auditor verifies that documented controls are implemented and operating effectively. For CI/CD, this means demonstrating that pipeline configurations enforce stated policies, that logs provide evidence of control operation, that access reviews have been conducted, and that security testing results show active vulnerability management. Auditors may request live demonstrations, sample pipeline execution logs, access review records, and incident response evidence.

Surveillance Audits

Conducted annually between certification cycles, surveillance audits sample specific controls to verify continued conformity. Auditors may focus on areas where nonconformities were previously identified, or on controls that are particularly relevant to the organisation’s risk profile — including CI/CD controls if the software delivery environment is a significant part of the ISMS scope.

Recertification

Every three years, a full recertification audit is conducted. This is essentially a repeat of the Stage 1 and Stage 2 process and provides an opportunity to demonstrate that the ISMS has matured, that lessons from previous audits have been incorporated, and that controls remain effective as the CI/CD environment evolves.

What Auditors Look for in CI/CD Environments

Experienced ISO 27001 auditors assessing CI/CD environments focus on four key areas:

  1. Documented policies: Written policies and procedures that specifically address CI/CD security — not generic IT policies that fail to mention software delivery infrastructure.
  2. Enforced controls: Technical evidence that policies are enforced — branch protection rules that prevent unapproved merges, pipeline gates that block deployments without security testing, access controls that restrict production deployment to authorised personnel.
  3. Evidence of effectiveness: System-generated logs and reports demonstrating that controls operate consistently — not just that they were configured once. Auditors look for pipeline execution histories, access review records, vulnerability remediation timelines, and incident response documentation.
  4. Continuous improvement: Evidence that the organisation reviews control effectiveness, learns from incidents and near-misses, updates the risk assessment as the CI/CD environment changes, and implements improvements through the Plan-Do-Check-Act cycle.

Common Non-Conformities in CI/CD Assessments

The following non-conformities are frequently identified during ISO 27001 audits of organisations with CI/CD pipelines:

  • Lack of change management evidence: Pipeline changes are made without documented approval workflows, or approval evidence exists only in email threads rather than system-enforced records.
  • Insufficient access reviews: Access to CI/CD platforms, deployment credentials, and secrets management systems is not reviewed periodically, resulting in privilege accumulation and orphaned accounts.
  • No security testing integration: Despite policies requiring security testing, SAST/DAST/SCA tools are not integrated into pipelines, or their results are not acted upon with defined remediation timelines.
  • Poor supplier management: Third-party CI/CD components — plugins, container images, SaaS platforms — are adopted without supplier risk assessments or ongoing monitoring.
  • Environment bleed: Development, testing, and production environments share credentials, service accounts, or infrastructure without proper segregation.
  • Incomplete logging: Pipeline activities are logged inconsistently, log retention does not meet the ISMS policy, or logs lack sufficient detail for forensic analysis.
  • Missing risk treatment: CI/CD-specific risks (supply chain attacks, pipeline compromise, secrets leakage) are not identified in the risk register or lack defined treatment plans.

Deep Dive Articles

Explore detailed guidance on specific aspects of ISO 27001 compliance in CI/CD environments:

Related Content

Cross-Framework References

ISO 27001 controls frequently overlap with requirements from other regulatory frameworks. Organisations pursuing multiple certifications can leverage a unified control set: