Ransomware and GDPR breach notification: what matters

Does a ransomware attack under GDPR always mean notifying the regulator?

A ransomware attack that encrypts personal data is usually a personal data breach under the GDPR, but it does not automatically mean notifying the supervisory authority. Whether notification is required depends on the risk to individuals, and the presence of usable backups and effective encryption can change that risk substantially. The EDPB's availability breach framing in Guidelines 9/2022 means loss of access alone can be notifiable even if no one outside the organization saw the data. Leadership should therefore treat the question as an open assessment to document, not a yes or no answer that follows from the attack alone.

The answer varies with three things: the kind of data affected, whether clean copies survived and could be restored within a reasonable time, and whether the attackers took data out before encrypting it. Encryption helps only where the key was not compromised, since Guidelines 9/2022 treat data as unintelligible in principle only in that case. Backups matter in the same way the EDPB's ransomware examples in Guidelines 01/2021 show: a tested, recent and isolated copy can turn an outage into a limited incident. Confirm with your backup administrator when the last restore test ran, whether backups are reachable from the production domain, and whether the key-management system was affected.

The organization owns this decision and must record its reasoning either way, because the GDPR requires documentation of every breach regardless of whether it is notified. Your incident commander, data protection officer and legal counsel should make the call with evidence from forensics. An implementation partner can help prepare the backup, encryption and logging evidence that supports the assessment, but it does not decide whether to notify or submit anything to a regulator. Plan for the 72-hour clock to start when the organization becomes aware of the breach, not when forensic work finishes.

How backups and encryption change the notification outcome

This table compares four illustrative ransomware scenarios and shows how restorable backups, encryption and key compromise shift the duty to notify the authority under Article 33(1) and individuals under Article 34. Read each row as a starting point for analysis, not a conclusion, because the outcome depends on the facts of your own incident and the organization must reach its own decision with its DPO or counsel.

Scenario (illustrative)	Notification to the authority	Notification to individuals
Data restored from proper, tested backups	Often not required if the breach is unlikely to result in a risk to individuals, but the availability loss must still be documented and assessed	Generally not required if the high risk is no longer likely after restoration, and the assessment must be recorded
Data encrypted, key not compromised	Assess whether the breach is unlikely to result in risk, since EDPB Guidelines 9/2022 say such data are in principle unintelligible	Not required where the data were rendered unintelligible under Article 34(3), but confirm that no copy of the data was taken
Data encrypted, key compromised	Presumptively notifiable within 72 hours of awareness under Article 33(1), with reasons for any delay	Likely required without undue delay if the risk to individuals is high, since the attacker can read the data
Data exfiltrated, with or without encryption	Notifiable within 72 hours of awareness under Article 33(1) unless the risk is clearly unlikely	Likely required if the stolen data create high risk, such as financial, health or identity harm to individuals

Working through the notification decision after a ransomware attack

This sequence turns a ransomware incident into a documented decision on whether the supervisory authority and affected individuals must be told, with a written record behind each step.

Confirm the breach and record awareness time
The incident lead confirms that personal data was affected and records the moment the controller became aware of the breach. Article 33(1) starts the 72-hour clock from that point, so the record should name the first alert, who received it and when it was escalated. Done when a timestamped incident entry exists with the source of the alert and the first confirmed facts. Ask your legal and DPO team to confirm how awareness is interpreted in your own procedures.
Classify the breach types that occurred
Security and privacy leads determine whether the attack caused a confidentiality breach (disclosure of or access to data), an integrity breach (alteration) or an availability breach (loss of access or destruction). EDPB Guidelines 9/2022 treat loss of access as an availability breach even when no data left the organization, so exfiltration evidence alone does not settle the question. Output: a written classification for each affected system, with the evidence used to reach it.
Check whether backups allowed restoration
The recovery lead checks whether clean, tested backups exist for each affected dataset and whether restoration was complete and timely. EDPB Guidelines 01/2021 contain worked ransomware cases with and without proper backups, and the difference between them shows how backup availability changes the notification outcome. Output: a restoration record listing each dataset, the backup used, the restore date and any personal data that could not be recovered.
Establish whether encryption keys were compromised
The security engineer determines whether the encrypted data was protected by a state-of-the-art algorithm and whether the decryption key was exposed, for example through credential theft or key storage on the same compromised host. EDPB Guidelines 9/2022 indicate that data encrypted this way are in principle unintelligible if the key was not compromised, which can remove the need to communicate with individuals. Output: a key custody finding with the date of any suspected exposure and the evidence for it.
Assess the risk to individuals
The DPO or privacy lead weighs the likelihood and severity of harm to people from the combination of confidentiality, integrity and availability effects, the sensitivity of the data and the number of people affected. The assessment must consider whether later measures have removed the high risk. Output: a written risk assessment that states the conclusion, the factors behind it and who approved it. Confirm your internal risk method with counsel before relying on it.
Decide on notification to the authority and individuals
The DPO and management decide whether the supervisory authority must be notified, and whether affected individuals must be told under Article 34. Notify the authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk. If a notification is late, the record must give the reasons. Output: a signed decision that names the authority, the timing and any phased content to follow. Regional or cross-border questions should be checked against the lead authority guidance.
Document the decision whichever way it goes
The DPO compiles a breach register entry that records the facts, effects, remedial steps, the risk assessment and the decision on notification, including reasons for not notifying. This record applies whether the decision is to notify, to notify only the authority, or to notify no one. Output: a closed register entry, filed with the supporting evidence and reviewed by a second person. Ask your DPO or counsel to confirm the required content of your register.

Which technical gaps turn a ransomware attack into a regulatory case

Ransomware becomes a GDPR enforcement matter when a controller or processor cannot show that its security was appropriate to the risk. The gaps below recur in the regulator decisions and shape how the EDPB treats availability, confidentiality and notification outcomes.

Backups not isolated or tested

A backup that the attacker can encrypt or delete does not restore availability, so the breach stays an availability breach with notification consequences. Check that at least one copy sits outside the reachable administrative domain, that credentials for backup systems are separate, and that restores have been tested against the systems that hold personal data. Ask whether a restore test has produced a documented recovery time for the most sensitive datasets.

Internet-exposed systems left unpatched

Patient and customer systems reachable from the internet without a controlled access path are the first thing an assessor asks about after an attack. Inventory every externally reachable service, including legacy portals and vendor-hosted administration pages, and record the patch status and owner for each. Confirm that known vulnerabilities in these services have a documented remediation deadline.

Missing MFA and remote access controls

The CNIL fined Hôpital Privé de la Loire EUR 500,000 after an attack on a patient record system holding data on 524,867 patients, which outside users could reach without VPN or multi-factor authentication. Require a gated remote access path with MFA for every administrative and clinical account, and remove direct access where a VPN or zero-trust gateway is the intended route. Review whether vendor and support accounts follow the same rule.

No real-time intrusion monitoring

The IMY fined Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) after a 2025 cyberattack affecting 2.2 million people, citing the absence of automated real-time monitoring for intrusions. Confirm that authentication failures, privilege changes, mass file modification and unusual backup deletion generate alerts that reach a staffed queue. Test whether the alerts would have fired during a rehearsal before relying on them.

Weak checks on software installation

The IMY criticized inadequate checks when new software was installed, which is a change-control gap rather than an external one. Verify that new or updated components pass integrity checks, come from approved sources, and are reviewed before they reach production. Record who approved each change and whether the change was tested for security impact.

Unmanaged encryption keys

Encryption only makes data unintelligible for notification purposes if the key stays uncompromised, as the EDPB Guidelines 9/2022 explain. Keys stored on the same host as the encrypted data, shared administrative secrets, or keys with no rotation or ownership record weaken that exemption. Ask who holds each key, where it is stored, how access is logged, and whether a compromised key would force re-encryption and a new notification assessment.

What regulators fined after recent ransomware and cyberattacks

Recent fines show that regulators tie attack damage to the controller's or processor's technical measures under Article 32, the security of processing obligation, which requires measures appropriate to the risk. The attack itself is rarely the sole finding. Article 83 sets the ceilings: EUR 10 million or 2% of total worldwide annual turnover for infringements such as Articles 25 to 39, and EUR 20 million or 4% for infringements of the principles, data subject rights and transfer rules, whichever is higher in each case. The two decisions below sit far beneath those ceilings, so the practical risk lies in the findings, the remediation orders and the reputational effect on patients and customers.

The Swedish Authority for Privacy Protection (IMY) fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) after a 2025 cyberattack affecting 2.2 million people. The decision of 22 September 2026 cited inadequate checks when installing new software and the absence of automated real-time intrusion monitoring. For a platform operator, the lesson is to confirm that every software change passes a documented security check before deployment and that intrusion alerts reach a responder without waiting for a manual log review. Read the decision text on the EDPB national news page before drawing conclusions for your own environment.

The French CNIL fined Hôpital Privé de la Loire EUR 500,000 in a decision dated 3 September 2026. The attacked patient record system held data on 524,867 patients and could be reached by outside users without VPN or multi-factor authentication. The finding points to access controls on internet-facing clinical systems, not to the ransomware itself. Inventory every system reachable from outside your network, confirm which ones require a VPN or MFA, and document the decision. Check which articles the CNIL decision applies in its full text, since the summary does not settle that for you, using the EDPB news page on the CNIL fine.

What to have in place before the next attack

A ransomware attack tests several controls at once, and a regulator will look at each of them. The items below are the ones the organization owns: the plan, the backups, the encryption, the access controls, the monitoring and the breach record. None of them decides the notification outcome on its own, but a missing one usually makes the outcome harder to defend.

Incident response plan with a 72-hour clock

Write the plan so the clock starts when the organization becomes aware of a breach, and name who makes that call and how quickly. Article 33(1) allows notification after 72 hours only with reasons for the delay, so the plan should include a draft notification template and a named decision owner. To check it, run a tabletop exercise that starts from a ransomware scenario and confirm the first notification can be drafted within the window. A reviewer will ask for the signed plan, the exercise record and the decision log from that exercise.

Isolated, tested backups

Backups matter for GDPR only if they can restore data that is actually unavailable. EDPB Guidelines 01/2021 contain worked ransomware cases with and without proper backups, and the difference between them shows how availability changes the outcome. Keep at least one copy offline or logically separated from the production identity domain. Check it by performing a timed restore of a representative dataset and recording what was recovered. A reviewer will ask for backup job logs, the restore test report and the isolation design.

Encryption with managed keys

Encryption can make data unintelligible, which is why the EDPB says an encrypted-data breach is unlikely to adversely affect individuals if the key was not compromised. That protection depends on the key. Confirm that keys are stored separately from the encrypted data, that access to them is restricted and logged, and that a compromised key can be rotated. Ask the system owner for the key inventory and the rotation procedure. Encryption does not remove the duty to notify in every case, so record the reasoning for each decision.

Access control and MFA on exposed systems

The CNIL's fine against Hôpital Privé de la Loire followed an attack on a patient record system that outside users could reach without a VPN or multi-factor authentication. Inventory every system that accepts remote logins, require MFA for each one and remove direct internet exposure where a VPN or gateway is the intended path. Review privileged accounts and their use. A reviewer will ask for the external-facing asset list, MFA enforcement settings and the most recent privileged access review.

Logging and intrusion monitoring

The Swedish IMY fined Miljödata under Article 32(1) partly for having no automated real-time monitoring for intrusions, so detection is a regulator's expectation as well as a security one. Centralize authentication, administrative and file-access logs, set alerts for unusual bulk reads and encryption activity, and assign someone to respond out of hours. Test the alerts with a simulated event. A reviewer will ask for log source coverage, retention settings and a sample alert with its response record.

Breach register for every incident

Article 33(5) requires the controller to document every personal data breach, including the facts, effects and remedial action, whether or not it is notified. Keep a single register that records the time of awareness, the breach type (confidentiality, integrity or availability), the risk assessment and the decision to notify or not. Review entries after each incident and during the annual plan review. A reviewer will ask for the register itself and the written justification behind each decision not to notify.

Who owns the notification decision and who prepares the evidence

Under the GDPR, the controller is responsible for deciding whether a personal data breach must be notified to the supervisory authority and to affected individuals, and for documenting that decision whatever it is. In practice this sits with a small group: the data protection officer (where one is designated), information security, legal counsel and an executive who can sign off under time pressure. Their decision draws on facts only the organization holds, such as which data sets were encrypted, what the categories of people affected are, and whether the business can operate without restoring data.

Notification decision: The DPO and legal counsel assess risk to individuals and record the reasoning, including where no notification is made.
Sign-off authority: Leadership should name who can approve a notification inside the 72-hour window set by Article 33(1).
Incident facts: Security staff establish what was encrypted, exfiltrated or made unavailable, since these facts drive the outcome.
Documentation: The organization keeps a record of every personal data breach, whether or not it was notified.
Processor oversight: Where a vendor hosts or runs systems, your team confirms what the processor must tell you and when.

Check that the decision group has a written role assignment and has rehearsed it, because the controller cannot delegate the decision itself.

Questions buyers ask about ransomware and GDPR notification

Does ransomware encryption always count as a GDPR breach?

Yes, in most cases an encryption attack on personal data is a personal data breach that the controller must assess, even when no data leaves the environment. The EDPB's Guidelines 9/2022 treat accidental or unauthorised loss of access to, or destruction of, personal data as an availability breach, which can be notifiable without any disclosure. Whether it must be notified depends on the likely risk to individuals, which the controller assesses case by case. Start the assessment on day one and record the reasoning, whatever the outcome.

Does a restored backup remove the need to notify a ransomware attack?

Not automatically. A restore can reduce the risk to individuals, and the EDPB's Guidelines 01/2021 include worked ransomware cases with and without proper backups that show how backup availability changes the notification outcome. Confirm what the backup actually covers: whether it is complete, recent, tested, and isolated from the attacker. Confidentiality questions remain if the attackers copied data before encrypting it. Document the restore, the data recovered, and the data that could not be recovered.

When does the 72-hour notification clock start after ransomware?

The clock starts when the controller becomes aware of the breach, which is not necessarily when the attack began. Under Article 33(1), the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to result in a risk to individuals. If notification is late, the controller must give reasons for the delay. Engineers should note that the first alert from a monitoring tool may start the clock, so triage procedures need to escalate quickly and record the time of awareness.

Can a processor notify the supervisory authority on the controller's behalf?

A processor must notify the controller without undue delay after becoming aware of a breach, but the controller carries the duty to notify the supervisory authority and affected individuals. Processor contracts should set out the notice channel, the contact people, the information the processor must provide, and who makes the decision. Where a supplier is a processor, the controller remains responsible for the notification even if the supplier's team does the technical work. Confirm the terms of your processing agreement before an incident, not during one.

What drives the cost of preparing backups and encryption for GDPR?

The GDPR does not publish a price, and no supplied figure sets one. Costs come from the size and number of systems holding personal data, the number of backup copies and their retention, the storage location, and the effort to test restores. Encryption costs depend on key management, which systems can support it, and the staff time to operate it. Costs are mostly one-time for design and testing, then recurring for storage, key rotation and periodic restore tests. Ask any provider for a written scope that lists systems, backup tiers, test frequency and deliverables before comparing quotes.

Can our own team handle ransomware and GDPR notification without outside help?

Yes, an organization can run its own breach response, and the GDPR does not require an outside firm. The controller owns the decisions, the notifications and the records. Outside help is usually useful for preparing systems, such as isolated backups, encryption and logging, and for testing the restore process before an incident. An implementation partner prepares systems and evidence, but only an independent auditor or certification body issues reports or certificates. Teams with no in-house privacy or incident response experience should confirm who will advise on the notification decision.

Does encrypted data still need to be reported if the attackers took the key?

If the key was compromised, the encryption does not make the data unintelligible, and the breach is still a confidentiality issue to assess. EDPB Guidelines 9/2022 state that a confidentiality breach of data encrypted with a state-of-the-art algorithm is still a personal data breach, but if the key was not compromised, the data are in principle unintelligible and the breach is unlikely to adversely affect individuals. Under Article 34(3), communication to individuals is not required where the data were rendered unintelligible. Check the key store, access logs and the attack path before relying on encryption as the reason not to notify.

Which technical controls do regulators look for after a ransomware incident?

Regulators look at whether security measures were appropriate to the risk, which is the test under Article 32. Recent decisions show what falls short. Sweden's IMY fined Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) after a 2025 cyberattack, citing inadequate checks when installing new software and no automated real-time monitoring for intrusions. The CNIL fined Hôpital Privé de la Loire EUR 500,000 after a patient record system was reachable without VPN or multi-factor authentication. Review remote access, multi-factor authentication, patching, monitoring and backup isolation.

What may change: the Digital Omnibus and procedural rules

The GDPR text has not been amended as of October 2026, so the breach rules this page describes, including the 72-hour notification clock in Article 33(1) and the Article 34(3) exemptions for unintelligible data, remain the law you must follow today. Two legislative files could change that position. The Omnibus IV proposal (COM(2025) 501, procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 and is awaiting Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) is awaiting committee decision. Confirm the current status of both files on the European Parliament Legislative Observatory before you change any policy.

The Digital Omnibus proposal includes a high-risk-only notification threshold, which would narrow when a breach must go to the supervisory authority. That change is not in force and may not survive the legislative process unchanged. The EDPB-EDPS Joint Opinion 2/2026, adopted on 10 February 2026, comments on the proposal and is the document to read if you want to understand the regulators' position on this threshold. For a ransomware incident, the practical question is whether your current documented risk assessment would still justify a notification decision under a narrower test, so record your reasoning in full now, including the backup and encryption facts that drove the decision.

Regulation (EU) 2025/2518 lays down additional procedural rules for complaints and investigations in cross-border enforcement cases and applies from 2 April 2027. It will affect how a multi-country ransomware incident is investigated, but it does not change the breach notification duties themselves. Until a change is adopted and applies, keep your current breach response procedures, backup and restore tests, and encryption key records in force, and review them against the official texts once the amending instruments are published. Assign an owner to track these files, and schedule a procedure review for the date each one takes effect.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the backup, encryption and monitoring evidence a GDPR breach assessment depends on. The organization keeps ownership of its controls and its breach decisions, and an independent assessor or regulator reviews the outcome.

How we scope

Written scope defines which systems, backup sets and key stores are covered before any work starts.
Scope records which personal data sets sit on each system and where encryption keys are held.
Scope names your owners for breach decisions, restore testing and log review, so responsibilities are clear.

How we build

Backups are configured as separate, access-restricted copies with documented restore procedures for each system.
Encryption at rest and in transit is set up with key custody separated from the data it protects.
Logging and alerting are configured to surface unauthorized access, mass file changes and backup deletion attempts.

How we hand over

Deliverables include configuration records, restore test results and key management documentation for your files.
Evidence packs show what each backup, encryption and monitoring control does, with dates of testing.
Runbooks explain how your team assesses whether data was unintelligible or recoverable after an incident.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask any implementation partner to confirm in writing which evidence they prepare and which your auditor or regulator must review.

Ransomware and GDPR: notification, backups and encryption