GDPR Series, Part 2: What Rules Require Data Protection Technology?

Continuing on from Part 1 of our GDPR series (Does the GDPR Apply To You?), in this post, we delve into the key GDPR requirements that pertain to data security.
The actual text of the GDPR is quite lengthy¹, but we’ve summarized the five most salient articles from a data security perspective.

Article 25 – Data protection by design and by default

This article requires the controller to implement appropriate technical and organizational measures to ensure that the data protection principles in the GDPR are met.
An example is pseudonymization (or data masking), defined as “the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person”[1] (i.e., make it difficult to link a given data record with the identity of a person).
For example, your employee ID may have an 8-digit format such as “DE-34-5678.” Pseudonymization changes the numbers but maintains the 8-digit format.  Thus, in the example above, the “masked” employee number could become something like “DE-12-9876.”  The better masking tools maintain statistical accuracy and table relationships so that applications don’t break.
The controller must also implement technical and organizational measures to ensure that by default it only process the personal data that’s needed for the specific purpose of the processing (i.e., process only what you really need to process).  Using the prior example of an employee ID number, the controller should not use the employee ID number in a company wide directory to identify an employee because that is not necessary to compile a directory of contact information and also not directly related to the purpose for which the ID number was assigned.

Article 32 – Security of the processing itself

While the GDPR was intentionally designed to avoid specifying technologies that could quickly become dated, Article 32 delineates data security requirements to consider as the state of the art evolves.  The key provisions can be summarized as follows:

• Controllers and processors must implement technical measures to the extent appropriate taking into account the state of the art, costs, and nature, scope, context and purpose of the processing and risk to the data subject:

(1) for the pseudonymization and encryption of personal data,
(2) to ensure that the processing systems and services are confidential, available and resilient,
(3) to enable access to data, including the restoration of access after an incident, and
(4) regularly test processes and technologies used to protect the data.
This article provides a framework for certifying entities as GDPR-certified.  While not yet available, such a certification will provide companies with a competitive differentiator and help minimize the risk of massive fines by demonstrating that companies are proactively protecting personal data.

Article 33 – Notification of data breaches to the appropriate regulator

There are a few notable provisions here:

• If there’s a breach of personal data, the controller must, if feasible, notify the appropriate regulator within 72 hours of finding out about the breach. If the controller is unable to do so, it has to provide reasons as to why it wasn’t able to meet the 72-hour requirement.
• The processor must notify the controller without undue delay when it discovers a breach.
• At a minimum, the notification must include the nature of the breach, type of data affected, approximate number of persons affected, approximate number of records affected, the name and contact information of the data protection officer (or other contact person), the likely consequences of the data breach, and the measures taken or proposed to mitigate the breach.
• Information can be provided in phases, instead of all at once, if the latter isn’t possible (e.g., if a resource cannot be found in time to produce a document regarding records that are in Slovenian, then documents pertaining to records in other languages can be provided first).

Article 34 – Notification of data breaches to the affected individual

Similar to Article 33, Article 34 requires that the controller notify the affected person of a data breach without undue delay if there’s a high risk to that person’s rights and freedoms.
The notification must be easy to understand and include the same information as what was provided to the regulator (see above).  Article 34 does provide some exceptions, however, so notification to individuals is not necessary if:

• The data remains secure via measures like encryption
• Subsequent measures successfully protected the data so that the risks to the individual is unlikely to materialize
• Identifying and notifying each impacted individual would involve “disproportionate effort”. In this case the controller must communicate the breach in another way such as placing an ad in newspapers and other news sources.

Article 35 – Data protection impact assessment

This article requires controllers to perform a Data Protection Impact Assessment (DPIA) when a new data process or processing technology is introduced and the processing is likely to result in a high risk to the rights and freedoms of individuals.  The controller must seek the advice of the company’s data protection officer (if there is one) when performing a DPIA.
At a minimum, the DPIA must include:

• Why the controller wants to add a particular processing operation
• An assessment of the necessity of the proposed processing operation
• An assessment of the risks to personal rights and freedoms
• Proposed measures to mitigate risks, including security measures that will ensure the protection of personal data

This requirement is more onerous than it might first appear.  For instance, to document and assess its data processing operations, a company will first need to fully inventory all the personal data it has, classify the data’s risk level, document its location, understand what systems access it, identify which users have rights to access that data, and then have a means to repeat this analysis on a regular basis.

More Information on GDPR

To learn more about the data security requirements of the GDPR as well as certification mechanisms, you can check out the following resources:
Actual text of the GDPR
GDPR codes of conduct and certification mechanisms

Other Posts in the Series

GDPR Series, Part 1: Does the GDPR Apply to You?
GDPR Series, Part 3: Preparing Your Organization for the GDPR
GDPR Series, Part 4: The Penalties for Non-Compliance
 
¹ Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016