The GDPR has established strict rules for how organizations must approach processing of personal data. One of the law’s key requirements is to implement Data Protection by Design (DPbD). DPbD essentially compels organizations to adopt a Privacy by Design (PbD) approach to the design phases of their technologies and business processes. If your organization has not yet done so, you’re nearly a year too late - GDPR turns one year old on May 25th.
The trouble is, while the GDPR is specific about the need to implement DPbD (as well as potentially applying severe penalties for GDPR non-compliance), it doesn’t provide specific guidance. Fortunately, there is a simple process that any organization, no matter its size or industry, can follow to demonstrate compliance and improve the bottom line.
Article 25 of the GDPR describes a company’s obligations concerning “data protection by design and by default.” It includes language such as “the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures […] and […] integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation.”
Translation: you must consider privacy and data protection issues at the design phase of any product, service or process, be sure to continue doing so throughout the lifecycle of same. Also consider technical, not just procedural, controls.
Unfortunately, the European Supervisory Authorities have yet to issue practical guidance on what exactly organizations need to do to comply. A lack of specific recommendations may make prioritizing PbD in your organization a challenge.
Of course, GDPR’s penalties for non-compliance should provide adequate motivation however it is not clear yet how they will be enforced. However, there are also business benefits for implementing PbD.
Organizations that perform only fairly routine, lower risk data processing will benefit from a lightweight DPbD process that ensures their products meet basic GDPR requirements. The costs are unlikely to be disproportionate and the process also help avoid potentially costly mistakes.
In line with the GDPR’s risk-based approach, a more elaborate DPbD process is required when an organization’s data processing potentially poses high risks to individuals. The process should identify specific privacy risks to individuals and identify technical and organizational safeguards for their mitigation.
The European Data Protection Board recently released comments on lists of criteria by national Supervisory Authorities that may indicate higher risk processing for organizations (and if fulfilled, necessitate a formal Data Protection Impact Assessment.) For example, companies that process sensitive data such as health information, engage in systematic monitoring of individuals, or utilize newer technologies such as AI, Blockchain, and IoT should build a DPbD program capable of addressing the inherent privacy concerns.
Once you make the decision to embrace PbD, what’s next? Here is a basic DPbD process that should work for most organizations.
First, because the Corporate Privacy Team (or the individual owning privacy as part of his responsibilities) will likely drive the DPbD review, it is useful to design a standard review template and share it with the product teams. It should be made clear that it’s the product team’s responsibility to fill out this form. The template has three parts:
- A detailed description of the product (or process), the categories of personal data processed, the purposes of processing, and a data flow diagram that describes the components of the system where data is processed or stored and how data flows among them.
- A risk assessment that identifies privacy risks to individuals. This is one of the most difficult parts and will likely require assistance from a privacy professional.
- Establish and support feasible privacy goals for your organization as appropriate and ensure with the review that they’re being met. If you decide to follow GDPR, Article 25 asks organizations to implement the “GDPR data-protection principles” (described in Chapter 2 of the GDPR) and to “protect rights of individuals” (described in Chapter 3). An example of the principles is that consent from the subject, where required, must be properly obtained. An example of rights is that users must be able to access their data or to obtain data they’ve provided in a machine-readable format (i.e. ‘data portability’).
There is a growing list of resources organizations can use to solve specific engineering tasks that come up during the review. For example, the International Association of Privacy Professionals (IAPP) offers UX (user experience) guidance on obtaining consent, and Forbrukerradet (the Norwegian Consumer Council) details “UX dark patterns” to avoid.
Be prepared to encounter obstacles. For example, if the DPbD reviews reveal privacy issues that require significant work by the development team, negotiations are likely needed with the privacy development teams. In these, development teams may cite tight release deadlines and limited development resources that will be tough to alter.
The traceability to GDPR requirements advocated in this DPbD approach, i.e., for regulatory compliance, gives the privacy team some leverage as it allows for answering the critical question of why development has to do this.
Securing full management and senior executive-level buy-in can also be difficult to achieve, but it too is a critical factor to the DPbD program’s overarching success.
Before the GDPR took effect in May 2018, organizations focused their compliance efforts on the most tangible and direct requirements such as updating vendor contracts, creating records of processing activities, creating policies and processes around data breach notification and addressing data subject access rights.
As we approach the GDPR’s first anniversary, now is the time for organizations who haven’t done so yet to embed privacy deeply into their business processes and fully operationalize Data Protection by Design. Following the approach described above, a basic DPbD process should be feasible even for organizations with limited resources devoted to privacy.