Erasure Requests Meet Immutable Backups and a US Litigation Hold
You are the privacy operations lead at an HR SaaS provider serving 900 enterprise clients across 14 countries, holding about six million employee records. The retention schedule says terminated employee records are kept for seven years for tax purposes. Production data is deleted on request, but backups are immutable for 90 days, and the analytics warehouse retains hashed employee IDs indefinitely. Legal holds are managed by email from the legal team. A German works council demands deletion of a former employee's data, while the same client's US litigation team has issued a hold related to a employment dispute. The contractual erasure response deadline is 30 days. The client insists that both the deletion and the hold be honored.
1. Design a decision flow for reconciling the erasure request with the litigation hold and retention obligations.
Read the worked answer
Create a single intake and decision record for the request. Steps: verify the requester's identity and authority; identify the controller-client and the applicable role; check for a documented legal hold covering the employee or the relevant records; check whether a retention obligation independently requires preservation; then decide.
If a valid legal hold applies, suspend deletion for the covered records and notify the requester within the 30-day period that deletion is restricted because of legal obligations, without disclosing privileged details. Document the hold reference, scope, and reviewer. If no hold applies, execute deletion under the retention schedule and record the systems and dates. The German works council request does not override a valid US litigation hold, but the provider should confirm the hold's scope with the client's legal team and avoid over-preserving unrelated data.
Fix the email-based hold process. Legal holds should be recorded in a central register with a unique ID, data subject or matter scope, start date, reviewer, and release date. The deletion workflow should query that register automatically. Where the provider acts as a processor, the client decides on the hold, but the provider must document the instruction.
Reasoning: erasure is not absolute. Legal claims and legal obligations can restrict it, but the exception must be documented and narrowly scoped. A manual email process cannot reliably support a 30-day SLA.
2. How should deletion be handled in the immutable backups and the analytics warehouse?
Read the worked answer
For production systems, delete or irreversibly anonymize the record and propagate the deletion through downstream systems. For immutable backups, document the backup rotation period and confirm that deleted data will age out within 90 days. The key control is that backups are not restored into production except for disaster recovery, and if a restore occurs, the deletion list is re-applied before the restored system is used. This is a standard defensible position when deletion from immutable media is technically impossible, provided the retention period is limited and the safeguards are documented.
For the analytics warehouse, determine whether the hashed employee ID is truly anonymized. If the hash can be linked back through a key or by matching other fields, it remains pseudonymized personal data and must be deleted. If the data has been aggregated beyond re-identification, document the test and retain only the aggregate. Otherwise, delete the record or destroy the mapping key and any quasi-identifiers that would allow re-identification.
Record the technical basis for each decision. Do not tell the requester that data is deleted if it remains linkable in the warehouse. If the client is the controller, provide a deletion certification listing systems, methods, and exceptions.
Reasoning: erasure must be effective across the data life cycle. Backups are a limited exception, not a permanent loophole, and hashed identifiers are not automatically anonymous.
3. What metrics and tests would you use to prove that deletion actually works across the client base?
Read the worked answer
Measure the deletion process end to end, not just the number of tickets closed. Useful metrics include: percentage of erasure requests completed within the contractual period; median and maximum days from request to completion; percentage of in-scope systems that return a deletion confirmation; exceptions by reason, such as legal hold or technical failure; and aging of open exceptions.
Run reconciliation tests. After deletion, query production, the warehouse, and a sample of downstream exports for the identifier. Restore a backup into an isolated environment on a scheduled basis and verify that the deletion list is re-applied before use. Sample completed requests each quarter and trace them through the data map. Test the legal hold register by confirming that held records are excluded from deletion and that released holds trigger deletion.
Report results to clients and to internal governance. A high completion rate with no reconciliation evidence is weak; a lower rate with documented exceptions and tested controls is more defensible.
Reasoning: deletion is a technical outcome, not a workflow status. Reconciliations and restore tests are the evidence that the control operates, and exception analysis shows whether the process is being gamed.