Losing a laptop with a customer list on it, a phishing email that hands over mailbox credentials, a misconfigured cloud folder anyone can open — none of these feel like paperwork problems in the moment. But under the AVG (the Dutch implementation of the GDPR), each one can trigger a legal duty to report what happened to the Autoriteit Persoonsgegevens (AP), the Dutch data protection authority, within 72 hours of finding out. Most Dutch SMEs know the phrase "datalek melden" in passing and assume it means calling a helpline the moment something goes wrong. In practice the rule is narrower and more procedural than that: not every incident has to be reported, the clock starts at a specific, definable moment, and the AP itself publishes the criteria for deciding rather than leaving it to guesswork. This guide walks through what actually counts as a data breach, the risk test that decides whether you report it, the 72-hour deadline and what "aware" means for starting it, and what happens once you've filed a report.
What Actually Counts as a Data Breach
Not every IT incident is a datalek in the legal sense. The Nationaal Cyber Security Centre (NCSC) frames it as three possible types of breach, and you only have one if personal data is affected by at least one of them:
- A breach of confidentiality — personal data has been disclosed to someone who shouldn't have seen it, whether that's an email sent to the wrong address or a hacker who copied a database.
- A breach of integrity — personal data has been altered without authorisation.
- A breach of availability — personal data has become inaccessible, for example because ransomware encrypted it or a backup turned out not to work.
A server going down for an hour with no personal data on it is an IT incident, not a datalek. A spreadsheet of customer email addresses sent to the wrong recipient is a datalek, specifically a confidentiality breach, even though nothing was "hacked."
The Risk Test: When You Must Report
The AVG's rule, as the AP explains it, is a default of reporting rather than a default of silence: you have to report a data breach to the AP unless it is not likely to result in a risk to the rights and freedoms of the people whose data it concerns. A separate, higher bar decides whether you also have to inform the affected individuals themselves: that's only required when the breach is likely to result in a high risk for them.
Working out which side of that line you're on means weighing several factors together, not checking a single box. The AP lists the ones that matter:
- the type of breach (confidentiality, integrity or availability);
- the nature, sensitivity and volume of the personal data involved;
- how easily the leaked data can be used to identify a specific person;
- how severe the consequences could be for the people affected;
- who the data ended up with, if you know;
- whether the people affected have any particular vulnerability;
- what your organisation does and how sensitive that context makes the data;
- how many people are affected.
Some categories push the assessment toward "high risk" almost automatically: health data, criminal records, and profiling data based on things like financial situation or behaviour. Financial details such as credit card numbers, copies of ID documents, and a Dutch BSN combined with a name and address sit in the same bracket, because they can be used directly for fraud. The AP is explicit that data that looks harmless at first glance — a phone number or email address on its own — can still enable a targeted phishing attack once it's in the wrong hands, so "it's just an email address" is not by itself a reason to skip the assessment.
If you're genuinely unsure after weighing this, the AP's own advice is to report anyway rather than gamble on the exception applying.
The One Exception: Data That Was Already Useless to an Attacker
There's one specific case where the AP says you don't have to report at all: if the leaked personal data had already been made unreadable to an unauthorised person before the breach happened, through proper encryption or hashing. That exception only holds if three conditions are all true at once: the data itself is still fully intact, you still have full control over it (a recent working backup exists), and the encryption or hashing key was never exposed during the breach and can't realistically be recovered by an attacker. Leaked salted password hashes, for instance, typically fall under this exception — but the moment any of the three conditions breaks, for example because the key was stored on the same system that was compromised, the exception no longer applies and the normal risk test is back in play.
The 72-Hour Clock
The deadline runs from the moment you become "aware" of the breach — defined by the AP as the point you can reasonably be certain that an incident has actually compromised the confidentiality, integrity or availability of personal data, not the point you first notice something unusual. You're expected to investigate a suspected incident immediately to establish whether it's a real breach, but the clock itself doesn't start until that awareness threshold is crossed.
For a complex incident — the AP names ransomware and phishing specifically — you're not expected to have finished your investigation before reporting. A preliminary notification within 72 hours, followed by a supplementary one once you know more, is exactly how the process is designed to work; waiting for a complete picture before filing anything is the mistake, not the delay it would cause.
Late notifications are accepted only in exceptional cases, and the AP is explicit about which excuses don't count: a weekend, a holiday, staff illness or simply being too busy are all listed as invalid reasons. Not being told in time by your own data protection officer isn't a valid excuse either — the AP treats timely internal escalation as the organisation's responsibility, not the DPO's.
Who Has to Report
Under the AVG, the controller — the organisation that determines why and how personal data is processed — is responsible for reporting, even when the breach actually happened at a supplier. If your payroll provider or CRM vendor is the one that got breached and your customers' data was affected, the reporting duty defaults back to you as the controller, unless you've explicitly and separately arranged in writing for that supplier to report on your behalf. A standard data processing agreement doesn't automatically cover this — the AP requires a specific written authorisation naming the processing activities involved, before a processor can file the notification.
What Happens After You Report
Filing a report doesn't usually trigger a reply. The AP's own description of its process is that most notifications receive no response at all, which means the submission went through and the AP had no immediate questions; if it does have questions, it contacts you within two weeks. Behind the scenes, the AP prioritises using a risk-based, automated classification of incoming notifications by seriousness, so a report describing a large-scale breach of medical records gets attention faster than a single misdirected email. Depending on what a given case shows, the AP can close the file, request more information, call for clarification, or open a formal investigation — most often triggered by a breach that was never reported at all, or reported late.
Getting It Wrong
The AP can impose an administrative fine on an organisation that wrongfully fails to report a breach it should have reported, and separately, it can order an organisation to inform victims it should have informed but didn't. Beyond the fine itself, the AP notes that if your organisation is later shown to have withheld a breach that affected customers or staff, the resulting loss of trust tends to outlast the incident itself. None of this depends on the breach being large: a single email with the wrong attachment is enough to trigger the same reporting duty as a full database compromise, if the risk assessment says so.
Not the Same Duty as NIS2
It's worth being precise about which law is which here, because Dutch coverage of cybersecurity obligations tends to blur them together. The AVG's breach notification duty covers personal data specifically and runs to the AP. A separate cyber incident reporting duty for organisations in scope of NIS2 runs through a different channel entirely, with different triggers. If your organisation is affected by both, they don't substitute for each other — a ransomware attack that leaks personal data can trigger the AVG's 72-hour AP notification and a separate NIS2 incident report at the same time. Our guide to NIS2 for SMEs covers that second duty in detail.
FAQ
Is reporting a data breach mandatory for SMEs in the Netherlands? Yes, under Article 33 of the GDPR (AVG), any organisation processing personal data — SMEs included — must report a data breach to the Autoriteit Persoonsgegevens within 72 hours of becoming aware of it, unless the breach is not likely to pose a risk to the people affected.
Do I always have to inform the people whose data was involved? No. Informing the affected individuals is a separate, higher bar than reporting to the AP — it only applies when the breach is likely to result in a high risk for them, under Article 34 GDPR.
What counts as the moment I "became aware" of a breach? The point you can reasonably be certain a security incident actually compromised personal data, not the moment you first noticed something odd. You're still expected to investigate a suspicious incident immediately to reach that point.
Does a data breach at our accounting or payroll provider have to be reported by them or by us? By you, by default. As the controller, the reporting duty stays with your organisation unless you've arranged in writing for the processor to report on your behalf.
What happens if we don't report a breach we should have? The AP can open an investigation and impose an administrative fine, and separately order you to inform the people affected if you didn't. The AP has also said it will confirm to the press when an organisation is found not to have reported within the statutory 72 hours.
Getting Your Breach Response Ready Before You Need It
The moment you actually need the 72-hour clock explained is the worst time to be reading about it for the first time. Our Cybersecurity & Identity service includes building an incident response process that already has the risk-assessment questions, the reporting steps and the internal escalation path worked out, so a real incident is a matter of following a plan rather than improvising one. Because a breach so often starts with how personal data is stored and who can reach it, our Data & Databases team can also review where sensitive data actually lives across your systems, which is usually the first question the AP's own risk test asks anyway.