Data Subject Access Request Process: A GDPR and CCPA Compliance Workflow

Overview

A DSAR is a request from an individual to learn about, access, or in some cases receive a copy of personal information held by an organization. Depending on the applicable law and the person’s relationship with your organization, the request may also involve correction, deletion, portability, restriction, or information about how data is used.

The exact rights, response periods, verification standards, exemptions, and fee rules depend on the law that applies. Treat GDPR and CCPA/CPRA requirements as separate legal workstreams rather than assuming that one procedure satisfies every jurisdiction. Your privacy or legal team should confirm the applicable requirements for each request, especially when the request involves employees, children, sensitive information, regulated records, or multiple jurisdictions.

The operational goal is straightforward: receive the request, establish what the requester is asking for, verify identity proportionately, find relevant data, review what can be disclosed, respond within the applicable period, and retain evidence of each decision. A documented process is also useful for your broader GDPR compliance checklist and privacy compliance workflow.

Checklist by scenario

1. A new access request arrives

• Record the date, channel, requester, contact details, jurisdiction indicators, and the exact wording of the request.
• Accept requests through more than one reasonable channel, while directing them into a controlled case-management system.
• Classify the request: access, correction, deletion, portability, objection, restriction, or a combination.
• Send an acknowledgment that explains the next step, any information needed for verification, and how the requester can contact the privacy team.
• Start a deadline tracker using the applicable law and document any permitted extension or clarification period.

Do not reject a request simply because it was sent to customer support, an employee, or another department. Staff should know how to recognize privacy requests and route them without unnecessary delay.

2. Identity needs to be verified

• Use information already held by the organization to select a proportionate verification method.
• Request only the minimum additional information needed to reduce the risk of disclosure to the wrong person.
• Never ask a requester to send unnecessary identity documents through an insecure channel.
• Record what was requested, why it was needed, when it was received, and who approved verification.
• Apply a separate process for an authorized agent, parent or guardian, employee, former customer, or other representative.

Verification is a security control, not a reason to create excessive friction. If the information supplied is insufficient, explain what is missing and pause the substantive search only as permitted by the applicable requirements.

3. The request covers several systems

• Use your records of processing activities, application inventory, data map, and retention schedule to build a search plan.
• Check identity systems, customer databases, support tools, product logs, billing platforms, marketing systems, collaboration tools, and relevant backups.
• Search using known identifiers such as name, email address, account ID, customer number, device identifier, or other approved key.
• Ask system owners to state which sources were searched, the search date, search terms, and any technical limitations.
• Separate personal data from internal notes, privileged material, security information, and information about other individuals.

For SaaS teams, a maintained system inventory is often more valuable than a one-time spreadsheet created after a request arrives. Keep ownership and search instructions current as tools change.

4. A processor or vendor holds relevant data

• Identify processors and service providers that may store, access, or generate information connected to the requester.
• Check the contract and data processing agreement for cooperation duties, response contacts, security controls, deletion terms, and subprocessors.
• Send a focused data request with the case ID, identifiers, systems in scope, deadline, and secure transfer method.
• Record the vendor’s response and escalate delays through the contract owner and privacy lead.
• Validate that the returned material relates to the requester and does not include unrelated customers’ information.

A vendor review is easier when processor contacts, system descriptions, and contract obligations are maintained before a DSAR occurs. See the vendor risk assessment workflow for a related approach to documenting supplier responsibilities.

5. The response contains restricted or third-party information

• Have an authorized reviewer assess redactions, exemptions, confidentiality concerns, privilege, security risks, and information about other people.
• Redact rather than withhold an entire document when a partial disclosure is appropriate.
• Document the legal or operational reason for each material withholding or redaction.
• Check whether the response includes credentials, access tokens, fraud-detection logic, trade secrets, or security details that require careful handling.
• Prepare a clear explanation of any limitation, subject to the applicable law and advice from counsel.

6. The response is ready to send

• Confirm the requester’s identity and the scope of the completed search.
• Use a secure delivery method and protect files with appropriate access controls.
• Include the relevant personal data and the required contextual information, such as purposes, categories, recipients, retention information, or data sources where applicable.
• Explain any unresolved items, exclusions, redactions, or next steps in plain language.
• Record the final response, delivery date, reviewer, evidence package, and closure decision.

What to double-check

Before closing a case, run a short quality review:

• Deadline: Has the team calculated the response period under the correct law, business context, and request type?
• Scope: Did the requester ask for more than access, and has each right been handled separately?
• Completeness: Were archived systems, support records, marketing platforms, and relevant vendors considered?
• Accuracy: Are the disclosed records associated with the correct person and current case?
• Confidentiality: Were other individuals’ data and privileged or security-sensitive material reviewed?
• Security: Was the response delivered through a controlled channel, with access limited to the requester?
• Evidence: Could an independent reviewer understand what was searched, who decided, and why information was withheld?

Maintain a DSAR register with at least the case ID, intake date, request type, applicable jurisdiction, verification status, deadline, systems searched, vendor dependencies, outcome, and closure date. Limit access to the register because it can itself contain personal information.

Common mistakes

• Relying on one database: Customer data may also exist in support tickets, invoices, product telemetry, or communications.
• Using a fixed verification script: The appropriate check depends on the account, risk, request channel, and information held.
• Starting the search before defining scope: Unfocused exports create noise, increase exposure, and make review harder.
• Ignoring processors: A contract does not remove the need for an operational contact and a tested retrieval process.
• Over-redacting: Removing entire files without documenting the reason can make the response difficult to defend.
• Under-documenting decisions: A response email alone is not evidence of a complete and repeatable process.
• Mixing retention and deletion: A deletion request may require a separate assessment of legal, contractual, security, or operational retention duties.
• Using stale contact lists: Departed system owners and changed vendors can create avoidable delays.

When to revisit

Review the DSAR process before seasonal planning cycles, after a material change in privacy law, and whenever your business enters a new jurisdiction or customer segment. Revisit it when you add or replace identity, analytics, CRM, support, billing, hosting, or marketing tools. A new acquisition, product launch, data migration, security incident, or major retention-policy change should also trigger a review.

At least periodically, run a tabletop request using a test account. Confirm that staff can recognize a request, the deadline tracker works, system owners know how to search, processors respond through current contacts, and the final package can be reviewed securely. Compare the results with your data retention policy and update the system inventory, templates, escalation paths, and training materials.

Keep the workflow practical: one accountable privacy owner, named system contacts, a controlled case register, approved response templates, and a documented review step. That combination gives technology and privacy teams a maintainable DSAR process without treating every request as an improvised investigation.