NIS2 in Practice: What Enterprise IT Teams Actually Need to Do

NIS2 expanded the scope of the original NIS directive significantly. More sectors are covered — energy, transport, health, digital infrastructure, manufacturing, and others — and the obligations are more prescriptive. The deadline for EU member states to transpose it into national law was October 2024.

The core requirements fall into two categories: risk management measures and incident reporting. Risk management includes access control, supply chain security, cryptography, vulnerability handling, and business continuity. Incident reporting requires notifying authorities within 24 hours of a significant incident and providing a full report within 72 hours.

The sanctions are serious. Senior management can be held personally liable. Maximum fines for essential entities reach €10M or 2% of global turnover.

When we assess an organization's NIS2 readiness, the most common gap isn't documentation — it's operational. Organizations have policies. They often don't have the technical controls to enforce them, or the monitoring to detect when they're violated.

Security scanning in the CI/CD pipeline is a good example. Most organizations don't have it. They run manual security reviews occasionally, or rely on annual penetration tests. NIS2 expects continuous vulnerability management — which means automated scanning as a standard part of how you ship software.

Incident response is another gap. Having an incident response plan is not the same as having practiced it. NIS2's 24-hour notification requirement means you need a process that can actually execute under pressure, not a document that describes what you'd ideally do.

The organizations that handle NIS2 well treat it as an engineering problem, not a compliance exercise. The question isn't 'how do we document that we meet these requirements?' — it's 'how do we build systems that actually do?'

Start with asset inventory and risk assessment. You can't protect what you can't enumerate. Then prioritize the technical controls that address your highest-risk gaps — access management, vulnerability scanning, logging and monitoring — before investing in documentation.

Supply chain security deserves specific attention. NIS2 requires organizations to assess the security practices of their suppliers. For software, this means understanding what's in your dependency tree and how you're notified of vulnerabilities in third-party components.

The sustainable approach to NIS2 compliance is to make the required controls part of how you normally build and operate software — not a parallel workstream that sits alongside delivery.

In practice, this means automated security scanning in CI/CD, infrastructure-as-code with security policies enforced at the pipeline level, structured logging that feeds into a SIEM, and runbooks for incident response that are tested regularly.

We've built this into our standard delivery process because our government clients require it. The result is that NIS2 compliance is largely a byproduct of how we work, not an additional burden. Organizations that build the same way will find the ongoing compliance cost is much lower than those who treat it as a separate exercise.