This page presents an illustrative scenario – not a specific client matter – drawn from the types of incident reporting challenges that Dutch software-as-a-service groups commonly face. It describes how a mid-sized SaaS business operating across multiple EU member states developed a structured incident reporting playbook that aligned with GDPR compliance obligations, NIS2 requirements and, where relevant, DORA. The lessons below reflect genuine structural complexity that any Dutch technology group should consider before a real incident occurs.
Client Profile and Challenge
The group in this scenario is a Dutch-incorporated BV registered with the Kamer van Koophandel (KvK), providing cloud-based workflow software to financial sector clients in the Netherlands, Germany, Belgium and two non-EU jurisdictions. Its customer base includes entities supervised by the Autoriteit Financiële Markten (AFM) and De Nederlandsche Bank (DNB), which placed the group's services squarely within the scope of both NIS2 as an essential or important entity and, indirectly, the Digital Operational Resilience Act (DORA) – because its financial-sector clients were contractually required to flow down DORA obligations to critical ICT third-party providers.
The core challenge was fragmentation. The group had three separate processes for incident escalation: one drafted by its internal IT security team, one inherited from a recent acquisition, and one inserted into standard data processing agreements in response to a customer audit. None of the three processes referenced each other. None specified which supervisory authority received which notification, within what timeframe, and in what format. When a configuration error briefly exposed a subset of customer metadata to an unintended internal user group, the group spent more than 48 hours simply deciding whether the event was a notifiable breach under GDPR – time that eroded its ability to meet the 72-hour notification deadline to the Autoriteit Persoonsgegevens.
If your organisation faces similar fragmentation across multiple regulatory frameworks, the data protection and technology practice at Ferraz & Whitmore can help you map obligations before an incident occurs. Write to info@ferrazwhitmore.com or visit our contacts page.
Strategy and Rationale
The engagement focused on producing a single, cross-referenced incident reporting playbook that could be maintained by a small in-house legal and compliance team without specialist legal input at the moment of crisis. The strategic rationale was straightforward: regulatory deadlines – particularly the GDPR's 72-hour clock – do not pause for internal debate. A playbook succeeds if it eliminates the preliminary questions and leaves the team free to focus on the substance of the incident.
The design rested on four pillars:
- A single incident taxonomy. Every event that crosses a defined internal threshold is logged identically, regardless of which framework ultimately governs the notification obligation. The taxonomy avoids assumptions about severity at the point of detection.
- A decision tree for regulatory routing. Once an event is logged, the tree establishes within minutes whether the primary obligation runs under GDPR (notification to the Autoriteit Persoonsgegevens and, where required, to affected data subjects), NIS2 (early warning and incident notification to the competent authority under the Dutch NIS2 implementation), DORA (incident classification and reporting to the relevant financial supervisor via the prescribed channels), or a combination. Where a cross-border data transfer dimension existed – for example, processing of personal data relating to individuals in non-EEA jurisdictions – the tree flagged the need to verify applicable transfer safeguards before disclosing incident details externally.
- Pre-approved notification templates. Draft notifications were prepared in Dutch and English for each regulatory channel. Templates contain bracketed fields for variable facts but do not require the team to compose prose under time pressure.
- Roles, deputies and escalation contacts. For each step in the playbook, a primary owner and a named deputy were identified. External escalation contacts – including a lawyer Netherlands-qualified to advise on regulatory interactions – were embedded at the point in the decision tree where legal privilege considerations arise.
The rationale for building a combined GDPR–NIS2–DORA playbook rather than three separate documents was the overlap in factual assessment. Whether a cybersecurity incident involves personal data, affects a financial-sector client, or both, the initial fact-gathering steps are largely identical. Duplicating them across three documents increases the risk of inconsistency and wastes time.
Milestones and Complications
The project proceeded in three phases over approximately four months.
Phase 1 – Mapping. A comprehensive audit of existing contractual obligations (data processing agreements, ICT sub-contracting provisions inserted by DORA-regulated customers), internal policies and prior incidents produced a gap analysis. The principal finding was that the group had no documented process for determining whether an event qualified as a "significant" incident under DORA or a "major" incident under NIS2 – both of which carry distinct reporting timelines and formats that differ from the GDPR breach notification regime.
Phase 2 – Drafting and testing. The playbook was drafted and then stress-tested against three tabletop scenarios: a ransomware event affecting production infrastructure, an inadvertent data transfer to a recipient in a jurisdiction without an EU adequacy decision, and a third-party supplier outage that affected the availability of the group's service to financial-sector clients. Each scenario exposed gaps in the draft, which were corrected before sign-off.
Phase 3 – Integration and training. The playbook was integrated into the group's incident management tooling, and a two-hour training session was delivered to the security, legal and customer success teams jointly. A condensed one-page reference card was produced for out-of-hours use.
Two complications arose during the project that are worth noting for their broader relevance.
First, the proposed Digital Omnibus (COM(2025) 837, published 19 November 2025) – which, among other things, proposes to extend the GDPR breach notification deadline from 72 to 96 hours and to create a single entry point for incident reporting – was under active discussion during the engagement. The EDPB and EDPS issued Joint Opinion 2/2026 on 10 February 2026, supporting the extended deadline and single entry point but opposing other elements of the proposal. As of the time of writing, the Digital Omnibus remains a proposal in the ordinary legislative procedure and has not been adopted; it carries no legal force. The playbook was therefore built on current law, with a clearly flagged review trigger if and when the Digital Omnibus or any successor instrument is adopted. Designing a playbook around a proposal that may change materially before adoption would have been imprudent.
Second, the entry into force of Regulation (EU) 2026/1744 – the AI-specific Digital Omnibus instrument, in force since 27 July 2026 – created a short additional review loop for one product line that incorporated automated decision-making components. The playbook's taxonomy was extended to include a flag for AI-system involvement, given the distinct obligations that regulation introduces.
For groups navigating cross-border data transfer obligations as part of their incident response planning, the analysis in our deep-dive on India's DPDP cross-border transfer rules illustrates how transfer restrictions can interact with the disclosure steps required during an incident. Similar structural questions arise for transfers to other third countries.
Outcome Category
This is an illustrative scenario and no specific outcomes, amounts or client details are presented as real. The category of outcome that a structured playbook of this kind is designed to achieve is procedural readiness: the ability to initiate a notifiable-event response within minutes of detection, to route correctly across concurrent regulatory obligations, and to provide regulators with substantively complete initial notifications within applicable deadlines. Procedural readiness does not guarantee any particular regulatory outcome, but its absence is consistently identified in supervisory guidance – including guidance from the Autoriteit Persoonsgegevens – as an aggravating factor in enforcement assessments.
Three Transferable Lessons
The following lessons apply broadly to Dutch technology groups operating across the GDPR, NIS2 and DORA frameworks.
- Lesson 1: The 72-hour clock starts at awareness, not at certainty. A recurring source of delay is the instinct to investigate fully before notifying. The GDPR obligation to notify the supervisory authority arises when the controller becomes aware that a breach has likely occurred – not when internal investigation is complete. The playbook must enable a preliminary, updatable notification rather than holding the process open until all facts are confirmed.
- Lesson 2: DORA obligations flow through contracts before they flow through regulation. A SaaS group that is not itself a DORA-regulated financial entity may nonetheless carry contractual incident-reporting obligations to its customers that replicate DORA timelines and formats. These contractual obligations should be mapped and incorporated into the playbook; a failure to notify a customer within the contracted window is a separate liability to a failure to notify a regulator, and the two clocks may not be aligned.
- Lesson 3: Regulatory proposals are not operational inputs. The Digital Omnibus has attracted significant commentary. Until it is adopted, the 72-hour deadline, the current NIS2 notification structure and the current DORA regime apply without modification. A playbook built on anticipated future rules rather than current law creates a compliance gap that may materialise before the anticipated rules ever take effect. Build for the law as it stands; schedule structured reviews when material changes are adopted.
Our data protection practice in the Netherlands advises on the full lifecycle of GDPR compliance and data breach notification, including playbook design, supervisory authority interactions and cross-border data transfer safeguards. Groups in the financial sector with concurrent DORA obligations may also wish to review our banking and finance practice in the Netherlands, which covers ICT risk and operational resilience requirements for financial entities and their critical service providers.
If your group is reviewing its incident response arrangements – whether in anticipation of a first incident or following a near-miss – we are available to discuss the specific regulatory landscape that applies to your structure and sector. Contact us at info@ferrazwhitmore.com or through our contacts page to arrange a preliminary conversation.
Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. Ferraz & Whitmore assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@ferrazwhitmore.com.