Organizations subject to global privacy regulations spend what often seems an exorbitant amount of time and resources to reach compliance objectives and keep up with constantly evolving privacy requirements. Data subject requests have become a prominent privacy program component. As data subject rights expand to new countries and new individuals, well designed processes for responding to requests must be implemented to avoid overburdening your organization.
Individual Rights: Being Prepared to Respond
Data subject requests (e.g., requests for access, rectification and deletion) have become unavoidable due to businesses’ reliance on digital personal information in our global online economy. Developing a data subject request response process poses a series of challenges – even when using privacy automation tools – which includes balancing business needs with regulatory requirements, developing policies and systems that are efficient and compliant with applicable regulations, and consistently training internal teams and stakeholders to assist with the processes implemented.
Organizations can effectively prepare for data subject rights under US state and federal regulations, as well as EU and other ex-US data protection laws, by creating data subject request response process workflows. Process workflows are visual representations of the internal response process which anticipate the types of data subject requests that may be received and details the step-by-step process for handling such requests.
Recognizing the Benefits of Data Subject Request Process Workflows
Data subject request process workflows that are thoughtfully developed lead to cross-functional benefits that improve the privacy function’s ability to effectively respond to data subject requests. These include:
- Cross-Functional Collaboration in Developing the Response Process: In order to develop a process workflow, the privacy team collaborates with other internal groups to make key decisions about how the response process will function. This includes simple choices such as the type of request intake mechanisms that will be implemented or specific language to be used in responses, as well as key strategic and compliance-oriented decisions such as the applicability and use of available exemptions. Utilizing process workflows facilitates that conversation in a thoughtful way prior to implementation, avoiding hasty decision-making when requests are received.
- Response Templates: Well-developed and drafted process workflows serve as updatable templates that can be modified as processing activities and third parties change. These workflows also serve as models for response processes for data subject rights in new laws and regulations, an important consideration as US states consider adopting laws similar to CCPA.
- Transferable Guidance: Process workflows provide detailed visual guidance on the specific actions that stakeholders responding to data subject requests must take when the response process reaches their function or role. Should the stakeholder change or the role otherwise transition, the new stakeholder is able to use the workflow to easily ascertain actions required to fulfill a request. For example, a well-designed process workflow will indicate the owners (individuals or roles) of databases, applications or third party relationships involved in a processing activity, allowing a new owner of that role to see precisely what they must do in order to support the effective response to a data subject request.
- Streamlined Implementation: Many organizations rely on software or tools that seek to automate responses to data subject requests. While some of these tools are working toward fully automating responses, they typically require some level of manual process in order to effectively respond to requests. Even automated tools require consideration of whether exemptions apply to requests from certain classes of data subjects. Or, in many instances, the tools require stakeholders to identify where the personal data in question flows within and outside of an entity’s network. Process workflows facilitate efficient implementation of these tools, as all steps are planned and visualized thoughtfully in advanced, minimizing the need to alter or redesign the organization’s instance of the tool.
Taking Inventory of Your Data to Build Your Privacy Program
Before an organization can implement processes to comply with applicable regulatory requirements, stakeholders must ascertain where in-scope personal data is stored and processed (inside and outside of the organization). They must also identify the functional roles or specific individuals responsible for those processing activities and supporting systems, databases and applications. The need for data inventory and mapping exercises has been well documented in recent years, particularly in light of the requirement for Records of Processing under GDPR. With regard to fulfilling data subject requests, mapping must be completed in order to establish the foundational view of personal data to support the development of data subject request process workflows.
Developing Data Subject Request Process Workflows
Having completed data inventory and mapping exercises, an organization will have established the necessary foundation to begin developing process workflows.
The Process Workflow Team: The process of designing process workflows requires cooperation and involvement from the privacy team, IT department, legal, and business owners responsible for databases, systems, applications and third parties within scope of the request. The privacy team generally is responsible for facilitating the collaboration between the teams and collecting the required information to design a comprehensive, yet practical response process. The legal team should be consulted regarding applicable exceptions and exemptions and can assist with drafting language for intake forms and template responses. The IT team will assist with the technical process for identifying, retrieving, modifying, compiling, or deleting data and, depending on the organization, can automate such processes as well. Business owners provide support by identifying databases, applications, systems, and third parties that may contain data within scope and designating the individuals who will retrieve personal data necessary to respond to requests.
Establishing Components of the Process Workflow: A process workflow that will effectively support appropriate management of data subject requests will include the following components:
- Request Intake and Verification: Regulations that grant data subject rights vary in the degree to which they address the methods for submitting rights requests. GDPR, for example, provides broad language that organizations should not make it “unreasonably or disproportionately difficult” to make a request. CCPA is more specific and requires a toll-free number and “Do Not Sell” links on websites. Prior to documenting an approach in a process workflow, organizations should consider all in-scope regulations and determine whether a single workflow will suffice, or whether separate workflows would more clearly address different regulatory requirements. The process workflow should reflect each step in the verification phase, including (as appropriate):
- initial communications to the requestor;
- validation of residency (e.g., California or EU), which may include requests further identification, types of acceptable identification and limitations on unacceptable identification;
- assessment of applicable exemptions; and
- steps for invalid requests, which should include communications back to the requestor.
Verification of the validity of the request comprises one of the more important aspects of what is documented in this phase of the process workflows, as it potentially limits the efforts downstream. Strategic decisions should be weighed during development of this phase of the workflows. For example, an organization may choose to verify data subject residency in order to limit CCPA requests to California residents or take a more consumer positive privacy position and honor all requests regardless of residency and in anticipation of likely new laws in the coming months and years.
The process workflows must also account for variances in verification steps depending on factors such as the sensitivity of the data requested or the complexity of the databases. While in some cases appropriate verification may be as simple as clicking through an authentication email, in more sensitive cases, it may be appropriate to require that the data subject send a copy of government-issued identification. Where the latter is the case, the process workflow should require and clearly indicate that copies of the identification must be deleted after verification.
Exemptions analysis is another critical component of the initial phase of the process workflow. If exemptions apply, the request can be rejected at the outset, eliminating the bulk of the effort associated with most requests. In order to depict the necessary steps in the workflow with regard to the exemptions analysis, the privacy team (perhaps in collaboration with Legal) must identify all exemptions which may apply to incoming requests, depending on the characteristics of the business (e.g., CCPA’s GLBA exemptions for financial services entities). In cases where an exemption does apply, the workflow should reflect steps requiring documentation of the applicable exemption and notification to the data subject of the reason that their request is being rejected. It’s important to note that in addition to exemptions that are explicit in a given regulation, consideration should be given to internal factors such as legal holds, or tax and finance needs.
- Databases, Systems, and Vendors: The level of complexity of the process workflow will vary greatly based on the sophistication of an organization’s information systems and data stores. There are two areas in the process workflow in which databases, applications, and vendors must be identified:
- Verification of Processing of Requested Personal Data: Upon verifying that a request is valid, the organization should query their databases, systems and applications that process personal data to determine whether the data subject and the requested data exist within the systems. This occurs after initial verification of validity of the request, as it requires the time and effort from additional resources. Remember that the objective of this step is solely to verify whether personal data of the requestor is being processed by the organization. If it is not, a communication should be sent to the requestor informing him or her that their personal data could not be found and that the request is being closed. Such communications should inform the requestor that he or she has the option to provide further information, if they believe that this will help to find data that they believe the organization possesses.
Keeping in mind that the objective of this phase is only to verify the existence of the personal data in order to determine whether to move forward toward fulfillment, the focus should be on any centralized data store or primary source of truth. For example, a central data warehouse may be an appropriate place to look to verify whether the requestor’s personal data exists on an organization’s systems. Or perhaps a central CRM system will comprise a reasonable place to search to establish whether the data is present. For the workflow, this step should depict the minimum number of databases, applications or systems required to complete the verification. A more in-depth depiction of databases, applications, systems and third parties will be required in the fulfillment stage.
- Fulfillment: Fulfillment is the final phase of the data subject request response process workflow, prior to notifying the data subject of the disposition of their request. Fulfillment must consider the specific type of request under which regulations, and should depict all databases, systems and applications to be queried. This will include service providers or vendors about which the data subject making an access request must be informed, or service providers or vendors which must be informed of a deletion request. The complexity of this step varies in line with the complexity of the organization and processing activities, as well as the type of request. For example, a deletion request to an organization with multiple internal databases, SaaS systems and dozens of vendors will require identification of all of these various data stores in the workflow so that deletion and notification to each vendor (as appropriate) can occur.
- Template Responses: The privacy team (in some instances with input from Legal) should work to anticipate the possible result of each phase of the process workflow and develop template responses for each scenario. These responses should be depicted in the process workflow at the point in which such response will be required. The workflows should also indicate the role or individual that will be responsible for communicating the response (e.g., the business owner or privacy team). These template responses should address all necessary data subject request communications, such as:
- Confirming receipt of a request;
- Requesting additional information from the data subject;
- Rejecting a request, including the basis for rejection;
- Confirming full or partial completion of the request;
- Notifying a third-party system owner or service provider of their obligation to honor a request; and
- Communicating an extension of time to honor the request (including and the basis for the extension).
- Timelines: Process workflows should indicate the timelines in which activities for each phase must be completed. Regulations may not be consistent in the rules driving required timing of responses. CCPA, for example, requires confirmation of receipt of a request within 10 days and complete response within 45 days (with possibility of a 45-day extension). GDPR, on the other hand, does not require a receipt confirmation, but requires fulfilment of a request within 30 days.
Since the response processes are comprised of multiple stages, and because layers within those stages require participation of multiple parties, the privacy team must determine appropriate timelines for each phase. The specific phases within the process workflows will commonly include request intake, data subject validation, data verification, exemption analysis, fulfillment, and communication with the data subject. Timelines should be realistic and approved/accepted by the business owners and other stakeholders. The timelines are commonly slightly shorter than regulatory limitations, to allow for unexpected delays. Once all of the above elements have been identified and communicated to relevant stakeholders, the privacy team can incorporate them into a visual process workflow.
Conclusion
Putting in the time to develop complete and detailed process workflows for each type of data subject request will set up the organization with a repeatable process that can be updated in accordance with evolving regulatory requirements. Data subject request process workflows provide an opportunity for the privacy team and data governance leaders to collaborate in developing a holistic process that can be easily followed in analyzing and fulfilling requests. For organizations implementing an automated tool to support responding to data subject requests, process workflows provide a blueprint of the remaining manual tasks for operational or technical stakeholders. Properly updated and maintained, these workflows can serve as effective response support tools for years, as they are easily modified to accommodate new requirements.
0 Comments