Hacked: incident response for companies operating in Spain

The first hours, in order

Order matters more than speed. These are the steps that keep a containable incident from turning into one that is not.

• 1. Contain without destroying. Isolate what is affected from the network, but do not power it off or rebuild it yet. Powering off erases whatever exists only in memory, and that is often the only way to know what was taken. The difference between "we were attacked" and "we were attacked and we know what left" is decided in this hour.
• 2. Stop using any credentials that may be compromised, and do not log into the affected machines with administrative accounts. It is the most expensive mistake and the most frequent one: the person who came to fix it hands their privileges to the person who is already inside.
• 3. Open a log with timestamps. What was seen, when, who saw it, what was touched. That document is later the basis of the notification, of the report to your insurer and of the criminal complaint, and it cannot be reconstructed from memory.
• 4. Preserve the evidence before you recover. Copies of the disks and of the logs, and the logs of everything that expires soon, which is usually what you end up needing most. This is digital forensics and it is worth having it led by somebody who has done it before.
• 5. Decide who decides. Before anything goes out, make it clear who is in charge: who authorises taking production down, who talks to customers and who signs the notification to the authority. Improvise this and you will improvise it badly.
• 6. Recover with judgement. Restoring on top of the same route they came in through means starting again in two weeks. Before a system goes back into production you need to know how they got in, or at least to have closed the most likely way.

A playbook written in advance turns these six steps into something you execute instead of something you argue about. And any indicators of compromise that come out are what you search the rest of the network with: if it was on one machine, the question is how many more it is on.

The clock: 72 hours, and it starts earlier than you think

This is the number people arrive looking for, so it goes first.

If the incident affects personal data and poses a risk to individuals, it has to be notified to the supervisory authority without undue delay and, at the latest, within 72 hours of becoming aware of the breach. That obligation is the GDPR, the EU regulation that Spanish texts call the RGPD. In Spain the supervisory authority is the AEPD, the Agencia Española de Protección de Datos. And if the risk to individuals is high, the affected people have to be told as well. On top of the GDPR sits the LOPDGDD, which has no equivalent in other countries because it is the Spanish act that adapts the GDPR into national law.

Two misunderstandings that cost dearly:

• 72 hours is not 72 hours to finish the investigation. It is the deadline to notify with whatever you know, and to extend later. Waiting until everything is clear is the usual way of arriving late.
• The clock starts when you become aware, not when the attack happened. Which is what turns this into a technical problem rather than a legal one: if you do not detect, you find out late, and that is comfortable right up until somebody asks how long they had been inside.

The procedure and the form are on the AEPD’s own page on notifying data breaches, and the text of the Spanish act is in the BOE, the Spanish state gazette. Both of those sources are in Spanish. We are a security firm and not a law firm: here we say where the obligation sits and which clock is running, and the reading of your particular case is signed by your own adviser.

If NIS2 or DORA apply to you, another clock runs first

Many companies operating in Spain assume the data protection deadline is the only one running. There are two more, and one of them is shorter.

NIS2 is Directive (EU) 2022/2555, and its Article 23 sets three milestones for a significant incident: an early warning within 24 hours, an incident notification within 72 and a final report within one month. Twenty four hours is not enough time to organise anything that was not organised already. Being a directive, it reaches you through each member state’s own transposition, so which authority you report to depends on where you operate. And be careful about ruling yourself out of scope by intuition: the list of sectors includes manufacturing, food, waste, postal services and managed service providers, and an entity inside the scope also pushes obligations onto its suppliers by contract.

DORA is Regulation (EU) 2022/2554 and it applies to the financial sector and to its technology service providers. It requires incidents to be classified and the major ones to be reported to the competent authority on its own schedule of initial, intermediate and final reports. The exact deadlines live in the technical standards that develop the regulation and we do not reproduce them here: if DORA applies to you, your compliance team needs that table in writing, and before they need it.

The practical consequence of the three clocks together is the same one: a duty to notify is a duty to detect. You cannot meet a deadline that starts counting when you find out if you have no way of finding out.

What we do, and what we do not

Plainly, because this page is read by people with a problem on their hands and they deserve a straight answer: Asperis does not sell incident response, and does not act as a forensic expert witness. If the fire is burning right now, what you need is a response team and, depending on the case, a criminal complaint to law enforcement. We are not going to sell you something else because you happened to land here.

Our part is the before and the after, which is where the day of the incident is actually decided.

• Before. An assumed breach exercise starts from the premise that somebody is already inside, and measures how far they get and how long it takes for anyone to see them. It is the cheap way to find out that detection did not cover what everyone believed it covered, without it being real. A red team exercise answers the same question against a defence team that does not know it is an exercise, which is as close as it gets to a dress rehearsal.
• After. Once the incident is over, the useful question is whether what was fixed is actually fixed. That is a retest: going back over the findings and checking one by one that the correction works, instead of trusting that the ticket was closed.
• And the framework. If the incident has made it plain that structure was missing, that is when it makes sense to build the ISO 27001 management system, or the Esquema Nacional de Seguridad if you work with Spanish public administration, which is the Spanish framework that any organisation handling information for the public sector has to meet, or data protection compliance. On incident response as a discipline, the glossary has the summary.

What you prepare today and are grateful for on the day

Almost everything that goes wrong during an incident does not go wrong for want of technology. It goes wrong because nobody had decided four things in advance.

Who decides. A name and a deputy, with the authority to stop production at three in the morning without asking permission.

How you talk to each other if email is unavailable. An agreed alternative channel, with the phone numbers somewhere that does not depend on the system that may be compromised. Coordinating an incident over the same mailbox the attacker is reading is more common than it sounds.

What backups you have and when a restore was last tested. Not when the backup was taken: when it was actually restored and how long that took. They are two different questions and only the second one is useful.

And who you call. With a name, a phone number and, if there is a contract, a contract number. Shopping for an incident response provider while the incident is happening is the worst negotiation there is.

None of this costs money. It costs a one hour meeting and writing it down somewhere that is not the intranet that might be down.

English edition adapted on 4 August 2026 from the Spanish original, first published on 23 January 2024 and last reviewed on 3 August 2026.