• United States




How to make your disaster recovery GDPR compliant

Aug 01, 20175 mins
Backup and RecoveryComplianceDisaster Recovery

disaster recovery plan ts
Credit: Thinkstock

With GDPR coming into effect on 25 May 2018, it’s costing businesses significant time and money to ensure compliance with the new regulations. Rather this than risk a fine of 4% of turnover or EUR20million. But when it comes to your IT have you really covered all bases? Have you thought about your disaster recovery and properly assessed whether this is compliant also? It’s crucial that you do so as one small slip-up by any one of your data processors could leave you paying the penalties. In 2016 the ICO imposed penalties of GBP2,155,500 on 21 companies, and fines are increasing year on year.

Playing it by the rules

The rules for GDPR are as applicable to your DR systems as they are your production systems, so ensuring they are compliant is critical. Whether you manage your DR in-house or use an external DR provider, there's a high chance that you'll need to do things differently. Article 32(1) of the new GDPR regulation states: "Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate.

(a) the pseudonymisation and encryption of personal data; => Article: 4 (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing."

You should be able to demonstrate processes around the security, availability, recovery and testing of your IT systems which encompasses disaster recovery. Furthermore these processes need to be of an adequate standard to ensure timely and effective recovery without risk to the confidentiality and integrity of a consumer's information.

[Related: General Data Protection Regulation (GDPR) requirements, deadlines and facts]


Security is made up of 3 building blocks- confidentiality, availability and integrity. ISO27001 provides a comprehensive framework for developing, implementing and maintaining an independently auditable information security management system (ISMS), aligned with GDPR policies. If neither you nor your DR provider is ISO27001 certified then it would be beneficial to do so through a reputable provider such as the BSI. If you are ISO27001 certified but your DR provider isn't then you are at risk of your certification being null and void, so it's important to check on the status of your DR provider's certification.

GDPR comes with more stringent rules around data being transferred outside of the EU so you should verify where your data is being held. If it is being transferred outside of the EU then the conditions of chapter 5 of GDPR need to be met.

A full process around data breaches should be made available by your provider and aligned with yours to ensure there are no holes that could be seen as a vulnerability.


It's well worth checking your provider's recovery commitments. There are two performance elements to IT recovery: 1. How long it will take to achieve full return to service, and 2. How much data could be lost during the recovery process. You'll no doubt have recovery time objectives (RTO's) and recovery point objective's (RPO's) in place, but are there any guarantees or consequences to them should they not be met, or are they merely 'hopeful targets'? In order for your recovery to meet GDPR regulations you should demand more certain outcomes such as guarantees from suppliers to ensure you are not at risk.

You should also review the process of keeping your backup data up to date in order that subjects can access, erase or amend their data. How frequently will your backup data be updated and is this frequently enough to keep you compliant should you need to failover to your DR systems?


Testing of your DR systems should be documented in order for you to prove that your procedures are in line with compliance. How often are DR tests performed and do these tests merely check that the data has been backed up or do they test the recoverability of systems, applications and data? Daily testing of DR systems to application level with certification will no doubt protect you against all risks and prove compliance, but is this possible through your current supplier or in-house team? Disaster recovery testing is probably the main area for companies to drive harder in terms of compliance.

Contract amendments

Contractually you should confirm with all DR and backup providers that they are a ‘data processor’ and seek new contracts from them which state this. Under GDPR rules, anyone obtaining, holding or retrieving data is considered as a 'data processor' and is therefore subject to the compliance. You should also have a data sharing agreement drawn up to confirm how the data can be used along with disclosure policies. This will ensure your DR provider has thought about GDPR.

If you're at all worried about GDPR then certification through a reputable body is recommended and will be encouraged to protect yourself against repercussions.


Beth Baxter is Marketing Manager for disaster recovery provider Plan B. She has been at the forefront of disaster recovery and business continuity for over four years, covering the topics of DRaaS, backup, continuous replication and cyber security. She researches disaster recovery trends and provides DR market insight reports twice a year and has written for a range of other IT sites including the Stack and Outsourced Magazine.

The opinions expressed in this blog are those of Beth Baxter and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.