Obtainer
Blog / Guides 10 min read

DSAR Exemptions: When You Can Withhold or Refuse Data

Last updated July 2026 · Obtainer

Request Studio
Requester
Compiled the manifest and drafted the response - illustrative sample request
0
records found
0
systems scanned
Data manifest
Response draft

Assembling the cover letter from the template...

You approve what is disclosed before anything ships

Helps you comply, not legal advice

DSAR exemptions are the limited circumstances in which you can withhold data, redact part of a response, or refuse a request entirely. The right of access is broad but not absolute: you must protect other people's personal data, you may withhold material that is legally privileged or covered by a specific exemption, and you can refuse or charge for a request only where it is manifestly unfounded or excessive. Every time you rely on an exemption, you should document the reason.

This is general information, not legal advice. Exemptions are fact-specific and vary by jurisdiction, so check the law that applies and take advice on borderline cases.

The two ways to limit a response

Exemptions work in two ways. Most of the time you still respond, but you redact or withhold certain material within it. Occasionally you may refuse the request as a whole. Refusal is the rare exception; partial withholding is the common case.

TypeWhat it meansHow common
Redact third-party dataRemove data about other peopleVery common
Withhold exempt materialHold back privileged or exempt contentOccasional
Refuse the requestDecline a manifestly unfounded or excessive requestRare

Third-party data: the most common exemption

An access request covers the requester's own personal data, not other people's. When a record about the requester also contains someone else's data, you generally redact the third party unless disclosure is reasonable, for example where they have consented or their identity is already known and disclosure causes no harm. This is the exemption you will apply most often, and it is covered in depth in the guide on how to redact a DSAR response. A dedicated redaction step keeps it consistent.

Legally privileged and exempt material

Some material can be withheld rather than redacted piecemeal. Common examples include:

  • Legal professional privilege. Confidential legal advice is generally exempt from disclosure.
  • Data under legal hold. Material preserved for litigation may be subject to separate rules; withholding it from a routine response can be appropriate, but coordinate with legal. The rules differ by regime and the scope is narrower than most teams apply it, which the guide to a litigation hold versus a deletion request works through.
  • Management and negotiation information. Certain internal planning or negotiation data may be exempt depending on the jurisdiction.
  • Data that would prejudice specific functions. Some laws exempt data where disclosure would harm functions such as crime prevention or regulatory activity.

Because these depend on the specific legal framework, treat the list as a prompt to check, not a definitive rule. Flag candidates during manifest review rather than at the last minute, which is easier when discovery has produced a clear list to work from through personal data discovery.

Refusing a request: manifestly unfounded or excessive

You can refuse a request, or charge a reasonable fee, only where it is manifestly unfounded or excessive. This is a high bar, not a convenience.

Manifestly unfounded

A request might be manifestly unfounded where the person clearly has no genuine intention to exercise the access right, for example where the request is made purely to harass or is explicitly used as a bargaining chip. The volume of data or the effort involved does not, on its own, make a request unfounded.

Excessive

A request may be excessive where it repeats a request you have already satisfied within a short period, or is part of a pattern of clearly repetitive requests. Again, a large amount of data is not the same as an excessive request. If in doubt, respond rather than refuse.

Document every exemption you use

Whenever you redact, withhold, or refuse, keep a record of what you did and the basis for it, without exposing the withheld content itself. That record is your evidence that the response was handled properly if the requester challenges it or a regulator asks. Documenting exemptions is part of a disciplined DSAR process, and it protects you far more than an undocumented judgment call.

The safeguard: human judgment

Exemptions are judgment calls. Whether a third party's data can be disclosed, whether material is genuinely privileged, or whether a request crosses the line into excessive all depend on context that only a person can weigh. Automation can surface candidates and flag likely exemptions, but the decision should sit with a reviewer. A human review gate is what keeps you in control and prevents both over-withholding and accidental disclosure. The same discipline applies whether you are meeting GDPR or CCPA obligations.

Exemptions under the CCPA

The framing above leans on GDPR concepts, but similar limits exist under the CCPA. A business does not have to disclose certain information where doing so would create a security risk, and there are constraints around specific pieces of sensitive personal information such as government identifiers and financial account numbers. The CCPA also does not require a business to retain data it would not otherwise keep just to answer a request, or to re-identify data that is not linked to a particular consumer. As with the GDPR, these are limits applied case by case, not blanket reasons to disclose less, and the safe default remains disclosing the requester's own data while protecting others.

What are the valid exemptions for a DSAR?

Valid DSAR exemptions fall into four groups: other people's personal data that cannot be separated from the response, legally privileged material, specific sensitive identifiers that the law bars you from disclosing, and requests that are manifestly unfounded or excessive. Everything else in the file is disclosable. Anything that feels inconvenient, embarrassing or commercially awkward is not an exemption on its own.

The distinction that matters in practice is between withholding a document and redacting part of one. Exemptions almost always operate at the level of the specific content that is exempt, not the whole record it sits inside. An email thread that contains one privileged paragraph is not a privileged email thread. Withholding the entire thread when only two sentences are exempt is over-withholding, and it is the more common failure in careful organizations, in the same way that under-redacting is the more common failure in rushed ones.

Is it illegal to withhold data on a DSAR request?

Withholding data without a lawful basis is a breach of the access right, not a criminal offense in the United States, but it is enforceable. Under the CCPA the California Privacy Protection Agency and the Attorney General can bring administrative and civil enforcement, and the person can complain to the regulator. Under the GDPR a refusal that does not fit a recognized exemption is an infringement of Article 15. Withholding on a genuine exemption, documented at the time, is lawful and expected.

Two behaviors do move closer to a real legal problem. The first is destroying or altering records after a request arrives in order to avoid producing them. The second is telling a person you hold nothing when you do. Both convert a scoping dispute into a credibility problem, which is the version regulators treat seriously.

The practical protection is the paper trail. If you withhold something, write down what you withheld, which exemption you relied on, and who approved it, without reproducing the withheld content in the note. A withholding decision you can explain a year later is defensible. One nobody wrote down usually is not, even when it was correct at the time.

When can data be withheld during a DSAR request if commercially sensitive?

Commercial sensitivity on its own is not an exemption. What is protected is a genuine trade secret, and the bar for that is higher than most teams assume. Under California law trade secrets are completely protected from disclosure, but a business withholding information on that basis has to be able to show the information has independent economic value precisely because it is not generally known, and that the business used reasonable efforts to keep it secret.

This matters most for the records businesses least want to produce: scores, segments, propensity models and enrichment outputs. The California Attorney General's Opinion No. 20-303, issued March 10, 2022, concluded that internally generated inferences a business holds about a consumer are personal information that must be disclosed in response to a right to know request, and that this holds even where the underlying data was exempt from the CCPA when it was collected. So an inference is disclosable by default, and the trade secret argument is the exception you have to prove, not the starting position.

The usual middle path is disclosing the output while protecting the method. Telling a person their account carries a high churn-risk score discloses the personal data. Publishing the model's features and weights is what the trade secret protection is for. If your team is going to rely on this exemption, decide before request season which specific artifacts you consider trade secrets and write down why, because doing that analysis under a 45-day clock is where the argument falls apart.

What documents can be withheld during a DSAR?

Under the CCPA, the regulations name the categories outright. California's regulations at 11 CCR 7024(d) state that a business shall not disclose a consumer's Social Security number, driver's license number or other government-issued identification number, financial account number, any health insurance or medical identification number, an account password, security questions and answers, or unique biometric data generated from measurements or technical analysis of human characteristics.

Note the direction of that rule. It is not a permission to withhold, it is a prohibition on disclosing, and it exists because a right-to-know response is a package of identity documents waiting to be intercepted. The regulation still requires you to tell the person, with sufficient particularity, that you collected that type of information. The worked example in the regulation is a business responding that it collects unique biometric data including a fingerprint scan without disclosing the actual scan.

Two more limits sit in the same regulation and are worth knowing. If you cannot verify the requester's identity, 7024(a) says you must not disclose any specific pieces of personal information and must tell them you could not verify them, which is why identity verification comes before collection rather than after. And 7024(h) sets the lookback: all personal information collected and maintained during the 12 months preceding the request, with consumers able to request information collected on or after January 1, 2022, unless doing so would be impossible or would involve disproportionate effort.

Beyond those, the categories that are commonly withheld or redacted are the same across regimes: material covered by legal privilege, information that would reveal another identifiable person, records subject to a litigation hold or an active investigation where disclosure would prejudice it, and genuine trade secrets. Everything else in scope goes in the response.

What is the DSAR third party data exemption?

The third party data exemption lets you withhold or redact information that identifies another living person when you cannot reasonably disclose it without revealing them, and they have not consented. It is the exemption you will use most often, because almost no record about one person is only about that person. It is also the one most often applied too broadly.

The test is not whether another name appears. It is whether the other person is identifiable in the response and whether disclosing that detail is reasonable in the circumstances. Employees acting in a professional capacity are usually a different case from a private individual: a support agent's name on a ticket they handled is normally disclosable, while a third-party customer's contact details in the same thread are not. Company names generally are not personal data at all, though a sole trader's business name can be, so a blanket rule that all company names get redacted removes context the requester is entitled to.

Work through it in the order the law does. Can you satisfy the request by redacting the identifying detail rather than withholding the record? If yes, redact and disclose the rest. If not, can you get the other person's consent? If not, weigh the requester's right against the other person's expectations and any duty of confidentiality you owe them, and record the outcome. That sequence is what redacting third-party data in a DSAR response covers in detail, with worked examples of what a redacted thread should look like before it ships.

When in doubt, disclose

The default position under access rights is disclosure. Exemptions are genuine, but they are limits on a right, not loopholes to shrink your obligations. If you are unsure whether something is exempt, the safer course is usually to disclose the requester's own data and redact only what clearly belongs to others, while taking advice on anything genuinely uncertain.

Want exemptions flagged during review instead of missed under deadline pressure? Obtainer compiles a manifest, surfaces likely third-party and exempt material, and holds everything at an approval gate. DSAR automation keeps a person in control of every withholding decision before the response is disclosed.

Run a data subject access request end to end

Obtainer finds where a person's data lives across your systems, compiles it into one manifest, drafts the deadline-safe response, and tracks the GDPR and CCPA clock. You review, redact, and approve what gets disclosed. Helps you comply; not legal advice.