Understanding the Choice
When designing your DSAR intake process, you must decide whether to provide a single "access my data" form or separate pathways for category-level and specific-information requests. The California Consumer Privacy Act (CCPA) recognizes six distinct request types. Five involve categories of personal information you collect, disclose, or sell, while the sixth involves the actual data you hold about a person.
Most privacy teams treat these as a single workflow. A 2022 survey by Greenberg Traurig LLP found that 52% of companies allow consumers to "access" their information or submit a "request to know" without differentiating between request types. This approach simplifies your intake form and consumer-facing language. However, it means processing every request as if it were the most expansive type, even when a consumer might want something more specific.
The question isn't whether you can legally combine them. You can. The question is whether you should.
Benefits of Separate Request Forms
Creating distinct intake paths gives you control over scope and effort. A category-level request might only require you to respond with "We collected identifiers" or "We collected your name and email address." A specific-information request requires more detailed responses, such as "We collected the name John Smith and the email address [email protected]." The effort difference depends on your data architecture.
Separate forms allow for triage. When a consumer selects "Tell me what categories of information you collect about me," your team can respond with a templated category list. When they choose "Give me the specific data you hold," you're pulling records from databases, CRM exports, and third-party integrations. You can set different internal SLAs, allocate resources accordingly, and avoid over-delivering on requests that didn't ask for full disclosure.
This approach also protects against ambiguity disputes. If a consumer submits a vague "I want to know what you have on me" and you respond with categories only, they might claim you didn't fulfill the request. If your intake form forces them to choose, you have a record of what they asked for. The CCPA's Final Statement of Reasons acknowledges that a business responding to a category-level request "might be sufficient" by stating it collected "identifiers," or it could be "more specific" by listing name and email. Separate forms make that distinction explicit upfront.
Additionally, you reduce the risk of over-disclosure. Some consumers want to understand your data practices in general. They don't need their Social Security number, transaction history, or device identifiers handed back in plaintext. Offering a category-level option provides transparency without forcing you to package and transmit sensitive data every time.
Advantages of a Unified Request Form
The counterargument is practical: consumers don't read regulatory definitions, and forcing them to choose between "category-level" and "specific-information" creates confusion. Most people submitting a DSAR want proof of what you know about them. If you make them parse legal distinctions, you'll get support tickets, abandoned forms, and complaints that your process is opaque.
A single "access my data" form is consumer-friendly. It shows you're not gatekeeping or making people guess which request type will get them the answer they need. If you're going to pull the full dataset anyway to verify the request and check for third-party disclosures, the incremental cost of returning specific information instead of categories is often negligible.
Operationally, maintaining separate workflows doubles your process documentation, training burden, and QA surface area. Your support team has to explain the difference. Your legal team has to draft separate response templates. Your engineering team has to build conditional logic into your DSAR portal. For many organizations, that overhead outweighs the benefit of occasionally responding with a lighter payload.
If you're already treating every request as specific-information by default, formalizing that in a single form just makes your actual practice transparent. The 52% of companies that don't differentiate aren't necessarily non-compliant. They've chosen to over-deliver rather than under-deliver, which is defensible if your systems can handle it.
Practical Implementation
In practice, most teams start with a unified form and only split the workflow if they see a pattern of low-value, high-volume requests that could be answered with categories alone. If you're a B2C company processing thousands of DSARs a month, the efficiency gain from triaging category-level requests justifies the complexity. If you're processing fifty requests a year, it doesn't.
Some organizations compromise by offering a unified intake form but adding a checkbox: "I only need to know what categories of data you collect" versus "I want the specific data you hold about me." That preserves simplicity while giving you a signal to route the request appropriately. Others route all requests through the full workflow but respond with categories first and offer to provide specific information as a follow-up if the consumer replies asking for more.
The real split happens at the backend. Even if your intake form is unified, your response process probably isn't. You're already distinguishing between "pull from the privacy notice and send a templated response" and "query the data warehouse and export records." The question is whether you surface that distinction to the consumer upfront or handle it invisibly.
Conclusion
Build separate request types if your DSAR volume justifies the operational complexity and your data architecture makes category-level responses cheaper to produce. Don't build them if you're processing every request as specific-information anyway.
The risk of a unified form isn't non-compliance. It's inefficiency and potential over-disclosure. The risk of separate forms is consumer confusion and abandoned requests. Choose the risk you'd rather manage. Whichever path you choose, document it in your privacy notice and train your team to handle edge cases where a consumer's intent doesn't match the form they submitted.
If you're unsure, start unified and revisit after six months of DSAR data. If you're seeing requests that clearly wanted categories but you delivered full exports, or if you're spending hours pulling data for consumers who just wanted to confirm you don't sell their information, that's your signal to split the workflow.
