The European Union (EU) General Data Protection Regulation (GDPR), the successor to the Data Protection Directive, is generating a lot of interest from the security community. Enforcement is slated to begin in May 2018, and those exhibiting non-compliance can expect stiff financial penalties. In the meantime, companies should revisit their security and compliance strategies to ensure they’re prepared to meet GDPR requirements.
Non-EU companies and entities may believe that the GDPR doesn’t apply to them, but it may. GDPR requirements apply to any organization doing business in the EU or that processes personal data originating in the EU, be it the data of residents or visitors. So organizations of any size in any country that process data—if that data originated in the EU—is subject to the GDPR. The borderless realms of the internet mean that companies not intending to control or process EU-sourced data could find out they are subject to GDPR requirements.
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). It’s 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 organisational 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).
The controller must also implement technical and organisational measures to ensure that by default it only processes 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 state of the art technology evolves. The key provisions can be summarised 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
If there’s a breach of personal data, the controller must 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 also 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
Similarly to Article 33, Article 34 requires that the controller notify the person affected by the 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 materialise
- 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.
In conclusion, it’s imperative that businesses of any size explore the GDPR extensively to make completely sure that their data protection measures are in compliance. The new legislation is designed to protect the interests of consumers, but keeping on top of it can help to protect the interests of businesses too!
Spencer Young, RVP EMEA at Imperva.
GDPR Summit London is a dedicated event which will help businesses to prepare to meet the requirements of the GDPR ahead of May 2018 and beyond.
Further information and conference details are available at http://www.gdprsummit.london/