Skip to main content

Rule C · Article 82.3 GDPR

You start out convicted: the case is won before the breach happens

The controller's fault is presumed. The only thing that disables it is proof of your diligence, and that proof is not manufactured afterwards.

Start by accepting the opening position, because it is counter-intuitive and it conditions everything. In a damages claim arising from the processing of data, you do not arrive at trial as someone who has to be proved guilty. You arrive as a controller who is presumed at fault, and on whom it falls to prove otherwise.

What Article 82.3 says exactly

Article 82 of the GDPR gives the data subject the right to compensation for the damage caused by an infringement. Its paragraph 3 sets out the only way out: the controller or the processor is exempt if it proves that it is not in any way responsible for the event giving rise to the damage. The verb is ‘prove’, not ‘plead’.

The Madrid Provincial Court of Appeal (Audiencia Provincial de Madrid) has applied that standard clearly: to avoid liability you must evidence that you employed adequate measures of diligence aimed at preventing the infringement, and that duty also extends to infringements that arrive through identity impersonation (SAP Madrid 273/2024).

It is worth seeing what diligence a court treats as evidenced looks like in practice. The same court described it when acquitting in a breach case.

SAP Madrid 371/2023, of 28 July
[...] acted diligently in complying with the obligations imposed on it in the event of a personal data breach. [translation]

That is the standard you have to reach to disable the presumption. Not ‘it was not our fault’, but ‘this is what we did, here is the record, and this is the date’.

Impersonation is not an automatic alibi

It is the most frequent scenario and the worst understood. Someone passes themselves off as a client, asks for a change or for some data, is given it, and the damage flows from there. The natural reaction of the business owner is that they are the victim of the deception.

You may be entirely right and still lose. Because what is examined is not whether you were deceived, but whether your identity verification procedure was adequate and whether you can prove that you applied it on that particular day, to that particular request.

Hence the defensive piece is not the evidence of the employee who took the call. It is the trace: what was asked of the applicant, what was checked, who authorised it and where it was recorded. Testimony can be contradicted; a dated record cannot.

And it is worth understanding why the court looks at it that way. If it were enough to say you had been deceived, the presumption in Article 82.3 would serve no purpose: every breach begins, by definition, with someone doing something they should not. What is examined, then, is the only thing that was in your hands: whether you put reasonable barriers in place and whether you can show them.

With no trace of the verification, an impersonation stops being an attack suffered and becomes negligence of your own.

Why reconstructing afterwards almost never works

When the file is put together after the event, the same cracks always appear: approximate dates, versions that do not match between departments, unsigned documents and emails saying ‘we discussed it and agreed that...’. None of that is proof of diligence: it is material for the other side's cross-examination.

The solid position is the opposite one, and it is recognised by a very simple symptom. If a judge asked you today for proof of your diligence, would you hand it over within a week without manufacturing anything? If the answer is three months, you already know your real exposure.

There is also a credibility effect that appears in no rule and decides many hearings. A company that hands over its complete file on day one conveys that the matter was governed. Another that produces documents as they are asked for conveys the opposite, even if the documents are good. In a case where fault is presumed, that impression counts.

What evidences diligence and what does not

Works

  • An inventory of measures with a date, predating the incident.
  • A written protocol stating who decides on notification and within what deadline.
  • Identity verification records with the outcome, the author and the time.
  • Training with an attendance list and a date.
  • Short minutes of the decisions taken, and of those rejected.

Does not work

  • The sincere conviction that ‘we have always done it this way’.
  • An excellent manual that nobody approved or dated.
  • Screenshots and emails gathered in the week of the formal request.
  • The judgement of an employee who no longer works at the company.

The difference between the two lists is not one of effort or of spending. It is one of timing: the first is done beforehand, the second afterwards.

The business consequence: serial claims

A presumption of fault turns every person affected into a claimant with half the work already done. That is why, after a breach, claims arrive in series: the same document, with the name changed. And that is why the defence is also organised as a block.

Your evidence file is not prepared once per claim. It is prepared once and serves them all. It is the only economy of scale that plays on your side in this field, and only those who built it beforehand have it. The points through which those claims find a way in are described in what a court looks at when the claim arrives.

If I prove the attack was highly sophisticated, am I exonerated?

Not on its own. The sophistication of the attack is weighed, but what you are required to evidence is your own conduct: what measures you had, from when, and how you acted once the incident was detected.

Does the presumption also reach the supplier that processes data for me?

It reaches the controller and the processor, each within their own sphere. Which is which in each system is determined by the data processing agreement, and that is why the contractual allocation is the first line of defence.

Is there any point in having notified the authority?

There is, because it forms part of the diligent conduct that is assessed. But it evidences how you reacted, not what you had in place beforehand; both are needed.

The Breach Management Test is built on that single question: if you were asked today, could you hand over the proof of your diligence without reconstructing anything?

Measure your position before you need it

Twelve questions about what you could prove, not about what you have installed. At the end, your Defensibility Index and the gaps in order of urgency.

Take the Breach Management Test
articulos/art82-3-culpa-presumida
Article 82.3 GDPR: you start out convicted | ILP Abogados