What NIS2 actually means for your network team
NIS2 is often discussed as a governance and reporting exercise: registering with the national authority, appointing accountable management, meeting incident reporting deadlines. All of that is real, but it's the second half of the story. The first half, Article 21, is a list of technical and organizational security measures, and it lands squarely on the desk of whoever runs your network and infrastructure.
Here is what Article 21 actually asks for, translated out of regulatory language and into the kind of work a network or security engineer recognizes.
Risk analysis and information system security policies
This sounds like paperwork, but it's really asking whether your risk register reflects your actual network topology. If your risk analysis was last updated before your most recent segmentation project, firewall migration, or cloud expansion, it doesn't reflect your real attack surface. This measure only works if it's a living document tied to real architecture, not an annual template exercise.
Incident handling
NIS2 expects a defined process for detecting, managing, and reporting incidents, not just tooling. A SIEM and an IDS are necessary but not sufficient. What's actually being asked for is a runbook: who decides an event is an incident, who escalates it, and how fast that decision gets made relative to the 24-hour early warning and 72-hour notification clock NIS2 sets for significant incidents.
Business continuity and crisis management
This is where network design choices get tested against reality. Redundant links, failover paths, and backup and recovery procedures all need to be more than a diagram. If nobody has actually pulled the primary link and watched failover happen, or restored from backup under time pressure, this measure isn't met, regardless of what the architecture document says.
Supply chain security
NIS2 explicitly extends security expectations to suppliers and service providers. For a network team, this means knowing which vendors have access to your infrastructure (remote management tools, MSP access, cloud provider consoles) and whether that access is scoped, monitored, and revocable. A supplier risk assessment that lives in procurement and never touches the network team's access control lists isn't meeting this measure in practice.
Security in system acquisition, development, and maintenance
This covers patch management, vulnerability handling, and secure configuration, areas where network and security engineering do the actual work. It also covers something teams often underweight: the security implications of how infrastructure gets deployed. A templated deployment pipeline (via Catalyst Center, Ansible, or similar) is a security control in its own right, since it's what stands between "documented policy" and "what's actually configured on every device."
Policies and procedures for cryptography and encryption
This one is straightforward on paper but often inconsistent in practice: TLS versions, VPN cipher suites, and certificate lifecycle management tend to accumulate technical debt over years of incremental changes. NIS2 asks organizations to actually know their current cryptographic posture across the estate, not assume it based on how things were configured when they were first deployed.
Human resources security, access control, and asset management
Access control policy is only as good as the identity and network access control systems enforcing it. This is the measure most directly connected to NAC deployments: if your 802.1X and MAB policies don't map cleanly to defined roles, and if you can't produce evidence of who had access to what and when, this measure is a gap regardless of how good your written access control policy looks.
Multi-factor authentication and secure communications
Explicitly named in Article 21, and increasingly treated as a baseline rather than an enhancement. The practical question isn't whether MFA exists somewhere in the environment, but whether it's consistently enforced at the points that actually matter: VPN access, admin interfaces, and privileged accounts, including the ones that get overlooked because they're old or "internal only."
Where the gap usually is
Most mid-sized organizations already have pieces of each of these measures. The gap NIS2 exposes is rarely a missing control. It's the absence of a single, coherent picture connecting the technical reality of the network to a risk framework someone can actually be accountable for at board level. That's the translation work that turns a list of technical measures into an NIS2-compliant program, rather than a collection of tools that happen to overlap with the requirements.
Esnami combines hands-on network security engineering with NIS2 compliance advisory, so a gap analysis results in controls your team can actually implement. Get in touch if you're assessing where your network stands against Article 21.