What a scale-up actually needs to be
audit-ready, investor-ready,
and NIS2-ready.

First, the classification question, answered precisely

The Cyberbeveiligingswet — the Dutch implementation of NIS2 — was approved on 7 July 2026 and enters into force on 15 August 2026. Whether it applies to your company comes down to two thresholds, and you only need to cross one of them.

Essential entities are companies with 250 or more employees, or annual turnover above €50 million, or a balance sheet above €43 million, operating in high-criticality sectors under Annex I — energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, and a handful of others.

Important entities are companies with 50 or more employees, or turnover or balance sheet above €10 million, operating across a broader set of sectors spanning both Annex I and Annex II — this pulls in postal services, waste management, chemicals, food, manufacturing, digital providers, and research organizations, among others.

There's a separate carve-out worth knowing about too: certain digital infrastructure and trust service providers fall into scope regardless of size, because the sector itself is judged systemically important. If you're running DNS services, a cloud platform, or a qualified trust service, headcount doesn't save you.

For a company sitting at 30 to 200 employees — the range where most of our clients live — the important-entity threshold is the one that matters, and 50 employees plus €10 million in turnover is a bar that a lot of well-funded scale-ups clear well before they think of themselves as a "regulated" company.

Second, even if you're not in scope, the market already expects this

Here's the part that gets missed in every conversation about legal thresholds: enterprise buyers and institutional investors stopped waiting for regulation to force the question years ago. A Series B due diligence process already expects SOC 2-level maturity as a baseline, not a differentiator. An enterprise procurement team already runs a security questionnaire before signing, regardless of what the Cbw says about your specific headcount. If your buyer or your investor already expects mature identity management, device control, and incident response, the legal threshold becomes close to irrelevant — the commercial one already applies.

This is the argument we make to founders who tell us "we're not in scope yet." Being technically exempt from a law doesn't exempt you from the market that law was written to catch up with.

Third, what actually needs to exist

Article 21(2) of the NIS2 directive lists the minimum security measures entities need in place, and nearly every clause maps directly onto IT foundations that any growing company should have anyway, law or no law.

Identity — a real identity provider with SSO and phishing-resistant MFA, not a spreadsheet of shared logins. Article 21(2)(j) specifically calls out access control policies and asset management as a required measure.

Devices — enrolled, managed, patched, encrypted by default. If a laptop leaves the company without being wiped, that's not a hypothetical risk, that's an open incident waiting to be discovered.

Onboarding and offboarding — automated, HRIS-triggered, so access is provisioned and revoked the same day someone joins or leaves, not whenever IT gets around to it.

Incident response — and this is where the Cbw gets specific and unforgiving: a 24-hour early warning to the relevant authority, a 72-hour incident notification, and a final report within one month. You cannot build that timeline reactively once an incident has already happened. It has to exist before you need it.

Governance and evidence — policies that are written down, reviewed, and actually followed, with a paper trail that proves it. Auditors and regulators are both, fundamentally, asking the same question: show me the evidence, not just the intention.

Supply chain awareness — Article 21(2)(d) explicitly requires supply chain security, meaning you need to know what your vendors and SaaS tools can access and what happens if one of them is compromised.

The honest bottom line

None of this is a shopping list you complete once and file away. It's an architecture, and architecture has an order. Identity comes before device management, because devices are only as trustworthy as the accounts logging into them. Onboarding automation comes before incident response, because you can't respond well to an incident involving an account that shouldn't have existed in the first place. Governance and evidence sit on top of all of it, because none of the other layers matter to an auditor or an investor if you can't prove they're actually in place.

Build it in that order, once, and you walk into an audit, a funding round, or a regulator's inquiry with the same answer every time: here's what we have, here's how it works, here's the evidence. Build it reactively, tool by tool, in response to whichever deadline is loudest that quarter, and you'll spend far more money arriving at a weaker version of the same result.