DSAR: What are data subject access requests?

DSAR: At a glance

• DSAR or data subject access requests are when someone asks a company for a record of the personal data that's been collected about them.
• A byproduct of modern privacy laws like GDPR and CCPA, DSAR are a subset of data subject requests, which include requests for deletion, correction, or transfer. 
• Skip to the end for a step-by-step guide for responding to DSAR.  

Table of contents

• Data Subject Access Request definition
• DSAR vs DSR
• DSAR and GDPR
• DSAR and US state privacy laws
• DSAR best practices, regardless of regulation
• How to fulfill a DSAR

Data Subject Access Request (DSAR) definition

DSAR or data subject access requests are when an individual (one protected by a relevant privacy law) asks a company or organization for a record of the personal data that company has collected about them. 

Though most privacy laws allow people to request a copy of their data, the term DSAR originated with the General Data Protection Regulation (GDPR). As the first comprehensive privacy bill of its kind, GDPR provided the blueprint for most subsequent privacy laws. 

Data subject access requests stem from the ‘right to access,’ which is provided in some form or another by the GDPR, California's CCPA, and the privacy laws in Virginia (CDPA), Colorado (CPA), Utah (UCPA), and Connecticut (CTDPA).

Though US state privacy laws don’t use the same terminology (“data subject” is specific to GDPR) —the intent and practical application of their ‘right to access’ is the same. This right allows consumers to request: 

• Access to the personal data a company holds on them
• Information about how the data is being collected or used
• Clarification on how long the data will be stored

Depending on the law, companies have between 30-60 days to respond to the request. 

DSAR are actually a subset of data subject requests, which span a greater set of consumer rights, including the right to deletion, correction, and portability. 

DSAR vs DSR

Data subject requests or DSR refer to a broader set of actions consumers can take when actioning their data rights. 

We went over the ‘right to access’ above, but most privacy laws also offer consumers the right to deletion and correction. Right to portability is provided by some laws, but not all. 

Deletion

A data deletion request stems from the ‘Right to delete,’ which means a consumer may request that a company deletes the personal data they hold about them. 

Correction

A data correction request comes from the ‘Right to correct,’ which gives consumers the right to request that companies correct known discrepancies in the data they hold about that person. 

Portability

A data transfer request is the byproduct of the ‘Right to portability.’ Though not all US state privacy laws give consumers this right (Utah’s privacy law does not), this right means a consumer can request a copy of their data in a format that’s easy to understand and transmit.  

As mentioned above, DSAR are a direct effect of Europe’s GDPR, meaning the guidelines there are well defined and worth exploring further. 

DSAR and GDPR

GDPR Article 15 states that: 

Put simply, consumers may ask companies if their personal data is being or has been processed. If so, they may request access to that data.

In addition to access, consumers may request information concerning:

• Why the data is being processed
• What categories of data are being processed
• Whether or not their data has been shared, and if so, to whom
• How long the data will be stored for and how that decision was made
• How the company got their personal data (if it didn’t come directly from the consumer)
• Whether or not their data is subject to automated decision making and profiling, as well as how that affects the processing of their data

Note: We’ve been using the term ‘company’ or ‘organization,’ but the GDPR uses the term “data controllers.”

Once a request is received, Article 15 requires that data controllers “provide a copy of the personal data” being processed, along with any of the information above, if it’s requested.

Under Article 15, consumers may also make a complaint to a country's data protection authority (DPA) or other “supervisory authority.”

DSAR and US state privacy laws

Five US states currently have privacy laws (California, Virginia, Colorado, Connecticut, and Utah)—and all five offer the ‘right to access’ to consumers under their purview.

This means that, though it doesn’t necessarily use the same terminology i.e. “data subject access requests,” the practical implications are the same.

Consumers in these states may request access to the data a company holds on them, and that company must respond in a timely manner (30-60 days depending on the law).

DSAR best practices, regardless of regulation

Though regulation does vary worldwide (and is still quite piecemeal in the US) there are some basic principles that should guide your DSAR fulfillment process.

Data must be sent in a format that’s easy to read and understand

Consistent across all privacy regulation, the guidance for DSAR formatting remains the same—data must be sent in a format that’s easy to read and understand. This means it can’t be in unicode, the wingdings font, or any other format your average person can’t quickly decipher.

Clearly, this is a somewhat subjective measure, but let common sense be your guide. If you or someone on your team wouldn’t be able to easily read and understand the data, it’s unlikely an average consumer would fare any better.

Verify user identify before sending the data

Though companies are expected to fulfill DSAR requests promptly and within the given time limit, they’re also required to maintain data integrity and take reasonable precautions to ensure data security. Verifying user identity is one the most important ways to do so. 

Imagine collating all the data your organization holds on someone, packaging it, and then sending it out—only to realize it was sent to the wrong person, or worse, that it was sent to a scammer pretending to be someone else. 

Best case scenario, you’ve given sensitive data to someone to whom it doesn’t belong. Worse case scenario, that someone uses the data to steal an identity, run up a credit card bill, or open fraudulent lines of credit. 

Automate your DSAR process

At the smallest of scales, manual DSAR fulfillment is feasible. But as request volumes increase, so does the opportunity for human error and security breaches—not to mention the increased resource drag on your legal or CX teams. 

DSAR automation is a best practices because it:

• Saves time by minimizing manual steps
• Improves security for sensitive personal data
• Minimizes the risk of non-compliance

We’ve written a full guide on the benefits of DSAR automation, so be sure to check that out as well. 

How to fulfill a DSAR

Even if one team or individual owns the task, fulfilling a DSAR can take involvement from teams throughout the organization, including CX, engineering, data, and even legal. Depending on the complexity of your data ecosystem and the privacy infrastructure you already have in place, the exact steps of your fulfillment process may vary. 

However, there are a few foundational steps that are key to any successful DSAR process. 

1. Identify user identity and request validity
2. Identify and collate data from your various data systems
3. Collate all the data into easily understandable and transmittable format

Something to keep in mind here—this process assumes the existence of a complete company data map.

Data mapping, the process of identifying where and how personal data is stored throughout your data ecosystem, is a critical part of DSAR fulfillment. Without a complete data map, Step #2 becomes much more complex. 

We have quite a few good resources on data mapping, so be sure to check those out. 

• The Complete Guide to GDPR Data Mapping
• Data Mapping: A Beginner’s Guide
• ROPA Process: A Step-by-Step Guide

Verify user identity and ensure request validity

Verifying a user’s identity is a non-negotiable part of fulfilling DSAR requests. As we said before, not authenticating the request's validity can lead to data leaks and other security issues. 

But how can you verify user identity without gumming up the works of your DSAR process? 

We’ve actually released an entire security learning session dedicated to this topic, but here’s a few key suggestions:

1. Move your DSR process from email to a secure form
   This enables a fixed set of choices, rather than arbitrary email text, and you can preload forms with spam catchers such as CAPTCHA.
2. Apply two-factor authentication (2FA)
   Implementing 2FA is a sure way to create additional security in your DSR process. How you do it is up to you, but requiring an additional text or email (especially before deleting data) or using a tool like the Authenticator app can minimize fraudulent DSR requests.
3. Require account login
   In some cases, it may be appropriate to require account login in order to request data access or deletion. Though it’s possible a spammer may have access to an individual's account, this option does add an additional layer of security, as someone would need to already be in their account before making the request. 

Identify and collate data from your various data systems

This part of the process is where DSAR fulfillment can get quite complicated. In order to fulfill the request successfully, you’ll need to identify every system where personal data is stored. Then, you have to find that individual’s data within each of those systems. 

By systems we mean every database, software, and SaaS application within your company’s tech stack. For some companies this number is quite small, but for others it can be in the triple digits.

With an automated privacy request platform, each system is connected to your privacy request tool, so the process of searching for an individual's data happens automatically. 

However, done manually, you or someone on your team will need to track down data from each of these systems one-by-one. For a database, this might just mean a search, but for a SaaS application that might mean reaching out to that company, requesting the user's data, and then waiting for a reply. 

This is why it’s so useful to have a data map that’s updated in real-time and an automated DSAR tool that searches each system automatically. For a few requests, the manual approach is tedious, but doable—but as request volumes increase it becomes difficult, if not impossible, to keep up. 

Collate all the data into an easily understandable and transmittable format

Once you have all the data, it’s time to collate your findings and send it back to the consumer. As we’ve mentioned, readability is explicitly required by most modern privacy laws, so it’s important you send the data in a format that’s easy to read and understand.

Automate DSAR fulfillment with Transcend

Transcend Privacy Requests is the easiest and most comprehensive way to delete, return, or modify a person's data or preferences across your entire tech stack.

Get started with Transcend Privacy Requests in minutes and cut privacy request processing costs by up to 80%. Access prebuilt workflows and zero-code customization to fully automate data requests — no humans required.

Explore our Docs library to learn how DSAR fulfillment works with Transcend Privacy Requests, or contact us today to learn more.

About Transcend

Transcend is the company that makes it easy to encode privacy across your entire tech stack. Our mission is to make it simple for companies to give users control of their data.

Automate data subject request workflows with Privacy Requests, ensure nothing is tracked without user consent using Transcend Consent, or discover data silos and auto-generate reports with Data Mapping.