GDPR Data Breach Response: What to Do If Ransomware Hits
Ransomware doesn’t just lock your files; under GDPR, it starts a clock.
From the moment you discover a ransomware attack, you have 72 hours to assess whether personal data has been compromised and, if it has, notify your supervisory authority. Miss that window, and you’re looking at regulatory penalties on top of the attack itself.
The problem is that ransomware incidents are chaotic by design. Systems are down, your team is firefighting, and the legal obligations under Articles 33 and 34 of the GDPR still apply regardless.
This article covers exactly what you need to do, from the first hour of an incident through to post-breach obligations, so that when it happens, you’re not figuring out GDPR compliance from scratch.
Determine What Kind of Breach You Are Actually Dealing With
Before doing anything else, you need to understand what type of breach you are dealing with. The reason for this is that GDPR does not treat all breaches the same way, and the steps you take next will depend entirely on this assessment.
The GDPR law in Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Under that definition, ransomware almost always qualifies. The harder question is: what kind of breach is it?
The GDPR and the guidance issued by the European Data Protection Board (EDPB) in Guidelines 01/2021 on Examples of Personal Data Breach Notification identify three categories:
Confidentiality breach — personal data has been accessed or disclosed to someone who should not have it. In a ransomware attack, this happens when attackers exfiltrate data before encrypting it, which is now standard practice among most ransomware groups.
Availability breach — personal data is no longer accessible, either temporarily or permanently. Encrypted files that you cannot open is a textbook availability breach, even if no data was actually stolen.
Integrity breach — personal data has been altered or corrupted without authorisation. This is less common in ransomware but can occur when attackers manipulate data prior to or during an attack.
The reason this classification matters is that a pure availability breach, where data was encrypted but there is strong evidence it was not accessed or exfiltrated, may carry a lower risk to individuals than a confidentiality breach where customer records have left your systems entirely. Authority guidelines acknowledge this distinction, and it directly affects whether you are required to notify affected individuals under Article 34, not just your supervisory authority.
In reality, you should assume the worst until your forensic investigation says otherwise. Most modern ransomware attacks involve both encryption and exfiltration. So, treating it as a confidentiality breach from the start is always the safer legal position.
Start Your Breach Log Before You Do Anything Else
If you have not started a breach log yet, start one now. If you have already taken steps to contain the attack, log those actions retroactively with as accurate a timestamp as you can recall. Please note: the log does not need to be perfect from the first entry; it just needs to exist.
Article 33(5) of the GDPR states that the controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. This requirement applies to every breach, including ones that never get reported to a supervisory authority. There is no threshold you have to cross before the documentation obligation kicks in. The moment you are aware of a breach, the obligation to document it begins.
In a ransomware scenario, the breach log becomes the single most important document in any subsequent regulatory investigation. If the supervisory authority asks how the incident was handled, this log is your answer. Gaps in it, or worse, the absence of one entirely, signal that your response was disorganised. That is not the impression you want to give when demonstrating GDPR compliance.
Check Your Backups Immediately
Once you have documented your initial breach assessment, the next move would be to check your backups.
Under GDPR, the ability to restore personal data in a timely manner is directly relevant to your obligations. Article 32(1)(c) specifically requires organisations to have the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. If the backups are clean and restorable, that works in your favour when demonstrating to the supervisory authority that appropriate technical measures were in place. If they are not, that changes the picture significantly.
Here is what you need to establish as quickly as possible:
a) Are the backups intact and unaffected?
Ransomware attackers frequently target backup systems before triggering encryption. Their goal is to remove the exit route. You need to verify that the most recent backups were not encrypted, corrupted, or deleted during the attack. Check the timestamps. Check whether backup systems were connected to the same network segments that were compromised. An offline or air-gapped backup that predates the attack is what you are hoping to find here.
b) How recent are the backups?
This matters for two reasons. First, it tells you how much personal data may be unrecoverable, which feeds directly into your risk assessment under Article 33. If the last clean backup is from three weeks ago, any personal data processed in that window may effectively be lost. That is a more serious availability breach than one where you can restore from yesterday. Second, it affects how you characterise the breach to the supervisory authority.
c) Are your backups stored separately from your main environment?
The EDPB Guidelines 01/2021 use backup availability as a factor in assessing the severity of an availability breach. An organisation that can demonstrate clean, recent, and separate backups is in a materially different position to one that cannot. If the backups were stored on the same systems that were hit, you need to know that right away, so the response and notification reflect the actual situation.
Document everything you find at this stage. Whether your backups are clean or compromised, write it down with timestamps. This documentation will form part of the records you are required to keep under Article 33(5), which obliges controllers to document all personal data breaches regardless of whether they are reported to a supervisory authority.
If the backups are intact, do not begin restoration yet. Preserve the compromised environment for forensic investigation first. Restoring too early can overwrite evidence you will need to understand the full scope of the breach, including whether data was exfiltrated before encryption occurred.
Notify Your Supervisory Authority Within 72 Hours
The 72-hour clock starts when your organisation becomes aware of the breach, not when the ransomware was deployed. In most ransomware cases, attackers have been inside the organisation’s systems for weeks before triggering encryption. That earlier period does not start the clock. But the moment someone on the team sees encrypted files, a ransom note, or a system alert, the clock starts immediately.
There are some organisations that wait until their forensic investigation is complete before notifying. But by that point, the deadline has, most likely, already passed. The GDPR does not require you to have the full picture before you notify. It requires you to notify when you have enough information to reasonably confirm a breach has occurred.
Does your specific incident require notification?
Article 33(1) exempts breaches that are unlikely to result in a risk to the rights and freedoms of individuals. In a ransomware attack, that exemption almost never applies. The involvement of criminal actors, the likelihood of exfiltration, and the loss of data availability make it extremely difficult to argue that individuals face no risk. The only realistic exception is a pure availability breach where backups are fully intact, restoration causes no meaningful harm to individuals, and forensic evidence confirms no data left your systems. Even then, notifying is the safer legal position.
What to include when you notify
Your notification to the supervisory authority under Article 33(3) needs to cover the following:
- The nature of the breach,
- The categories and approximate number of individuals and records affected,
- Your DPO contact details,
- The likely consequences for individuals,
- And the containment measures you have taken or are taking.
You will, most likely, not have all of this confirmed within 72 hours in most ransomware cases, and the law accounts for that.
Article 33(4) explicitly permits phased notification. Submit what you have within the 72-hour window and state clearly that further information will follow as your investigation develops. Your first notification might only confirm that a ransomware attack occurred, that personal data is affected, and that the full scope is being determined. That is compliant. What is not compliant is waiting until you have everything, thereby running down the clock.
What if you miss the 72-hour window?
The GDPR law in Article 33(1) requires that late notifications be accompanied by reasons for the delay. A late notification with documented justification is not automatically a violation. What supervisory authorities penalise is an organisation that deprioritised notification or assumed the breach did not meet the threshold without properly assessing it. Under Article 83(4), failures to notify in line with Article 33 carry fines of up to 10 million euros or 2 percent of global annual turnover, whichever is higher.
If you operate across multiple EU member states, notify the supervisory authority where your main establishment is located. That authority leads the response and coordinates with others under the one-stop-shop mechanism in Article 56. For controllers subject to UK GDPR, the main authority is the ICO, and the same 72-hour obligation applies under Section 67 of the Data Protection Act 2018.
Decide Whether You Need to Notify Affected Individuals
Notifying the supervisory authority and notifying affected individuals are two separate obligations under GDPR. Therefore, notifying the authorities does not mean you have satisfied this one.
The threshold here is higher and more specific. In Article 34(1), the law requires you to notify affected individuals when a breach is likely to result in a high risk to their rights and freedoms. That means not every breach that requires notification to the supervisory authority automatically requires individual notification. You need to assess the specific risk level posed by the breach to the data subjects.
How to assess whether your ransomware incident crosses the threshold
The EDPB Guidelines 01/2021 identify several factors that determine whether a breach reaches the high-risk threshold. In a ransomware context, the most relevant ones are:
The nature of the data involved. If the compromised data includes special category data under Article 9, such as health records, biometric data, religious beliefs, or data relating to criminal offences under Article 10, the threshold is almost certainly met. The same applies if financial data, identity documents, login credentials, or data relating to children was affected. The more sensitive the data, the harder it is to argue that individuals face anything less than high risk.
Whether exfiltration occurred or is suspected. This is the factor that most dramatically shifts the risk assessment in a ransomware attack. An availability breach where data was encrypted, but there is strong forensic evidence it never left your systems, carries a materially different risk profile than one where attackers copied data before encrypting it. If you cannot confirm that exfiltration did not occur, you should treat it as though it did. That assumption directly affects whether individual notification is required.
The number of individuals affected. Scale matters. A breach affecting thousands of individuals carries a higher aggregate risk than one affecting a small number, even if the data type is the same.
The ability of attackers to weaponise the data. Ask concretely what someone could do with the specific data that was compromised. Could it be used to commit identity fraud? Could it enable targeted phishing against the affected individuals? Could it cause reputational, financial, or physical harm? If the answer to any of these is yes, the high risk threshold is likely met.
What individual notification must contain
If you determine that notification is required, Article 34(3) sets out what it must include:
- You need to describe the nature of the breach in plain language that a non-specialist can understand.
- You need to provide the contact details of your DPO or another point of contact.
- You need to describe the likely consequences of the breach for that individual.
- And you need to tell them what steps you have taken to address the breach and what they can do to protect themselves.
That last point is where many notifications fall short. Telling someone their data was compromised without giving them any actionable guidance is not sufficient. In a ransomware scenario where exfiltration is confirmed or suspected, your notification to individuals should tell them concretely what to do. If login credentials were involved, tell them to change passwords immediately and on any other accounts where those credentials were reused. If financial data was compromised, tell them to monitor their accounts and contact their bank. If identity documents were affected, tell them to be alert to identity fraud and consider notifying relevant authorities.
The three situations where individual notification is not required
Article 34(3) provides three specific exemptions. First, if you had implemented appropriate technical protection measures, specifically strong encryption, and the compromised data is unintelligible to anyone without the decryption key. Second, if you took immediate steps after the breach that eliminated the likelihood of high-risk materialising. Third, if notifying each individual would involve disproportionate effort, in which case a public communication or equivalent measure may be used instead. In a ransomware attack, the third exemption is the one most likely to be relevant, where the number of affected individuals is very large and individual contact is genuinely not feasible within a reasonable timeframe.
What happens if you get this decision wrong
Under Article 83(4), failure to notify individuals in line with Article 34 carries the same penalty tier as the supervisory authority notification failure; fines of up to 10 million euros or 2 percent of global annual turnover. Beyond the financial penalty, failing to notify individuals when you should have compounds the reputational damage of the breach itself. Individuals who find out through other channels that their data was compromised, and that you knew and said nothing, lose trust in a way that is very difficult to recover.
When there is genuine uncertainty whether the high-risk threshold is met, notify. The law does not penalise organisations for erring on the side of transparency with the people whose data they are responsible for.
Make and Document Your Ransom Decision
At some point during a ransomware incident, someone in the organisation might ask whether you should pay. This article will not tell you whether or not to pay. It tells you what you need to understand before you decide, and why the decision itself must be formally documented regardless of which way it goes. Here are a few things to keep in mind:
What GDPR says about paying a ransom
GDPR does not explicitly prohibit paying a ransom. There is no article that makes payment unlawful under data protection law. However, the decision to pay sits directly inside your Article 32 obligations, which require you to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. How you respond to an attack is part of that assessment.
More directly, paying a ransom does not extinguish your GDPR obligations. This is the assumption that gets organisations into serious difficulty. Some believe that if they pay, get a decryption key, and restore their systems, the breach is resolved and notification is no longer necessary. That is legally incorrect. The breach occurred the moment personal data was compromised. Payment does not undo that. Your notification obligations under Articles 33 and 34 remain in place regardless of whether you pay or recover your data.
The legal landscape around payment
Depending on your jurisdiction, paying a ransom may carry legal risk beyond GDPR. In the United Kingdom, payments to sanctioned groups are prohibited under the Sanctions and Anti-Money Laundering Act 2018. In the United States, the Office of Foreign Assets Control has issued advisories making clear that payments to sanctioned ransomware operators may violate federal sanctions law. Several of the most active ransomware groups, including those operating under names that have appeared on sanctions lists, are covered by these restrictions.
Before any payment decision is made, you need to establish whether the attacker or the group behind the attack appears on any relevant sanctions list. This is not always possible to determine quickly, but the attempt to establish it must be documented. Making a payment without conducting that check creates legal exposure that sits entirely separately from your GDPR position.
Why paying rarely resolves what you think it resolves
Even setting aside the legal considerations, the operational assumption behind paying deserves scrutiny. Paying a ransom does not guarantee that a working decryption key will be provided. It does not guarantee that exfiltrated data will be deleted or not sold. It does not guarantee that the attacker has fully exited your systems.
For example, in 2024, UnitedHealth Group paid $22 million to the BlackCat ransomware group and did not get its data back. What happened next illustrates exactly why payment provides no real assurance. BlackCat performed an exit scam, pocketed the ransom, and did not pay the affiliate who had actually conducted the attack. That affiliate retained a copy of the stolen data and took it to a second ransomware group, RansomHub, which then attempted to extort Change Healthcare a second time. Despite the initial payment, a second ransomware group claimed to have obtained the stolen data and threatened to publish it unless an additional ransom was paid.
This is a documented consequence of the ransomware-as-a-service model, where the group you pay and the individual who carried out the attack are often different actors entirely, each holding copies of your data independently.
From a GDPR perspective, paying and receiving a decryption key does not constitute evidence that exfiltrated data was not retained or distributed. Your risk assessment for individual notification under Article 34 cannot be resolved simply because the attacker claimed to have deleted the data. The EDPB guidelines make clear that unverifiable assurances from a criminal actor do not reduce the assessed risk to individuals.
If you decide not to pay
The decision not to pay is increasingly supported by law enforcement guidance. Both Europol and the UK National Cyber Security Centre advise against paying ransoms on the basis that payment funds further criminal activity and do not guarantee recovery. If you follow this guidance and document that you did so, it strengthens your position when demonstrating that your response was reasonable and proportionate under Article 5(2).
Not paying means your recovery depends entirely on your backups, which is why having backups matters as much as it does. It also means your breach log needs to reflect clearly that the decision was made, who made it, on what basis, and what recovery path was chosen instead.
If you decide to pay
If, after legal consultation, you decide to pay, document the entire decision trail. Record who authorised the payment, what legal advice was obtained, what sanctions checks were conducted, what assurances, if any, were received from the attacker, and what the outcome was. This documentation does not make the payment compliant with every applicable law, but it demonstrates that the decision was made with due diligence rather than in panic.
Critically, paying does not change your timeline for supervisory authority notification. If the 72-hour window is still running, it continues to run. Payment is not a reason to pause your notification obligations.
Why documenting this decision matters as much as the decision itself
Under Article 5(2), the accountability principle requires you to be able to demonstrate that every significant decision made during a breach response was considered, reasoned, and recorded. The ransom decision is one of the most significant decisions you will make during an incident. A supervisory authority reviewing your response will want to see that this decision did not happen informally over a phone call with no record. It should appear in your breach log with the date, the decision maker, the rationale, and the outcome.
If the decision was made under time pressure without full information, record that too. Context matters. What regulators look for is evidence of a functioning decision-making process, not a perfect one.
Bottom line
A ransomware attack is simultaneously an operational crisis and a legal one. The technical response and the GDPR obligations run on the same clock, and both require the same thing: a structured, documented, and timely response.
The steps covered in this article reflect what the law requires and what regulators will look for if your incident is ever reviewed. How thoroughly you execute them, and how early you prepare for them, will define your legal position long after your systems are restored.