This browser is not actively supported anymore. For the best passle experience, we strongly recommend you upgrade your browser.

Social Media Links

| 5 minutes read

Lessons Learned from Implementing Privacy Rights Request Processes – Part 2

This article is the second in a multi-part series covering concepts that can be applied to your company’s process for managing privacy rights requests, as required by various modern privacy laws. The first article in this series discussed the ideas of designing for regulatory expansion, considering different data subject types, and how to gain process efficiencies. This second article will expand on the first and discuss communicating with requestors, acceptable ways to “delete” data, and dealing with requests from authorized agents.

Communicating with Requestors

There are various points throughout the processing of a privacy rights request when the privacy office will need to communicate with the requestor. For example, some regulations require organizations to acknowledge a request within a certain number of days. There are various reasons why organizations might need to inform the requestor that the organization is denying their request.  And of course, when an organization fulfills a request, the organization needs to notify the requestor and in certain cases provide a copy of their personal information. These communications are important. Below are several key considerations:

  • Use Templates: Ensure the organization has a standard response template for the handling of the common communication scenarios associated with processing each request type. Most of the language in these templates should be boilerplate and require no editing each time they are used. This ensures consistent and appropriate communication throughout the process. Parts of each template can be designated for replacement, such as inserting the requestor’s name in place of a “Dear” placeholder to make the message more personal.
  • Get Input from Counsel: The language used in response templates should be crafted carefully. Make sure to obtain input from internal and/or external counsel to ensure that the company is covering all applicable requirements in these communications, and that the language doesn’t inadvertently expose the company to unforeseen risk.
  • Secure Messaging: If possible, electronic communications with the requestor should be secured to ensure sensitive information is not intercepted. Using secure email or a dedicated messaging portal for your privacy requests are good options. At a minimum, when sending personal information to a requestor (such as when fulfilling an Access or Right to Know request) that this data is protected in transit.

Ensuring proper and consistent communication while processing privacy rights requests helps create a good experience for the people whose personal information is managed, while also minimizing the company’s risk.

Acceptable Ways to “Delete” Data

Many new privacy laws include the right for a person to request that a company delete their personal information. This can be one of the hardest types of privacy rights requests for a company to fulfill, because the organization may rely on the data for any number of purposes. It’s important to understand that there are options for “deleting” personal information:

  • Hard Deletion: This refers to actually deleting the data. It’s gone. This is the obvious option but one which a company may be hesitant to do, unless it can be sure that deleting the data won’t cause any problems.
  • Soft Deletion: This refers to marking data as “inactive” or “deleted” or something similar to indicate that it should be ignored. The data isn’t actually deleted, it’s just designated with a status flag or a true/false field to indicate that any system or process which works with the data should ignore certain records. This can be more palatable in some cases than hard deletion because the data still exists if a problem arises. However, this option must be used with care to ensure that ALL systems or processes correctly ignore the designated records, as if they had actually been deleted. It is unlikely that soft deletion tactics will meet regulatory requirements for an erasure request, but soft deletion may be considered as part of interim solution while more robust or permanent data deletion protocols are being implemented.
  • Anonymization: Anonymization is the process of permanently removing personally identifiable information from a dataset so that the people whom the data describe remain anonymous. This might include de-identifying the records in a way that is not easily reversible or aggregating the data such that it can be analyzed without knowing the identities of the individuals represented by the data. This can often result in minimal loss of the data’s usefulness while protecting privacy.
  • Pseudonymization: Pseudonymization refers to the process of replacing personally identifiable information fields within a record with one or more artificial identifiers, or pseudonyms. Pseudonymized data can be restored to its original state with the addition of information which then allows individuals to be re-identified, while anonymized data can never be restored. Similar to soft deletion, this option should be exercised with care to ensure that data is not re-identified without proper justification.

Consider what mix of these options makes sense for the various types of data that your organization manages.  

Dealing with Requests from Authorized Agents

The CCPA includes a requirement to allow “authorized agents” to act on behalf of an individual with respect to exercising their privacy rights. Section 999.301(c) of the CCPA regulations defines an authorized agent as the following:

"a natural person or a business entity registered with the Secretary of State to conduct business in California that a consumer has authorized to act on their behalf subject to the requirements set forth in section 999.326.”  

Handling requests submitted by these agents includes some unique challenges:

  • Automated Requests: Some agents are what you might expect, a human being acting on behalf of another. On the other hand, there are companies with automated technology which can scan a person’s email inbox or other repositories to identify companies that person deals with and send automated privacy rights requests on their behalf. Many of the automated solutions submit requests without insufficient information included, especially as it relates to providing proper authorization. In some cases, they offer little or no way to follow up with anyone to get more information required for processing a request. Be prepared to receive these kinds of requests by having a standard email template with which to respond. For example, you might re-direct the agent to a web form used specifically for accepting agent requests.
  • Verifying Authorization: Section 999.326 of the CCPA regulations explains the requirements for an agent to be properly authorized and the obligations of such agents. When combining this with the definition above, there are two things that need to be verified with respect to authorization.  First, if the agent is a company (business entity), it must be registered with the California Secretary of State. The second is that the agent must provide either valid power of attorney or a signed (preferably notarized) authorization to act on behalf of the person they are representing. Make sure that the organization's process for submitting agent requests requires documentation to be provided in support of these points so that the organization can properly verify agent authorization before proceeding any further.

Agent requests are here to stay and seem to be increasing in volume. If your company has exposure to the CCPA, make sure you’re prepared to deal with them.

Stay tuned for one more planned article in this series which will discuss additional lessons learned from the real world of implementing and improving privacy rights request processes.

© Copyright 2021. The views expressed herein are those of the author(s) and not necessarily the views of Ankura Consulting Group, LLC., its management, its subsidiaries, its affiliates, or its other professionals. Ankura is not a law firm and cannot provide legal advice. 



risk, cybersecurity & data privacy, data privacy & cyber risk, memo

Let’s Connect

We solve problems by operating as one firm to deliver for our clients. Where others advise, we solve. Where others consult, we partner.

I’m interested in

I need help with