Data Subject Access Requests (DSARs): A Practical Handling Guide

6 min read

If you have been putting off building a DSAR process, you are in good company. Many organizations approach their first data subject access request without a documented procedure, only to discover how exposed they are. The honest answer is that a repeatable DSAR process is one of the highest-impact investments you can make in your privacy program.

Handling a data subject access request is a bit like receiving a formal inspection notice for your business. The request itself is routine. Whether you’re ready for it or not is entirely a function of the preparation you’ve done before it arrives.

When the Inbox Lights Up: Are You Ready?

The first Data Subject Access Request (DSAR) catches most companies off guard. An email arrives: “I want to see all the personal information you have about me.” Or: “I want you to delete all my data.” Or: “I want my data in a portable format so I can move it to your competitor.”

If your company doesn’t have a documented process for handling these requests, that first one will create chaos. You’ll scramble to figure out where data lives, who needs to be involved, how to pull it together, and whether you can actually respond in time. The deadline for responding to a Data Subject Access Request (DSAR) under General Data Protection Regulation (GDPR) is 30 days (extendable to 3 months). Under California Consumer Privacy Act (CCPA), it’s 45 days (extendable 45 more). Miss the deadline, and you’re in violation.

A repeatable DSAR process is one of the highest-impact things you can build in your privacy program. It’s the moment where your privacy program meets the real world, where you actually have to prove you know what personal information you hold and you can retrieve it on demand.

What a DSAR Is and Who Can Submit One

A Data Subject Access Request (DSAR) is a consumer’s formal request to exercise one of their privacy rights:

• Right to access: “I want to know what personal information you have about me”
• Right to deletion: “Delete all my personal information” (sometimes called “right to be forgotten”)
• Right to correction: “That information about me is inaccurate; please fix it”
• Right to portability: “I want my data in a portable format so I can move it to another service”
• Right to opt-out: “Stop selling/sharing my data” or “Stop processing my data for targeted advertising”

Under GDPR (General Data Protection Regulation), any individual (data subject) whose data you process can submit a DSAR. Under CCPA (California Consumer Privacy Act), any California resident can submit a request. Under state laws like TDPSA (Texas Data Privacy and Security Act), residents of that state have DSAR rights. A DSAR doesn’t have to come via a formal legal notice. It can be an email, a contact form, a social media message, or even a phone call. If a consumer is clearly asking to access, delete, or correct their data, you must treat it as a DSAR and respond within the legal timeline.

The DSAR Timeline You’re Required to Meet

GDPR (EU/EEA): 30 days from receipt of a valid request. This can be extended by 2 additional months (total of 3 months) if the request is complex or if you receive many requests at once. But you must communicate the extension to the requester within 30 days, explaining why you need the extension.

CCPA (California): 45 days from receipt of a verifiable consumer request. Can be extended an additional 45 days if the request is complex. Again, you must communicate the extension to the consumer.

TDPSA (Texas): 45 days from receipt of a consumer request to respond.

Other state laws (Colorado, Virginia, Connecticut, Utah, Montana): 45 days, with a 45-day extension available for complex requests (same timeline structure as CCPA).

Missing the deadline is a violation. Regulators view this as a particularly serious breach because it prevents the consumer from exercising their legal rights. If you’re facing a regulator inquiry and you can produce documentation showing you responded to every DSAR on time, that’s a strong defense. If you’re missing deadlines or have no record of responses, you’re exposed.

Step-by-Step: How to Handle a DSAR

Step 1: Intake, Recognize the Request and Log It

The request might come through email, a web form, chat, social media, or even a phone call. The first step is recognizing it as a DSAR and logging it. Establish a central intake point so requests don’t scatter across different inboxes. Many companies use a dedicated email address (privacy@company.com) or a web form linked from their privacy policy. Your log should record: receipt date, requester name/contact info, type of request (access, deletion, correction, portability), and status.

Step 2: Verify Identity

You must verify the person making the request is actually the individual whose data they’re asking about (or an authorized representative). But the verification must not be “unduly burdensome.” Under GDPR and CCPA guidance, asking for government ID is usually excessive. A combination of information you already have (account email, phone, account number, purchase history) is sufficient. If someone emails from their registered account email asking for their data, that’s adequate verification in most cases. Fraudsters don’t usually know the victim’s registered email.

Don’t overthink this. You need reasonable confirmation that the requester is who they claim to be. If you require documents from everyone, you’ll create backlogs and miss response deadlines.

Step 3: Determine the Scope, What Data Needs to Be Provided?

For an access request, you need to locate and compile all personal information about the individual. This includes:

• Data in your primary systems (CRM, database, user account)
• Data in vendors’ systems (email marketing platforms, analytics tools, payment processors)
• Data in backups or archives (even if deleted from primary systems)
• Data in employee records or notes (if the person is or was an employee/candidate)

The requester is entitled to all personal information you hold about them, including data generated about them (activity logs, inferred preferences, interaction history). This often means querying databases, exporting from third-party platforms, and consolidating data from multiple sources.

For deletion and correction requests, identify which records need to be modified or deleted. For portability requests, compile the data in a structured, commonly used format (CSV, JSON, XML).

Step 4: Perform a Legal Review

Not all data must be provided. General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) allow you to withhold information if:

• It would interfere with other individuals’ rights and freedoms (data about someone else)
• It would harm national security or law enforcement
• It’s legally privileged (attorney-client communications)
• Providing it would harm the requester’s wellbeing (suicide risk, medical intervention, etc., very narrow exception)

Most requests don’t hit these exceptions. But review before responding to catch legitimate grounds for withholding information. For deletion requests, there are broader exceptions: you can refuse deletion if you need to retain data for legal compliance, to complete a contractual obligation, or for legitimate business purposes like fraud detection.

Step 5: Compile and Prepare the Response

Consolidate all the data you’ve located into a response document or file. For access requests, this might be a PDF or a structured export. For portability requests, use a standard format like CSV or JSON. For deletion requests, execute the deletion and provide confirmation. For correction requests, correct the inaccurate information.

The data should be in a clear format. If you’re providing database exports, include a legend explaining what each field means. If there’s jargon or encoded data, explain it.

Step 6: Send the Response to the Requester

Provide the response within the legal timeline (30 days for GDPR, 45 days for CCPA). Deliver it securely. If it contains sensitive personal information, use an encrypted method (password-protected file, secure file transfer, encrypted email) rather than plain email with attachments.

Include a brief cover note explaining what’s included, any limitations (if you withheld information, explain why), and how to contact you if they have questions or want to dispute your response.

Step 7: Document Everything

Maintain a record of: the request, your verification steps, what data you provided/deleted/corrected, the response date, and the method of delivery. Regulators will ask for this during an audit. Your documentation should allow you to prove you responded to every request on time and handled it correctly.

The Most Commonly Mishandled Request Types

We see these mistakes repeatedly:

• Deletion requests: companies delete data but don’t delete from backups, logs, or vendor systems. A complete deletion requires touching multiple systems.
• Portability requests: data compiled in a non-portable format (PDF instead of structured data like CSV). Portability specifically requires a “commonly used, machine-readable format.”
• Requests from minors: under GDPR, children have DSAR rights. Some companies wrongly assume only parents can make requests. A child (depending on age and maturity, typically 13+) can request their own data.
• Authorized representative requests: someone requests data on behalf of another individual (power of attorney, legal representative). Verify the authorization relationship, not just the identity of the requester.
• Overly broad verification: requiring documents like government ID or passport. This blocks legitimate requests. Use data you already have.
• No communication about extensions: if you need more time, notify the requester within the first response window and explain why.

Documenting and Logging DSARs (Non-Negotiable)

You must maintain a register of all DSARs. At minimum, log:

• Date received
• Type of request (access, deletion, correction, portability, opt-out)
• Requester identity (or method used to verify)
• Scope (which data/systems involved)
• Date response sent
• Any extensions granted (and notice given)
• Any grounds for withholding information
• Whether request was honored or denied

This log is your audit trail. Regulators reviewing your privacy program will ask to see it. A company with no DSAR log is a liability: you have no proof you’re responding to requests at all.

When to Use Technology vs. When to Handle Manually

For very small companies with simple databases, manual DSAR handling might be feasible. For anyone beyond that, a DSAR management platform is invaluable. Tools like OneTrust, TrustArc, and DataGrail automate data discovery, vendor coordination, and response compilation. They also maintain audit logs automatically.

At a minimum, use a ticketing system or spreadsheet to track requests so they don’t fall through the cracks. But for data location and compilation, especially if you have many systems or vendors, a purpose-built tool saves time and reduces errors.

Building a Repeatable DSAR Process

A robust DSAR process includes:

• Defined intake point: email, form, or both where requests are received and logged
• Defined ownership: which team member owns the DSAR process and is accountable for timelines
• Data map: a documented inventory of where personal data lives (databases, third-party platforms, backups)
• Vendor list with access points: third-party processors and how to request data from them
• Verification procedure: documented identity verification process (what information is sufficient)
• Response template: standardized cover letter, data format, and delivery method
• Log/registry: spreadsheet or tool tracking all requests and their status
• Escalation procedure: if a request is complex or you’re near deadline, who escalates and to whom
• Quarterly review: audit your DSAR handling to catch gaps or missed deadlines

The first time you handle a DSAR, it’s chaos. By the fifth, it should be a routine process. By the 100th, it should be automated or delegated to a competent team member following a documented checklist.

Next Steps

A DSAR that’s handled late or incorrectly is a regulator’s entry point to audit your entire privacy program. It’s the moment where regulators start asking: “If you can’t handle consumer requests correctly, what else are you doing wrong?” Build a defensible process now, before your first DSAR arrives or before a regulator asks to see your DSAR log.