A request can be refused when the data is tied to an ongoing transaction, is already public knowledge, forms part of legal proceedings, or serves a public interest such as scientific, historical, or public health records. Organisations may also refuse where erasure would compromise freedom of expression or freedom of information. The decision depends on the data’s purpose and legal context.
When GDPR Erasure Can Be Refused
Under GDPR, refusal is not a blanket exception, it is tied to the legal basis and purpose of the data. The strongest refusals arise when deletion would undermine a legal obligation, a public-interest function, a defence or claim in proceedings, or another protected right that the regulation preserves. The key question is whether erasure would conflict with a recognised GDPR exception or override another lawful interest.
Where that tension exists, the controller should be able to explain why the specific record cannot be deleted now, rather than issuing a generic refusal. For a fuller privacy-law treatment of data subject rights and retention decisions, see Identity Data Privacy and Consent Guide.
Which GDPR exceptions most often justify refusal?
The common refusal cases are practical, not theoretical. If the personal data is still needed for an active transaction, for compliance with legal claims, or for records that support scientific, historical, or public health purposes, erasure can be declined where GDPR permits retention. Refusal can also be justified when deletion would interfere with freedom of expression or freedom of information, because those interests are explicitly protected.
In practice, the controller should test the request against the specific purpose of each dataset, not the dataset as a whole. A public-facing record, a litigation file, and a transactional record may have different answers even if they contain overlapping personal data. For guidance on how these decisions sit inside broader privacy and compliance obligations, the Identity Security Regulatory Map is a useful reference.
When the record is linked to an ongoing dispute, complaint, audit trail, or regulatory hold, refusal is usually stronger because deletion would impair the organisation’s ability to demonstrate what happened. That is also why teams should treat retention rules and deletion rules as connected controls rather than separate workflows.
How should organisations decide whether to delete or retain?
The decision should follow purpose, necessity, and legal context. First, confirm whether the data is still needed for the reason it was collected. Next, check whether a GDPR exception applies, such as legal defence, public interest, or protected expression. If neither applies, erasure should normally proceed without unnecessary delay.
Good decisions rely on documented retention logic, clear ownership, and an auditable record of why the request was granted or refused. Where the data is especially sensitive or subject to consent and lawful-processing questions, teams should align the erasure workflow with privacy governance rather than leaving it to ad hoc case handling. The EU General Data Protection Regulation (GDPR) is the primary legal reference for those exceptions, and the NIST Privacy Framework can help teams structure the governance and retention decision process.
Risk and Threat Considerations
Refusing erasure without a valid legal or public-interest basis creates privacy, compliance, and trust exposure. Over-refusal can also become a records-management problem, because teams may end up retaining personal data longer than necessary and lose visibility into why it is still held.
Failure mechanism: Controllers either over-apply a narrow exception or fail to document the legal reason for retention, so the organisation cannot show that the refusal was proportionate and lawful.
Impact: The result can be unlawful retention, failed subject-rights handling, complaint escalation, regulatory scrutiny, and avoidable disputes about whether the personal data should have been deleted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 17 — Right to Erasure | Defines when erasure can be refused under GDPR exceptions. |
| Art. 5 — Principles Relating to Processing of Personal Data | Purpose limitation and storage limitation govern whether continued retention remains lawful. | |
| Art. 89 — Safeguards and Derogations for Scientific, Historical and Statistical Purposes | Supports refusal where deletion would undermine recognised research or archival purposes. | |
| Recommendation — Assess each erasure request against Article 17 exceptions before approving deletion. Apply purpose and storage limitation tests to justify any retained personal data. Use Art. 89 safeguards to retain data needed for compatible scientific or historical processing. | ||
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Retention and deletion decisions often depend on preserving records for legal or investigative needs. |
| Recommendation — Set retention rules that preserve records needed for legal and audit purposes. | ||
| ISO/IEC 27001:2022 | A.5.33 — Protection of Records | Records protection and retention support lawful refusal where deletion would impair required records. |
| Recommendation — Define record-retention controls that support lawful preservation and controlled disposal. | ||
Practitioner Guidance
What to verify: Before refusing, verify the exact dataset, its retention purpose, and the specific GDPR exception being relied on. A valid refusal for one record type does not automatically justify keeping every related record.
Decision rule: If the data is needed for a live legal, public-interest, or expression-related purpose, keep only the minimum necessary scope and record the justification; if not, delete it rather than defaulting to retention.
Practitioner takeaway: The defensible position is not “we can keep it because it may be useful later,” but “we can show why this particular record still falls within a protected exception today.”
Related resources from NHI Mgmt Group
- How should security teams control personal data sharing with third parties under GDPR?
- Who is accountable when a processor mishandles personal data under GDPR?
- How should organisations assess whether pseudonymized data is still personal data under GDPR?
- Why do organisations struggle to keep personal data limited to what is necessary under GDPR?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
