What is a Data Subject Access Request (DSAR) And Why You Should Care?

yayabobi - May 3 '22 - - Dev Community

In a security landscape defined by regular high-profile breaches compromising individual data - states, countries, and economic unions introduced laws aiming to give people more control over what businesses do with their data. A pressing security concern for CISOs, IT security, and compliance teams is ensuring that their organization doesn't breach any rules from the increasing number of regulations protecting people's data. 

The EU's GDPR and California's CCPA are two data privacy laws that provide a slew of rights concerning personal data. A critical commonality between the two laws is the right for an individual to request businesses provide access to any personal data about them. Data Subject Access Requests form an important part of the right of access to data. This article aims to explain what a Data Subject Access Request (DSAR) is and what processes and procedures your business needs to be compliant if you receive a request. 

What is a Data Subject Access Request?

A data subject access request (DSAR) is a request initiated by an individual and addressed to an organization that exercises the right to get a copy or disclosure of any personal data processed about them by that organization. A DSAR is one of the most common requests organizations receive in their privacy mailboxes. 

When signing up for online accounts, buying products, using platforms, or subscribing to services, people share personal information with many types of businesses online.

In the early 2010s, governments and individuals expressed little concern for how businesses used the data they collected about people. 

However, scandals such as the Facebook and Cambridge Analytica incident demonstrated that businesses were harvesting, selling, and using personal data, often without people's consent. More stringent data privacy regulations arose from the need to protect and return control to people over what data is gathered about them and how businesses use it. 

Data subject access requests are part of the right of access, which is one of eight data subject rights under GDPR. The CCPA, which is essentially Calfornia's GDPR-inspired data privacy regulation, has the right of access as one of seven rights given to consumers. 

What information do you need to provide in a Data Subject Access Request? 

Typically, people want to know about the personal data processed and stored about them and how that information is being used. The type of information you need to provide a copy of is personally identifiable data, such as name, address, medical records, passport number, or social security numbers. Alongside this copy or disclosure, you also need to include:

  • The purpose of processing particular information
  • The data retention period
  • The rights of individuals pertaining to this data

The required information in a DSAR response varies slightly between GDPR. Under CCPA, each response to a request only needs to disclose information about data collection, usage, and sharing over the 12 month period before the request was received. GDPR has no such limit and it also mandates that data subjects are informed how long their data can be retained. 

How to prepare for a Data Subject Access Request 

Preparation is invaluable in all areas of compliance. This rings even truer for DSARs where high volumes of requests can catch unprepared businesses off guard and lead to compliance violations. Some general preparation tips include:

  • Understand how to recognize a subject access request (people could request access from an online form, when speaking to a staff member, via a written letter, or even through social media).
  • Have a specific policy in place that documents in clear steps how to handle a request.
  • Be aware of the conditions in which you can deny a DSAR and the information you need to provide with a refusal (businesses complying with GDPR and CCPA can deny excessive or manifestly unfounded requests).
  • Establish processes to track the date every request is received and ensure the response is provided within a compliant timeframe.
  • Ensure you have suitable systems or solutions in place that allow you to efficiently locate and retrieve personal information about individuals.
  • Be familiar with how to deliver a copy of requested information securely and in an accepted format. 

How long do organizations have to respond to a Data Subject Access Request?

Under GDPR, businesses need to comply with a data subject's access request within one month from the date they received that request. Where an access request is complex or the same individual sends a number of requests, GDPR rules allow businesses a two-month extension to this timeframe. If a business plans to use the two-month extension for any request, the individual who made the request still needs to be informed of this within one month. 

Businesses that need to comply with CCPA have 45 days to disclose and deliver the data requested by an individual. Similar to GDPR, CCPA allows for a one-time extension in the event of a complex request. The length of the extension allowed is 45 days for a total of 90 days from the original request being received. 

How to respond to a Data Subject Access Request 

It's imperative to understand that responding appropriately to a DSAR isn't just about avoiding compliance penalties. A strong compliance program emphasizes the customer trust benefits that are feasible from displaying a strong commitment to individual data privacy. 

With most people aware of data privacy regulations---Forbes found 83% knew about GDPR back in 2020---responding properly to these requests can even provide a competitive advantage. Here are some important steps. 

  1. Verify identity if necessary --- it's reasonable to ask for proof of identity in some circumstances, such as when the information requested is of a particularly sensitive nature or a representative carries out the request on behalf of the individual.
  2. Identify the scope of the request --- is it a simple access request or does the request exercise other rights that require additional processes and policies?
  3. Determine the request's feasibility within standard timeframes --- if extra time is needed, communicate this to the person requesting access within an appropriate timeframe. 
  4. Discover, collect, and amend the data --- find where the sensitive data held about an individual is in your environment, make a copy, and amend where necessary to protect other people who may be identifiable with that data.  
  5. Add extra information --- both GDPR and CCPA have their own set of requirements for what supplementary information is necessary with each copy/disclosure of data held about an individual. 
  6. Provide data in an accepted format ---  CCPA limits access rights to just a written disclosure in a portable format while GDPR provides broader access methods.

How Polar Security can help you with Data Subject Access Requests 

With awareness of data privacy regulations growing, many organizations struggle to cope with the volume of data subject access requests they receive. Complicating matters further is the complex IT infrastructures most businesses have in place today, which are a mix of on-premise and cloud computing environments. Within this infrastructural complexity, it's difficult to identify where the sensitive data is and what information is in it. 

Polar Security introduces a platform that automatically discovers, classifies and maps your data no matter where it flows in your IT environment. You can effortlessly discover and classify information in a way that facilitates streamlined and reliable processes for responding to DSARs comprehensively and on time. Book a demo to see the Polar Security platform in action.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .