When your business receives a data subject request, verifying the identity of the requestor is a key first step. This step-by-step guide takes you through the pros and cons for different methods of subject request identity verification.
Thanks to the introduction of sophisticated data privacy law in recent years, companies have been forced to rethink how they view the data they process. To stay compliant with global regulations, organizations are now obliged to implement systems that not only protect an individual’s data, but also respect their choices when it comes to how that data is stored and used. The individual can make certain legally-enforceable demands of the organization that processes their data using a mechanism called a Data Subject Access Request.
The European GDPR was the first major law to codify Data Subject Access Requests. In line with Article 15 of GDPR, a ‘data subject access request’ ( or just ‘access request’) is a request an individual can make for a complete record of their personal data which are being ‘processed’ (i.e. used in some way) by a ‘controller’ (i.e. an organization who decides how and why their data are processed).
Many of the access rights GDPR grants to an individual are being mirrored all over the world, most notably in the California Consumer Privacy Act (CCPA) and Brazil’s Lei Geral de Proteção de Dados (or LGPD), so it’s crucial for any organization that processes personally identifiable information (PII) to have a system in place to deal with these requests in an efficient, secure way. Key to this is having some form of identity verification in place to confirm the identity of the individual making an access request.
To explain why identity verification is a necessary step in access requests, it’s first necessary to explain two common data privacy terms: data controller and data processor.
A data controller determines the purposes for which and the means by which personally identifiable data is processed. If your company defines ‘why’ and ‘how’ the personal data that it processes should be processed then it is, by definition, the data controller. If the ‘why’ and ‘how’ is jointly determined with one or more other organizations then they are deemed to be joint controllers along with your company.
A data processor, on the other hand, processes personally identifiable data on behalf of the controller. The data processor is usually a third party external to the company. Most commonly, a company occupies both roles as data controller and data processor and may have a number of third party service providers that act as data sub-processors.
As part of a data controller’s legal privacy obligations, access requests need to be carried out with identity verification, so as to prevent data from being shared with an individual that they do not belong to.
Recital 64 of GDPR states that:
Under GDPR, state bodies can be fined up to €1 million for failure to meet their obligations, and multinationals can be fined up to €20 million, or four per cent of their previous year’s turnover.
Under the CCPA, businesses are also required to observe a number of privacy best practices, facilitate access requests, and more. Those found to be in breach of the CCPA can be fined per individual affected, per violation. The maximum fine can be as high as $7,500 of statutory damages per individual affected, per violation. In a class action lawsuit, that adds up quick.
Brazil’s Lei Geral de Proteção de Dados Pessoais (LGPD) follows suit with a fine of up to 2% of a private legal entity’s, group’s, or conglomerate’s revenue in Brazil, for the prior fiscal year, excluding taxes, up to a total maximum of 50 million Brazillian reals.
When the possibility of receiving such heavy penalties is on the line, a violation of data privacy law is not something any organization wishes to experience.
To make it easier for you to get started with identity verification, we’ve outlined some of the methods that you can implement for Data Subject Access Requests below.
One thing to consider from the outset is GDPR’s obligation that “A controller should not retain personal data for the sole purpose of being able to react to potential requests”. This means that your company cannot ask for any more information than that which it already possesses in order to verify an individual’s identity.
Another way to think about this is: you shouldn’t ask for people to provide more, new data in order to access the data your business already has.
With this in mind, we’ve provided a number of methods that an organization can implement to make sure that they’re in compliance with data privacy law. Each has its pros and cons, and the right approach will be dependent on the needs and capabilities of your organization.
One of the easiest methods of identity verification is to use the PII your company already possesses about an individual in order to verify that they’re who they say they are. This involves asking them questions that relate to the information you store about them. Some examples of this method are:
Depending on your business’ data systems, the individual making the access request may be able to prove their identity by virtue of having access to your company’s services or by possessing certain account credentials. Some examples of this method could be:
If your company possesses a contact method for an individual, you can use it to carry out a form of authentication that is even more robust than having that individual log in to their account alone. By sending the individual a one-time passcode and asking them to confirm the passcode, you can securely and easily confirm that they are the person that is making the access request. Examples of this method include:
If maintaining Data Subject Access Request compliance is not something your company wishes to do themselves, then you could consider outsourcing the workload to one of a number of third party specialists that can implement and manage this system for you.
If your company decides to go down the outsourcing route, there are a couple of options:
This is a poor experience for the individual making the request. It can also be very expensive in comparison to managing it internally with the help of data privacy software that actually lives in your system. One of the advantages of Ethyca’s solution is that we don’t duplicate any of your user data into new locations, or share it with any additional third parties, including identity verification vendors. Our software simply identifies and classifies data as it exists in your systems. When users file a data subject request with an Ethyca-powered business, they can rest assured that their PII footprint will not increase simply because they make a request for access.
Regardless of the method that you choose to implement, it is crucial that your organization stores an audit trail of all Data Subject Access Requests that they process, including identity verification confirmation, so that you can prove that they were carried out in compliance with data privacy law. That audit trail should be uneditable so as to support its legitimacy.
Implementing a system for identity verification can be a complex and time-consuming task, but you can make the process painless by using Ethyca’s Subject Request Panel. You can create an account for free today and get started managing user privacy, or you if you have any questions about how Ethyca works, reach out to one of our team.
We enjoyed two great days of security and privacy talks at this year’s Symposium on Usable Privacy and Security, aka SOUPS Conference! Presenters from all over the world spoke both in-person and virtually on the latest findings in privacy and security research.
At Ethyca, we believe that software engineers are becoming major privacy stakeholders, but do they feel the same way? To answer this question, we went out and asked 337 software engineers what they think about the state of contemporary privacy… and how they would improve it.
The UK’s new Data Reform Bill is set to ease data privacy compliance burdens on businesses to enable convenience and spark innovation in the country. We explain why convenience should not be the end result of a country’s privacy legislation.
Our team at Ethyca attended the PEPR 2022 Conference in Santa Monica live and virtually between June 23rd and 24th. We compiled three main takeaways after listening to so many great presentations about the current state of privacy engineering, and how the field will change in the future.
For privacy engineers to build privacy directly into the codebase, they need agreed-upon definitions for translating policy into code. Ethyca CEO Cillian unveils an open source system to standardize definitions for personal data living in the tech stack.
Masking data is an essential part of modern privacy engineering. We highlight a handful of masking strategies made possible with the Fides open-source platform, and we explain the difference between key terms: pseudonymization and anonymization.
Our team of data privacy devotees would love to show you how Ethyca helps engineers deploy CCPA, GDPR, and LGPD privacy compliance deep into business systems. Let’s chat!Book a Demo