In the run-up to May 25, 2018, many businesses that thought they were well-prepared to meet their new General Data Protection Regulation obligations discovered that operationalizing many components of a GDPR-compliant privacy program requires more than simply drafting a new or updated set of policies and procedures. With GDPR now in full effect, these businesses are quickly realizing that truly effective GDPR compliance is a highly complex undertaking requiring active, cross-functional collaboration between privacy and information technology. In instances where businesses struggle to operationalize key compliance components (e.g., response to data subject rights requests, revocation of consent), they should consider developing “functional requirements” that provide specific, detailed guidance to the privacy and IT teams to fully meet their GDPR obligations.
Functional requirements sit at the intersection of privacy and IT and go deeper than business-oriented standard operating procedures to truly operationalize the regulatory, industry and business requirements reflected in procedures. There are two distinct phases in the functional requirements process:
- Phase 1: The privacy team must draft the functional requirements to set out the details of specific GDPR and other applicable requirements.
- Phase 2: The privacy team must work in collaboration with the IT team to gain initial verification of the feasibility of implementing the functional requirements. It is often during this second phase of active and engaged discourse between teams that new solutions and automated processes are developed to enable the organization to meet its GDPR (and other) privacy obligations.
Phase 1: Drafting functional requirements
In order to draft functional requirements that will enable effective compliance, the privacy team must understand and communicate full details of the applicable requirements to the IT team. For example, for an erasure request under GDPR, the privacy team must clearly convey in the functional requirements that erasure is not limited to deletion of an entire record (which may be difficult for some businesses due to system infrastructure). Rather, an erasure request can be fulfilled by anonymizing a record or anonymizing or deleting only those fields that could be used to identify the individual. In addition, the functional requirements should indicate that certain requests, such as erasure or rectification, must be communicated out to third parties processing the requestor’s personal data.
Functional requirements for fulfilling access requests must be similarly specific. For example, they must consider the extent to which the IT team must search within the company’s systems to find and then provide personal data responsive to the request. The privacy team must then determine what personal data will meet the requester’s expectations, what will be practical to operationalize and what will effectively mitigate regulatory risk. The functional requirements will ultimately indicate whether the response must include every bit of personal data that can be found or whether a core set can be defined that will satisfy requestor expectations and contain regulatory risk. Similarly, the privacy team must consider, in instances of requests such as rectification or erasure, how far out to third parties the changes must be communicated. While GDPR may not put any limits on this, practical considerations and risk mitigation must be taken into account.
In addition to requests for access, rectification and erasure, functional requirements should be drafted — depending on the business, the nature of processing and the legal basis for processing — to operationalize processes for objection to processing, restriction of processing, data portability and revocation of consent.
Phase 2: Teaming with IT for operational functional requirements
Once a draft of the functional requirements has been prepared, the privacy team should seek input from the IT team to gain initial verification of the feasibility of implementing the requirements. The IT team will be critical in this phase, contributing potential solutions to automate or otherwise streamline processes to meet applicable obligations, as well as to help make determinations regarding the depth and breadth of the necessary actions (inside and outside of the organization). Some determinations may also need to be made by IT regarding whether specific technologies will be necessary to effectuate the functional requirements. For example, where anonymization is selected as a solution for an erasure request, IT will need to evaluate and recommend a technology solution. They may need to evaluate factors such as whether the anonymization tool can preserve the relational integrity of the data, once applied, as well as ensure the data is rendered truly anonymous.
Revocation of consent provides another example of a GDPR requirement for which IT contributions will be critical, as effectively responding to a consent revocation can pose a significant challenge depending on the nature of the business and the complexity of processing activities. To effectively prevent the further processing of personal data after receipt of a revocation of consent, privacy and IT teams must work together to place appropriate controls on the personal data in question across all processing activities to which the revocation applies. If an individual revokes consent to processing for marketing activities, for example, that revocation must be effectuated in a manner which will prevent further processing for all current and future marketing activities, potentially across multiple areas of a business. If an organization has a need to keep this individual’s personal data in its systems (e.g., for tax reporting purposes or due to a litigation hold) this may require very finite controls that enable processing for limited purposes, but not for anything that would directly or indirectly lead to their receiving any further direct marketing materials.
While the intent of the functional requirements document is to reflect the requirements of applicable regulatory requirements and internal policies and procedures, the privacy and IT teams, and IT developers in particular, should look at operationalizing the functional requirements as an opportunity to develop new and innovative approaches to meeting GDPR and regulatory obligations. Automation and innovation opportunities may arise, for example, in creating solutions for:
- Self-service portals for making data subject rights requests and validating identity.
- Self-service portals for viewing personal data (access) and updating incorrect information (rectification).
- Automated search and “data pull” functions across databases and applications.
- Automated tracking of request responses and documenting of fulfillment.
Process flows for clear steps and common language
The functional requirements should not only include narrative instructions, but also process flows so that team members who will be operationalizing the requirements have a visual map of what must take place to fulfill the obligation. Process flows should indicate key decision points (e.g., whether to erase or anonymize and whether to do so against entire records or only certain fields) and should provide clear direction to the next steps in the process. And while the process flows cannot contain the level of detail included in the narrative description of the requirements, they represent a common language and a guide that can be readily understood by technical and non-technical contributors alike.
Live runs
Even the most carefully drafted functional requirements should be considered draft until they are put to use against real-life activities, such as data subject rights requests and consent revocations. It should be fully expected by the privacy and IT teams responsible for responding that the functional requirements will be further refined through active application. In fact, these “live runs” are critical for testing the functional requirements and adding even more granularity that cannot be reasonably anticipated by individuals drafting documents on their laptops. Only after applying the functional requirements to a set of live runs and making appropriate refinements can the requirements be considered final and ready for use on an ongoing basis.
Operationalizing complex regulatory requirements, such as those in the GDPR, is a highly challenging exercise, and businesses are finding that merely training staff on the policies and procedures drafted in anticipation of GDPR is not sufficient to operationalize these procedures. Functional requirements that are the product of collaboration between privacy and IT teams provide a highly useful tool to accomplish compliance goals. Not only do they address requirements with the requisite breadth and depth, but — if applied to actual “live” activities such as data subject rights requests — provide the teams an opportunity to apply the functional requirements, determine where adjustments are required, and make those adjustments to create a robust and detailed GDPR compliance roadmap that can be successfully applied going forward.
photo credit: Nicholas_T via photopin