NIS 2 secure development and acquisition under Article 21(2)(e)
NIS 2 says you must secure systems across procurement, development and maintenance. Article 21(2)(e) is the umbrella. CIR (EU) 2024/2690 §6 splits it into ten sub-sections. Germany puts it into national law through §30(2)(5) BSIG.
The short version
Article 21(2)(e) is the umbrella duty for security across the whole IT lifecycle. Not just code. Not just patching. The whole path: buying a system, building it, configuring it, changing it, testing it, patching it, running it, decommissioning it. The same rule applies across the EU.
CIR (EU) 2024/2690 fills in the detail. §6 of the Annex has ten sub-sections (§6.1 to §6.10) that operationalise the duty. This page covers the development and change side: procurement (§6.1), the secure development lifecycle (§6.2), configuration management (§6.3), change management (§6.4), security testing (§6.5) and patch management (§6.6). Network security, segmentation, anti-malware and vulnerability management (§6.7 to §6.10) have their own pages.
Germany puts the same rule into national law through §30(2)(5) BSIG. The wording is almost word for word the EU text. This page walks the directive, the EU follow-up regulation, and the German transposition in that order.
Article 21(2)(e) NIS 2 Directive (2022/2555)
Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
This is point (e) on the list of ten cybersecurity measures every essential and important entity has to put in place. It is the only point on the list that explicitly stretches from purchase order to end of life.
CIR (EU) 2024/2690, Annex §6
Security measures in acquisition, development and maintenance of network and information systems (Article 21(2)(e) of Directive (EU) 2022/2555).
Because this is a regulation (not a directive), it is directly binding EU law. No national transposition needed. It applies to DNS providers, TLD registries, cloud providers, data centres, managed service providers and the other sectors listed in its Annex. §6 has ten numbered sub-sections that each name a specific duty.
§30(2)(5) BSIG (Germany)
Security in the acquisition, development and maintenance of information technology systems, including the handling and disclosure of vulnerabilities.
Germany copies the EU text almost word for word. 'Information technology systems' instead of 'network and information systems' is wording, not meaning. The BSI points at IT-Grundschutz modules CON.8 (software development) and OPS.1.1.3 (patch and change management) as the practical route.
Write security requirements into every purchase
Before you buy an IT product or service, you write down what it must do on security. Authentication, logging, update support, vulnerability disclosure, hosting region, where data sits. Then you validate the vendor actually meets the requirements. This sits with the buying entity, not the vendor. 'We use SaaS' does not transfer the duty.
Run a secure development lifecycle
Security requirements get analysed during specification and design. Secure coding principles apply, including security by design and zero-trust architectures. Development environments themselves are secured. Security testing happens before release. Test data is handled with care, not copied from production. The whole lifecycle is documented, not just one or two practices.
Patch on an appropriate timeframe, test first
Security patches get applied within an appropriate timeframe (the CIR text), tied to the severity of the vulnerability. Patches are tested before production. Emergency patches are documented. 'Whenever the team has time' is not a timeframe. Pick a cadence, write it down, prove you stick to it.
Security across procurement to decommission
§6 is not about development in the narrow sense. It covers the whole lifecycle: how you choose what to buy, how you build, how you configure, how you test, how you patch, how you change, how you retire. A Mittelstand that buys 95 percent of its software still owns §6.1 (procurement requirements) and §6.6 (patch management). You cannot opt out of the lifecycle just because you do not write code.
Change discipline: no untracked production changes
§6.4 is blunt: changes to production are managed, documented, and reviewed. Emergency changes also get documented, just after the fact instead of before. A change with no ticket, no approver and no rollback plan fails the requirement, even if it works. Auditors check the change log against the ticket system. If they cannot reconstruct who changed what and when, the control is not in place.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
The BSI maps §30(2)(5) BSIG onto two Grundschutz modules. CON.8 'Software-Entwicklung' covers the SDLC side: requirements, secure coding, test, release. OPS.1.1.3 'Patch- und Änderungsmanagement' covers the change and patch side. If you follow CON.8 and OPS.1.1.3, you are inside what §30 BSIG asks for.
ENISA Technical Implementation Guidance
ENISA, the EU cybersecurity agency, publishes a Technical Implementation Guidance (TIG) that takes the abstract CIR §6 text and shows you what to do in practice. It maps each sub-section onto ISO/IEC 27001:2022 controls (A.8.25 to A.8.32 on secure development, A.5.20 to A.5.23 on supplier relationships), so existing certifications give you a head start.
National transposition laws
Every member state has its own transposition law (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duties under Article 21(2)(e) are the same because the directive sets one EU-wide standard. What differs: which national framework the regulator points to as the practical route.
We use SaaS, so secure development is the vendor's job.
Half right. The vendor owns the code. You still own §6.1: documented security requirements for every IT product or service you buy, plus validation that the vendor meets them. Authentication, logging, update support, data location, breach notification. If your procurement file is empty, the duty is not met, even if the vendor is excellent.
We do code reviews, so the SDLC piece is covered.
Code review is one practice. §6.2 wants the full lifecycle documented: security requirements during specification, secure coding principles (including security by design and zero-trust), secured development environments, security test procedures before release, careful test data handling. A single practice on top of an undocumented process does not meet the section.
We patch when the team has time.
§6.6 asks for an appropriate timeframe tied to severity, plus testing before production and documentation for emergency patches. 'When there is time' is not a timeframe. Pick a cadence (e.g. critical within 72 hours, high within 14 days), write it down, prove you stick to it in the change log. An auditor will reconstruct your patch history from the ticket system.
Most German Mittelstand IT looks like this: 90 percent vendor software (ERP, payroll, mail, file share, CRM), some integration glue, occasional internal scripts. The big §6 lift for that profile is not the SDLC. It is §6.1 procurement and §6.6 patch management.
Write the security-requirements template once. Authentication, logging, vulnerability disclosure, update support, hosting region, data export, breach notification. Apply it to every new procurement and every renewal. Pair it with a written patch cadence (critical / high / medium with a timeframe each) and a change log everyone uses. That covers the bulk of §6 for a typical Mittelstand without hiring a software-security specialist.
We built §6.1 procurement requirements, §6.2 SDLC documentation, §6.4 change log and §6.6 patch cadence into the platform's PRO module. You fill the procurement template once and reuse it. Each new IT product or service runs through the same security checklist with a sign-off.
The change log and patch cadence run on the same audit trail as the rest of the platform: ticket, approver, rollback plan, evidence file. Emergency changes get the after-the-fact form. You do not maintain a separate compliance log. When an auditor asks how you patched a CVE, the answer is one query, not three spreadsheets.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §6 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(5) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz modules CON.8 'Software-Entwicklung' and OPS.1.1.3 'Patch- und Änderungsmanagement'
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)