NIS2 Netherlands Mid-Market: What IT Teams Must Know

If you run IT for a mid-sized company in the Netherlands, NIS2 has probably landed on your desk twice: once as a vague directive from Brussels, and again as the Cyberbeveiligingswet, the Dutch law that actually puts it into force. The gap between those two moments is where most confusion lives. This article is about what NIS2 Netherlands mid-market obligations mean in practice, for companies that were never in scope for cybersecurity regulation before and now suddenly are.

The short version: NIS2 pulled a much wider group of Dutch organisations into scope than its predecessor, and a meaningful share of them are exactly the mid-market companies that don't have a dedicated compliance department. If that's you, the good news is that most of what the law expects overlaps heavily with access-control practices you can actually implement with the Microsoft stack you already run.

This is not legal advice, and no software makes you compliant on its own. What follows is a practical read on scope, obligations, and where identity and access automation genuinely helps.

From Wbni to Cyberbeveiligingswet: what actually changed

The Netherlands previously implemented the original NIS Directive through the Wet beveiliging netwerk- en informatiesystemen (Wbni), which applied to a fairly narrow set of critical infrastructure operators. NIS2 replaces that regime with the Cyberbeveiligingswet, and the scope expansion is the whole story.

Where the old law mainly caught energy, drinking water, and a handful of digital infrastructure providers, NIS2 adds sectors like managed service providers, manufacturing, food production, waste management, postal services, public administration, and digital providers more broadly. Within those sectors, the deciding factor for whether you're in scope is no longer "are you critical infrastructure" but a combination of sector and company size.

That size threshold is exactly why this now matters for the mid-market. A company with roughly 50 or more employees, or annual turnover above the thresholds set in the implementing regulation, operating in an in-scope sector, can fall under the law even if it never thought of itself as critical infrastructure. IT managers at manufacturers, logistics companies, healthcare providers, and regional MSPs are discovering this the hard way.

Essential versus important entities

The Cyberbeveiligingswet splits organisations into two categories, and the split determines how closely a supervisory authority will look at you.

Essential entities	Important entities
Typical size	Larger organisations, often 250+ staff or higher turnover, in higher-risk sectors	Smaller organisations, often 50-249 staff, in the same or adjacent sectors
Supervision	Proactive: authorities can inspect without a prior incident	Reactive: authorities generally act after an incident or signal
Obligations	Same core risk-management and reporting duties	Same core risk-management and reporting duties
Sanctions	Higher maximum fines	Lower maximum fines, still substantial

Both categories carry the same underlying duty of care and incident-reporting obligation. The difference is supervisory intensity and the ceiling on fines, not the substance of what good security looks like. If you're unsure which bucket your organisation lands in, that determination sits with legal and compliance, but don't wait for the answer before doing the IT groundwork, because it's the same groundwork either way.

Why mid-market IT feels this more than large enterprise

Large enterprises usually already run a security team, a GRC function, and some flavour of identity governance. Mid-market companies typically don't. That's the real story behind NIS2 Netherlands mid-market coverage: the law didn't get stricter for enterprise, it got wider for everyone else.

A few reasons mid-market IT teams end up carrying more of this than they expect:

• No dedicated compliance headcount. The person figuring out what "access control policy" means in practice is often the same person managing the helpdesk queue.
• Supply-chain pressure. Organisations outside the formal scope still get pulled in when a larger customer or an in-scope partner asks for evidence of their security posture during vendor due diligence.
• Legacy access sprawl. Environments that grew through manual group management and ad hoc permission grants have the most cleanup to do before they can demonstrate least privilege.
• Mixed on-prem and cloud identity. Many Dutch mid-market companies still run on-prem Active Directory alongside Entra ID, doubling the places access has to be controlled and evidenced consistently.

What the duty of care means for identity and access

The Cyberbeveiligingswet's central obligation, the zorgplicht, requires appropriate and proportionate technical and organisational measures to manage cybersecurity risk. It doesn't hand you a technical checklist, but access control shows up explicitly among the baseline risk-management measures, alongside things like incident handling, business continuity, and supply-chain security.

In IT terms, that translates into a short list of expectations that should feel familiar to anyone who has looked at ISO 27001 or a security audit before:

1. A defined policy for who gets access to what, and why. Not "ask your manager on Teams," but a rule tied to role, department, or project.
2. Least privilege as the default, not a periodic cleanup exercise. New hires and role changes should start with the minimum required, not a copy of a colleague's access "to be safe."
3. One consistent source for identity attributes. Job title, department, location, and employment status need to live somewhere authoritative and drive access decisions the same way every time.
4. Access that follows people through their lifecycle. Joiners get access on day one, movers get it adjusted when their role changes, leavers lose it immediately, not at the next quarterly cleanup.
5. A record of who had access to what, and when. Supervisory authorities and incident investigators both want the same thing: a reconstructable history, not a best guess.

None of this requires a heavyweight enterprise IGA suite. It requires access decisions that are rule-based and logged rather than manual and undocumented, which is achievable for a mid-market Microsoft environment without a multi-year identity program.

Accountability moves up to the board

One change worth flagging specifically for mid-market leadership: the Cyberbeveiligingswet, in line with NIS2, makes management bodies accountable for approving and overseeing cybersecurity risk-management measures, and puts training obligations on them too. This is not purely an IT problem anymore in the way it might have been treated before.

For IT managers, that is a useful lever. If a director has personal accountability attached to whether access control is demonstrably in order, it gets a lot easier to secure budget for cleaning up group sprawl, retiring manual provisioning scripts, or investing in an audit trail that can survive a supervisory request.

Getting ready without overbuilding

The practical path looks the same for most mid-market Dutch companies, regardless of exact scope determination:

• Map which sector(s) your organisation and your customers sit in, and get a scope opinion from legal or a compliance advisor.
• Inventory where access decisions currently get made: Entra ID groups, on-prem AD groups, Microsoft 365 roles, and any manual exceptions living in spreadsheets or tickets.
• Tie group and role membership to attributes that already exist in Entra ID, so access follows a rule instead of a memory of who asked for what.
• Log every membership change against the attribute and moment that triggered it, so "who had access to what, and when" has a real answer.
• Treat this as ongoing hygiene, not a one-time project. Sustained risk management, not a clean snapshot on audit day, is the point.

This is precisely where ServiceChanger's ABAC engine fits. It automates Entra ID and on-prem AD group and role membership from attributes like department, location, and job title, keeps a log of every change, and gives you a self-service portal so access requests run through the rule instead of a side channel. It won't make you NIS2 compliant by itself, nobody's software will, but it produces the reproducible, auditable access foundation the law is actually asking for.

FAQ

Does NIS2 Netherlands mid-market coverage really include companies under 250 employees? Yes, in many cases. The Cyberbeveiligingswet uses sector plus size thresholds, and "important entities" typically start around 50 employees or a smaller turnover threshold within in-scope sectors. Confirm your exact status with legal or a compliance advisor.

Is the Cyberbeveiligingswet the same as NIS2? The Cyberbeveiligingswet is the Dutch national law that transposes the EU NIS2 Directive into Dutch legislation. It replaces the older Wbni and carries the same core obligations, adapted to Dutch supervisory structures.

Does ServiceChanger make us NIS2 compliant? No. No tool does. ServiceChanger automates attribute-based access in Entra ID and on-prem AD and logs every membership change, which produces evidence for the access-control parts of NIS2. Certification and full compliance run through your own risk assessment and your auditor.

We're not sure if we're an essential or important entity. Should we wait to act? No. The access-control groundwork, defined policy, least privilege, lifecycle automation, and an audit trail, is the same regardless of which category you land in. Start there while legal sorts out the formal classification.

Curious what your current Entra ID and on-prem AD setup would show an auditor today? Read more on the access governance, digital security and compliance page, browse related posts under NIS2 and compliance, or book a demo and we'll walk through it together.