NIS2 Secure SDLC: What CIR 2024/2690 Section 6.2 Requires From Your SAST, DAST, and Code Review Pipeline

A documented information security policy does not tell an auditor whether your pull requests get scanned before merge. Article 21(2)(e) of Directive (EU) 2022/2555 requires essential and important entities to secure the full lifecycle of the systems they build — and Commission Implementing Regulation (CIR) 2024/2690 turns that single sentence into ten enforceable sub-sections covering everything from procurement criteria to patch timelines. Section 6.2, specifically, is the one that reaches into your development pipeline: secure coding standards, design-phase security requirements, security testing, code review, and environment separation. This guide maps each 6.2 sub-point to the engineering controls — SAST, DAST, dependency scanning, review checklists — that actually satisfy it, and shows where 6.2 connects to the configuration-management, change-management, testing, and patching requirements sitting on either side of it in the Annex.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Article 21(2)(e) and CIR Section 6: Scope and Who This Applies To

Article 21(2)(e) of the NIS2 Directive requires essential and important entities to implement “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” — one of ten mandatory measures under Article 21(2), all grounded in the all-hazards, risk-based approach Article 21(1) establishes.^[1] The binding technical detail sits in CIR 2024/2690, which supplements NIS2 for the specific sectors it covers (DNS providers, TLD registries, cloud and data centre providers, CDNs, managed service and security providers, online marketplaces, search engines, social networking platforms, and trust service providers). Section 6 of the CIR Annex is titled “Security in network and information systems acquisition, development and maintenance” and runs from 6.1 (acquisition) through 6.10 (vulnerability handling and disclosure).^[2] Section 6.2 — secure development lifecycle — is the sub-point this guide covers in depth.

Who	What Section 6.2 means for you
CISO / engineering security lead	Own the documented SDLC policy, the secure coding standard, and the CI/CD security-gate configuration — this is the technical implementation layer
Development team lead	Code review must include security objectives, not only functional correctness; test data can’t be live production data
Compliance officer	Needs evidence the policy exists, is dated, is reviewed periodically, and is actually followed — not just written once
Board / senior management	Accountable under Article 20 for approving the risk-management measures, including this one, and can face liability for failing to do so

If your organisation is not directly named in CIR 2024/2690’s scope, Section 6.2’s specific sub-points are not binding text — but Article 21(2)(e) itself applies to every essential and important entity, and CIR Section 6 is the clearest available benchmark for what “appropriate and proportionate” looks like in practice. In practice, Section 6 is still commonly used as the reference benchmark for what “appropriate and proportionate” looks like, even outside its formal scope — that’s practitioner convention, not a binding rule.

What CIR 2024/2690 Section 6.2 Actually Requires

Section 6.2 requires entities developing software in-house, or through contracted developers acting on the entity’s behalf, to apply four groups of controls.^[2] The CIR does not name a specific methodology or vendor tool — it specifies outcomes, and leaves the implementation proportionate to the entity’s risk profile.

CIR sub-point	What it requires
6.2.1	Documented rules for secure development covering every phase from specification through testing
6.2.2	Security analysis at the design stage, secure coding principles, a secured development environment, security testing, and controlled test data
6.2.3	The same rules applied to development outsourced to third parties — contracted developers are not exempt
6.2.4	Periodic review and update of the secure development rules themselves

An entity that lets developers write and merge code with no documented coding standard, no security-scoped review, and shared dev/test/production credentials fails 6.2 regardless of how strong its perimeter defences are — the requirement sits inside the pipeline, not around it.

Secure Coding Standards: What Actually Satisfies 6.2.2

CIR Section 6.2.2 requires “secure coding principles” without naming a framework — deliberate flexibility, but it means your documented standard has to be defensible, not decorative. National competent authorities assess whether the standard fits the technologies in use and the risk classification of the system, not whether it matches a specific brand name.

Framework	What it adds
OWASP Secure Coding Practices checklist	14 categories — input validation, output encoding, authentication, session management, access control, cryptography, error handling, and more — free, technology-agnostic, widely recognised[4]
NIST SP 800-218 (SSDF)	Four practice groups — Prepare the Organization, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities — maps closely to 6.2’s lifecycle structure
ISO/IEC 27034	Application security standard aligned with acquisition and development obligations, useful if you’re already running an ISO 27001 ISMS
CWE/SANS Top 25	A baseline list of the most dangerous software weaknesses — useful minimum scope for code review objectives

Three practices come up in almost every supervisory review, regardless of which named framework an entity picked. Input validation at every system boundary: user input, API responses, file uploads, and reads from third-party systems must all be validated before processing, since injection remains one of the most exploited weakness classes across every sector. Secrets management: credentials, API keys, and cryptographic material must not sit in source code or version control — a dedicated vault or environment-scoped secret store, enforced through repository scanning, is the expected control. Dependency management: every open-source and third-party library in production has to be inventoried and monitored for known CVEs, because an entity that cannot list what’s running in its own software has no path to meeting the 6.10 vulnerability-monitoring obligation covered later in this guide.

SAST and DAST: Where Automated Testing Fits the Pipeline

6.2.2’s “security testing” requirement is where most entities either over-invest in tooling with no policy behind it, or under-invest and rely on a single annual penetration test that never touches code written in between. Static Application Security Testing (SAST) scans source code without executing it — it catches injection flaws, hardcoded secrets, and insecure API usage early, cheaply, and before the code ever reaches a running environment. Dynamic Application Security Testing (DAST) probes a running application from the outside, the way an attacker would, catching configuration and runtime issues SAST structurally cannot see — authentication bypass, session handling, server misconfiguration. The two are complementary, not substitutes for each other.

A risk-proportionate pipeline typically runs SAST and dependency/secrets scanning on every pull request, with unresolved critical findings blocking merge, and reserves DAST for pre-release gates against a staging environment that mirrors production — DAST needs a running application, so it naturally lands later in the pipeline than SAST. What CIR 6.2.2 actually requires is that this scope and frequency is documented and proportionate to the system’s risk classification, not that a specific tool brand is deployed — auditors examine the documented policy and the testing records it produces, not your vendor invoice.

Code Review as a Documented Security Control

6.2.2 requires code review “that includes security objectives, not only functional correctness” — a distinction most engineering teams already have the process for and simply never wrote down. A review that only asks “does this work” is a quality gate; a review that also asks “does this introduce an injection point, does this change touch authentication or cryptographic code, does this add a new external dependency” is a security control, and only the second one satisfies 6.2.2.

In practice, the CIR 6.2 audit failures that come up most often are not missing SAST reports — tooling is usually already running somewhere. They’re a security-review checklist that exists on paper but isn’t actually referenced in merged pull requests, so there’s no record that the security questions were ever asked. Three review triggers are worth making mandatory rather than discretionary: any change to authentication or authorisation logic, any change touching cryptographic functions or key handling, and any change that adds a new third-party dependency. Reviewer identity, the checklist items covered, and the outcome should be retained as part of the pull request record — that record is what a supervisory authority will ask to see, not a description of your process.

Dependency Scanning and the Open-Source Supply Chain: The Audit Exposure Competitors Skip

On 29 March 2024, a maintainer identity that had spent roughly two years building contributor credibility inserted a backdoor into xz-utils versions 5.6.0 and 5.6.1, a compression library used by OpenSSH — CVSS 10.0, the maximum possible severity. It was caught not by code review or automated scanning but by a Microsoft engineer investigating unrelated CPU-latency anomalies during routine performance testing.^[7] The lesson for Section 6.2 compliance isn’t “scan more” — dependency scanning would not have caught this specific backdoor, because the malicious code was hidden in test files and only assembled during the build process. The lesson is that an entity’s own written record of which components it monitors, how it tracks CVEs against them, and what its update cadence is, is the actual audit evidence — not a claim that scanning makes the risk zero. According to ENISA’s 2025 Threat Landscape report, software supply chain attacks remained one of the top ten threat categories across the EU, at 10.6% of the 4,875 incidents analysed between July 2024 and June 2025^[6] — a large enough share that “we didn’t write the vulnerable code ourselves” is not a defensible audit position under 6.2.2’s test-and-monitor requirement.

Environment Separation and the Rest of the CIR 6.x Pipeline

6.2.2 also requires logical or physical separation between development, test, and production environments, and prohibits populating test environments with real production data unless equivalent data protection controls apply. This is where 6.2 stops being a standalone requirement and becomes one stage in a connected pipeline the CIR Annex builds across five adjacent sub-sections.

Pipeline stage	CIR sub-point	What connects them
Design and coding	6.2 — Secure development lifecycle	Security requirements set before code is written; secure coding standard applied
Build configuration	6.3 — Configuration management	Build and infrastructure configs documented, monitored, and enforced — not ad hoc
Release and deployment	6.4 — Change management, repairs and maintenance	Every code change follows a documented, risk-assessed change process before production
Pre- and post-release testing	6.5 — Security testing	Scope and frequency proportionate to risk; type, time, and results documented
Operational maintenance	6.6 — Security patch management	Patches applied within reasonable timeframes; deviations documented and justified

Treating 6.2 in isolation is the most common structural mistake in secure-SDLC compliance work: an entity can have a perfect coding standard and still fail an audit because nobody connected the dots between the pipeline stage that writes the code and the pipeline stage that ships it. For the change-management and patch-timeline mechanics specifically, see the dedicated guide to NIS2 vulnerability and patch management requirements.

Proportionality: What This Looks Like at Different Scales

A 12-person SaaS startup and a 500-person manufacturer are both bound by the same Article 21(2)(e), but “appropriate and proportionate” means different implementations. ENISA’s Secure by Design and Default Playbook, published in draft for consultation in March 2026, formalises a two-tier model: entities building for lower-risk environments can run a “minimum viable” security-by-design approach that is fast to produce, easy to refresh, and tightly coupled to normal delivery work, while products intended for higher-risk or critical use cases need a fuller, more resource-intensive analysis.^[5] For a small team, that typically means one documented coding standard, SAST and dependency scanning wired into the existing CI pipeline (both have free and low-cost tiers), and a two-line addition to the pull request template rather than a separate security review board. For a larger or higher-risk entity, it means a dedicated application security function, staged testing gates by system criticality, and a periodic (not one-time) review cycle for the standard itself, as 6.2.4 requires.

Audit Evidence: What a Supervisory Authority Will Actually Ask For

Section 6.2 compliance is proven with records, not with a policy document alone. A national competent authority reviewing this control typically requests the documented secure development policy itself, code review records showing security-scoped checklist items were addressed, SAST/DAST scan outputs tied to specific builds or releases, the dependency inventory and its CVE-monitoring log, and evidence the policy has been reviewed on a defined cycle per 6.2.4 — not just that it was written once and filed away.

Role	Owns
CISO / AppSec lead	Secure development policy, coding standard selection, testing-tool configuration
Development team lead	Code review enforcement, pull-request security checklist compliance
Compliance officer	Evidence collection, periodic review scheduling, audit-readiness
Board / senior management	Article 20 approval and oversight of the risk-management measures, including this one

Gap Analysis: From “We Have Some Tests” to 6.2-Compliant

Current state	6.2-compliant state	Effort
Coding guidelines live informally in a wiki or nowhere	Dated, version-controlled secure coding standard mapped to a named framework	Low
SAST or dependency scanning runs occasionally, ad hoc	SAST + dependency/secrets scanning on every pull request, blocking on critical findings	Medium
Code review checks functionality only	Security-scoped checklist mandatory for auth, crypto, and new-dependency changes, with retained records	Low
DAST run once a year, disconnected from releases	DAST or equivalent run against staging before every major release, risk-proportionate	Medium
Test environments share data or credentials with production	Logical/physical separation enforced; test data anonymised or synthetic	Medium-High
Secure development policy has never been reviewed since it was written	Periodic review cycle documented per 6.2.4, with dated revision history	Low

Frequently Asked Questions

Does CIR 2024/2690 Section 6.2 name specific tools like SonarQube or Snyk?

No. The CIR specifies outcomes — secure coding principles, security testing, code review with security objectives — and deliberately does not mandate a named framework or vendor product. Auditors assess whether your documented standard and testing evidence are proportionate to your risk profile, not which brand you used.

Is Section 6.2 binding on every NIS2 entity, or only the sectors CIR 2024/2690 names?

CIR 2024/2690’s specific sub-points bind only the sectors it covers directly (DNS, cloud, managed services, and similar digital-infrastructure entities). Every other essential and important entity is still bound by Article 21(2)(e) itself, and in practice Section 6.2 is commonly used as the reference benchmark for what “appropriate and proportionate” secure development looks like, even where it isn’t formally binding.

What’s the difference between this guide and NIS2 Secure Development on this site?

The broader secure development guide maps the full acquisition-through-decommissioning lifecycle at policy level. This guide goes deep on one stage — the CIR Section 6.2 secure development lifecycle specifically — down to SAST/DAST pipeline placement, dependency-scanning mechanics, and code-review checklist content.

Does finding a vulnerability in our own code trigger NIS2 incident notification?

Not by itself. Discovering a vulnerability is a 6.2/6.10 vulnerability-handling matter. Notification under Article 23 is only triggered if that vulnerability is actually exploited and the resulting disruption meets the significance thresholds — see the full coordinated vulnerability disclosure guide for the CVD process itself.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21
2. Commission Implementing Regulation (EU) 2024/2690, Annex Section 6
3. NIST SP 800-218, Secure Software Development Framework (SSDF)
4. OWASP Secure Coding Practices Checklist
5. ENISA Secure by Design and Default Playbook (draft, March 2026)
6. ENISA Threat Landscape 2025
7. XZ Utils backdoor, CVE-2024-3094
8. NIS2 Article 21 Decoded: All 10 Security Measures
9. CIR 2024/2690: Complete Guide to Technical Requirements