About Data Subject Requests

Overview

• What is a Data Subject Request (DSR)?

• What is a Data Subject Access Request (DSAR)?

• Understanding the Differences Between DSRs, DSARs, and SARs

• Requirements for DSRs and DSARs

• How to Fulfill DSRs and DSARs

• Automating and Simplifying DSRs and DSARs

A

data subject request (DSR)

is a user’s request to access, modify, or delete the personal data that a company holds on them. A growing number of laws—including the European Union’s

GDPR

,

California’s CCPA

, and

Connecticut’s CTDPA

—grant individuals the legal right to submit these requests. Companies must follow specific guidelines in fulfilling data subject requests or risk fines and other penalties.

A data subject access request (DSAR) is a specific type of data subject request: a user’s request to access their personal data that a company has processed. Alongside the data itself, companies often must supply descriptions of how and why the data was processed. Companies’ requirements

vary from one law to another

, in areas like what personal data categories are included and how promptly a company must respond.

Efficient fulfillment of data subject requests and data subject access requests is also a key way to show users that your data practices are worthy of their trust.

The central goal for teams is to promptly provide accurate and comprehensive responses to data subject requests. It sounds simple enough. But as data systems are becoming more complex, it can become an overwhelming challenge to track down all of a user’s data when they request it be deleted, corrected, or shared with them. However, understanding the basic requirements and procedures for data subject requests can prepare your team for compliance success.

As their names suggest, both DSARs and subject access requests (SARs) refer to a user’s request to access the personal information that a company holds on them. On the other hand, a DSR is an umbrella term to include users’ requests to access, modify, or delete personal information. In other words, (data) subject access requests are one type of data subject requests.

At their essence, DSRs and DSARs aim to empower users with greater control over how companies use their personal data. Data subject requests rose to global prominence in recent years thanks to the EU’s General Data Protection Regulation (

GDPR

). Spelled out in detail in GDPR’s

Chapter 3

, end-users (aka “data subjects”) who reside in the EU are granted a suite of rights. When it comes to data subject requests that users can submit to companies, these include:

• A right to access personal information (GDPR Article 15)
• A right to rectification, or correction, of inaccurate personal information (GDPR Article 16)
• Why does the company collect and process this personal data?
• A right to erasure, sometimes called the right to be forgotten, of personal information (GDPR Article 17)

Importantly, as with GDPR in general, the responsibility to fulfill data subject requests is not just for companies based in the EU. Any company that processes EU users’ personal information is responsible for EU users’ fulfilling data subject requests.

DSRs and DSARs in Regulations Worldwide

GDPR has influenced how data subject requests are codified in data privacy regulations worldwide, Brazil’s

Lei Geral de Proteção de Dados

(LGPD) also grants the rights of access, erasure, and correction. In the US, both California’s CCPA and

Virginia’s CDPA

grant users the rights of access and erasure, and the CDPA includes the right to correction. A right to correction is already on its way in California, with the right included in the passed CPRA that goes into effect at the start of 2023.

The CCPA also encodes data subject requests under the

“Do Not Sell My Personal Information”

feature. In plain terms, a California resident can submit a request to opt-out of a company’s personal data sales.

It is critical to understand that the CCPA takes a broad interpretation of “data sales” to include any exchange of personal information, not just exchanges that involve a monetary transaction.

Zooming out from specific regulations, it is clear that data subject requests are an integral part of global privacy compliance; all of the above regulations went into effect less than five years ago, and a surge of state- and federal-level bills are presently under consideration.

Guiding Principles for DSRs and DSARs

Across regulations, a handful of principles for DSRs and DSARs hold steady throughout. DSRs must be:

• Easy for users to understand: GDPR requires companies to use clear, plain language when delivering personal information to a user in response to their access request
• Promptly fulfilled by the company: each regulation enforces its own timeline, generally ranging from 15 days under LGPD to 45 days under CCPA, with predefined extensions permitted
• Supported with identity verification: Because a DSAR inherently involves the exchange of personal information, GDPR requires companies to verify the identity of the requester (GDPR Recital 64). That way, companies avoid exposing one user’s personal information with another party. Other regulations worldwide require similar verification steps.

Finally, failure to fulfill data subject requests can lead to sizable fines. For instance, CCPA and CDPA non-compliance penalties can reach $7,500 per violation. GDPR non-compliance regarding data subject requests’ can reach €20 million or 4% of annual revenue, whichever is larger. In short, complying with data subject requests belongs at the core of your privacy ops.

Understanding Your Obligations and Exceptions for DSRs and DSARs

To fulfill a DSAR across regulations, a company should provide the following information to the verified requester:

• A copy of personal information the company holds
• The company’s purposes for processing that data
• The categories of personal information collected (e.g. name, purchase history, etc.)

Some regulations, like GDPR, require companies to share additional information, including:

• The recipients of the personal information, domestic or intentional
• The company’s timeline for retaining the data
• Whether automated decision-making is involved in processing this data and the significance of those operations on the user

For deletion requests, companies may be required to retain the personal information in question for purposes like taxes. In the absence of such legitimate interests, however, companies must respect the deletion request.

In general, companies cannot require payment to process data subject requests. However, GDPR does carve out an exception: companies can charge a fee when it' considered “manifestly unfounded or excessive.” The CCPA and CDPA require companies to grant each user two free data subject requests each year, beyond which they can apply a reasonable fee.

A single data subject request can cut across your team’s operations. For instance, if an EU resident requests access to all of the personal information you hold on them, a handful of tasks need to take place:

• Verify the identity of the requester
• Identify all of places in your data systems and third-party apps where that users’ data resides
• Consolidate the relevant personal information into a readable format

You could face a steady stream of requests from users across the globe with their own deadlines for fulfillment. As such, it is clear that your systems need to be in sync to carry out the request.

A DSAR Walkthrough

First, you must implement a way to verify that your user is indeed who they say they are. Multi-factor authentication is one such practice. This method involves sending the user a code, often as an email or a text message. Importantly, the authentication medium is different from the one that the user used to submit the DSAR.

Next, find all of the places where the requesting user’s data resides. The objective sounds simple enough, but it can be a Herculean challenge in practice. Perhaps you have a tech stack with thirty different SaaS apps: some for SMS marketing, others for processing financial details, the list goes on. Unless you have an automated solution, you’ll need to individually contact each SaaS app to request the user’s data. And don’t forget about your own in-house data stores, where each database might have a distinct structure.

Finally, it’s time to ship off an easy-to-read copy of the user’s data. Your systems might use labels with formatting suitable for databases but awkward for a human reader. For instance, your database might store users’ shipping addresses in a column called “address1” and their billing addresses in a column called “address2.” When fulfilling a DSAR, rename them “Shipping Address” and “Billing Address.” It’s a simple yet meaningful edit that signals to the user that you prioritize transparent data practices.

Fides can help your business simplify your DSAR fulfillment process with the Fides platform. To deliver the user a full picture of their data in your company, you need a comprehensive data inventory. This can be a time, and resource, intensive task for teams to do on their own. With the Fides platform, you can generate a data map so you know where user data is. That will help you start automating user subject requests with our tools. Fulfilling data subject requests will become a seamless part of your workflow, rather than a constant headache for legal and engineering teams.

Erasure and Correction Workflows

Erasure and correction requests follow a similar workflow to the one for a DSAR. These requests both require identity verification and a comprehensive picture of all the places their data resides. However, instead of delivering a copy of the data to the user, erasure and correction requests call for a change to the data in your systems.

It is essential for teams to

exercise caution

when deleting or modifying data, because changes to one data field can set off cascading errors in processes that rely on that data field. For strong privacy and data ops, be sure that deleting or modifying a user’s data won’t spill over into downstream errors. Once you have successfully deleted or corrected the user’s data, contact the user to provide this confirmation.

The End-User’s DSR Experience

Strive to provide users with the most seamless DSR experience possible. Providing a simple process is not just a respectful thing to do; it’s a specific right granted to users under laws like GDPR. On your website, provide an easy-to-identify location where they can submit DSRs. Your front-end developers should make sure that this resource is available to users throughout the site, not just upon entrance to the site. To keep your bases covered across global regulations, incorporate a link to users’ privacy rights into your website’s footer. Then, users will always have access, no matter where they are on the site.

Once they’ve clicked the link, users should see a clear display of their data subject request options, with clear instructions for any multi-factor authentication. After the request has been submitted, they should receive a short email notification confirming a successfully fulfilled request.

Fides equips you to seamlessly fulfill data subject requests, and it also empowers your users to exercise their data rights with peace of mind. All DSRs flow into a single Control Panel, giving you a comprehensive view of pending requests. From there, you can approve data subject requests with a single click. Ethyca connects to your in-house data stores and your third-party tech stack. It does the heavy lifting in coordinating a single request across disparate data flows.

In addition to fulfilling requests across complex parts of your data systems, Fides helps you keep users informed on the status of their requests. From your Control Panel, you can set up automatic emails that notify users when you have received and completed their requests. When a DSAR is fulfilled, the requesting user receives an easy-to-read HTML webpage with a copy of their personal information residing in your systems. It’s a win-win: you know that you’re providing the user with a full picture of their data in your systems, and your user receives a package of data that’s readable to them. Beyond meeting regulatory requirements, you show that you respect users’ data and are worthy of their trust.

If appropriate under the relevant regulations, you can also deny requests. To simplify CCPA compliance, Fides automatically flags DSARs from users who have reached their annual limit. In doing so, Fides takes the guesswork out of your privacy ops. Ethyca also helps you communicate with users on the basis for denying their requests.

Ready for Compliance Success

On top of day-to-day business, your team could receive a steady stream of data subject requests from users worldwide. It can be overwhelming to keep track of different regulations’ distinct requirements on what each request entails and how quickly they need to be fulfilled. Fides gives you an up-to-date log of all pending data subject requests, including the time remaining to fulfill them.

Beyond completing DSRs, leading privacy regulations like GDPR and CCPA require teams to maintain a record of those requests. Fides automatically logs requests in reports that you can open in-browser or download as a .csv file. For instance, an in-browser report might look like this:

With this auditable record of requests, you can be confident that you’re respecting users’ data and generating the documentation that regulations require.

DSRs and DSARs Made Simple

If you’re ready to simplify DSRs for your team and your users,

book a demo with us.

We’d be happy to answer your questions and show you what Fides can do for your privacy ops.