GDPR – Key Data Security Requirements

This is Part 2 in a 4 part series of posts that will help to educate you on GDPR, including who is affected, key requirements, implications, preparedness, and potential penalties. Continuing on from Part 1 – who is subject to the GDPR, in this post, we will explore the key requirements that pertain to data security. The following information is powered by one of our security partners, Imperva.

The actual text of the GDPR is an imposing document, 88 pages consisting of 99 Articles. In an effort to help more easily digest this information, this post summarizes the most important articles and provdides relevant examples from a data security perspective.

Article – 5, Processing and storing personal data: Details the basic rules data controllers must follow to protect personal data. All personal data must be processed lawfully and transparently, and only for the purpose specified to the individual. That data may be stored “in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed.” All personal data must be processed securely to protect against unlawful access, loss or damage “using appropriate technical or organizational measures.” Those measures are not defined, but presumably if the data is lost or stolen, a company could be considered not in compliance.

Articles – 6, 7 and 8, Consent: All processing of personal data must be done lawfully, by which is meant that each individual must give consent to use their personal data. The data collected must also be necessary to complete a task or transaction initiated by the individual, with the exception of public authorities.

Article 15 – Right to access:  EU citizens and visitors have the right to know upon request what personal data a company is using and how it is being used.

Article 17 – Right to be forgotten and to data erasure: EU citizens and visitors can expect companies to stop processing and to delete their personal data upon request.

Article 20 – Right to data portability: EU citizens and visitors may transfer their personal data from company to company upon request.

Article 25 – Data protection by design and by default: 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” (i.e., make it difficult to link a given data record with the identity of a person).

As an example, your employee ID may have an 8-digit format such as “PE-43-6978.” Pseudonymization changes the numbers but maintains the 8-digit format. Thus, in the example above, the “masked” employee number could become something like “PE-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, your company only processes the personal data that’s needed for a specific purpose (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 specific 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 appropriate extent, taking into account the costs, 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
  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: Requires companies to report breaches to authorities:

  • 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: 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, 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: 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.

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

Part 3 of this series will take a closer look at what the GDPR means to organizations & how to prepare.

For a free GDPR data security consultation, contact one of our security experts here.

Subscribe to get the latest IT trends, news and advice, right in your inbox

This field is for validation purposes and should be left unchanged.

Ready to take your IT infrastructure to the next level? Talk to StrataCore today.

Skip to content