Having implemented your strategy to comply with the General Data Protection Regulation (GDPR), you know it touches every corner of your infrastructure—and your customers’. Ultimately, maintaining compliance comes down to knowing where all data stored, including backups.
A key aspect of GDPR is the “right to be forgotten.” It means an individual can request that an organization remove any personal data pertaining to them, although there are some caveats.
The challenge is data is often duplicated by accident thanks to siloed business processes and applications. It’s also intentionally replicated for backup and disaster recovery purposes. The latter is where things get murky. If an individual does ask for their data to be completely erased, backup copies of that data are implied to be included in that request.
But backups can duplicate data too, so frequent requests for personal data erasure threaten to be come somewhat onerous because that information could be spread across multiple locations, including backups.
Who’s responsible for personal data backups under GDPR?
Further complicating matters is understanding who is responsible for erasing data that’s been backed up.
Under GDPR, an organization has one month to answer an erasure request and make certain personal information is completely wiped from their system. But it raises questions about backups, particularly long retention backups—removing a person from an historical backup is no easy task when backups included millions of database entries.
GDPR clearly also states that accountability for protecting personal data is the responsibility of the organization that is collecting and storing information on EU residents. But in an era of managed IT, cloud services, and outsourced backup and data recovery, personal information governed by GDPR could flow into a service provider’s infrastructure.
This reinforces the need understand where all customer data is flowing and stored. Although organizations should have already mapped their data and information flows in advance of the legislation taking effect, the process may not have considered all services providers and business partners that may have access to that data.
Backups have leeway under GDPR
When an individual does exercise their right to be forgotten, an organization must remove their data from production systems, but there’s some wiggle room on backups.
Communication with the data subject is essential: You must explain clearly that their personal data has been removed from your production system, but that a backup copy may remain for a finite period of time. The expiration of that backup will be informed by your retention policies, which must also be clearly communicated with the data subject. It also means the individual’s data should never be restored again to a production system. This added complexity should be seen as an opportunity to re-engineer your data protection processes and review your retention policies.
Bear in mind that you GDPR commitments must be balanced with other responsibilities. Just because an individual requests that their personal data be deleted from their systems, you can refuse that request if that information is needed to continue to deliver services or for other compliance reasons. It’s a reminder that GDPR compliance is a continuum—you must be ready to play the long game.
Not only should your documentation and data processing activities must be transparent and accountable but also treated as living entities that are always evolving. Now that GDPR is in full force, you should always be re-evaluating your data protection practices and policies, including your backups and your customers’ backups, to confirm compliance and find areas that could use improvement.