NIS2 Secure Development: Security in ICT System Lifecycle

Every software deployment, system acquisition, and configuration change in scope of NIS2 now carries legal weight. Article 21(2)(e) of Directive (EU) 2022/2555 requires essential and important entities to implement security across the complete lifecycle of network and information systems — from the moment procurement criteria are written, through development and maintenance, to eventual decommissioning. This is not a requirement for a dedicated secure software team. It is a requirement for a governance process that spans procurement, engineering, IT operations, and senior management.

Organisations that treat secure development as a technical preference rather than a binding obligation under the ten mandatory measures of Article 21(2) are exposed to enforcement action, not just security risk. This guide maps every CIR 2024/2690 Section 5 requirement to practical controls, with implementation guidance for each stage of the ICT lifecycle.

This article provides general information only and does not constitute legal advice. NIS2 implementation varies by member state and sector — always verify requirements against your national transposition law and the guidance of your competent authority.

Article 21(2)(e): Scope and Legal Basis

Article 21(2)(e) of NIS2 requires essential and important entities to implement:

“security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.”

Unlike some of the ten mandatory measures, which focus on a single domain, Article 21(2)(e) spans the entire ICT asset lifecycle. It applies equally to software built in-house, commercial off-the-shelf applications, cloud services, managed services, and embedded firmware. The measure covers what your organisation buys, what it builds, how it changes existing systems, and how it identifies and responds to weaknesses.

The four components each carry distinct obligations:

• Acquisition — procurement of hardware, software, and services, including security requirements that must be defined before the selection process begins
• Development — in-house code or software developed by contracted parties on the entity’s behalf, requiring a documented secure development lifecycle
• Maintenance — patches, updates, and configuration changes to existing systems, requiring formal change management with security review
• Vulnerability handling and disclosure — processes for detecting, assessing, remediating, and — where the entity produces software for external use — communicating vulnerabilities

The binding technical detail for each of these components is provided by the Commission Implementing Regulation (CIR) 2024/2690, which supplements NIS2 for essential and important entities in specific sectors. Annex Section 5 of the CIR is the primary source for Article 21(2)(e) requirements.

CIR 2024/2690 Section 5: What the Regulation Actually Requires

Section 5 of the CIR Annex addresses “Security in network and information systems acquisition, development and maintenance.” It is structured around five operational areas, each with enforceable requirements.

Section 5.1 — Security requirements for acquisition

Before procuring any network or information system component — hardware, software, or service — entities must define and document the security requirements that component must meet. These requirements must:

• Specify the security functionality the component must provide, including authentication mechanisms, logging capabilities, encryption support, and access control features
• Define the assurance level appropriate to the risk classification of the system in which the component will be used
• Require suppliers to demonstrate how security requirements are satisfied, not simply assert compliance in commercial terms
• Include contractual provisions requiring the supplier to disclose vulnerabilities in the component within a defined timeframe

A procurement process that evaluates vendor bids solely on price, feature sets, and commercial terms — without formal security criteria — does not meet Section 5.1. For the broader contractual obligations that apply when acquiring services from third-party suppliers, see the guide to NIS2 supply chain security requirements.

Section 5.2 — Secure development lifecycle requirements

For any software developed internally or by contracted developers on the entity’s behalf, Section 5.2 requires security to be embedded throughout the development process from design to deployment. The CIR requires entities to:

• Maintain a documented secure development lifecycle (SDLC) policy
• Establish security requirements at the design phase, before any code is written
• Apply secure coding standards and guidelines appropriate to the technologies and languages in use
• Conduct security testing proportionate to the risk classification of the system under development
• Perform code review that includes security objectives, not only functional correctness
• Maintain logical or physical separation between development, test, and production environments
• Ensure test environments do not contain real production data without equivalent data protection controls applied

These requirements use obligatory language throughout. An entity that allows developers to write and deploy code without documented secure coding standards, security-focused review, or environment separation is in direct breach of Section 5.2.

Section 5.3 — Change management as a security control

Section 5.3 requires a formal change management process covering all changes to production systems — software updates, configuration changes, infrastructure modifications, and cloud environment changes. Requirements include:

• A documented change management policy defining scope, approval authority levels, and risk categories
• Mandatory security review before any significant change enters production — embedded in the approval workflow, not optional
• Rollback or remediation plans prepared and tested before change execution
• Emergency change procedures with compensating controls and a defined post-implementation review timeline
• Records of all changes, approvals, and outcomes retained and available for supervisory review

A critical point for cloud-deployed systems: automatic updates pushed by a SaaS provider or managed service constitute a change to your production environment. Your change management controls must address how you manage, validate, and where necessary approve or reject those externally-initiated changes.

Section 5.4 — Test environments

Section 5.4 requires test environments to be:

• Separated from production systems to prevent testing activities from affecting live services or exposing live data
• Representative of the production configuration so that security testing results are valid and transferable
• Access-controlled so that only authorised testing personnel can modify or interact with the test environment
• Not populated with real customer or operational data unless equivalent data protection controls are in place

Organisations that test directly in production, or maintain test environments that share credentials, network access, or data with live systems, face specific exposure under Section 5.4.

Section 5.5 — Vulnerability handling and disclosure

Section 5.5 covers both inbound vulnerability management — identifying and remediating weaknesses in your own systems — and, where the entity develops software used by third parties, outbound disclosure obligations. Requirements include:

• A documented vulnerability management process with defined triage criteria, severity rating methodology, and remediation timelines by severity band
• Active subscription to threat intelligence feeds and vendor advisories relevant to the technology components in use
• Coordinated vulnerability disclosure (CVD) procedures for entities that produce software products or services consumed by others
• Patch application within timelines proportionate to severity, consistent with ENISA guidance and national authority requirements
• Tracking of vulnerability remediation through to verified closure, with records available for audit

Note: discovering a vulnerability in your systems does not itself trigger NIS2 incident notification. However, if that vulnerability is exploited and the resulting disruption meets the significance thresholds under Article 23, the incident must be reported. For the full notification requirements, see the NIS2 incident reporting guide.

The ICT Lifecycle Under NIS2: Full Mapping

The following table maps each stage of the ICT lifecycle to the CIR requirements and key controls that apply.

Lifecycle Stage	CIR Requirement	Key Controls Required
Requirements and design	Security requirements documented before procurement or development begins (5.1, 5.2)	Security requirements specification; threat modelling; system risk classification
Procurement / acquisition	Security criteria defined; supplier assurance obtained; disclosure contractually required (5.1)	Security scoring in vendor evaluation; contractual security clauses; SBOM request for software components
Development	Documented SDLC policy; secure coding standards; security code review; automated testing (5.2)	Coding standards documentation; SAST/DAST in CI/CD pipeline; security-focused peer review records
Testing and QA	Security testing proportionate to risk; separated test environment; no live data without controls (5.2, 5.4)	Penetration testing schedule; DAST and composition analysis; anonymised or synthetic test data
Deployment and change management	Change management policy; security review in approval; rollback plan; emergency change procedure (5.3)	Change request records; security sign-off for configuration and infrastructure changes; post-emergency-change review
Operational maintenance and patching	Vulnerability management process; advisory monitoring; patch SLAs by severity (5.5)	Severity-tiered patch timelines; advisory subscription list; remediation tracking through to verified closure
Decommissioning	Secure disposal linked to asset management and access control (CIR Section 11)	Decommission checklist; data destruction records; access revocation confirmation; system removal from CMDB

Framework based on CIR 2024/2690 Annex Section 5 and Article 21(2)(e) NIS2. National transposition may impose additional sector-specific requirements — check with your national competent authority.

Secure Coding: What CIR Section 5.2 Requires in Practice

CIR Section 5.2 requires entities to apply “secure coding standards.” The regulation does not mandate a specific named framework — this is intentional flexibility. In practice, supervisory authorities will assess whether your documented standards are appropriate for the technologies in use and the risk level of the systems being developed.

Widely accepted frameworks that satisfy the requirement include:

• OWASP Secure Coding Practices — foundational guidance covering input validation, authentication, session management, cryptography, error handling, and logging; available as a quick reference and a detailed implementation guide
• NIST SP 800-218 (SSDF) — the Secure Software Development Framework, which maps closely to the lifecycle approach CIR Section 5.2 requires and is increasingly referenced in EU regulatory guidance
• ISO/IEC 27034 — Application Security standard aligned with the acquisition and development requirements of Article 21(2)(e)
• CWE/SANS Top 25 — most dangerous software weaknesses, useful as a minimum baseline for defining code review objectives

What matters for compliance is not the label on your standard, but that you have one, apply it consistently, and can demonstrate application through code review records and testing outputs produced during development.

Three secure coding requirements that supervisory assessments consistently examine:

Input validation at all system boundaries. Every data input entering your system from an external source — user input, API responses, file uploads, database reads from third-party systems — must be validated before processing. This is the primary defence against injection vulnerabilities, which remain among the most exploited classes of weakness across all sectors.

Secrets management. Credentials, API keys, tokens, and cryptographic material must not be hardcoded in source code or stored in version control repositories. A formal secrets management approach — using dedicated vaults or environment-scoped secret stores — must be in place and enforced through automated scanning of repositories and build artefacts.

Dependency management. Third-party libraries and open source components form part of every modern application’s attack surface. Each dependency must be inventoried, monitored for known vulnerabilities (CVEs), and updated within defined timelines when a relevant CVE is published. An entity that cannot identify which open source components are running in production has no functional path to meeting the Section 5.5 vulnerability monitoring obligation.

Change Management: A Security Control Under CIR Section 5.3

Most organisations of any maturity have change management processes. CIR Section 5.3 elevates change management from an operational discipline to an enforceable security control — with specific requirements that extend beyond standard change advisory board processes.

The critical addition is mandatory security review embedded in the change approval workflow, not applied as an optional escalation. This means:

• Changes that introduce new software components or third-party libraries require a security assessment of those components before deployment
• Configuration changes that affect authentication, authorisation, network exposure, or cryptographic settings require explicit security sign-off as part of the approval record
• Emergency changes applied outside the normal approval process — due to urgent operational need — must be followed by a post-implementation security review within a defined timeframe, with the review outcome documented

For cloud-deployed systems and DevOps environments, change management must extend to infrastructure-as-code modifications, container image updates, pipeline configuration changes, and cloud security policy modifications — not only traditional application releases. An environment where engineers can push infrastructure changes directly to production without documented approval and security review does not satisfy Section 5.3.

Change records also intersect with enforcement. During a post-incident investigation, supervisory authorities will typically request the change log for the period preceding the incident. Incomplete or absent change records compound the compliance exposure beyond the incident itself.

Vulnerability Management: Timelines and Evidence Requirements

CIR Section 5.5 requires a documented vulnerability management process. The following table provides a severity-tiered patch timeline framework consistent with ENISA guidance and common supervisory expectations — this is a practical baseline, not a statement of legally binding timelines.

Severity	CVSS Score	Recommended Timeline	Interim Mitigation Required?
Critical — actively exploited	9.0–10.0 + known exploitation	Mitigations within 24–72 hours; full patch as soon as operationally feasible	Yes — network isolation, WAF rule, or equivalent compensating control while patching proceeds
Critical — not yet exploited	9.0–10.0	7–14 days	Yes if internet-facing or in high-criticality systems
High	7.0–8.9	14–30 days depending on exploitability and exposure	Yes if publicly exploited or affecting an internet-facing surface
Medium	4.0–6.9	30–60 days	No, unless active exploitation is confirmed in the wild
Low / Informational	0.1–3.9	Next planned maintenance cycle	No

Recommended framework based on ENISA guidance and CIR 2024/2690 Section 5.5. National competent authorities may specify different timelines for your sector. Check with your authority for binding sector-specific requirements.

Patch timelines are a starting point, not the complete obligation. CIR Section 5.5 also requires:

• A mechanism for receiving vulnerability intelligence — vendor security advisories, CVE feed subscriptions, ENISA advisories, national CERT notifications, and sector-specific threat intelligence
• A triage process that assesses severity in the context of your specific environment. A critical CVE in a library you do not use in production has different priority than the same severity rating in an internet-facing, customer-critical component
• Evidence that fixes are tested in a separated environment before production deployment, linking patch management directly to the Section 5.3 and 5.4 controls
• Records showing remediation was completed, verified, and closed — not merely that the patch was applied

Common Implementation Gaps

The following gaps appear regularly in supervisory assessments and self-audit reviews. Each maps to a specific CIR Section 5 requirement.

Gap	CIR Requirement	Typical Finding
Security requirements undefined at procurement	Section 5.1 — security criteria required before acquisition begins	Procurement evaluated on price, features, and vendor reputation only; no security scoring in vendor selection
No documented SDLC policy	Section 5.2 — documented secure development lifecycle required	Informal security practices exist among experienced developers but are not documented, standardised, or consistently applied across teams
Security testing is manual and release-only	Section 5.2 — testing proportionate to risk; automated for higher-risk systems	SAST and DAST not integrated into CI/CD pipeline; penetration testing conducted only for major releases, not for incremental changes
Change management covers only application code	Section 5.3 — applies to all system changes including configuration and infrastructure	Infrastructure-as-code changes, cloud configuration modifications, and pipeline changes bypass the change control process
Patch SLAs documented but untracked	Section 5.5 — remediation within defined timelines with verification evidence	SLAs exist in policy; no tracking mechanism; critical patches routinely applied beyond SLA without documented justification
No coordinated disclosure process for software producers	Section 5.5 — CVD procedures required for entities producing software for third parties	No formal policy; vulnerability reports received via support inbox without triage, assignment, or defined response commitment

Alignment with ISO 27001:2022 and OWASP

Entities certified to ISO 27001:2022 have significant advantage in meeting Article 21(2)(e) — the standard’s Annex A controls map directly to CIR Section 5 requirements:

• A.8.25 (Secure development life cycle) — maps to CIR 5.2 SDLC requirements
• A.8.29 (Security testing in development and acceptance) — maps to CIR 5.2 and 5.4 testing and test environment requirements
• A.8.32 (Change management) — maps to CIR 5.3 change control obligations
• A.8.8 (Management of technical vulnerabilities) — maps to CIR 5.5 vulnerability management and patch timelines
• A.5.20 (Addressing information security within supplier agreements) — maps to CIR 5.1 acquisition security requirements

The NIS2/CIR requirement is not only that these controls are documented — it is that they are implemented and demonstrably effective. ISO 27001 internal audits and ISMS reviews should produce evidence of implementation that can be presented during supervisory assessment. Certification alone is not a defence if controls are found to be paper-only.

For the complete mapping between ISO 27001 controls and all ten Article 21 measures, see the guide to NIS2 and ISO 27001 alignment.

OWASP resources directly applicable to Section 5.2 compliance include the Secure Coding Practices Quick Reference Guide (defining secure coding standards), the Application Security Verification Standard (ASVS, defining security testing requirements by risk level), and the Dependency-Check and Dependency-Track tools (dependency vulnerability management). These are not mandated by name in the CIR but are widely referenced in ENISA implementation guidance and accepted by supervisory authorities as evidence of a functioning security testing programme.

Regardless of your framework choice, the governance requirement is consistent: your NIS2 compliance programme must include documented standards, implementation evidence, and periodic review. If you need ready-made policy documents and implementation checklists for secure development and change management, the NIS2 templates library provides Article 21-aligned documentation sets for each of the ten mandatory measures.

Frequently Asked Questions

Does Article 21(2)(e) apply to commercial software and SaaS services we purchase but do not build?

Yes. “Acquisition” under Article 21(2)(e) covers all procurement of network and information system components — hardware, commercial off-the-shelf software, and SaaS services. CIR 2024/2690 Section 5.1 requires entities to define security requirements before procurement, evaluate vendors against those requirements, and obtain contractual commitments covering vulnerability disclosure. You cannot transfer your NIS2 compliance obligation to a vendor — the acquiring entity remains accountable for the risk associated with every system in scope.

What does a compliant secure development lifecycle look like under NIS2?

CIR Section 5.2 requires a documented SDLC policy that embeds security from design through deployment. In practice: security requirements defined before coding begins; documented secure coding standards appropriate to the technology stack; mandatory code review with security objectives; automated security testing (SAST/DAST) integrated into the build pipeline; separated development, test, and production environments; and records of security testing outcomes retained. The depth of testing is proportionate to risk — an internet-facing critical service requires more rigour than a low-risk internal tool. Your risk assessment should inform the security testing approach applied to each system.

How quickly must we patch critical vulnerabilities under NIS2?

CIR Section 5.5 requires remediation within timelines proportionate to severity. For actively exploited critical vulnerabilities, ENISA guidance and supervisory practice suggest interim mitigations within 24 to 72 hours and full patching as soon as operationally feasible. For critical CVEs not yet actively exploited, 7 to 14 days is a widely accepted benchmark. National competent authorities may specify sector-specific timelines — verify with your authority, as critical infrastructure sectors may face stricter requirements than these general benchmarks.

Does NIS2 require a Software Bill of Materials (SBOM)?

NIS2 and CIR 2024/2690 do not use the term SBOM explicitly, but the dependency management and vulnerability monitoring requirements under CIR 5.1 and 5.5 functionally require you to know every software component in your systems. An SBOM is the most effective way to meet this obligation for modern applications built on open source dependencies. Entities that cannot identify which third-party libraries are running in production have no viable path to meeting the Section 5.5 requirement to monitor for and remediate known vulnerabilities within defined timelines.

Are there NIS2 requirements for coordinated vulnerability disclosure if our organisation develops software?

Yes. CIR Section 5.5 requires entities that develop software products or services consumed by third parties to establish a coordinated vulnerability disclosure process. This includes maintaining an accessible channel for receiving vulnerability reports, a triage and severity assessment process, remediation timelines, and a framework for communicating with security researchers and affected users. ENISA has published CVD guidance aligned with ISO/IEC 29147 that provides a practical implementation baseline. Check your national authority’s guidance for any sector-specific CVD requirements that may apply.

Does NIS2 change management apply to cloud environments and infrastructure-as-code?

Yes. CIR Section 5.3 applies to all changes to production systems, regardless of deployment model. In cloud environments this extends to infrastructure-as-code modifications, container image updates, pipeline configuration changes, and cloud security policy changes that affect the security posture of in-scope systems. A cloud environment where developers or platform engineers can push infrastructure changes to production without a documented security review and formal approval record does not satisfy Section 5.3 requirements.

Sources

1. European Parliament and Council. Directive (EU) 2022/2555 (NIS2 Directive) — Article 21(2)(e). EUR-Lex
2. European Commission. Commission Implementing Regulation (EU) 2024/2690 — Annex Section 5. EUR-Lex
3. ENISA. Technical Implementation Guidance for NIS2, v1.0. European Union Agency for Cybersecurity
4. NIST. SP 800-218: Secure Software Development Framework (SSDF), Version 1.1. National Institute of Standards and Technology
5. OWASP. Secure Coding Practices Quick Reference Guide. Open Worldwide Application Security Project