GDPR Disaster Recovery: What Article 32 Requires When Systems Go Down
Most GDPR conversations focus on consent, breaches, and data subject rights. Disaster recovery gets less attention, but it sits directly inside the regulation’s security requirements. If your systems go down, whether from a server failure, a natural disaster, or a ransomware attack, GDPR has specific expectations about how quickly you can bring personal data back online.
Key Takeaways
• Article 32(1)(c) GDPR specifically requires the ability to restore the availability and access to personal data promptly after a physical or technical incident.
• A ransomware attack can trigger three separate breach types at once: availability, confidentiality, and integrity, each with different notification implications.
• Verified, tested backups can reduce or eliminate breach notification obligations after a ransomware incident, but only if restoration happens quickly enough that individuals are not affected.
• GDPR requires you to test your disaster recovery measures, not just have them documented. An untested backup plan does not satisfy Article 32(1)(d).
Does GDPR Require a Disaster Recovery Plan?
GDPR does not use the phrase “disaster recovery plan.” Still, Article 32 requires organisations to implement technical and organisational measures appropriate to the risk, including the ability to restore access to personal data after a physical or technical incident. Our breakdown of Article 32’s security requirements covers the full text and its practical implications in more depth. In practice, that means a documented, tested capability to recover systems and data, which is what a disaster recovery plan is built to provide.
Article 32(1) sets out four specific measures, taking into account the state of the art, implementation cost, and the risk involved:
• pseudonymisation and encryption of personal data;
• the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems;
• the ability to restore availability and access to personal data promptly after an incident;
• a process for regularly testing, assessing, and evaluating how effective these measures actually are.
The third and fourth points are where disaster recovery obligations live directly in the regulation’s text.
What Counts as an “Incident” Under Article 32?
Article 32(1)(c) refers broadly to “a physical or technical incident,” which covers considerably more than cyberattacks. Server failures, fire or flood damage to a data centre, a failed software update that corrupts a database, and a ransomware attack all fall within scope. The obligation is the same regardless of cause: personal data availability and access need to be restorable within a timeframe appropriate to the risk the data represents.
Does a Ransomware Attack Count as a GDPR Breach?
Usually yes, and often as more than one type of breach simultaneously. A ransomware attack that encrypts personal data is an availability breach on its own. If the attacker also exfiltrated data before encrypting it, that adds a confidentiality breach. If the attacker had write access to the systems, integrity cannot be guaranteed either. A single ransomware incident can trigger all three breach categories GDPR recognises.
Do You Have to Notify a Regulator If Your Backups Restore the Data Quickly?
Not always. If an organisation has verified, uncompromised backups and can restore affected systems promptly, with no lasting effect on the individuals whose data was involved, the incident may not meet the threshold for notification under Article 33, which only applies where a breach is likely to result in a risk to people’s rights and freedoms. Restoration speed is directly relevant here: a slow or failed recovery from backup increases the likelihood that individuals are actually affected, which pushes the incident back toward a reportable breach.
The EDPB’s guidelines on personal data breach notification work through this exact scenario using ransomware as a worked example, weighing backup availability and restoration speed against the risk to individuals. Where backups are unavailable, outdated, or themselves compromised by the same incident, that changes the analysis significantly. A lengthy period where personal data is inaccessible, even without any data loss or exposure, can itself constitute a reportable availability breach, particularly where the data supports time-sensitive decisions such as healthcare or financial services.
What Does “Timely” Restoration Actually Mean Under Article 32?
GDPR does not attach a fixed number of hours or days to “timely” restoration in Article 32(1)(c). What counts as timely depends on the risk profile of the data and the processing activity, following the same risk-based approach that runs through the rest of the regulation. Restoring a marketing mailing list within a few days carries different consequences than a multi-day outage affecting a hospital’s patient records or a financial platform’s transaction data. Organisations processing higher-risk data need faster recovery capability to meet the same legal standard as organisations processing lower-risk data with a longer acceptable recovery window.
What Does It Mean to “Test” Disaster Recovery Under GDPR?
Article 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of security measures, which extends to backup and recovery capability specifically. A backup policy that has never been tested with an actual restoration exercise does not satisfy this requirement, even if backups are being taken correctly on schedule. Regulators reviewing a breach response consistently look for evidence that recovery procedures were tested before the incident, not assembled afterwards.
Practical testing includes periodically restoring data from backup in a controlled environment to confirm it is complete and usable, timing how long a full restoration actually takes against the recovery targets the organisation has set, and updating the recovery plan when infrastructure, vendors, or data volumes change.
What Should a Disaster Recovery Plan Cover to Meet GDPR’s Standard?
A disaster recovery plan built to satisfy Article 32 needs to identify which systems process personal data and prioritise recovery accordingly, define a recovery time objective appropriate to the risk each dataset represents, maintain backups that are encrypted, tested, and stored separately from the primary systems they protect, and include a documented process for assessing whether an incident triggers breach notification obligations once systems are restored.
This should sit alongside, not separate from, the organisation’s incident response and breach notification procedures, since a single incident like ransomware typically triggers both processes at once.
Conclusion
Disaster recovery is not a separate concern from GDPR compliance; it is written directly into Article 32’s security requirements. The ability to restore personal data availability within a timeframe appropriate to the risk, backed by testing that actually proves the recovery plan works, is a legal expectation, not just good IT practice. Organisations that treat backups as a checkbox rather than a tested capability are the ones most likely to face both a longer outage and a harder conversation with a supervisory authority afterwards.
Frequently Asked Questions
Is a documented backup policy enough to satisfy GDPR?
No, not on its own. Article 32(1)(d) requires the effectiveness of security measures to be regularly tested and evaluated. A backup policy that exists on paper but has never been tested through an actual restoration exercise does not meet this standard.
Does GDPR require offsite or cloud backups specifically?
GDPR does not mandate a specific backup architecture. It requires the outcome: the ability to restore availability and access to personal data promptly after an incident. Offsite or geographically separated backups are a common way organisations achieve that outcome, particularly against risks like fire, flood, or a compromised primary data centre.
If ransomware encrypts our data but we pay the ransom and recover it, do we still need to notify?
Paying a ransom does not remove the notification analysis. The relevant questions are whether the incident is likely to result in a risk to individuals’ rights and freedoms, and how long their data was unavailable or exposed. Data exfiltrated before encryption, or a lengthy outage before recovery, can still trigger notification obligations regardless of whether a ransom was paid.
Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.
About the Author
Zlatko Delev
Country Manager & Head of Commercial — GDPRLocal
Zlatko specialises in data protection compliance, ISMS strategy, and AI law. With a legal background and hands-on experience supporting organisations globally, he helps businesses navigate GDPR, the EU AI Act, and international privacy frameworks.