3 GDPR Security Requirements You Need to Set Up

This blog series focused on the GDPR has walked you through the various obligations under the GDPR that make up these new regulations. The GDPR comes into force in May 2018 with potential fines of up to 4% of global turnover.

We’ve talked about when it applies; what PII vs. personal data means; what consent and sensitive data encompass; how to ensure data processing activities are lawful and how new data rights need to be addressed under the GDPR (hint: focus on article 30 for starters!).
This post addresses GDPR’s security requirements you need to fulfill when personal data is being processed.

Building on top of existing security best practices

Most of you will probably be familiar with existing security practices such as those encompassed by the CIA triad, which stand for Confidentiality, Integrity and Availability. Typically, these concepts are part of classical SLAs, where uptime and recovery are verified as a percentage, ideally as close as possible to 100%.

Recently, the security community has also focused on adding a ‘T’ to the acronym, bringing it to CIAT. The ‘T’ is for traceability which refers to the audit trails required under article 30 of the GDPR.

Beyond the triad, the GDPR refers to codes of conduct, to be ideally defined per sector, as well as certification mechanisms.
The slide below highlights the certifications Microsoft Azure has put together so far:

From https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings

Security of processing also highlights the need for pseudonymization techniques on top of encryption.

Pseudonymization explained

There seems to be some confusion about what pseudonymization exactly means and what the consequences of undergoing such data transformations will be.

First up, the GDPR defines pseudonymization in article 4.5:

“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”

We need to satisfy two conditions to consider personal data as pseudonymized:

1. separation of the UIDs from personal data
2. both data sets need be secured, hashed for example, while access should be restricted to make re-identification as unlikely as possible

Note that all this needs to be documented to prove accountability. This is highlighted in the 2nd paragraph, article 5 Principles relating to processing of personal data: “The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).”

Secondly, note that pseudonymization does not mean that no privacy obligations apply. The GDPR gently reminds us at the end of recital 28 that: “The explicit introduction of ‘pseudonymization’ in this Regulation is not intended to preclude any other measures of data protection.” And this can be a chicken and the egg conundrum as you would still need to assure that processing of personal data is lawful.

Data Breach Notification within 72 hours

While most companies will have some form of security best practices, what’s really new in the GDPR is the obligation to report a data breach to the supervisory authorities within 72 hours.

Most organizations will therefore need to set up alerts to not only passively review security procedures, but also effectively wake someone up in case of trouble during the night.

Once detected, the affected organization should also set procedures in motion to correct these security issues, decide whether to declare a data breach, and document their decision.

It’s possible for a data breach to be detected and yet not lose any personal data. There is therefore a gray area between noticing an anomaly and recognizing that a notification should be sent out. That’s what those 72 hours should be used for, checking thoroughly before setting in motion the “notification playbook.”

Additionally, once reported to the Supervisory Authorities, it is possible that they will require a communication of a personal data breach to the data subject. These obligations are laid down in article 34 of the GDPR.

We need an additional playbook, one that includes the communication department, the Data Protection Officer, legal counsel, and the previously mentioned security teams.

Data Protection Impact Assessments (DPIAs)

On top of breach notifications, the GDPR also introduced obligations related to data protection impact assessments (DPIAs) “Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons”, as explained in detail in article 35.

DPIAs, also called privacy impact assessments (PIAs), are starting to become common practice. The challenges in setting-up impact assessments are twofold:

1. the actual questionnaire: which questions to ask and how to write them clearly, in an easily understandable way
2. the workflow surrounding the scoring of said questions, involving the right intermediaries to assure adequate mitigation methods to limit risk.

The market is also still trying to figure out how to deal with the fact that these assessments are rather static, typically done once when a new tool is acquired for digital measurement. However, our environments tend to be dynamic. A fact highlighted by the continuous misalignment between privacy policies and tools used to optimize digital endeavors.

If not sure, reach out and ask Supervisory Authorities!

While the GDPR seems to contain only obligations for companies, there is also a lot to be said about how the regulating authorities need to align to the demands of the market. The current Data Protection Authorities (DPAs) will become Supervisory Authorities (SAs) in May 2018.

Not only will the Article 29 Working Party be replaced by the European Data Protection Board (EDPB), local authorities will also have to collaborate. They will serve as a consultative party where “processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk,” as stated in article 36 on prior consultation.

This doesn’t mean one should expect SAs to give companies exact instructions on how to move forward. Yet a collaborative mindset, where we all share best practices, is to be encouraged and is certainly in the spirit of the regulations. Once you appoint Data Protection Officer (DPO), it makes sense to contact the Supervisory Authority right away to start to build a solid relationship. We’ll discuss this further in the next post.

GDPR security requirements – final thoughts

Summing up, when it comes to security and data protection, your IT team should collaborate with other departments to build this paradigm of data handling into their existing practices. They need to set up data breach notification processes, be involved in data protection impact assessments, and not be afraid to reach out to Supervisory Authorities to align security best practices.