Problem solve Get help with specific problems with your technologies, process and projects.

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.

This was last published in August 2018

Dig Deeper on Disaster recovery planning - management

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

How have you changed your disaster recovery plans following the implementation of GDPR?
Cancel

What I dislike with this and any similar regulations is not really sharp statement on dates and timings, for example 'controller shall have the obligation to erase personal data without undue delay' is very confusing and could lead to different concepts what does 'undue delay' mean. For me it could be 10 years, as I my company created my own personal information policy. For others it could be 10 days. For user 1 day. And at the end European Court of Justice will decide what does it mean in favour to EU. Good regulation is clear and short regulation. This one is long and unclear.

Also, when data breach was reported the company will be fined (could be) up to 20 million, but where this money will go? No, no, not to the victims of this crime - they have to spend their time and money to fight for their right in the court. Is this justice?

The conept is ok becouse we all need personal data protection, but I'm afraid it's another way of making money, that's why the amount of fine is so high

Cancel
Totally agree. From the perspective of the regulation's authors, they have no way of knowing what's "reasonable" for each company, so they really *must* write these using generic and broad terms.  

And the fines are merely there to ensure compliance - in the US, you'd have to demonstrate damages to have a court case, and yet, in the case of GDPR, if a person can't gain access to their records, a company is fined (even without demonstrating any damages to the individual requesting access). 
Cancel

-ADS BY GOOGLE

SearchDataBackup

SearchStorage

SearchConvergedInfrastructure

Close