NIS2 secure-development duties — what in-scope teams owe

The EU's NIS2 Directive widened the set of organisations that must manage cybersecurity risk and broadened what counts as adequate. Member States have been transposing it into national law, and enforcement is ramping. If your organisation operates in a covered sector — energy, transport, banking, health, digital infrastructure, managed services, and others — the relevant question is no longer whether NIS2 reaches you, but which duties apply to your software and how you evidence them.

The secure-development and vulnerability angle

NIS2 frames cybersecurity as risk management across the lifecycle, and two strands land squarely on engineering teams:

• Security in development and maintenance. Covered entities are expected to account for security across acquisition, development, and maintenance of network and information systems — which in practice means secure-by-design practices, dependency hygiene, and controls baked into the build rather than bolted on after.
• Vulnerability handling and disclosure. Entities are expected to have a coordinated way to handle and disclose vulnerabilities, including those in the components they ship and depend on. That assumes you can actually see the weaknesses in your stack in the first place.

The supervisory regime adds weight: management bodies can be held accountable, and penalties for essential and important entities are non-trivial. The practical pressure is to show your work — what you scanned, what you found, what you fixed, and when.

Where a scan helps

The hard part for most teams is the gap between a directive written in risk-management language and a real repository. OLYDI fingerprints the stack and surfaces the controls and weaknesses that map to these duties — dependency and configuration findings, the boundaries around sensitive components, and what is and is not logged — as findings you can triage in the Security tab. It does not make you NIS2-compliant and it is not a substitute for a formal assessment; it gives you a baseline read so the secure-development and vulnerability-handling conversation starts from evidence rather than an empty checklist.

Get your baseline

npx @olydi/cli scan
# Scan complete. Findings written to SARIF.

Run the scan, review the findings, and decide what to clear first. The scan is free; clearing findings at volume is paid on Valty tiers.

This article is general information about regulatory developments, not legal advice. Consult qualified counsel for your specific obligations.