The Next 90 Days
Two hard dates, no transition period, and one question you must be able to answer on 15 August.
Count with me for a second.
On 15 August 2026, the Dutch Cybersecurity Act (Cyberbeveiligingswet) enters into force. Not "is announced," not "phases in." Enters into force. The Senate voted on 7 July; the government has locked the date. There is no general transition period. The obligations apply immediately. Only higher-education institutions get three years.
On 11 September 2026, a second clock starts. From that day, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act. First warning within 24 hours.
That's not a horizon measured in months. It's a matter of weeks. And the ninety days ahead of you aren't the run-up to those dates. They contain both deadlines and your first weeks living under them. That second part is the part nobody talks about, and it's the part that counts.
Because the deadline isn't an audit somewhere in 2027. The deadline is whether you can demonstrate you're in control on the day the clock starts running.
Most organizations I talk to now know that they're in scope. They have a plan to make a plan. They have a consultant, a gap analysis from March, and a steering group that reconvenes after the summer. That's exactly the position in which the clock catches you off guard: in scope, time running, and the plan is an agenda item.
This piece is not an explainer on NIS2. Those exist in abundance. This is a countdown: what must be done, tested, and demonstrable, and in what order, because the two dates leave you no choice about the order.
1. What changes on 15 August
The Cybersecurity Act (Cbw) implements NIS2 in the Netherlands and replaces the 2018 Wbni. More than 8,000 organizations fall directly within scope, across eighteen sectors. On top of that, roughly 500 organizations are formally designated as critical entities under the simultaneously introduced Critical Entities Resilience Act (Wwke), the Dutch CER implementation.
One thing up front, because it's consistently told wrong: the law is not one document. There are three layers. The Cbw is the framework. The Cybersecurity Decree (Cbb) works out the obligations: risk management, registration, the training requirement for directors. It enters into force at the same time. The third layer is ministerial regulations per sector, which specify, among other things, when an incident must be reported. If you wait until all three layers have settled before you start, you start too late.
Four things switch on at 00:00 on 15 August.
Registration duty. You must register your organization in the entity register, in the Netherlands via mijn.ncsc.nl. The NCSC itself estimates registration at ten minutes, provided you've gathered the data beforehand. That "provided" does the work: both network and organizational data are requested, which means your CISO, network administrator, and a director all have to be involved. And you need eHerkenning (the Dutch eID for businesses). This is the cheapest task on your list and simultaneously the easiest one to trip over on 14 August.
Duty of care. Appropriate and proportionate technical, operational, and organizational measures, based on an all-hazards approach. That explicitly includes physical: a fire in the server room is a risk that requires measures. And it extends to your supply chain. More on that shortly.
Reporting duty. Significant incidents, in phases, from the moment you become aware of them: within 24 hours an early warning to your CSIRT and sector regulator, within 72 hours an initial notification, and within one month at the latest the final report.
Note that last figure. The Cbw gives you a month for the final report. The CRA works on fourteen days. Two laws, two clocks, different numbers. Anyone who builds one runbook on "it's 24/72 anyway" builds a runbook that violates one of the two laws.
And then the board. This is the part that goes quiet in the meeting. Directors of essential and important entities are ultimately responsible for compliance with the duty of care and can be held personally liable if the organization fails to meet it. They are also required to complete training and must be able to produce a certificate of attendance.
Read that last sentence again as a security officer. There is now a physical document that is either in a folder, or isn't. That's no longer a policy discussion. That's a piece of evidence.
Supervision is divided among sector regulators: RDI, DNB, AFM, IGJ, ILT, and NVWA, depending on your (sub)sector. The NCSC is not a regulator. It's your CSIRT and the place where you register. That distinction is not semantics: it determines whom you report to, and who can enforce.
Essential entities get proactive supervision: being checked without anything having happened. Important entities get reactive supervision: after the fact, following an incident or a signal. Fines run up to €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities. Always: the higher of the two.
One power deserves separate attention, because it was added by amendment and therefore goes further than NIS2 itself prescribes: the relevant minister can require essential and important entities to stop using certain products or services from specific suppliers, with a deadline for replacement. National security as the grounds, your architecture as the subject. Anyone who doesn't know their supplier concentration doesn't know their own replaceability.
2. What starts on 11 September
The CRA, Regulation (EU) 2024/2847, has a longer run-up than most people think and a sharper sting than they hope.
From 11 September 2026, the reporting obligations of Article 14 apply. Actively exploited vulnerabilities and severe incidents affecting the security of your product:
- 24 hours: early warning
- 72 hours: full notification
- 14 days: final report after a corrective measure is available (for actively exploited vulnerabilities); one month for severe incidents
You report only once, through ENISA's Single Reporting Platform, addressed to the CSIRT of your main establishment, with ENISA informed simultaneously. The platform is operational as of 11 September; there is a testing period beforehand. If you're in scope of the CRA: go test. A reporting channel you use for the first time during an actively exploited vulnerability isn't a reporting channel, it's a second incident.
Fines run up to €15 million or 2.5% of worldwide annual turnover. That highest bracket applies to, among other things, breaches of the essential requirements in Annex I and of the obligations in Articles 13 and 14. So the reporting duty sits in the heaviest fine category.
Who is a "manufacturer"? Two surprises here.
The first: you're a manufacturer if you develop, or have developed, a product with digital elements and place it on the market under your own brand name. Paid or free. But you're also treated as a manufacturer, as an importer or distributor, when you place a product on the market under your own name or trademark, or carry out a substantial modification. Take an open-source library, build it into a product you supply under your own name. You're a manufacturer. Not a steward. Manufacturer.
For the average Dutch organization that thinks "the CRA is for hardware vendors": do you white-label software? Do you supply a portal under your own brand? Then this conversation is for you.
The second surprise is in the transitional provision, and it's sharper than it looks. Article 69(2) says products placed on the market before 11 December 2027 fall under the CRA requirements only if they undergo a substantial modification from that date. That sounds like breathing room. But paragraph 3 makes an explicit exception to it:
"By way of derogation from paragraph 2, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027."
Translated: the rest of the CRA waits for your next substantial modification. The reporting duty does not. It applies from 11 September 2026 to your entire installed base. To that product from 2019 still running at forty customers, whose builder is two employers down the road. You have no design obligation for that product. You do have a reporting obligation, and it starts running the moment you "become aware" of active exploitation. Do you know what's running? Do you know who reports it? Do you know within how many hours you'd hear?
And for completeness, in one paragraph: the financial sector already knows this pattern. DORA has applied since January 2025 and has already had the discussion there: not "is your data safe," but "can you keep operating when your technology fails." What happens to the rest of the Netherlands on 15 August, banks and insurers already have behind them. That's not comfort. It's a free preview of what regulators are going to ask.
3. The letter you don't get
Now the part that's most often told wrong, usually by people who want to sell you something.
You hear it a lot: "tens of thousands of companies fall indirectly under NIS2." That's not true, and it's important to be precise, because the truth is more uncomfortable.
The Cbw imposes no direct obligations on suppliers of Cbw organizations. In fact, the NCSC is explicit: a regulator will not supervise suppliers and therefore will not fine them either. No letter. No fine. No registration duty.
What does happen: Article 21(3)(d) requires Cbw organizations to take measures to secure their supply chain, including the relationships with their direct suppliers and service providers. In determining what is "appropriate," they must take into account the specific vulnerabilities of each direct supplier and the overall quality of that supplier's products and security practices, including secure development procedures.
So: the regulator isn't coming for you. Your customer is.
According to the NCSC, you'll likely appear in the risk inventory if you supply services or products related to a Cbw organization's network and information systems, if you supply an ICT component, or if you have access to their systems. The coffee supplier, no. The party managing office IT, yes.
And here's the operational pain, which the NCSC names honestly: the criteria aren't in the law. "Appropriate measures" leads, per supplier, to a bespoke package of requirements. Supply to multiple Cbw organizations, and you'll get different lists of measures to respond to. Five customers, five questionnaires, five different definitions of the same thing.
A certificate helps that conversation, since you can quickly show which standards you follow. But the NCSC warns in the same breath: it offers no guarantee that the identified chain risk is actually covered. ISO 27001 or CYRA can be handy. The Cbw doesn't require them.
No law compelling you. But a market assessing you. That's not a softer variant of compliance. It's compliance with no clear requirements and no clear endpoint, and it starts on 15 August, when 8,000 organizations begin asking at once.
4. The trap: "audit-ready someday" versus "in control now"
I break into systems. That's my job. And the pattern is the same every time.
I come into organizations that have passed their audit. The certificate is on the wall. The policy is set, the risk assessment is done, the measures are "implemented." And then the service account from the 2023 migration turns out to still exist, with permissions no one can explain anymore, outside the reach of every offboarding process, because it isn't tied to a human.
That service account is in no audit report. Not because the auditor was bad. Because an audit is a point-in-time snapshot.
That's the whole issue. An audit proves you had it in order on one Tuesday. Attackers pick a different Tuesday. And from 15 August, regulators will too: for essential entities without cause, without an incident, without notice.
The space between those two Tuesdays is where my work happens. It's also exactly the space where "compliant" ends and "in control" begins.
The difference isn't rhetorical, it's testable. Ask yourself these four questions, and accept only answers with a timestamp:
- Can you demonstrate a measure works today, or only that it was described in March?
- If you get a call now about active exploitation: how many hours does it take you to determine whether it affects you? You have 24 until the first report, and that clock starts at "become aware," not "understood."
- Who pushed the button on the report last time, and are they still here?
- If the regulator asks for evidence tomorrow morning, does that cost you an export or three weeks?
A program that answers "three weeks" to the fourth question is not in control. It's documented. That's something else, and the difference costs you 24 hours you don't have.
Compliance describes what you would do. Control is what happens when it goes wrong, at quarter past three in the morning, in August, when half your team is on holiday.
That's not a rhetorical holiday, by the way. 15 August falls in the middle of the summer break.
5. The next 90 days: what must be done, tested, and demonstrable
No eighteen-month roadmap. Three phases, and they're ordered not by comfort but by the two dates. What's legally required before 15 August is in phase 1, full stop. What touches the CRA clock is in phase 2. And phase 3 is where "in control" gets proven, in the first weeks you're running under the law.
Phase 1 · Before 15 August: the non-negotiables
Everything here must be done on the day the law enters into force. Not "under way." Done.
- Define your scope. Essential or important entity? The distinction sets your fine ceiling and whether you get proactive supervision. Even "we're not in scope" is a decision you must be able to defend, with a date.
- Register. Sort out eHerkenning now, gather the network and organizational data beforehand (NCSC checklist), put your CISO, network administrator, and a director in one meeting, and register via mijn.ncsc.nl. Mandatory as of 15 August.
- Arrange board training and keep the certificate of attendance. This is not a formality; it's the piece of evidence the personal-liability story lands on.
- Have the board sign off on residual risks, with a date. Liability that isn't assigned sits with your directors without their knowing it.
- Demonstrable on 15 August: registration confirmation, training certificates, a dated scope decision, a signed board resolution.
Phase 2 · Before 11 September: the CRA clock
- Determine whether you're a manufacturer under the CRA. Do you place something on the market under your own brand, or make a substantial modification? Then probably yes, even if you don't think of yourself as one.
- Map your installed base. All products placed on the market before 11 December 2027 fall under the Article 14 reporting duty. Know what's running, at whom, in which version.
- Build one reporting runbook with two clocks. Cbw: 24h → 72h → 1 month. CRA Art. 14: 24h → 72h → 14 days (1 month for severe incidents). Put them side by side; they are not identical. Record who establishes "become aware" and how that moment is logged.
- Test ENISA's Single Reporting Platform during the testing period, before 11 September, not after.
- Demonstrable on 11 September: a tested runbook, a decision card with names and phone numbers, a product register, and a measured time-to-first-report.
Phase 3 · The first weeks under it: where "in control" is proven
This is why it's called "the next 90 days" and not "the last 30." Meeting the law is phases 1 and 2. Demonstrating you're in control happens after, and it's exactly what a proactive regulator comes to check.
- Adopt one control baseline and map it to both laws. ISO 27001 or NIST CSF 2.0, mapped to the duty of care and (if you're a manufacturer) to CRA Annex I. The mapping table (control → legal requirement → evidence → owner → last verified) is the most important document you'll make this summer.
- Capture evidence continuously, in the process, not in a quarterly sprint. A control without a fresh evidence date is an assumption.
- Run your reporting runbook again with a holiday roster. 15 August falls in the summer.
- Prepare for proactive supervision (essential entities): checks without an incident, without notice.
- Set up a quarterly cycle in which evidence ages and is re-confirmed.
- Demonstrable, ongoing: one mapping table with an owner per control and a date per piece of evidence.
6. One control, many frameworks
Reading phase 3, you'll have thought something along the lines of: this is doing the same work twice.
It doesn't have to be, and that's the best news in this whole piece.
Access control is access control. Logging is logging. Continuity is continuity. That same control appears in the Cbw duty of care, in CRA Annex I, in ISO 27001, in DORA, and in the GDPR: different words, different numbering, different regulator. Most organizations build it four times, evidence it four times, and defend it four times, because the compliance work is organized per law instead of per control.
Flip it around. Build the control once. Capture the evidence once. Map that one control to every law that demands it.
That's not a trick to do less. It's the only way to survive these ninety days without doubling the work, and it's exactly why the mapping table from phase 3 is the most important document you'll make this summer. Not because a regulator asks for it. Because it's the only artefact that tells you which evidence you're missing before someone else asks the question.
7. What "operated, not archived" means
I built Soveryne because I saw the same thing too often: organizations with a fine policy folder and a service account from 2023 still left open, evidence that was valid on the day it was collected and on no day after, in a compliance stack that itself ran outside the EU jurisdiction it was meant to provide evidence for. Evidence that runs with your systems instead of alongside them, inside the jurisdiction you have to account for it in: that's the difference between a program you operate and one you archive.
Beyond that, I'm not selling you anything here. If you take one thing from this piece, let it be the mapping table. You can start it in a spreadsheet on Monday.
8. A few weeks left
Back to the countdown.
On 15 August, someone asks you a question. Maybe a regulator, maybe your biggest customer, maybe your own director who has just understood what "personally liable" means. The question isn't "are we compliant?" That question has an answer you wrote down in March.
The question is: can you demonstrate it, today, with a date on it?
If the answer is "give me three weeks," you know what the next ninety days hold. If the answer is an export, you're in control.
There is no transition period. That's not meant as a threat. It's just the date.
Working through the next ninety days? Soveryne Command is in early access, and the way in is a free intake. Tell us what you have to demonstrate, and by when. Register your interest
Ilke Tosunoğlu is an ethical hacker and penetration tester, and founder of Soveryne. Want to respond or talk through the countdown? LinkedIn.
