Introduction: Risk Management as a Legal Obligation Under NIS2
Article 21(1) of the NIS2 Directive (Directive 2022/2555) requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage the risks posed to the security of network and information systems. This is not a suggestion — it is a binding obligation with supervisory enforcement.
For organisations that develop and deliver software, this obligation extends directly into the software delivery pipeline. CI/CD environments are network and information systems under NIS2. They process, store, and transmit code, credentials, configurations, and deployment artifacts that directly affect the security posture of the services your organisation provides.
This post provides compliance officers and auditors with a structured framework for understanding how NIS2 risk management applies to software delivery, what controls should be in place, and what evidence to look for during assessments.
How NIS2 Risk Management Applies to Software Delivery
Many organisations treat software delivery pipelines as purely engineering concerns. Under NIS2, this is insufficient. The directive requires an all-hazards approach to risk management, meaning every system that could affect the security of your services must be covered — including the systems that build and deploy your software.
Software delivery processes present specific risk characteristics that demand dedicated attention:
- High privilege concentration: Pipelines typically hold credentials with production-level access, making them high-value targets.
- Complex supply chains: Modern delivery depends on third-party dependencies, container images, and external services — each introducing supply chain risk.
- Rapid change velocity: Frequent deployments increase the attack surface window and the probability of misconfiguration.
- Cross-environment reach: A compromised pipeline can affect development, staging, and production simultaneously.
Compliance officers should ensure that risk assessments explicitly include software delivery systems in their scope, not merely the applications those systems produce.
Risk Assessment Framework for CI/CD Environments
A compliant risk assessment for software delivery should follow a structured methodology with three phases: identification, analysis, and treatment.
Phase 1: Risk Identification
Catalogue all assets within the software delivery environment, including pipeline infrastructure, source code repositories, artifact stores, secrets management systems, deployment targets, and third-party integrations. For each asset, identify potential threats and vulnerabilities specific to that asset class.
Phase 2: Risk Analysis
For each identified risk, assess the likelihood of occurrence and the impact if realised. Use a consistent scoring methodology (e.g., qualitative scales of Low/Medium/High/Critical) and document the rationale for each rating. Consider both technical factors (e.g., exposure, exploitability) and business factors (e.g., regulatory consequences, service disruption).
Phase 3: Risk Treatment
For each risk above the organisation’s risk appetite threshold, select a treatment option: mitigate (apply controls), transfer (e.g., insurance or contractual allocation), avoid (eliminate the activity), or accept (with documented justification and senior management sign-off).
Risk Categories and Controls for Software Delivery
The following table maps common risk categories in software delivery to their likelihood factors, impact factors, and typical controls. Compliance officers should use this as a baseline and adapt it to their organisation’s specific context.
| Risk Category | Likelihood Factors | Impact Factors | Typical Controls |
|---|---|---|---|
| Pipeline Integrity | Unprotected pipeline definitions; lack of change approval on pipeline configs; no integrity verification of build outputs | Malicious code injection into production; compromised software delivered to customers; loss of trust | Pipeline-as-code with version control; mandatory review for pipeline changes; cryptographic signing of build artifacts; build provenance attestation |
| Access Control | Over-privileged service accounts; shared credentials; lack of MFA on pipeline administration; no regular access reviews | Unauthorised deployments; lateral movement from pipeline to production; data exfiltration via pipeline credentials | Least-privilege access model; individual service accounts per pipeline; MFA enforcement; quarterly access reviews; just-in-time access for sensitive operations |
| Supply Chain | Unvetted third-party dependencies; no integrity checks on external packages; transitive dependency risks; lack of vendor assessment | Introduction of known vulnerabilities; malicious packages in production; regulatory non-compliance for supply chain management | Software Bill of Materials (SBOM) generation; dependency scanning and approval workflows; private artifact repositories; vendor security assessments |
| Secrets Exposure | Secrets hardcoded in source code; secrets in pipeline logs; unencrypted secrets in configuration; lack of rotation policies | Credential theft leading to system compromise; unauthorised access to production systems; data breaches | Centralised secrets management; automated secret scanning; log redaction; regular credential rotation; secrets never stored in repositories |
| Deployment | No deployment approval gates; lack of rollback capability; insufficient pre-deployment testing; no deployment audit trail | Defective releases impacting service availability; inability to recover from bad deployments; compliance gaps from untracked changes | Mandatory approval gates for production deployments; automated rollback mechanisms; deployment audit logging; environment promotion policies |
Governance Model: Ownership and Accountability
NIS2 places ultimate responsibility on the management body (Article 20), which means risk management for software delivery cannot be delegated without clear accountability structures. The following RACI model provides a starting point for organisations to define ownership.
| Activity | Management Body | CISO / Security Team | Engineering Leadership | Compliance / Risk Team |
|---|---|---|---|---|
| Approve risk appetite for CI/CD | A | R | C | C |
| Conduct CI/CD risk assessments | I | A | R | C |
| Implement pipeline security controls | I | C | A/R | I |
| Monitor and report on residual risk | I | A | R | R |
| Review and update risk register | I | R | C | A |
| Accept residual risks above threshold | A | R | C | R |
| Report material risks to regulators | A | R | I | R |
R = Responsible, A = Accountable, C = Consulted, I = Informed
Key governance principles to enforce:
- Risk assessments for software delivery must be reviewed at least annually, or after any significant change to the pipeline environment.
- Residual risk acceptance must be documented and signed off by an individual with appropriate authority — not by the team that operates the pipeline.
- The risk register must include software delivery risks alongside other operational risks, not in a separate silo.
What Auditors Should Verify
When assessing NIS2 compliance for software delivery risk management, auditors should examine the following areas:
1. Documented Risk Assessments
- Does a formal risk assessment exist that explicitly covers CI/CD and software delivery systems?
- Is the assessment based on a recognised methodology (e.g., ISO 27005, NIST SP 800-30)?
- Does it identify risks specific to the pipeline — not just generic IT risks applied without context?
- Is the scope appropriate? (All pipeline components, integrations, and dependencies should be in scope.)
2. Risk Treatment Plans
- For each identified risk above the appetite threshold, is there a documented treatment plan?
- Are controls mapped to specific risks, with clear rationale for why the control is appropriate?
- Are treatment plans assigned to named owners with target completion dates?
- Is there evidence that treatment plans are actually being executed, not just documented?
3. Residual Risk Acceptance
- Where risks have been accepted rather than mitigated, is there formal sign-off from appropriate management?
- Is the rationale for acceptance documented and defensible?
- Are accepted risks subject to periodic review to determine if conditions have changed?
4. Risk Review Cadence
- Is there evidence of regular risk reviews (at minimum annually)?
- Are risk assessments updated when significant changes occur (new pipeline tools, architecture changes, new deployment targets)?
- Is there a defined trigger list for ad-hoc risk reviews?
- Do review records show meaningful updates, not just re-approval of the same document without change?
Red Flags for Auditors
- Risk assessments that list only generic risks with no pipeline-specific context
- No evidence of management body involvement or awareness of software delivery risks
- Risk registers that have not been updated in over 12 months
- All risks rated as “Low” with no justification
- Treatment plans with no owner or no target date
- Residual risk accepted by operational staff rather than appropriate management
Related Resources
For further guidance on NIS2 compliance and software delivery governance, see:
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- NIS2 Security Architecture
- Executive Audit Briefing
- Dual-Compliance Architecture
New to CI/CD auditing? Start with our Auditor’s Guide.
