Data Access Requests Under GDPR and CCPA

If your business is subject to data privacy laws such as the EU General Data Protection Regulation and the California Consumer Privacy Act, then soon enough, it will encounter the challenge of data subject access requests. 

Under both laws, consumers have the right to see whatever personal data a company has collected about them. That is, they can request access to their data. A company subject to either law — and almost every company of appreciable size is subject to at least one if not both — must be able to fulfill that request somehow.

The idea of data subject access requests (DSARs) might sound reasonable and straightforward. In reality, compliance with this branch of data privacy law is fraught with risk. Compliance officers trying to manage their company’s data privacy program have no easy task.

What the Data Privacy Laws Actually Require

The right to data access is spelled out in Article 15 of the GDPR and in Section 3 of the CCPA. The two provisions are broadly similar, although not identical. For example, both provisions specify that when an individual — a consumer, employee, or anyone else —  submits a verified access request, the company must disclose:

• The categories of personal information collected about the individual;
• The purpose the business has for collecting the data;
• The categories of third parties with which the business is sharing the person’s data;
• The sources from which the business collected the personal data if the business didn’t collect the data directly; and
• The actual personal data the business has collected.

The GDPR also requires a business to disclose how long it plans to keep the individual’s data. The CCPA doesn’t. The GDPR gives a business 30 days to respond to a data access request (sometimes longer, for complex cases), whereas the CCPA allows 45 days. 

One important point: these provisions apply to the company that collects and controls the data, rather than the company that processes it. 

For example, if a travel website collects information about its customers, but stores and processes that information with third-party tech vendors, then the travel website is subject to Article 15 of the GDPR. The vendors aren’t, because they don’t “control” the information; they only process it on behalf of the controller. (Although data processors may be called upon to help the data controller fulfill a DSAR.)

Under the GDPR, when a company fails to respond to a DSAR in a timely manner, the data subject can then complain to his or her data protection regulator, who can open an investigation and pursue fines against the company. The same is true for the CCPA: individuals can complain to the state attorney general, who can impose fines of $7,500. What’s more, consumers can also file class-action lawsuits, where the costs and damage awards can escalate quickly.

How to Fulfill Data Access Requests 

The challenges for compliance officers here are twofold. 

First, the business needs a process to receive and answer DSARs at scale — because you might have dozens or hundreds of DSARs at any one time, requiring your business to sift through potentially millions of records, scattered across multiple databases managed by multiple vendors. 

Second, as part of that DSAR process, you’ll need to be able to verify the identity of the subject; and determine which personal information you can’t disclose to the subject — because both laws have exceptions to their DSARs provisions, too. 

For example, you could try to build a self-service model to fulfill DSARs. A consumer would visit your website, verify his or her identity, and your IT systems could then retrieve and display all the relevant data for that person. That approach automates much of the fulfillment work, which alleviates the burden from your employees. 

In practice, however, a lot can go wrong with that idea if it’s implemented recklessly. For example, an impostor could pretend to be a certain individual, and without suitable verification procedures, you might share personal data with the wrong person. Result: privacy breach. 

Or your systems might share certain data that should be kept secret, such as records pertaining to a law enforcement investigation against the individual (say, a credit card fraud or embezzlement scheme). Result: law enforcement agents irate at your business, possible civil litigation, and similar headaches.

So what can compliance officers do to avoid those pitfalls?

Build Effective, but Reasonable, Procedures

Begin by reviewing the requirements of the CCPA and the GDPR, to understand what your business must deliver to someone submitting a DSAR. For example, you must be able to acknowledge receipt of the DSAR, even if you can’t fulfill the request immediately. You also need to verify the identity of the person submitting the DSAR.

So consult with your IT developers to consider what procedures can be created to fulfill those goals, given the systems and applications your business uses. The company could use an online submission form to receive DSARs and build verification into that process by requiring individuals to enter a user ID and password they had previously created with your business. (For extra security, you might even use multi-factor authentication.) If you don’t take steps to verify the data subject’s identity and turn over the information to the wrong person, that invites investigations and regulatory enforcement from regulators, as well as civil litigation from the wronged person.

You also need to understand the circumstances where you could not share personal data in your possession. For example, you could not provide any email records between your company and law enforcement about an ongoing criminal investigation into the subject. You might also be able to withhold data that are relevant to civil litigation.

In that case, the compliance, legal, HR, and IT teams would all need to collaborate to develop procedures that cross-reference data access requests to legal or HR systems. The goal would be to develop controls that prevent confidential information from being turned over to a data subject by mistake.

A large company might be able to achieve that with sophisticated data management, to tag personal data according to taxonomies that would flag sensitive information automatically. Smaller organizations might need to take a more human approach, where personnel reviews and approve DSARs individually. 

The Compliance Officer’s Role

In all cases, compliance officers will need to understand the challenges your organization will face in fulfilling a DSAR, and then develop procedures and controls to fulfill that regulatory obligation prudently. 

Those tasks go well beyond simply tracking personal data within your company’s control. For example, part of fulfilling a DSAR is articulating the company’s business purpose for collecting personal data. Who gets to define that purpose? Presumably someone in marketing, HR, or business operations — but those people are often far removed from regulatory compliance, and “because we can” is not a satisfactory answer here. So compliance will need to consult with those executives and craft a reasonable consensus on what data is collected, and why. 

As we mentioned earlier, the compliance officer will also need to collaborate with IT, legal, and HR teams (and probably others) to develop DSAR procedures and controls that make sense for your business. It’s about clarifying risks, roles, and responsibilities. It’s about assuring that everyone has the proper tools and knows the proper processes to do their part to fulfill DSARs. And compliance officers themselves need the ability to monitor and supervise DSARs, to confirm that everyone is following policy and procedure correctly. 

In the modern enterprise, with so many systems and so many third parties working under your organization’s umbrella, none of this will be easy. But given the disastrous consequences that can come from privacy programs gone wrong, it’s imperative to get this right.