After reading my last post, you should have defined your business’ GDPR-ready data retention period. You should also have ensured your backup partner offers retention capabilities that are aligned to your corporate objectives. A successful backup solution will support customizable backup retention periods. Next on your journey to ensuring that your backup strategy is GDPR-ready is striking the right balance between the GDPR Article 32, Security of Processing, and Article 17, the Right to Erasure.
Article 32: Security of Processing
GDPR Article 32, Security of Processing, takes into account the state of the technology art and the cost of implementation when you are securing and safeguarding personal data. The use of appropriate technical and organizational security measures are dictated in Article 32. These include:
- 1a - using pseudonymisation and encryption of personal data
- 1b - the ability to ensure the ongoing confidentiality, integrity, availability, and resiliency of your data and services.
To appropriately align with Article 32, you should not only protect your data from unauthorized access and outages, but also from modification. In the SaaS backup world, many businesses are in highly regulated industries, thus their focus is on ensuring secure data processing by having immutable, or unchangeable, backups of EU Subject personal data.
Daily Backup Snapshots
One example of an immutable backup is a daily snapshot of your live Salesforce environment. A daily snapshot cannot be modified, so backing up snapshots makes it easier to comply with data resiliency requirements under the GDPR Article 32.
Secure Data Encryption
Furthermore, to comply with GDPR Article 32 (1), you need to make sure you are protecting the privacy of the data you have backed up. This can be accomplished by ensuring that your backups are encrypted in transit and at rest and your backup solution has archival data resiliency, granular access controls, and uses security auditing procedures, such as those defined under AICPA Trust Principles of SOC 2 and ISO 27001. Or if you are in the federal space: NIST SP 800-53.
Timely Disaster Recovery
After ensuring your daily backups are being maintained and kept secure, you are required by GDPR Article 32(1 a-d), to have a documented disaster recovery process that proves, through regular testing, that the data can be restored in a timely manner in the event of a data loss or corruption. Under the GDPR, a timely manner is defined as from hours to days, not from weeks to months.
If you currently use the Weekly Export, Salesforce’s out-of-the box backup solution, you will want to pay attention to the recovery of backed up data within a timely manner. Recovering lost or corrupted data using this tool is a multi-step, manual process that can take a considerable amount time, given the size and complexity of your scheme. For example, it took one Own customer 80 hours over 5 weeks to do a Weekly Export recovery. Similarly, tools that integrate to on-premise or SQL databases have the potential risk to overwrite historic data, so you will want to pay close attention to ensure your recovery process meets the regulation.
Article 17: The Right to Erasure
Article 17, Right to Erasure, also known as the Right to Be Forgotten, allows EU individuals to request their personal data be erased by the Data Controllers that process it. Article 17 also states that all traces of personal data have to be deleted if you no longer have a legal basis for keeping it. Data Controllers may be obligated to maintain data in compliance cases of
- legal obligation
- freedom of expression
- regulatory requirements
- customer contracts
- public interest
- historical archiving
- research and statistical purposes
- legal defense claims
- significant legitimate interest
If none of these cases apply, however, the EU data subject has a legal right to have their data removed.
Article 32 and 17: Finding a Balance
Deleting someone’s information from all copies of your company data, including backups, archives, and test sandboxes could become extremely challenging if you have yet to map your data nor know what data you have and where it lives. This data inventorying process has been documented in my previous blog, GDPR Subject Access Requests: Can You Respond?
Article 17 seems directly at odds with Article 32, Security of Processing, and immutable or uneditable backups. Under Article 17, personal data must be erased without undue delay, with many organizations setting a target of doing so within 30 days. If your organization keeps backups for ten or 30 days, your data will age out of the backups within a reasonable amount of time. But, if you need to keep your backups for longer, for example six months, then you will still have many months where you are holding and processing personal data, potentially against the EU Data Subject’s wishes unless your reason falls within the requirements listed above.
“Scrub on Restore” to Forget EU Data Subjects
There are plenty of justified reasons why you may need to keep backups for a longer period, such as in regulated industries that require audit trails and point-in-time sets of evidence, or long-term immutable storage, such as SEC or HIPAA. In these cases, what happens if your controller get a deletion request and you did not delete the data from your long-term backups or archives?
To avoid this, you need to design a backup strategy that allows for scrub on restore. This enables you to mark the data or contact IDs inside the backup as due for deletion through a blacklist, ensuring that should the backup data set ever be accessed or searched, an automated process will kick in to apply the EU Data Subject’s erasure request to the restored data, before it ever enters your live environment. By doing this, you avoid having to re-encrypt and re-archive, which reduces potential security risks to your regulated archives.
Maintain Data Transparency
Since the EU Data Subject’s data is not being deleted from backups and archives right away, due to controller compliance and legal reasons or because it is being held for scrub on restore, your company, as the Data Controller, must be transparent about your actions, processes, and subvendor processes. This means that after taking action on an EU Subject’s Right to Be Forgotten request, you should inform them that their personal data will not be restored back to production systems.
If a EU Data Subject’s personal data needs to be restored from backups, you, as the Data Controller, will take the necessary steps to honor their initial request and erase the data again. Furthermore, backups and archives containing personal data will need to be continuously protected with strong encryption so that the EU Data Subject’s information will remain secure and immutable, even in the event of data theft.
Notifying the EU Data Subject of all steps and precautions taken in your Right to Be Forgotten confirmation will not only let EU Data Subjects know that your company has honored their request, but also that it has thought through the process and made a conscious decision to go above and beyond to maintain data transparency.
The Own GDPR solution helps customers find the balance
Own helps customers meet requests for GDPR Article 17, Right to Be Forgotten and Right to Rectification. Furthermore, Own exceeds GDPR requirements with backups that enable Data Controllers to also comply with Article 32, Security of Processing.
Working Party 29’s guidelines and case law will continue to be released to help expand the GDPR interpretation. Balancing where the “state of art technology” is and where the risks are, Own has an obligation to protect customer data, thus our approach will continue to evolve over time.
Visit the Own website to find out more about Own’s GDPR data protection solution and find answers to some of the most commonly asked questions on these topics.
.png){kind=logo}
