NIS2 Article 23: Incident Reporting Requirements Overview
NIS2 Article 23 imposes strict incident notification obligations on essential and important entities. Organisations must report significant incidents to their national CSIRT or competent authority within tight timeframes:
- Early warning: Within 24 hours of becoming aware of a significant incident
- Incident notification: Within 72 hours, providing an initial assessment including severity and impact
- Final report: Within one month, including a detailed description, root cause analysis, and mitigation measures applied
For organisations that deliver or maintain software through CI/CD pipelines, pipeline logs and deployment records become critical evidence during incident investigation and regulatory reporting. Auditors and compliance officers must ensure that pipeline environments are configured to produce and retain the evidence needed to meet these obligations.
How CI/CD Pipeline Logs Serve as Incident Evidence
When a security incident occurs — whether a compromised deployment, a supply chain breach, or an unauthorised code change — investigators need to reconstruct exactly what happened, when, and by whom. CI/CD pipelines are uniquely positioned to provide this evidence because they sit at the intersection of code changes, build processes, security scans, and production deployments.
Pipeline evidence enables organisations to:
- Establish timelines: Determine precisely when a malicious or faulty change entered the delivery process
- Identify scope: Understand which artifacts, environments, and services were affected
- Demonstrate due diligence: Show regulators that appropriate controls (code reviews, security scans, approval gates) were in place and functioning
- Support root cause analysis: Trace the incident back to its origin — whether that is a compromised dependency, a misconfigured pipeline, or a human error
Required Pipeline Evidence Categories
Deployment Timelines
Complete records of when each deployment occurred, to which environment, and the outcome (success, failure, rollback). These records must include timestamps synchronised to a reliable time source.
Change Logs
Records linking each deployment to specific code changes, including commit identifiers, change descriptions, and the author of each change. Change logs must demonstrate an unbroken chain from code commit to production deployment.
Approval Records
Evidence that required human approvals were obtained before deployment. This includes code review approvals, change advisory board (CAB) sign-offs where applicable, and any emergency change authorisations with post-hoc justification.
Security Scan Results
Records from automated security gates including static analysis, dependency vulnerability scanning, container image scanning, and any other security checks integrated into the pipeline. Results must show what was scanned, the findings, and whether the pipeline proceeded or was halted.
Artifact Provenance
Records establishing the origin and integrity of deployed artifacts. This includes build logs showing how artifacts were constructed, checksums or signatures verifying artifact integrity, and records of which source code and dependencies were used.
Evidence Retention Requirements
NIS2 does not specify a single mandatory retention period for all evidence. However, the following considerations apply:
- The final incident report is due within one month, so all evidence must be available for at least that period
- Competent authorities may request additional information during follow-up investigations, which can extend well beyond the initial reporting period
- Member state transpositions may impose specific retention requirements — organisations must check their national implementing legislation
- As a prudent baseline, organisations should retain pipeline evidence for a minimum of 24 months to cover investigation timelines, regulatory follow-ups, and potential legal proceedings
Incident Type to Pipeline Evidence Mapping
| Incident Type | Required Pipeline Evidence | Recommended Retention Period |
|---|---|---|
| Compromised deployment (malicious code reaches production) | Full deployment timeline; commit and change logs for the affected release; approval records; security scan results (especially any bypassed gates); artifact provenance and integrity verification | Minimum 24 months |
| Supply chain compromise (malicious dependency or base image) | SBOM for affected builds; dependency update logs; artifact provenance; registry access logs; vendor assessment records | Minimum 24 months; retain SBOMs for the lifecycle of the affected software |
| Unauthorised access to pipeline infrastructure | Pipeline authentication and access logs; RBAC configuration history; MFA verification records; administrative action logs | Minimum 24 months |
| Data exposure via pipeline logs or artifacts | Pipeline execution logs (to identify what data was exposed); secrets management audit logs; artifact storage access logs | Minimum 24 months; may extend based on data protection authority requirements |
| Pipeline tampering (unauthorised modification of pipeline configuration) | Pipeline configuration change history; access logs for pipeline administration; commit logs for pipeline-as-code files; approval records for pipeline changes | Minimum 24 months |
| Failed deployment causing service disruption | Deployment logs including error details; rollback records; change logs; pre-deployment test results; post-deployment health check results | Minimum 18 months |
Auditor Checklist: Incident Readiness in CI/CD Environments
Use this checklist to assess whether an organisation’s CI/CD environment is prepared to support NIS2 incident reporting obligations:
Evidence Generation
- ☐ Pipeline logs capture the full lifecycle: trigger, build, scan, approval, deploy, and outcome
- ☐ Every deployment is linked to a specific set of code changes and approvals
- ☐ Security scan results are recorded and retained independently of pipeline tool interfaces
- ☐ Artifact provenance records (build inputs, checksums, signatures) are generated for each release
- ☐ Timestamps across all pipeline components are synchronised to a common, reliable time source
Evidence Integrity
- ☐ Pipeline logs are stored in append-only or immutable storage
- ☐ Log integrity can be verified (e.g., through checksums or cryptographic chaining)
- ☐ Access to log storage is restricted and separately audited
- ☐ Pipeline administrators cannot delete or modify historical logs
Evidence Retention
- ☐ A documented retention policy exists that covers CI/CD pipeline evidence
- ☐ Retention periods meet or exceed the recommended minimums (24 months as baseline)
- ☐ Retention is enforced automatically — not dependent on manual intervention
- ☐ Evidence remains accessible and readable throughout the retention period (format longevity)
Incident Response Integration
- ☐ The incident response plan explicitly references CI/CD pipeline evidence and how to access it
- ☐ Roles and responsibilities for pipeline evidence collection during incidents are defined
- ☐ The organisation has tested its ability to retrieve and analyse pipeline evidence under incident conditions
- ☐ Escalation paths exist for incidents originating in or affecting the CI/CD pipeline
Reporting Readiness
- ☐ The organisation can produce a deployment timeline for any given service within the 24-hour early warning window
- ☐ Root cause analysis procedures include pipeline log review as a standard step
- ☐ Template reports for competent authorities include sections for pipeline-related evidence
Related Resources
For the full NIS2 compliance resource library, visit our NIS2 Compliance Hub.
For an overview of NIS2 security architecture principles and how they apply to software delivery, see NIS2 Security Architecture Explained.
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- NIS2 Security Architecture
- Continuous Compliance via CI/CD
- How Auditors Review CI/CD
New to CI/CD auditing? Start with our Auditor’s Guide.
