NIS2 Article 21(2)(e) covers secure development, and Implementing Regulation 2024/2690 spells out what that means for certain digital entities: written secure development rules covering all phases, security requirements analysis, secure coding principles, security testing in the lifecycle, and documented test results with mitigations for critical findings.
The development rules
Point 6.2 of the annex says that before developing a system, including software, entities lay down rules for secure development and apply them in-house and to outsourced development. The rules cover specification, design, development, implementation and testing.
Entities must:
- analyse security requirements at specification and design;
- apply secure engineering and secure coding principles, such as security by design and zero trust architectures;
- set security requirements for development environments;
- establish security testing processes in the lifecycle;
- select, protect and manage security test data, and sanitise or anonymise test data according to the risk assessment.
Rules must be reviewed and updated at planned intervals.
The testing policy
Point 6.5 asks for a security testing policy and procedures. Entities must:
- Decide, from the risk assessment, the need, scope, frequency and type of tests.
- Run tests to a documented methodology, covering components that matter to secure operation.
- Document the type, scope, time and results of tests, including criticality and mitigating action for each finding.
- Apply mitigating actions for critical findings.
Turning that into engineering practice
Map each requirement to something already in your pipeline:
- Security requirements at design: a design review template with a security section.
- Secure coding principles: a coding standard and a code review checklist.
- Testing in the lifecycle: CI jobs for static analysis, dependency scanning and dynamic tests.
- Documented results: archived scan reports with ticket links.
- Mitigation of critical findings: merge gates, or tracked exceptions with an expiry date.
- Test data protection: a rule that production data is masked before use in test.
Keep this list in your repository and link to real examples.
Gates make the policy real
A written policy that no pipeline enforces is weak evidence. A merge gate that blocks on critical findings, with an exception path, shows the rule operating. Record the exception reason and approver, since point 6.6.2 of the same annex expects documented reasons when you choose not to act.
Click through it at your own pace, or open it full screen.
Safeguard provides policies, gates and guardrails plus SBOM and dependency scanning, which can enforce and record several of these checks. You can try a free scan.
Quick check
Does this regulation apply to all NIS2 entities?
No. Regulation 2024/2690 applies to listed digital entity types such as cloud, managed service and DNS providers. Other entities follow Article 21 and national guidance, but can use it as a model.
Is penetration testing mandatory under these rules?
The annex asks for a risk based testing policy that sets the type and frequency of tests. It does not name penetration testing as a fixed requirement.
Sources
Last reviewed: 19 October 2026.
