4 areas where compliance with GDPR and disaster recovery intersect
Your disaster recovery plans may have to change following the need for compliance with GDPR. These four elements involve backups, personal data, security and archiving.
Most organizations are focused on two specific aspects of the European Union's General Data Protection Regulation: how personal data is collected and how it's processed. This has marketing teams worried about opt-in functionality and IT teams worried about data security.
But GDPR compliance also impacts recovery efforts, and there is some very specific text that outlines how the regulation will affect your disaster recovery planning. Rather than make you rummage through the entire regulation, here are four specific parts that refer to GDPR and disaster recovery. I'll cite the GDPR text and what it requires of you and then explain the ramifications to your DR plans.
You must have backups of personal data
Article 5(1)(f) says that personal data shall be "processed in a manner that ensures appropriate security of the personal data, including protection … against accidental loss, destruction or damage, using appropriate technical or organizational measures."
While the use of the term security usually has connotations about permissions and privileges, note the use of the phrase "against accidental loss."
In this case, the "security of the personal data" is ensuring the data isn't lost, destroyed or damaged. And since you need to protect that data against loss, you obviously need to have backups of it.
Recovery of personal data needs to be a priority
Article 17(1) says that the owner of personal data has "the right to obtain from the controller the erasure of personal data concerning him or her without undue delay, and the controller shall have the obligation to erase personal data without undue delay."
There is similar text within requirements related to an owner's right to access, request a copy of and correct personal data within your systems. It's the "without undue delay" that should be of particular interest regarding GDPR and disaster recovery plans.
Systems containing personal data -- such as marketing systems -- may not be considered Tier 1 workloads in your DR plan. They don't have short recovery objectives and are, therefore, secondary or tertiary in focus when a real disaster occurs. But in a disaster situation where you're focused on getting the business operational, if a request should come in and you're thinking "in about a week," that may be considered "undue delay."
Recovery must include security
Article 25(1) states that a controller will "both, at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures … in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects."
It's certainly not impossible to make compliance with GDPR and disaster recovery plans jibe.
Anytime you see the word "safeguards" in this regulation, it includes appropriate permissions that protect personal data form being mishandled. When you see that those safeguards need to be in place at the "time of processing," which can occur after a DR scenario, you must ensure that your recovery efforts include putting all security configurations that impact personal data back in a known-good state. This compliance with GDPR and disaster recovery effort includes permissions at the database, file, server and directory levels.
You can't archive personal data
Article 5(1)(e) says that data shall be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes."
This part of the regulation ties in with the owner's right to be forgotten -- that is, the right to ask your organization for removal from your systems. The EU only wants you to keep backups of personal data for the purpose of being able to recover active systems and current data sets. (Note "for no longer than is necessary for the purposes for which the personal data are processed.")
The last bit about keeping the data for "longer periods" may look like you can archive forever, but keep reading. There are very specific reasons to archive the personal data, and "because I don't want to reconfigure my archives to exclude it" isn't one of them.
It's certainly not impossible to make compliance with GDPR and disaster recovery plans jibe. In short, it amounts to keeping systems hosting personal data running, ensuring security around personal data and only generating enough backups to achieve either of these two goals.
Dig Deeper on Disaster recovery planning and management
