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 refusal is lawful under GDPR
Under GDPR, a company can refuse erasure when the request conflicts with another lawful basis for keeping the data. That usually means the record still has a live business purpose, is needed for legal claims or compliance, or falls within a public-interest or expression exception. The key question is not whether the requester wants deletion, but whether deletion is legally required.
The practical test is whether the data must remain available in its current form. If the information is still needed to complete a transaction, defend or pursue a claim, preserve a record for public-interest reasons, or support freedom of expression or information, the company may keep it. If none of those conditions apply, erasure should normally be granted.
For identity and request handling teams, the refusal decision should be tied to the record category, retention rule, and legal context rather than a generic preference to retain data. NHIMG’s Identity Data Privacy and Consent Guide is useful here because it covers lawful handling, retention, special category data, and data subject rights in a way that maps directly to deletion decisions.
Which exemptions matter most in practice?
The most common refusal scenarios are operational rather than exceptional. A company may need to retain data for contract completion, invoicing, dispute handling, audit evidence, or statutory retention. It may also need to keep data that has been published, is already part of a legal proceeding, or contributes to records with scientific, historical, or public-health value. Those categories are narrower than they sound, so the organisation should be able to explain the exact purpose.
Another important boundary is publication and public interest. If the data is already public in a way that makes erasure ineffective or legally disproportionate, the company may have grounds to refuse. Similarly, where erasure would undermine freedom of expression or freedom of information, the right to erasure is limited by the competing interest. That balancing exercise should be documented, not assumed.
Because the decision depends on legal context, a useful control is to tie each refusal to a named legal basis and a specific record set. NHIMG’s DSAR Guide: Handling Data Subject Requests helps practitioners operationalise exemptions, evidence gathering, and response decisions without turning every request into an ad hoc judgment call.
How to decide whether to erase or refuse
The cleanest way to handle these requests is to separate three questions: whether the data is personal data, whether erasure is legally available, and whether any exception overrides the request. If the record is no longer needed for its original purpose and no exemption applies, deletion should proceed. If a retention obligation or protected interest remains, the company should refuse only that part of the request, not the whole request by default.
This is also where records discipline matters. If the company cannot show why the data must remain, the refusal will be hard to defend. Data mapping, retention schedules, and request logs should make it obvious which systems hold the data, why it is retained, and when the retention basis ends. A refusal without that evidence is usually a process failure, even if the final legal answer is correct.
When the request touches broader privacy governance, Data Mapping and ROPA Guide is a useful companion because it shows how to connect processing inventories, retention schedules, and rights handling to the actual systems that store the data.
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 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.17 — Right to Erasure ('Right to be Forgotten') | Directly governs when deletion can be refused under lawful exceptions. |
| Art.5 — Principles Relating to Processing of Personal Data | Purpose limitation and storage limitation shape whether retention can still be justified. | |
| Art.30 — Records of Processing Activities | ROPA supports proving why data is held and which systems/processes are involved. | |
| Recommendation — Apply Article 17 exceptions narrowly and document the specific legal basis for any refusal. Limit retention to the stated purpose and delete data once that purpose ends. Maintain accurate processing records so erasure decisions can be traced to a lawful retention basis. | ||
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Retaining evidence for disputes or compliance depends on controlled log and record retention. |
| Recommendation — Define retention periods for audit evidence and delete records when the legal need expires. | ||
Practitioner Guidance
What to verify: Check the data set, the purpose of processing, the retention rule, and whether a narrower deletion, redaction, or restriction option exists. A refusal should be based on the smallest defensible retained scope, not on keeping the entire record because one part is still needed.
Decision rule: If the only reason to keep the data is convenience or internal preference, approve erasure. If the company can point to an active legal, contractual, public-interest, or expression-based basis, refuse only to the extent that basis truly applies.
Practitioner takeaway: A good GDPR erasure decision is evidence-led and proportionate, the organisation should be able to show exactly why each retained record still needs to exist.
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
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org