Overview: NIS2 Article 21 and Cybersecurity Risk-Management Measures
NIS2 Directive Article 21 establishes the baseline cybersecurity risk-management measures that essential and important entities must implement. For organisations relying on CI/CD pipelines to deliver software, these requirements translate directly into pipeline governance controls that auditors and compliance officers must evaluate.
Article 21 mandates an all-hazards approach — meaning controls must address risks across the entire software delivery lifecycle, not just production infrastructure. This includes build environments, deployment automation, artifact management, and change approval workflows.
The table below maps each Article 21 requirement to the corresponding CI/CD controls and the evidence auditors should request during assessments.
Article 21 Requirements Mapped to CI/CD Controls
| NIS2 Article 21 Requirement | CI/CD Control | Evidence for Auditors |
|---|---|---|
| Art. 21(2)(a) — Risk analysis and information system security policies | Documented pipeline security policy covering build, test, and deployment stages; periodic risk assessments of CI/CD infrastructure | Approved policy documents with version history; risk assessment reports referencing CI/CD assets; management sign-off records |
| Art. 21(2)(b) — Incident handling | Pipeline incident response procedures; automated alerting on build/deployment failures; rollback mechanisms | Incident response playbooks specific to pipeline failures; alert configuration records; incident logs showing detection-to-resolution timelines |
| Art. 21(2)(c) — Business continuity and crisis management | Pipeline redundancy and disaster recovery plans; backup of pipeline configurations and secrets; recovery time objectives for build infrastructure | Business continuity plans covering CI/CD systems; documented recovery procedures; test results from DR exercises; backup verification logs |
| Art. 21(2)(d) — Supply chain security | Dependency governance policies; approved registries and base image catalogues; vendor assessments for CI/CD tooling providers; Software Bill of Materials (SBOM) generation | Approved dependency lists; SBOM records per release; vendor risk assessment reports; third-party component approval workflows |
| Art. 21(2)(e) — Security in network and information systems acquisition, development, and maintenance | Secure pipeline configuration standards; environment separation (dev/staging/production); automated security scanning gates | Pipeline configuration baselines; environment architecture documentation; scan gate policies and pass/fail records |
| Art. 21(2)(f) — Policies and procedures to assess the effectiveness of cybersecurity risk-management measures | Pipeline security metrics and KPIs; periodic pipeline audits; control effectiveness reviews | Dashboard reports on security gate pass rates; audit findings and remediation tracking; management review minutes |
| Art. 21(2)(g) — Basic cyber hygiene practices and cybersecurity training | Developer training on secure pipeline usage; documented onboarding procedures for pipeline access | Training completion records; onboarding checklists; awareness programme materials referencing CI/CD security |
| Art. 21(2)(h) — Policies and procedures regarding the use of cryptography and encryption | Secrets management policies; encryption of artifacts in transit and at rest; code signing requirements | Secrets management tool configuration attestations; encryption policies; signed artifact verification records; certificate management logs |
| Art. 21(2)(i) — Human resources security, access control policies, and asset management | Role-based access control (RBAC) for pipeline systems; pipeline asset inventory; joiner/mover/leaver processes for CI/CD access | RBAC matrices for pipeline tools; access review logs; asset registers listing CI/CD components; access provisioning and de-provisioning records |
| Art. 21(2)(j) — Use of multi-factor authentication (MFA) and secured communication | MFA enforcement on all pipeline administration interfaces; encrypted communication channels between pipeline components | MFA enforcement configuration attestations; authentication logs showing MFA usage; TLS/mTLS configuration evidence for inter-component communication |
What Auditors Should Verify
Policy and Governance Layer
- Policy existence and currency: Confirm that pipeline security policies exist, are approved by appropriate management, and have been reviewed within the last 12 months.
- Scope adequacy: Verify that policies explicitly cover CI/CD infrastructure, not just production systems. Many organisations overlook build environments in their security frameworks.
- Risk assessment coverage: Check that the organisation’s risk register includes CI/CD-specific risks such as pipeline tampering, secret leakage, and dependency poisoning.
Control Implementation Layer
- Segregation of duties: Verify that the person who writes code cannot also approve and deploy it without independent review.
- Change traceability: Confirm that every production deployment can be traced back to an approved change request, code review, and successful security scan.
- Access controls: Request evidence of periodic access reviews for pipeline administration tools. Look for dormant accounts and excessive privileges.
- Secrets management: Confirm secrets are not hardcoded in pipeline configurations. Request attestation from secrets management tooling.
Evidence and Monitoring Layer
- Log completeness: Verify that pipeline logs capture who triggered a deployment, what was deployed, when it was deployed, and whether all required gates passed.
- Retention periods: Confirm log retention meets both NIS2 requirements and the organisation’s own policy (typically a minimum of 12–24 months).
- Tamper protection: Check whether pipeline logs are stored in append-only or immutable storage to prevent post-incident manipulation.
Red Flags to Watch For
- Pipeline security policies that simply reference general IT policies without CI/CD-specific controls
- No evidence of periodic access reviews for pipeline tools
- Deployments that bypass required approval gates (look for override or emergency deployment records without post-hoc justification)
- Secrets visible in pipeline logs or configuration files
- No documented supply chain governance for third-party dependencies
Related Resources
For a deeper understanding of how NIS2 security architecture principles apply to CI/CD environments, see NIS2 Security Architecture Explained.
For the full NIS2 compliance resource library, visit our NIS2 Compliance Hub.
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- DORA Article 21 Deep Dive
- NIS2 vs DORA Comparison
- Audit Readiness Checklist
New to CI/CD auditing? Start with our Auditor’s Guide.
