Your organization detects unusual network activity. Your IT team investigates and finds unauthorized access to customer data. You contain the threat. Now comes the urgent question: do you need to report this to authorities? Who exactly? What information do you provide? How much time do you have?
Under NIS2 and Dutch law, many organizations must report cybersecurity incidents to government authorities within strict deadlines. You typically have between 24 and 72 hours after detection. The regulations specify which authority receives your report, what information you must provide, and the format requirements. Miss the deadline or report to the wrong body, and you face substantial fines, enforcement actions, and legal liability that can extend beyond the initial incident itself.
This guide shows you exactly how to meet your reporting duties. You’ll learn which laws apply to your organization, when an incident requires reporting, which authorities to notify at each stage, what information each report needs, and how to build procedures that actually work. We’ll skip the legal jargon and focus on practical steps you can take right now to stay compliant and protect your organization.
What your cybersecurity incident reporting duties are
Your cybersecurity incidents reporting duties depend on your organization’s size, sector, and the services you provide. Essential entities (energy, transport, banking, healthcare, critical infrastructure) and important entities (postal services, waste management, digital providers, food production) face mandatory reporting under NIS2. If you operate critical infrastructure or digital services for Dutch consumers, you almost certainly fall under these rules.
The three reporting stages you must complete
You face three separate reporting obligations with different deadlines. Your first duty starts within 24 hours of detecting a significant incident: you submit an early warning to your CSIRT (Computer Security Incident Response Team) or competent authority. This initial notification flags the incident and indicates whether you suspect malicious activity or cross-border impact.
Within 72 hours, you submit your incident notification. This report includes your initial assessment of severity, impact, affected systems, and available indicators of compromise. You provide technical details that help authorities understand the scope and nature of the breach.
Organizations that miss these deadlines face fines up to €10 million or 2% of global annual turnover under NIS2, whichever is higher.
Your final report arrives within one month of your incident notification. This comprehensive document details the incident’s full scope, root cause analysis, mitigation measures you implemented, and cross-border effects. If you’re still handling the incident when the month expires, you submit a progress report and then a final report within one month of resolution.
Additional duties beyond initial reporting
You must also inform affected parties when a significant incident impacts service recipients. This notification happens without undue delay and includes practical steps those recipients can take to protect themselves. For trust service providers specifically, the 72-hour window shortens to 24 hours for incidents affecting trust services.
Your CSIRT or competent authority responds within 24 hours of receiving your early warning, providing initial feedback and operational guidance on mitigation measures.
Step 1. Identify which EU and Dutch laws apply to you
You need to determine which regulatory frameworks govern your cybersecurity incidents reporting duties before an incident occurs. NIS2 (the Network and Information Security Directive) applies broadly across the Netherlands, but DORA (Digital Operational Resilience Act) and specific Dutch implementation rules create additional obligations for certain sectors. Start by evaluating your organization against each framework’s criteria.
Check if NIS2 applies to your organization
NIS2 applies if you qualify as an essential entity or important entity. Essential entities include organizations in energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, public administration, and space. Important entities cover postal services, waste management, chemicals, food production, manufacturing, digital providers, and research organizations.
Your organization size matters only for digital service providers (DSPs). You fall under NIS2 as a DSP if you operate an online marketplace, cloud service, or search engine with at least 50 employees and either €10 million in annual turnover or €10 million in total assets. All other essential and important entities face obligations regardless of size.
If you operate critical infrastructure or were previously designated under the old NIS Directive (Wbni), you automatically qualify under NIS2.
The Dutch government maintains a registry of designated entities. Check with your sector’s competent authority (energy and digital infrastructure report to RDI; financial services to AFM and DNB; healthcare to IGJ) to confirm your status. You should verify this before January 2026 when enhanced enforcement begins.
Determine if DORA covers your financial services
DORA applies separately to financial institutions and ICT service providers serving them. You fall under DORA if you operate as a credit institution, payment service provider, insurance company, investment firm, crypto-asset service provider, or electronic money institution. This regulation runs parallel to NIS2 with its own reporting requirements.
Financial service providers report significant incidents to both AFM (via the AFM Portal) and DNB (via My DNB) in addition to RDI. You also must register all contractual agreements with ICT third parties for critical or important functions through these portals within specified timeframes.
Assess your digital service provider obligations
The Wbni (Dutch implementation) creates specific duties if you provide online marketplaces, cloud computing, or search engines. You report incidents to both RDI and CSIRT-DSP (the specialized incident response team for digital providers). Unlike essential entities in other sectors, you face size thresholds: 50+ employees and €10 million+ turnover or assets.
Trust service providers face accelerated deadlines under eIDAS regulation. You must report significant incidents affecting trust services within 24 hours instead of the standard 72-hour window that applies to other entities.
Step 2. Define when an incident is reportable
You need concrete criteria to determine whether an incident crosses the reporting threshold. The law defines significant incidents as those causing severe operational disruption, financial loss, or considerable damage to others. Your cybersecurity incidents reporting duties begin when you detect an incident meeting these criteria, not when you finish investigating it. This means you must make reporting decisions quickly, often with incomplete information.
Assess the severity threshold for your organization
An incident qualifies as significant when it disrupts your core services or creates substantial financial impact. NIS2 provides two main categories: incidents that severely disrupt your operations or cause financial loss, and incidents that affect other parties by causing considerable material or non-material damage. You report when either category applies.
Operational disruption means you cannot deliver services to customers, critical systems fail, or you lose access to essential data. Financial loss includes direct costs like ransom payments, recovery expenses, lost revenue, or regulatory fines. The law does not specify exact euro thresholds, so you evaluate based on your organization’s size and the incident’s relative impact.
Document your internal thresholds before an incident occurs. This creates consistency in reporting decisions and demonstrates good faith compliance if authorities later question your judgment.
Consider these indicators when assessing significance:
- Service availability: Can customers access your services? For how long have systems been down?
- Data integrity: Has unauthorized access occurred? Which data categories were affected?
- Geographic scope: Does the incident affect multiple locations or countries?
- Customer impact: How many users or recipients face service disruption?
- Recovery time: Do you expect resolution within hours, days, or weeks?
Evaluate cross-border and cascading effects
You must report incidents with potential cross-border impact even when domestic effects seem minor. An incident affecting your Dutch operations might impact customers, partners, or supply chains in other EU member states. This triggers reporting obligations because authorities coordinate responses across borders.
Cascading effects matter equally. Your incident becomes reportable when it disrupts services you provide to other essential or important entities, regardless of direct impact on end users. For example, if you supply cloud services to a hospital and your security breach affects their patient systems, you report based on their operational impact, not just your own losses.
Trust service providers face stricter thresholds. Any incident affecting the provision of trust services (digital signatures, certificates, timestamps) requires immediate reporting within 24 hours. You don’t wait to assess whether the impact meets general significance criteria.
Step 3. Create your incident reporting procedures
You need documented procedures that specify exactly who does what, when, and how during an incident. Your incident response plan must include clear reporting workflows that activate automatically when your team detects a significant incident. These procedures translate your cybersecurity incidents reporting duties from abstract legal requirements into concrete actions your staff can execute under pressure.
Build your incident classification matrix
Your classification matrix helps incident responders determine reporting requirements within minutes of detection. Create a table that maps incident types and severity levels to reporting obligations, deadlines, and recipient authorities. This removes guesswork and ensures consistent decisions across your organization.
| Incident Type | Severity | Report To | Initial Deadline | Incident Notification |
|---|---|---|---|---|
| Unauthorized access to customer data | High | RDI + CSIRT | 24 hours | 72 hours |
| Ransomware affecting core systems | Critical | RDI + CSIRT + NCSC | 24 hours | 72 hours |
| DDoS disrupting public services | High | RDI + CSIRT | 24 hours | 72 hours |
| Trust service compromise (if applicable) | Critical | RDI + CSIRT | 24 hours | 24 hours |
| Financial service incident (DORA) | High | RDI + AFM + DNB | 24 hours | 72 hours |
Update this matrix whenever regulations change or your organization adds new services. Test it quarterly using realistic scenarios to identify gaps or confusion points.
Design your notification workflow
Your workflow must specify the exact sequence of actions from incident detection through final reporting. Document who initiates reporting, who reviews and approves notifications, who submits them, and who maintains contact with authorities. Assign backup personnel for each role to cover absences.
Your workflow should assume incidents occur outside business hours when senior management may not be immediately available. Build in approval mechanisms that prevent delays.
Create a checklist format your team follows:
- Incident detected: Security team lead assesses against classification matrix within 2 hours
- Reportable incident confirmed: CISO notified immediately, begins early warning preparation
- Early warning drafted: Include incident type, detection time, suspected cause, potential cross-border impact
- Legal review: Legal counsel reviews draft within 4 hours for accuracy and completeness
- Submission: CISO or delegate submits via official portal within 24-hour deadline
- Authority response: Security team implements guidance received within 24 hours
- Incident notification: Technical team prepares detailed assessment by 60-hour mark
- Final submission: Complete documentation submitted before 72-hour deadline
Prepare report templates for each stage
Templates ensure your reports contain all required information while reducing preparation time. Build separate templates for your early warning, incident notification, and final report that include all mandatory fields specified by NIS2 and Dutch authorities.
Your early warning template needs: detection timestamp, incident category, affected systems summary, suspected malicious activity indicator (yes/no), cross-border impact indicator (yes/no), primary contact information. Your incident notification adds: severity assessment, impact scope, affected user count, indicators of compromise, initial mitigation steps taken. Final reports include: complete incident timeline, root cause analysis, full impact assessment, implemented security measures, lessons learned, preventive recommendations.
Save these templates as fillable forms your team can access instantly. Store them in your incident response platform, security wiki, and offline backups to ensure availability during system outages.
Step 4. Embed reporting in training and governance
Your reporting procedures fail if staff don’t understand their roles or if governance structures don’t support rapid decision-making. You need systematic training and board-level oversight to ensure your organization executes its cybersecurity incidents reporting duties correctly every time. This means integrating reporting obligations into your existing security training programs and creating clear accountability at the governance level.
Train all staff on detection and escalation
You must train all employees to recognize potential security incidents and know exactly how to escalate them. Your technical staff needs detailed training on the classification matrix and reporting workflows, but non-technical employees need simpler guidance focused on spotting unusual activity and contacting the right people immediately.
Run quarterly tabletop exercises that simulate realistic incidents requiring reporting. Walk your incident response team through the entire process from detection through final report submission. Use these exercises to identify procedural gaps, test your templates, and verify that backup personnel understand their roles. Document lessons learned after each exercise and update your procedures accordingly.
Security awareness training for general staff should cover these reporting essentials:
- What constitutes a potential security incident (unusual emails, unauthorized access attempts, missing data)
- Who to contact immediately (provide 24/7 contact details for your security team)
- What not to do (don’t try to investigate yourself, don’t delete evidence, don’t wait until Monday)
- Why speed matters (regulatory deadlines start when incidents are detected, not reported)
Train staff that detecting and reporting suspicious activity immediately protects both the organization and themselves from liability, not just fulfills compliance requirements.
Integrate reporting into existing governance
Your board and executive leadership need regular updates on incident reporting capabilities and actual incidents. Schedule quarterly governance reviews that cover your reporting procedures, any incidents that occurred, authority responses received, and procedural improvements implemented. This creates accountability and ensures leadership understands reporting obligations.
Assign a specific executive responsibility for incident reporting compliance. This person (typically your CISO or Chief Risk Officer) reports directly to the board on preparedness, maintains relationships with competent authorities, and owns the budget for reporting tools and training. Clear ownership prevents confusion during actual incidents when decisions must happen quickly.
Include reporting metrics in your security dashboards: time from detection to early warning submission, percentage of incidents meeting deadline requirements, authority response times, and corrective actions completed. Track these monthly to identify trends and improvement opportunities.
Moving forward
You now have a complete framework for meeting your cybersecurity incidents reporting duties under NIS2 and Dutch law. You know which regulations apply to your organization, when incidents cross the reporting threshold, which authorities receive notifications, what information each report must contain, and how to build procedures that function under pressure. Your next step is immediate implementation.
Start by reviewing your current incident response plan against the requirements outlined here. Update your classification matrix, prepare your report templates, and train your incident response team on the new workflows. Schedule your first tabletop exercise within the next 30 days to test procedures before a real incident occurs. Document everything you create so your team can access it instantly when needed.
Legal compliance in cybersecurity requires both technical expertise and legal knowledge. If you need assistance interpreting how these regulations apply to your specific situation, contact Law & More for specialized guidance. Their team helps Dutch organizations navigate complex cybersecurity compliance requirements and build incident response frameworks that protect both your operations and your legal standing.
