The Right to be Forgotten creates a conflict for IT teams: you must erase personal data to comply with GDPR, yet you must keep data to ensure business continuity. If you restore a backup taken before a deletion request was processed, you accidentally re-introduce the erased data, placing your organisation in breach of Article 17. To solve this, you need a granular recovery strategy that cross-references a secure erasure log before data is written back to production.
Under Article 17 of the General Data Protection Regulation (GDPR), individuals have the Right to Erasure, commonly known as the Right to be Forgotten. When a valid request is made, an organisation must erase that individual's personal data from its live systems without undue delay.
However, organisations also have an obligation to maintain backups for resilience and disaster recovery. The conflict arises because a backup is a snapshot of the past. If a user requests deletion on Tuesday, and you erase them from the live system, they still exist in the backup taken on Monday.
If your system suffers a failure on Wednesday and you restore the Monday backup, the "forgotten" user's data is written back into the live environment. You have now effectively un-erased the data, reversing the compliance action you took on Tuesday.
Most standard backup tools exacerbate this risk because they suffer from two flaws:
The consequences of re-introducing erased data include regulatory fines of up to 4% of global turnover, but arguably the greater cost is the loss of trust and the operational complexity of cleaning up the data a second time.
To navigate this paradox, IT and compliance teams must adopt specific restoration patterns. You cannot simply restore and hope for the best.
You should keep a secure, minimised log of identifiers (such as hashed email addresses or IDs) for individuals who have exercised their Right to be Forgotten. This is not the personal data itself, but a "Do Not Restore" list. This list must persist outside your standard backup cycle.
Avoid full-system rollbacks whenever possible. Modern backup strategies allow for the surgical restoration of specific datasets, pipelines or properties. By restoring only what is broken, you reduce the surface area of the restore and the likelihood of re-introducing unrelated, erased records.
This is the gold standard for compliance. Before data is pushed back into the live HubSpot portal, the recovery process should validate the backup data against your suppression log. If a record in the backup matches an ID on the "Do Not Restore" list, it must be excluded from the restore job.
backHUB is designed to solve the tension between recovery and privacy. It moves beyond simple snapshots to offer a compliance-aware recovery platform.
Our architecture supports the safe patterns described above. By enabling granular selection of data, down to the specific property or record, backHUB helps you avoid the "all or nothing" trap of traditional backups.
Furthermore, we provide an immutable audit trail. Every restore action is logged, providing evidence that you followed a controlled process. Following any significant restoration, Struto provides a stabilisation period. During this time, we help you verify that the integrity of the system is restored and that no compliance boundaries were crossed.
In the modern regulatory landscape, your backup strategy is part of your compliance strategy. A restore process that ignores GDPR is a liability waiting to be triggered.
By adopting granular recovery and maintaining strict validation protocols, you can ensure that your organisation remains resilient against data loss without compromising the rights of your data subjects.
Yes. Personal data stored in backups is subject to GDPR. However, regulators generally accept that immediately scrubbing every backup tape or snapshot is technically impossible. The key requirement is that the data must be put beyond use and, crucially, must not be re-processed or restored to the live system.
You are not typically required to mount and edit every historical backup file immediately. Instead, you must ensure that if a backup is used to restore the system, the "forgotten" data is not re-introduced. This is usually achieved by maintaining a suppression list and filtering data during the restore process.
In data management terms, deletion often means hiding data or marking it as trash, where it can be easily recovered. Erasure (under GDPR) implies a permanent action where the data is destroyed or anonymised so that the individual can no longer be identified, and the process cannot be reversed.
See how backHUB enables compliant recovery