What a Spanish court really looks at after a personal data breach

When a company suffers a personal data breach, the board's first question is always the same: how did they get in. It is a legitimate question, but it is not the one that decides what the episode costs. The one that decides that arrives months later, it is put by a court, and it sounds very different: show me what you were doing the day before.

The attack is not the end of the problem: it is the beginning

The incident is contained in days. The repair is closed in weeks. The claims last years. And they do not arrive one at a time: they arrive in series. If you hold the data of tens of thousands of people, every one of them is a potential claimant the moment the episode becomes public.

That mechanism is not a hypothesis: Spain has already seen it with credit blacklists. The same law firms that industrialised those claims know the route, have the machinery in place and know how to recruit affected people in bulk. What changes now is the origin of the harm, not the business model of the claimant side.

The business owner then faces three fronts at once, with a clock running on each of them: notification to the Spanish Data Protection Agency (AEPD), communication to those affected and the wave of claims that follows. All three demand decisions in hours, not weeks. And all three decisions leave a trail. That trail is exactly what a judge will read afterwards.

The practical conclusion is uncomfortable but useful: the damage from the attack is only the first cost. The second, almost always larger and always longer, is losing the claims the attack generates. And that second cost, unlike the first, does depend on you.

The trap in Article 82.3: you start out condemned

In an ordinary civil claim, whoever brings it has to prove what they assert. In data protection, they do not. Article 82.3 of the General Data Protection Regulation reverses the burden of proof: the controller's fault is presumed, and to be exonerated it is the controller who must evidence that it applied the appropriate measures of diligence to prevent the infringement.

The Madrid Provincial Court of Appeal (Audiencia Provincial de Madrid) applied it in exactly that way in its judgment 273/2024: for processing not to give rise to liability, the controller must demonstrate that it applied appropriate due diligence measures to prevent infringements, including those arising from identity impersonation. Until it evidences that, fault is presumed. The same decision also recalls that processing inaccurate data that gives a misleading picture of the data subject's situation infringes the rules.

Translated for the boardroom: you walk into the hearing condemned, and you walk out acquitted only if you manage to demonstrate something. Having been diligent is not enough. You have to be able to show it, with documents, and within a timeframe that will not let you manufacture them.

This is where most Spanish mid-sized companies break down. It is not that they have no protective measures: they usually do, and reasonable ones. It is that they have no file documenting them. When the lawyer asks for the evidence, what turns up is a stray email, a supplier's invoice and the recollection of a meeting. That is not evidence. That is an account.

And there is a silent aggravating factor: everything you put in place after the incident works against you. A court will read it as a reaction, not as prior diligence. Measures count for what you can evidence already existed, not for what you now show you know how to do.

The good news is counter-intuitive: you are not required to be infallible

The market sells you total protection. The courts do not require it. Diligence in the face of a breach is assessed concretely, case by case, in the light of what the company did and could evidence, not against an abstract standard of invulnerability that nobody meets.

The judgment of the Madrid Provincial Court of Appeal 371/2023, of 28 July, dismissed the claim against the defendant for precisely that reason:

It is worth pausing on which measure was held to be sufficient in that case. Not an extraordinary deployment, nor an investment beyond the reach of a mid-sized company: a password-protected file, with access limited to two people.

The message for the person who signs is twofold, and it is liberating. First: the bar for the measure itself is reasonable, and you very probably already clear it. Second: the bar that actually decides the case is the evidential one, and you very probably do not clear it. What stands between you and a dismissal is not a bigger investment. It is an orderly file.

The five questions that will decide the case

These are the five questions that, in practice, resolve the case. They are ordered by business consequence; the legal basis comes afterwards, because it is the second thing that matters.

1. Can you evidence, with a date, which measures you had the day before?

Consequence. If you cannot date your measures, you will not be able to rely on them. You will lose the cheapest argument you have, and you will lose it without even arguing it: there will be nothing to argue.

Basis. The security obligations under Article 32 are assessed by reference to the controller's diligent conduct in the face of the breach, which is how SAP Madrid 371/2023, of 28 July, approached it when it dismissed the claim. A dated inventory of measures is the ordinary way of evidencing that conduct.

2. Could you hand over the evidence of your diligence today without reconstructing anything?

Consequence. Reconstructing after the event almost always leaves gaps, and the gaps show. The other side only has to point to one date that does not hold up for the whole set to lose credibility, including the part that was true.

Basis. Because fault is presumed (SAP Madrid 273/2024, Article 82.3 GDPR), the only defensible position is to have the file closed before you need it. After the event you no longer build evidence: you build suspicion.

3. Is it in writing who decides, and is the training you gave on record?

Consequence. With the seventy-two-hour clock running, improvising who decides is what makes you miss the deadline. And training that is not documented is, before a judge, the same as never having given it.

Basis. The accountability principle does not only require you to comply: it requires you to be able to demonstrate it. The judgment of the Asturias Provincial Court of Appeal 412/2024, of 3 October, puts it plainly:

4. Do you correct inaccurate data and record when and why?

Consequence. A breach exposes the real quality of your data. If someone affected shows that you were holding wrong information about them, they are no longer arguing only about the breach: they are arguing about the processing as well, and adding a separate ground of claim to the one they already had.

Basis. The accuracy principle requires you to act without delay, and the party that has to prove it acted in time is you:

5. Do you record the erasure requests and the reply you give to each one?

Consequence. After a public episode, erasure requests arrive in waves, and they are often sent by the very firm that will later bring the claim. Every request you cannot evidence you answered in time becomes a stand-alone claim on top of the main one.

Basis. The right to erasure must be dealt with without undue delay and, in any event, within one month, with an express decision even where you hold no data on the applicant (SAP Barcelona 307/2023). The two-month extension is available only on grounds of complexity and must be communicated within the first month. And there is one point in your favour: the burden of proving that the request was sent and received falls on whoever makes it.

With one time limit worth bearing in mind: processing that was lawful at the outset may become unlawful through the mere passage of time (SAP Alicante 33/2024). Keeping data longer than you should is also actionable.

Who answers and who does not: allocation as a barrier

Almost no breach happens entirely inside your own house. It happens in a supplier's system, in a tool you have contracted, in the service of a third party that processes data on your behalf. The question that decides who pays is who held the status of controller or processor at that particular point.

Security obligations can only be attributed to whoever holds that status, not to a third party outside it. That was the reasoning of SAP Madrid 371/2023, of 28 July, when it ruled out the defendant's liability:

Read it the other way round and the business value is plain: the contractual allocation of roles is not paperwork, it is the barrier that decides who ends up in the dock. If your Article 28 data processing agreements do not say in writing who answers for what in each system, the judge will make the allocation. And by default the judge will look at whoever decides about the data, which is you.

The work is contained and perfectly manageable: knowing, one by one, which suppliers reach which data, and making sure every contract states what obligations each party assumes, how an incident is reported and within what deadline. Without that map you will not be able to point to the party truly liable or evidence that you controlled the chain. With it, a good part of the claim stops being yours.

A quick self-assessment: three questions

Before going on, answer these three honestly. And count “I don't know” as a “no”: if you do not know it, you cannot prove it, and before a court that is exactly the same thing.

1. Could you hand over tomorrow, without reconstructing anything, a dated document setting out the protective measures you had in place last month?
2. Do you know, one by one, which suppliers access your clients' personal data, and does each contract say who answers if the breach happens in that supplier's system?
3. Is there a signed document setting out who decides on notification to the Spanish Data Protection Agency and within what deadline, together with a dated record of the last training you gave your staff?

If you have answered “no” to even one of the three, your evidential position today is fragile. The Breach Management Test measures it in twelve questions, none of them technical, and gives you your Defensibility Index with the breakdown rule by rule and the judgment that applies to each one.