DSAR vs Deletion Request: What Is the Difference and How to Handle Each

A deletion request is a type of data subject request, not something separate from a DSAR. A data subject access request asks you to show a person the data you hold about them. A deletion request asks you to erase it. Both start with the same intake and identity check, both run on the same statutory clock, which is 45 days in 18 of the 20 states with a comprehensive law, and both can arrive in the same email. Where they split is what you do next: access ends in a compiled, redacted copy going out; deletion ends in records being removed and the removal proven. The exemptions that let you refuse also differ, which is why teams that treat them as one button get tripped up.

DSAR vs deletion request: the core difference

The confusion is mostly about the word DSAR. In common use "DSAR" means the right of access specifically, the request to see one's data. But "data subject request" (also DSR) is the umbrella term for every right a person can exercise: access, deletion, correction, portability, and opt-out. A deletion request is one of those rights. So the accurate way to say it is that a deletion request and an access request are two different data subject requests, and a lot of people use "DSAR" loosely to mean the access one.

Is a deletion request a DSAR?

Loosely yes, precisely no. A deletion request is a data subject request, and if you use DSAR to mean any data subject request, then a deletion request is a DSAR. If you use DSAR in its narrow, common sense of an access request, then a deletion request is a different request that happens to travel through the same intake. Either way the practical point stands: your request workflow has to recognize which right the person is exercising, because access and deletion end in opposite places.

Where the two workflows diverge

Verification is stricter for deletion

An access request that reaches the wrong person leaks data. A deletion request that reaches the wrong person destroys data, and you cannot undo it. Most privacy teams set a higher identity-verification bar for deletion and for any request touching sensitive fields. California's regulations explicitly allow a more stringent standard for deletion of sensitive information. Verify to a level that matches the harm of getting it wrong, and getting a deletion wrong is worse.

Discovery is the same problem for both

Whether you are copying a person's data or erasing it, you first have to find every place it lives: the production database, the warehouse or BI copy, the CRM, the support ticketing tool, the email and SMS platforms, the billing system, backups, and every vendor that received an export. This is where both request types actually get expensive, because the data is scattered and no single system knows about the others. A deletion that fixes the source of truth but misses the warehouse copy is not a completed deletion, and the next sync can even re-create the record. Being able to trace where a data element flows across your systems turns that scatter into a checklist instead of a guess. Our data discovery page covers how the same inventory serves both access and deletion.

The exemptions point in different directions

For access, you refuse or redact to protect other people, privileged material, or trade secrets. For deletion, you refuse to keep data you are legally required to retain: tax and accounting records, data needed to complete a transaction the person requested, information required for legal claims, security and fraud prevention, and, under GDPR, freedom of expression. The classic mistake is deleting a record that a retention law required you to keep. Before you erase, check the retention obligations, then delete only what is not held back by one, and tell the person what you kept and why.

Deletion has to propagate; access does not

An access request ends when the copy is delivered. A deletion request only ends when every downstream system and vendor has removed the data too. Under GDPR Article 17(2) you also have to take reasonable steps to tell other controllers who received the data that the person asked for erasure. Under CCPA you must direct your service providers and contractors to delete. That downstream leg has no equivalent in an access request, and it is the step most often skipped.

Running one workflow for both

You do not need two systems. You need one intake that captures which right the person is exercising, verifies them to a bar set by that right, discovers every copy of their data once, and then branches: compile and redact for access, or check retention and erase for deletion. A deletion request and an access request for the same person can even be worked from the same manifest, since the hard part, finding the data, is identical. Obtainer runs that shared workflow: intake, verification, discovery across your systems, a reviewable manifest, a drafted deadline-safe response, and a 45-day clock, with a human approving before anything is disclosed or erased. The deletion request feature and the access request software are two faces of the same tool, and the data subject rights hub ties the full set together.

Frequently asked questions

Is a deletion request the same as a DSAR?

Not exactly. DSAR usually means a data subject access request, which is the right to see and receive a copy of your data. A deletion request is a different right, the right to have that data erased. Both are data subject requests and share the same intake, identity verification, and 45-day statutory clock, but access ends in a disclosure package while deletion ends in records being removed and the removal proven. Many people use DSAR loosely to cover both.

What is the difference between an access request and a deletion request?

An access request asks you to show a person the personal data you hold about them and give them a copy. A deletion request asks you to erase that data. Access is reversible and low-risk to over-fulfill; deletion is permanent and carries the risk of destroying data you were legally required to keep. Access exemptions protect other people and privileged material; deletion exemptions protect legally required retention, active transactions, and fraud prevention.

Do access and deletion requests have the same deadline?

Yes. Every comprehensive US state privacy law gives you 45 days from receipt for both access and deletion, extendable once by another 45 days with notice, except Florida, which allows only a 15-day extension, and Iowa, which uses 90 days for the rights it grants. Under GDPR both run on one month from receipt, extendable by two more months for complex or numerous requests. The clock starts on receipt, not on the day verification finishes.

Can I refuse a deletion request?

Sometimes. You can decline to delete data you are legally required to keep, such as tax and accounting records, data needed to complete a transaction the consumer requested, information you need for a legal claim, and data used for security or fraud prevention. Under GDPR, freedom of expression and public-interest grounds also apply. You cannot refuse silently: tell the person what you deleted, what you kept, and the specific reason you kept it.