DevSecOps and NIS2: what Dutch companies must do before July 2026

DevSecOps NIS2 readiness means proving that your software development process has working security controls, not just written policies. Before July 2026, Dutch companies in scope for the Cyberbeveiligingswet need evidence for Article 21 controls such as secure development, supply chain security, access management and effectiveness testing. For engineering teams, the practical evidence usually comes from SAST, SCA, CI/CD access reviews, vulnerability remediation logs and incident response records.

For Dutch engineering teams, NIS2 requires a documented way to show that security is built into how code is written, tested, released and maintained.

A DevOps team that already runs code review, dependency scanning and controlled releases may be closer than it thinks. The gap is often the audit trail: who reviewed the finding, when it was fixed, which release closed it and where the evidence is stored.

For companies that need a wider DevSecOps capacity plan, read our DevSecOps team hiring guide for EU companies.

TL;DR: 

• DevSecOps NIS2 readiness means your software delivery process can prove that Article 21 controls are active, reviewed and corrected. 
• For Dutch companies preparing for the Cyberbeveiligingswet around July 2026, the core evidence is SAST/SCA output, access reviews, remediation records, dependency governance and incident-response timelines.

What NIS2 Article 21 requires from your software development process

NIS2 Article 21 requires essential and important entities to take technical, operational and organisational measures to manage cybersecurity risks. For software development teams, the most relevant clauses are Article 21(2)(d), 21(2)(e), 21(2)(f) and 21(2)(i).

Article 21(2)(d) covers supply chain security. In a development context, that means your team must know which third-party libraries, open-source dependencies, cloud services and development tools affect your product risk.

Article 21(2)(e) covers security in acquisition, development and maintenance of network and information systems. For engineering teams, this maps directly to secure SDLC controls: code review, SAST, DAST, vulnerability handling and secure maintenance after release.

Article 21(2)(f) covers policies and procedures to assess whether cybersecurity risk-management measures work. A policy alone is not enough. Your team needs test records, scan cadence, retest evidence and proof that critical findings are tracked to closure.

Article 21(2)(i) covers human resources security, access control and asset management. For DevSecOps, this means least-privilege access to repositories, CI/CD pipelines, cloud environments and production systems, with documented access reviews.

If your compliance team is still translating Article 21 into control areas, explore NIS2 Article 21 risk management measures, explaining the full Article 21 requirement set.

The Cyberbeveiligingswet: what changes for Dutch companies in July 2026

The Cyberbeveiligingswet is the Dutch law that transposes the EU NIS2 Directive into national law. It is expected to replace the current Wet beveiliging netwerk- en informatiesystemen once it enters into force.

For Dutch companies, the practical change is that more organisations will need to demonstrate duty of care, incident reporting readiness and registration. The exact scope depends on sector, size and whether the company is classified as an essential or important entity.

Essential entities include organisations in sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, ICT service management, public administration and space.

Important entities include sectors such as postal services, waste management, manufacturing, food and digital providers. Software and IT services companies can fall into scope when they meet the relevant size and sector criteria, or when they provide services that support essential-sector clients.

For Article 21 and Article 23 breaches, NIS2 sets fine thresholds of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, whichever is higher. With important entities, the threshold is at least EUR 7 million or 1.4% of worldwide annual turnover, whichever is higher.

For engineering and DevOps teams, the key point is not the fine. The key point is the evidence request that comes before an audit, customer questionnaire or supervisory review: “Show that your development controls were active, reviewed and corrected when findings appeared.” That means the Cyberbeveiligingswet creates a documentation problem as much as a security tooling problem. A working pipeline that leaves no audit trail will be hard to defend.

Not sure if your DevSecOps process meets NIS2 Article 21? Sunbytes runs a structured NIS2 readiness check against your current development pipeline, mapping your existing controls to Article 21 obligations and producing a remediation roadmap with evidence requirements. ISO 27001 certified. All engagements can operate under a signed DPA. Check your NIS2 readiness.

How DevSecOps controls map to NIS2 Article 21 obligations

NIS2 does not mention DevSecOps by name. But Article 21(2)(d), 21(2)(e), 21(2)(f) and 21(2)(i) describe the outputs that a mature DevSecOps pipeline should produce: dependency control, secure development checks, access governance and repeatable effectiveness testing.

The control itself is only half of the requirement. The other half is evidence.

If your pipeline already runs SAST and dependency scanning with documented remediation SLAs, you have the evidence base for parts of Articles 21(2)(d) and 21(2)(e). The gap is usually not the tooling. The gap is whether the output is retained, reviewed and connected to ownership.

A SAST finding that appears in a build log but never becomes a ticket is weak evidence. A SAST finding that is logged, assigned, risk-ranked, fixed, retested and linked to a release record is usable evidence.

The same applies to dependency scanning. A dependency tool that flags CVEs is useful, but Article 21 evidence needs the next step: which CVEs were accepted, which were fixed, which were deferred and who approved the decision.

For who need the pipeline mechanics behind these controls, read our DevSecOps pipeline guide. It explains how CI/CD, automated security checks and release gates work together.

What the audit evidence trail looks like

A NIS2 evidence trail should answer four questions:

1. What control exists?
2. When did it run?
3. What did it find?
4. What changed because of the finding?

For a DevSecOps team, the evidence trail usually sits across several systems: CI/CD logs, security tooling dashboards, ticketing systems, access review records, incident response documentation and release notes. The compliance risk appears when those systems do not connect.

A practical evidence pack for software development should include:

The audit question is rarely “Do you use SAST?” It is more likely to be: “Show evidence that your SAST control was active over the past 12 months, and show how high-severity findings were handled.”

The same standard applies to access control. A role-based access policy is useful, but the stronger evidence is a quarterly review record: who had access, what changed, who approved it and which accounts were removed.

Incident response evidence needs a separate timeline. Article 23 requires an early warning within 24 hours of becoming aware of a significant incident and a more detailed incident notification within 72 hours. Your engineering process should already define who confirms technical impact, who opens the incident record, who collects indicators of compromise and who approves the notification path.

Steps to take before July 2026

1. Map your current DevSecOps controls to Article 21(2)(d), 21(2)(e), 21(2)(f) and 21(2)(i). 

Owner: CISO or DevOps Lead. 

Output: one gap analysis document showing which controls exist, where evidence is stored and where the gaps sit.

2. Establish a quarterly access review cadence for CI/CD pipelines, code repositories and production environments. 

Owner: IT Manager. 

Output: access review record with reviewer name, approval date, removed accounts and exception notes.

3. Verify SAST and SCA tooling in your CI/CD pipeline. 

Owner: DevSecOps engineer. 

Output: scan reports stored by release, with findings assigned to tickets and retained for at least 12 months.

4. Schedule a penetration testing service if no valid test has been completed in the past 12 months. 

Owner: CISO. 

Output: pentest report, remediation roadmap and retest evidence for critical and high findings.

5. Document your incident response procedure for development and production systems. 

Owner: CISO or IT Director. 

Output: named roles, escalation path, severity criteria and detection-to-notification timeline.

6. Assess your development supply chain. 

Owner: DevOps Lead. 

Output: dependency inventory, development tooling list, vendor security review notes and a policy for approving new dependencies.

These six steps produce the evidence base that Article 21 compliance requires. Starting before July 2026 gives your team time to build the access review cadence, schedule testing and close high-risk findings before a customer or regulator asks for proof.

After the gap analysis, some teams discover the missing control is not a tool but ownership. This is where a dedicated DevSecOps role becomes necessary.

How Sunbytes supports NIS2-ready DevSecOps

NIS2 Article 21 requires evidence that the controls your team already runs, or should run, are documented, tested and effective. The gap between a functioning DevSecOps pipeline and a NIS2-ready one is usually an audit trail, not a tooling rebuild.

Sunbytes helps Dutch companies turn that evidence gap into a remediation roadmap. Our CyberSecurity Solutions map CI/CD controls, access reviews, vulnerability handling and incident-response records to NIS2 Article 21 obligations. The Digital Transformation Solutions help engineering teams implement the required delivery changes in the pipeline, while Accelerate Workforce Solutions can add vetted DevSecOps or QA capacity when ownership is missing. ISO 27001 certified. Engagements can run under a signed DPA with audit-ready documentation.For NIS2-ready DevSecOps, the goal is a development process that can prove what it controls: scan results, access reviews, remediation records, incident timelines and evidence owners. Sunbytes helps Dutch companies structure that work across delivery, security and capacity. Request a NIS2 readiness check for your DevSecOps pipeline.