Lessons Learned from Implementing Privacy Rights Request Processes
Over the last three years, several data privacy regulations have been adopted around the world which include requirements related to the collection, processing, and use of personal information. The list includes the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA) and the Lei Geral de Proteção de Dados Pessoais (LGPD) for Brazil, among many others. These apply broadly to many companies but there are also other regulations which only apply to certain companies or industries such as the Health Insurance Portability and Accountability Act (HIPAA). The list of privacy regulations continues to grow.
A key area addressed by some of these regulations is the granting of different “request” rights to individuals whose personal information is held by companies. For example, individuals may have rights to request that a company provide a copy of the personal information held about them, to have this information corrected or deleted or to stop/limit certain types of data processing such as selling of their personal information to third parties. Different regulations have used different terms for these requests such as Data Subject Requests, Consumer Rights Requests, etc. Let’s refer to them generically as Privacy Rights Requests.
Based on experience helping a wide array of companies implement processes to accept, manage and fulfill these requests, several lessons have emerged. This article is the first in a multi-part series covering concepts which can be applied to your company’s process.
Design for Regulatory Expansion
Most companies start implementing a solution for privacy rights requests because of compliance requirements from a regulation such as the GDPR in 2018 or CCPA in 2020. However, with new regulations emerging every year and organizations expanding into different business jurisdictions, many will need to comply with an expanding list of regulations. As such, it may be wise for some companies to design the initial process to be extensible to accommodate more regulations over time. Here are a few tips:
Awareness is Key: Your Privacy Office and/or external privacy counsel should monitor the regulatory landscape for awareness of new laws which will impact the organization. For example, those companies currently subject to CCPA need to plan for the fact that the California Privacy Rights Act (CPRA) will supplant it as of January 1, 2023. There are several additional requirements to consider for California residents, including new and expanded request rights for individuals. The first step toward change is awareness.
Alignment Accelerates Awareness: Align your Privacy Office with executive leadership so you know about business expansion plans which may bring new jurisdictions and regulations into scope. The earlier these expansion plans are known, the more time you’ll have to plan for new types of requests or changes to how the current process for a given request type is executed.
Overlapping Request Types: Two or more regulations may require compliance with the same type of request but have slightly different requirements for fulfillment. For example, both the GDPR and the CCPA provide for the right to request that an individual’s data be deleted in certain circumstances. However, the requirements for verifying an individual’s identity prior to honoring a deletion request may be slightly different across the GDPR vs CCPA. Adapting your process to handle the most stringent superset of requirements for each request type and one process could help you be compliant with both regulations.
Depending on the needs of your organization, designing one process with enough flexibility to allow for accommodating new regulations may be helpful, rather than designing separate siloed processes for each.
Consider Different Data Subject Types
A “data subject type” is a type of person about whom your company collects/processes/uses personal information. This might include customers, employees or B2B contacts. Furthermore, your company might deal with multiple types of customers about whom you store very different types of data. It is important to distinguish these different types of people in your process. Consider the following:
Ask the Individual: As part of the request submission process, ask the individual what their relationship is with your company. Have them choose from a curated list of data subject types rather than asking them to describe the relationship in free-form text. This should be simple for the person to indicate in most cases and provides a means very early in the process to differentiate next steps.
Branch the Process: Your process can and often should be a little different depending on what type of person submitted the request. Customer data is typically stored in different systems than employee data, so you’ll need to be ready to retrieve, update or delete different data in different places. The fields of data available for performing identity verification may differ significantly as well. Account for these differences in your process and you’ll have an easier time with processing requests.
Differing Rights: In some cases, one data subject type may have a certain request right while another may not. For example, as of writing this article, the CCPA currently requires certain companies to honor “right to know” requests for consumers but not for employees or B2B contacts. This may change when the CPRA goes into effect but buys you some time to build out the details for certain branches of the process.
When working with companies to review and enhance their existing processes, differentiating data subject types is a concept which has commonly been missed in the initial implementation.
Process Efficiencies
Managing and fulfilling these requests means more work for someone in your organization to do. Most companies have limited resources to devote and it seems like we’re always being asked these days to “do less with more.” Here are some ideas which can help:
Comprehensive Requests: Ask for all information you’ll need to evaluate and process a request up front, instead of building follow up steps into the process. You don’t want to make the process of submitting a request overly burdensome, but at the same time you can’t proceed correctly without the correct information. Once a request is received the clock starts ticking on your fulfillment timeframe, so this is a good way to save time. For example, if you use a web form as the primary means for request submission, include fields on it that you’ll need for verifying the person’s identity.
Spread the Load: The Privacy Office, if your company ] has one, is usually the owner of this process but can’t do everything. Enlist help from other parts of the organization. Perhaps you have a Customer Support team which can handle request intake and identity verification. When working with data in various systems you’ll almost certainly need assistance from the IT team or Business Owners of certain systems.
Define Roles and Responsibilities: Spreading the load can be troublesome if roles and responsibilities in the process aren’t clear, making it easy for steps to be missed or for people to point fingers. List out the different roles to be played in the process and define the responsibilities for each. If you have a policy/procedure to support your process (which of course, you should), include these definitions within it and align the steps in the process clearly with the roles.
Automation: It’s always wise to walk before you run, but sometimes circumstances require us to run before we’re ready. Depending on the nature of your business and the industries served, some companies receive very few requests while others receive a large volume. In the latter case, automation is your friend. Once the details are determined for manually fulfilling requests, the steps to retrieve, update or delete data from a given system usually don’t change very frequently. Automate as much of this as possible so your people can “click a button” rather than manually follow a tedious set of repetitive and potentially complex steps.
We may not have a choice about complying with privacy regulations but at least we can be smart about it and try to minimize the pain involved.
This article is written by Mir Ali and Mark Melnychenko of the Ankura Cybersecurity and Data Privacy office. We received permission from Ankura to republish it for the ADCG community. The original publication can be found here.