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
How Auditors Test These Controls in Practice
Mapping requirements to controls is only half the exercise. During fieldwork, auditors do not read policies in isolation — they test whether the mapped controls actually operate as described. Understanding their method helps compliance teams prepare the right evidence.
A typical assessment combines three techniques:
- Inquiry — interviewing pipeline owners and engineers to understand how a control is intended to work, then comparing that account against the documented policy.
- Inspection — examining configuration, RBAC matrices, gate definitions, and log samples to confirm the control exists as configured, not merely as written.
- Re-performance and sampling — selecting a sample of production releases from the review period and tracing each one from the originating change through review, security gates, approval, and deployment.
Because Article 21 demands an all-hazards approach, a single failed sample — a release that reached production without a passing security gate, or an approval granted by the change author — is often enough to raise a finding against the corresponding requirement. Preparing a small number of complete, traceable release examples in advance is one of the most effective ways to shorten an assessment.
Overlap with DORA, ISO 27001, and SOC 2
Most regulated entities are subject to more than one framework at once. The controls that satisfy Article 21 also address large parts of DORA, ISO 27001, and SOC 2 — meaning a single, well-evidenced CI/CD control environment can serve several obligations simultaneously. The mapping below highlights the strongest overlaps.
| NIS2 Article 21 theme | DORA | ISO 27001 (Annex A) | SOC 2 |
|---|---|---|---|
| Risk analysis & security policies (a) | ICT risk-management framework | A.5.1, A.5.9 | CC3.x |
| Incident handling (b) | ICT incident management & reporting | A.5.24–A.5.27 | CC7.x |
| Supply chain security (d) | Third-party ICT risk | A.5.19–A.5.23 | CC9.2 |
| Secure development & acquisition (e) | ICT change management | A.8.25–A.8.32 | CC8.1 |
| Access control & MFA (i, j) | ICT protection & prevention | A.5.15–A.5.18, A.8.5 | CC6.x |
For auditors, this overlap is an opportunity to reduce duplication: a single walkthrough of the pipeline can provide evidence against multiple frameworks. For compliance officers, it argues for maintaining one consolidated control set rather than parallel, framework-specific documentation.
Preparing an Article 21 Evidence Package
Rather than gathering evidence reactively, mature teams maintain a standing evidence package aligned to the ten Article 21 sub-requirements. At a minimum it should contain:
- The current pipeline security policy, with its approval and last-review dates
- The most recent CI/CD risk assessment and asset inventory
- RBAC matrices and the latest access review for pipeline tooling
- A sample SBOM, a signed-artifact record, and a dependency approval for a recent release
- Incident-response and business-continuity procedures that name the pipeline explicitly
- Two or three fully traceable release examples spanning code, review, gates, approval, and deployment
Keeping this package current turns each assessment from a fire drill into a straightforward walkthrough, and directly addresses requirement (f) — the obligation to assess the effectiveness of the measures themselves.
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.
