Skip to content
AuditFront
Art.21.2e NIS2

NIS2 Art.21.2e: Security in Network and Information Systems Acquisition, Development and Maintenance

What This Control Requires

The measures referred to in paragraph 1 shall include at least the following: (e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.

In Plain Language

Every system you buy, build, or maintain is a potential attack surface. If security is not woven into the full lifecycle - from procurement through development to decommissioning - you are leaving gaps that attackers will find. When acquiring systems, security requirements need to be part of the procurement criteria from day one. For in-house development, that means secure coding standards, peer code reviews, and security testing baked into your pipeline. Maintenance is equally important: timely patching, solid configuration management, and regular security assessments. Vulnerability handling sits at the heart of this control. You need a reliable process for finding vulnerabilities (scanning, pen testing, monitoring advisories), assessing their severity, and remediating them within defined timeframes. On top of that, you should publish a coordinated vulnerability disclosure policy so external researchers have a clear, responsible way to report issues to you.

How to Implement

Start by establishing a secure systems development lifecycle (SSDLC) that covers every phase: requirements, design, implementation, testing, deployment, and maintenance. Every new system or major change should have documented security requirements. Adopt secure coding standards that fit your technology stack. Train your developers on common vulnerability classes like the OWASP Top 10 and CWE Top 25. Integrate static application security testing (SAST) and dynamic application security testing (DAST) into your CI/CD pipeline so issues are caught early. For procurement, build security requirements into vendor specifications. Evaluate commercial off-the-shelf products before deployment and confirm that vendor support and patching commitments meet your needs. Set up a vulnerability management programme with regular scanning - at least monthly for internet-facing systems, quarterly for internal ones. Subscribe to relevant advisories and threat intelligence feeds. Define a clear triage process and set remediation SLAs by severity. Create a patch management process with firm timelines. Critical vulnerabilities on internet-facing systems should be patched within days. Everything else follows a risk-based schedule. Publish a coordinated vulnerability disclosure (CVD) policy. It should give external researchers a clear reporting channel, define your response timelines, and outline how you handle public disclosure. Finally, maintain a complete inventory of software and hardware assets with version information. This underpins both vulnerability management and patch tracking. Pair it with a change management process that includes security review for anything touching production.

Evidence Your Auditor Will Request

  • Secure development lifecycle documentation and procedures
  • Vulnerability management policy with remediation SLAs
  • Vulnerability scan reports and remediation tracking records
  • Patch management records showing timely application of security patches
  • Coordinated vulnerability disclosure policy (published)

Common Mistakes

  • Vulnerability scans are performed but findings are not remediated in a timely manner
  • No secure development lifecycle; security is bolted on rather than built in
  • Patch management is ad-hoc with no defined SLAs based on severity
  • No coordinated vulnerability disclosure policy or process for external reports
  • Legacy systems with known vulnerabilities remain in production without compensating controls

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.8 Related
ISO 27001 A.8.25 Related
ISO 27001 A.8.26 Related
SOC 2 CC8.1 Related

Frequently Asked Questions

What are the expected patch management timelines under NIS2?
NIS2 does not prescribe exact timelines, but industry best practice gives you a solid baseline. Critical vulnerabilities on internet-facing systems should be patched within 24-72 hours. High severity issues within one to two weeks, medium within 30 days, and low within 90 days. Document these targets in your vulnerability management policy and adjust them based on your specific risk context.
Is a vulnerability disclosure policy mandatory?
Yes - NIS2 explicitly calls out vulnerability handling and disclosure as a required measure. Having a published coordinated vulnerability disclosure policy shows maturity and gives external researchers a proper channel to report issues. Without one, you risk vulnerabilities going unreported or being disclosed publicly before you have a chance to fix them.

Track NIS2 compliance in one place

AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.

Start Free Assessment