Deletion in Backups, Replicas, and Cloud Services (CDPSE: Data Life Cycle Management)
Introduction
Deleting data from a primary system is easy. Making sure it is gone from every backup tape, snapshot, disaster recovery replica, cache, log, cloud bucket and third-party processor is much harder. For the ISACA Certified Data Privacy Solutions Engineer (CDPSE) exam, this topic sits inside Data Life Cycle Management. It tests whether you can design and run technical controls that honor retention schedules, data subject erasure requests and contractual end-of-service obligations wherever personal data lives.
Why It Is Important
1. Legal and regulatory compliance. Many privacy laws require that data be erased once it is no longer needed or when a valid request is received. Examples include GDPR Article 17 (Right to Erasure), Article 5(1)(e) (storage limitation), CCPA/CPRA deletion rights, LGPD and PIPEDA. Regulators expect organizations to consider backups and replicas, not just production databases.
2. Data minimization and risk reduction. Every forgotten copy is breach exposure. A stolen backup containing data that should have been deleted years ago turns a manageable incident into a serious violation.
3. Data resurrection risk. If a backup is restored without re-applying deletions, erased records come back to life. This breaks commitments made to data subjects.
4. Cloud and shared responsibility. In cloud services the customer often cannot physically destroy media. Assurance depends on contracts, provider attestations, encryption and key control.
5. Trust and accountability. Organizations must be able to demonstrate that deletion happened, through logs, certificates of destruction and audit evidence. This reflects the accountability principle.
What It Is
This concept covers the policies, processes and technical mechanisms used to ensure personal data is removed or made irrecoverable across all secondary copies:
- Backups: full, incremental and differential backups, tape archives, offline and offsite media, immutable or WORM backups.
- Replicas: database mirrors, read replicas, DR sites, high-availability clusters, geo-redundant storage.
- Snapshots and caches: VM snapshots, storage snapshots, CDN caches, search indexes, data warehouses and data lakes.
- Logs and derived data: application logs, analytics extracts, test or dev copies, machine-learning training sets.
- Cloud services: IaaS, PaaS and SaaS storage, object versioning, soft-delete recycle bins, multi-region copies and subprocessor systems.
Key related terms:
- Deletion (logical): removing references, so the data may still be recoverable.
- Erasure or sanitization: rendering data unrecoverable. NIST SP 800-88 defines three levels: Clear, Purge and Destroy.
- Crypto-shredding (cryptographic erasure): destroying the encryption keys so encrypted data becomes unreadable.
- Beyond use: data that cannot yet be technically erased but is isolated, protected and never restored or used for any purpose.
How It Works
1. Data inventory and mapping. You cannot delete what you cannot find. Maintain a data inventory and data flow maps that identify every location of personal data, including backups, replicas and cloud regions. Link each data category to a retention period in the retention schedule.
2. Retention-aligned backup design. Set backup rotation and expiry periods that align with retention requirements. Example: if customer records must be deleted 30 days after account closure, backup retention should not routinely keep them for 7 years without justification. Separate long-term archives (legal or regulatory holds) from operational backups. Prefer granular backup technologies where possible.
3. Handling erasure requests against backups. Restoring every backup to delete one record is often impractical. Accepted approaches include:
- Delete from production immediately and propagate the deletion to live replicas.
- Allow backups to age out naturally per the rotation cycle, keeping the data beyond use in the meantime.
- Maintain a deletion or suppression log (a tombstone list of deleted identifiers). When a backup is restored, re-apply the deletions before the data goes back into production.
- Inform the data subject transparently, where appropriate, that residual copies in backups will be overwritten within a defined period.
4. Replica synchronization. Deletions must cascade to all synchronized replicas, DR sites, caches, search indexes and downstream systems. Event-driven deletion workflows, orchestration tools and verification jobs confirm that replicas are consistent. Watch for asynchronous replication lag and for one-way data exports that bypass synchronization.
5. Crypto-shredding. Encrypt data, ideally with per-tenant, per-dataset or per-subject keys. Destroying the key renders every copy unreadable, including copies in immutable backups and cloud storage you cannot physically wipe. This works only if:
- key management is strong (HSM or KMS), and
- no key backups or escrow copies survive.
6. Cloud service deletion.
- Understand the provider's deletion process: soft-delete windows, object versioning, multi-region replication and backup retention on the provider side.
- Contractual controls: the Data Processing Agreement (DPA) should specify deletion or return of data at contract end, deletion timelines, flow-down to subprocessors and certification of deletion. This is required under GDPR Article 28(3)(g).
- Customer-managed keys (BYOK/HYOK): allow the customer to crypto-shred.
- Assurance: SOC 2 reports, ISO/IEC 27001/27017/27018 certifications, right-to-audit clauses and provider attestations of media sanitization per NIST SP 800-88.
- Configure lifecycle policies: object lifecycle rules, disabling or limiting versioning, purging recycle bins.
7. Physical media sanitization. Apply NIST SP 800-88 for retired drives and tapes:
- Clear: overwrite, which protects against simple recovery.
- Purge: degaussing, cryptographic erase or block erase, which protects against laboratory recovery.
- Destroy: shredding, incineration or disintegration.
Obtain certificates of destruction from vendors and maintain chain of custody.
8. Legal holds and exceptions. Legal holds suspend deletion for relevant data. Deletion processes must check hold status and resume once the hold is lifted. Document any lawful basis for continued retention.
9. Verification, logging and audit. Record deletion events, scope and method, and periodically test that deleted data does not reappear after restores. Include backup and cloud deletion in privacy audits and DPIAs.
Common Pitfalls
- Deleting only from the primary database while copies persist in data lakes, test environments or exports.
- Restoring old backups without re-applying deletion logs.
- Indefinite backup retention with no business justification.
- Relying on a cloud provider's console delete without understanding soft-delete or versioning.
- Crypto-shredding while key backups still exist.
- DPAs lacking deletion and subprocessor flow-down clauses.
Exam Tips: Answering Questions on Deletion in Backups, Replicas, and Cloud Services
1. Think practical and risk-based. ISACA rarely favors restoring and editing every backup. The best answer usually combines:
- deleting from production,
- keeping backup copies beyond use,
- letting them expire per the rotation schedule, and
- re-applying deletions upon restore.
2. Start with the data inventory. If a question asks what to do FIRST to ensure complete deletion, identifying all locations of the data (data mapping or inventory) is often correct.
3. Crypto-shredding is the go-to answer when physical deletion is impossible. This applies to immutable backups, multi-tenant cloud storage and SaaS where you cannot access the media. Remember the condition: keys must be fully destroyed, and customer-controlled keys are needed.
4. Contracts first for cloud and vendors. For questions about ensuring a provider deletes data, look for answers involving DPA or contract clauses, deletion certification, subprocessor flow-down and right to audit. Prefer preventive and contractual controls over hoping the provider complies.
5. Align with the retention schedule. Backup retention should be driven by documented retention requirements and business need, not by IT convenience. An answer that aligns backup rotation with the retention policy is typically superior.
6. Remember legal holds. If a scenario mentions litigation or investigation, deletion must be suspended for the relevant data. A hold overrides routine deletion and erasure requests.
7. Know NIST SP 800-88 terminology. Clear, Purge and Destroy. Choose the method that matches the media and sensitivity:
- Destroy for highly sensitive data on media leaving organizational control.
- Purge for reuse outside the organization.
- Clear for internal reuse.
Degaussing does not work on SSDs.
8. Replicas are not backups. Deletions in production generally propagate automatically to synchronous replicas. Questions may test whether you know that asynchronous replicas, caches, indexes and analytics copies need explicit handling.
9. Evidence and accountability. When asked how to demonstrate deletion, choose answers involving logs, certificates of destruction, audit trails or attestation reports.
10. Transparency with data subjects. It is acceptable, and often recommended, to inform individuals that their data will be removed from backups within a specified period.
11. Watch for distractor answers:
- Delete the backup tapes entirely: too disruptive, harms availability.
- Rely on the provider's privacy policy: insufficient assurance.
- Mark records as inactive: not deletion.
- Anonymize by removing names only: likely still personal data, so this is pseudonymization.
12. Privacy by design. The most mature answer often builds deletion capability into the architecture from the start. Examples are per-subject encryption keys, tagging data with retention metadata and automated lifecycle policies. Retrofitting deletion later is weaker.
Sample Question
A data subject requests erasure. The organization's backups are retained for 90 days on immutable storage. What is the BEST approach?
A) Restore all backups, delete the record, and re-create the backups.
B) Delete from production, record the request in a deletion log, ensure backup data is not used, and re-apply the deletion if a restore occurs.
C) Refuse the request because the backups are immutable.
D) Delete the entire backup set.
Answer: B. It satisfies the erasure obligation proportionately, preserves availability and prevents data resurrection.
Summary
Effective deletion across backups, replicas and cloud services requires:
- complete data mapping,
- retention-aligned backup design,
- deletion propagation and restore-time re-application,
- crypto-shredding with strong key management,
- solid cloud contracts and assurance,
- NIST SP 800-88-based media sanitization,
- legal hold awareness, and
- verifiable evidence.
On the exam, favor answers that are risk-based, practical, contractually enforced, evidence-backed and designed in from the start.
