An ever-increasing range of privacy regulations are providing individuals with rights to make requests to the organizations that are processing their personal data. HIPAA has bestowed a set of “Individual Rights” in the US medical sector, the General Data Protection Regulation (“GDPR”) provides a range of rights to EU residents, CCPA and the LGPD are emerging in California and Brazil respectively, and many other jurisdictions have and continue to develop regulations to put power in the hands of individual data subjects, giving them the ability to exercise their data subject rights (“DSRs”) through making requests to the organizations processing their personal data.

This increasing web of rights that organizations need to be prepared to address has also been made more complex by the extraterritorial scope of certain regulations (e.g. residents of the EU, California, and Brazil may have the ability to exercise their rights at organizations processing their personal data, even if those organizations are not physically located in the respective jurisdictions). Rapid advances in technology and exponential increases in the volume and dispersed nature of personal data processing, both internally to the organization and externally at third parties, have also presented new challenges.

Renewed interest is appearing in leading organizations wishing to raise the bar and apply higher standards as well as increasingly innovative solutions to solve these challenges posed by the DSR lifecycle. There is no one-size fits all approach to what an effective DSR program looks like, and although the same basic request types you have to deal with may be the same as your competitors (due to shared regulatory requirements, for example) the way you approach responding to these rights is going to be highly customized to suit the structure and data governance landscape at your own organization.

LevelUP has identified five important features of a successful DSR program that often go overlooked, but go a long way to helping you increase efficiency and success when it comes to handling DSRs at your organization.

“How would you recognize a data subject request?”

Start here and put yourself in the shoes of each of your operational front-line teams to whom you would ask this question. Identifying who could receive data subject requests, and then work with them to ensure they understand: (1) your updated policies and procedures, (2) how to identify a request, and (3) how to escalate requests for handling by the Privacy Office or Legal.

Going through these steps makes your frontline teams’ jobs easier, your job easier, and helps avoid a dissatisfied requester or a potential regulatory issue. Common training and guidance focus so much on what to do once you’ve received a request, but far less on how we recognize and direct it so that it arrives in the request queue, ready to be evaluated by the privacy team.

Many organizations promote unstructured, free text submission from requesters, by simply referring them to a generic privacy email address. However, many privacy tools exist, such as OneTrust, that can allow you to build a detailed and effective external-facing web form, an internal-facing request queue that is easy to sort and filter, and then also build out structured workflows behind the scenes to kick off the response process.

The act of customizing your intake process could include referring requesters to a dedicated web form specifically set up to allow them to submit DSRs. You can then promote the page by supplying a link to this page on your privacy notice. You could also require requesters to provide certain key fields or prioritized information in advance when submitting their request. That way, when requests are received into the queue, they arrive in a consistent structure, in a way that makes sense to your team, and in the format that allows for efficiency and prioritization. Asking for someone’s residency by country or state, for example, can help you quickly prioritize a GDPR or CCPA request, or efficiently reject a request where no such rights exist.

Another good question to ask is “how do we manage and maintain templates to ensure we send a consistent, accurate and approved message to external parties each and every time?”

Templates can speed up efficiency if you have a high volume of requests to work through and need to respond to each with the acknowledgment for acceptance, or an outright reject decision. A template response can be sent to the requester to explain the legal decision to proceed or reject, the rationale for the decisions, as well as any further information that may be required to satisfy regulatory requirements (privacy notice links, etc.).

4. Identity Verification: Not Just a Box Ticking Exercise

Just like in the accept/reject evaluation phase, identity verification should have clearly defined procedures for all external-facing teams who may perform it, including Legal and Privacy. A common solution that works well both internally as a procedure, and externally for the data subject, includes presenting options to requesters (e.g., a health insurer may allow a customer to provide three out of four from policy number, date of birth, phone number, and policy activation date). This can also be coded into a CRM to capture what evidence was provided to verify identity, for regulatory audit purposes and internal assurance.

It is also recommended (and required in certain instances) to only verify identity using data you already hold about the data subject that was collected legitimately as part of your relationship with them. If you are asking them to provide additional data to verify identity, such as government ID that you didn’t already hold, make sure there is a strong business case, and an assessment has been done to balance the need for this against the rights and freedoms of the requester.

Note that evaluating a request’s legal basis is different from identity verification. For example, in evaluating a request made by a third-party law firm on behalf of their client, we need to ask both whether the client has the legal basis, and whether the law firm has legal basis to act on their behalf. Neither of these steps is identity verification – both are evaluating the legal basis of the request, even if it may involve some kind of document exchange from the relevant parties to prove their relationship (e.g., receipt of a notarized authorization form, or similar).

Both legal basis evaluation and identity verification need to work hand in hand as part of a successful DSR response. If either isn’t executed according to your requirements, it can lead to an unauthorized disclosure and possible data breach. If either is done too late, it can waste time and resources in data gathering and other internal tasks, where a simple rejection and privacy notice referral may have been a preferable decision from the outset.