Organisations should treat deletion requests as a rights check, not an automatic purge. If the data is no longer needed, was collected unlawfully, or consent has been withdrawn, deletion may be required. If legal obligations, public interest duties, or legal claims justify retention, they can refuse, but they should explain the basis clearly and without undue delay.
When a deletion request meets a lawful retention duty
The key issue is that deletion rights are not absolute. An organisation should first identify whether the requested data is still needed for a lawful purpose, such as compliance with a legal obligation, defence of legal claims, or another retention basis that overrides deletion for that specific data set. The decision should be data-specific, not a blanket refusal.
That means the organisation should separate data that can be erased from data that must be retained, and it should avoid keeping more than the stated purpose requires. If only a subset is needed, the rest should be deleted or anonymised where appropriate.
How to handle the request operationally
A practical process starts with locating the data, checking whether the requester is entitled to deletion, and then testing each record or system against the applicable retention basis. If retention is justified, the organisation should document the reason, limit access to the retained copy, and set a review point so the data is not kept indefinitely by default.
Response timing matters too. Even when deletion is refused in whole or in part, the organisation should answer clearly and without undue delay. The response should explain what was deleted, what was retained, and the specific basis for retention in language the requester can understand.
How to reduce risk when retention is necessary
When data must be retained, the safest approach is minimisation with controls. Retained material should be isolated from routine use where possible, protected by access controls, and used only for the purpose that justified retention. If the legal need ends later, the organisation should delete the data promptly rather than wait for another request.
Operational teams should also be careful about copies. Backups, logs, exports, and downstream replicas often outlive the main system and can become the place where “deleted” data still persists. If those copies are in scope, the deletion decision needs to account for them, or at least define when they are removed through normal retention cycles.
Risk and Threat Considerations
Retention decisions can become a privacy and exposure problem when organisations keep more personal data than they can justify, or when they fail to segregate retained records from data that should have been deleted. The main risk is not just non-compliance, but unnecessary exposure if retained data is later accessed, disclosed, or reused outside the original purpose.
Failure mechanism: organisations either overretain data because they treat every request as a binary delete-or-keep decision, or they retain the data but lose track of where copies exist across systems, backups, and exports.
Impact: the requester may receive an incomplete or delayed response, the organisation may breach retention limits or rights obligations, and retained personal data may remain exposed to unnecessary internal or external misuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 17 — Right to Erasure | Directly governs deletion requests and retention exceptions for personal data. |
| Art. 5 — Principles relating to processing of personal data | Requires data minimisation and storage limitation when retaining data after a deletion request. | |
| Art. 12 — Transparent information, communication and modalities for the exercise of the rights of the data subject | Supports clear, timely explanations when a deletion request is granted only in part or refused. | |
| Recommendation — Assess each erasure request against Article 17 exceptions and delete data that no longer has a lawful retention basis. Limit retained personal data to what is necessary and keep it no longer than the stated purpose requires. Respond without undue delay and explain the retention basis in clear terms. | ||
Practitioner Guidance
What to prioritise: decide first whether the data element is actually needed for the asserted legal or operational purpose. If only part of the record is needed, delete the rest rather than preserving the whole file by convenience.
What to verify: confirm that the retention basis is specific, current, and documented, and that the retained copy is the minimum necessary version. If the data sits in logs, backups, or analytics stores, verify those locations separately instead of assuming the primary system controls the whole lifecycle.
Decision rule: if retention is justified, limit the purpose, restrict access, and schedule deletion once that purpose ends. If you cannot explain the retention basis in one clear sentence, the decision is probably too weak to defend.
Practitioner takeaway: handle deletion requests as a scoped rights assessment, not a reflexive purge or blanket refusal, and make sure any retained data is demonstrably necessary, controlled, and time-bound.
Related resources from NHI Mgmt Group
- How should organisations handle large-scale deletion requests across multiple data brokers and systems?
- Why does personal data create legal and operational risk when organisations do not know where it is?
- How should organisations adapt their privacy programme to the revised FADP when they handle Swiss personal data?
- Why does outdated software increase legal and operational risk for organisations that handle regulated data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
