A GDPR fix counts for more if you made it before you heard from the regulator

A company selling video-conferencing software had a tracking pixel from a social media provider on its website. A function in the provider's developer tool took precedence over the privacy settings the company had configured in its own customer data platform, and for two years the hashed email addresses and phone numbers of roughly 50,000 users were sent to the social media provider. Nobody at the company noticed, because the company had no routine that would have caught a change like that. An outsider reported it. The national data protection regulator, which the GDPR calls a supervisory authority, found a breach of Article 32(1) of the GDPR, the duty to secure personal data, and issued a reprimand rather than a fine.

Be careful about the lesson there, because the company got lucky rather than good. The authority called the breach minor because of what the leaked data was, not because of anything the company did: it was hashed and therefore unusable, it included no sensitive categories, and none of it was publicly exposed. Change any one of those and the same two years of not noticing produce a fine.

That case is one of 14 worked examples in draft guidelines adopted on 17 September 2026 by the European Data Protection Board 1, the body where the EU's national data protection regulators agree a common line, so what the EDPB publishes is what your own regulator applies. The guidelines set out how any of them should decide whether a GDPR breach deserves a fine at all. Two things in them matter to anyone running a product. Not knowing the rule is treated as negligence in almost every case, so it is no defence. And doing what the GDPR already obliges you to do, including cooperating with the investigation and reporting your own breaches, earns you no credit at all. The work that counts in your favour is the work you did before anyone asked.

Can you argue that you did not know?

Almost never. An authority can only fine you for something you did intentionally or negligently, so in principle carelessness is a thing you could dispute 1. In practice the bar for negligence sits on the floor. You are negligent where you "could not be unaware of the infringing nature" of your conduct, whether or not you knew you were breaking the GDPR. What matters is whether you were in a position to know, not whether you realised. The guidelines quote Advocate General Emiliou, one of the advisers whose non-binding opinions the Court of Justice works from, saying the threshold is so low it is difficult to imagine a situation where it is not met.

There is a harder rule underneath that one. If the EDPB has already published guidance on the exact point you got wrong, your error "is always to be considered avoidable and therefore at least negligent" 1. Note the scope: it is the specific point the guidance covers, not the whole subject. Elsewhere you can still argue that your mistake was unavoidable, but only in what the EDPB calls very exceptional circumstances, where due diligence could not reasonably have caught it.

Legal advice does not reopen it. Three of the worked examples are about exactly that. A listed company relied on an external opinion saying its processing was lawful, but the opinion itself acknowledged that most of the legal literature disagreed, so the company knew its position was contestable and was negligent anyway. A second company relied on an internal legal assessment that contradicted the authority's known view, with the same result. A third told the authority it had taken external advice on the information it gives people when it collects their data, the notice Article 13 requires, and could not produce any documentation of that advice, so the argument carried no weight. The guidelines add that even documented advice "must not be blindly trusted" 1.

So the culpability question is nearly always settled against a company that got something wrong. Preparing to argue you acted in good faith is preparing the wrong argument. The guidelines are still in consultation until 13 November 2026 and their wording can move, but this part rests on decided Court of Justice case law and will not.

What decides a fine instead of a reprimand?

Whether the breach counts as minor. The GDPR gives the authority eleven things to weigh when it decides, in Article 83(2), and they fall into two groups. Four describe the breach: how serious it was, how long it ran, how many people it touched, how sensitive the data was. The rest describe you: whether you were careless, what you did to limit the damage, how you behaved towards the authority, whether you have been in trouble before.

Minor means the breach posed no significant risk to the people affected, and that you got the mechanics of a rule wrong rather than missing its point. If it is minor, the general rule is no fine and a reprimand instead. If it is not, the guidelines describe a "strong presumption" in favour of a fine 1.

Either way you are not finished, and this is the part most founders price wrong. Orders travel alongside both a fine and a reprimand: an authority can order you to bring processing into compliance by a date, suspend your transfers to a country outside the EU, or limit or ban the processing entirely 1. That order is usually the expensive half, because it lands on a feature rather than on a bank balance. All three arrived together in one decision in Ireland last year, per the regulator's 2025 annual report: a reprimand, fines, and nine months to stop the processing.

Which mitigating factors count in your favour?

Only the ones covering work you were not already required to do. Read across the Article 83(2) factors as the EDPB applies them and the same principle appears three separate times.

Cooperation is the clearest case, and the one I found hardest to accept. Article 31 already requires you to cooperate with the supervisory authority, so the guidelines state that the GDPR gives no discretion to treat mere cooperation as mitigating. It counts only where it went beyond what the law requires and measurably limited the harm to the people affected 1. Breach notification under Article 33 is treated as neutral for the same reason, that it is obligatory. Telling an authority about something you were under no duty to report, before it found out by other means, is the version that can help you.

Then there is timing, and it is the most useful line in the document. A fix counts for more when it was "spontaneously implemented" before the investigation became known to you 1. So an identical fix has two different values depending on the date you shipped it. Deploy it the week you found the problem yourself and it counts in your favour. Deploy it the week after you learned an authority was looking, and it counts for much less, even though the code and the cost are the same.

So the number to watch is how long a problem runs before anyone inside the company sees it, and that interval does two separate things to you. It sets the floor on the duration of the breach, which the guidelines weigh directly: the longer one ran, the less likely it is to be called minor. And it is the window in which you can still fix the thing on your own initiative. In the video-conferencing case that window was two years long and the company never used it, because the report came from a stranger. Across the CMS GDPR Enforcement Tracker Report, the most frequently cited failure is not a dramatic one: it is processing without a sufficient legal basis, which is the kind of thing that sits unnoticed for years.

What should you check before anyone asks?

If you run a product that handles personal data in the EU, you need to find your own compliance problems and date the fixes. Do it and your remediation is a mitigating factor pointing at a reprimand. Leave it until a regulator writes to you and the same work counts for much less, on the wrong side of a strong presumption in favour of a fine, with an order against a live feature alongside it. A short list, in the order I would work through it:

List the third-party scripts and vendors that receive data from your product, and confirm the settings you configured are the settings in force. Our scan of 458 Product Hunt launches found 292 setting tracking cookies, and only 17% of those asking first.

Put a person, not just a filter, on your data subject request inbox. The EDPB's own first reprimand example is a request that landed in a spam folder, and a French consultancy was fined 300,000 euros for never answering the deletion requests it received.

Write down the dates. When you find a problem and fix it, record when you found it and when the change shipped, while you still remember. A year later you are reconstructing it from commit history.

Lawcel, the product my co-founder and I build, watches what your team ships through GitHub pull requests, Linear and Jira, analyses each change against your published legal documents, and raises the ones that make a privacy policy or a data processing agreement inaccurate, naming the documents affected. It does nothing for your security controls or your request inbox. What it shortens is how long a problem runs before anyone inside the company sees it, for the documents it does cover, and it keeps a change log of every revision you publish. If that is the gap you recognise, connect a repository and read the first analysis.