GDPR Top Ten #9: Security and breach notification

Modern security thinking

Once upon a time, security meant that you had a firewall to keep the bad guys out, and that every user had a password of no less than six characters to make sure their accounts could not be compromised. Those days are long gone. We now know from modern security thinking that taking only preventive measures (like firewalls and passwords) are no longer enough nor efficient. Security these days means you are able to prevent your digital assets from being compromised, but also able to detect when something threatens them and able to respond to incidents to bring the situation back to normal.

Now in the General Data Protection Regulation (GDPR) the security section has been much extended when compared to its predecessor, the Data Protection Directive. Security is now described in three articles (art. 32, 33 & 34), instead of one (art. 17), and it has been extended with breach notification obligations. Taking a closer look at Chapter IV, Section 2 of the GDPR, what does it actually say?

Secure the data you process

Under the regime of the GDPR you still have to make sure that you properly secure the personal data you process. The basic description of how to do so is unchanged compared to the definition in the Directive. Security is again described as a risk management process: you should first assess the risk, then look at what is possible in terms of security, and after having balanced risk versus costs, define your security measures. Nothing new there, and by the way: proper information security has always been that way. There are however some aspects to take into account.

• First, there is the notion that you should asses the risks for the rights and freedoms of natural persons, and not, say, the financial risks your organisation might face when the security of personal data gets compromised. You can of course include the latter, but including the former is a must. Security risk assessments regarding personal data should at least consider the impact of security failures on the individual – all the rest is optional.
• Second, the GDPR gives a number of examples of security measures. Pseudonymisation¹and encryption of personal data are suggested as good security measures, as is the fact that security is about the Confidentiality – Integrity – Availability-triad and about being resilient to disruptions. Further, disaster recovery and having processes in place to regularly assess the state of your security measures are also suggestions given.
• Third, security is no longer the responsibility of the controller alone. The processor is addressed as well in the security articles of the GDPR. The processor now has an obligation to apply proper security measures independent of the controller. This also means processors can be addressed directly by the supervisory authorities when their security fails and are no longer shielded by the controllers.

¹The GDPR defines pseudonymisation as “the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information.”

Breach notification

New in the GDPR is the notion of breach notification: in case (preventive) security measures are breached and personal data is unlawfully processed, the controller must report such a breach to the supervisory authority within 72 hours, and possibly to affected data subjects as well. This is the case unless you can establish that the breach has caused no actual risks for the data subjects or other individuals.

Although new in the GDPR, this breach notification requirement is a well-known mechanism. It has been part of the ePrivacy Directive for some time now, meaning that telecommunications companies in the EU already deal with this on a daily basis. Also, a number of countries, the Netherlands among them, currently have breach notification obligations. As a result, numerous guidelines have already been published on how to establish whether a breach is severe enough to require notification, and if so, how breaches should be notified.

Having said all this, in case you do suffer a security breach (and it is not a question of whether it will happen to you, but when), breach notification should not be at the top of your mind. Responding to the breach should be, taking into account all actions that need taken care of: fighting possible intruders, establishing extent of the damage and restoring the situation back to normal. Notifying the breach to the supervisory authority is one of the elements of your response, but probably not your first.

To make sure that breach notification is properly executed, it should be firmly embedded within and throughout the whole of your security incident response plans. And, as with all other response processes, for breach notification a sub-process should be defined, including roles and responsibilities, process description, checklists, etc. This has the added advantage that, when security response plans are practiced (you do practice, don’t you?), breach notification is automatically taken into account, as it should be.

Outlook

What does this all mean? Should you now encrypt and pseudonymise every little snippet of data you processes? Should you redefine your entire incident handling processes making it revolve around breach notifications? No, that would be the wrong reaction.

You should resist those urges and keep acting like you always did (or should have done): make sure you perform proper risk assessments and then define your security measures based on these assessments. Address technical and organisational security measures and importantly, measures in all three areas of prevent, detect and respond. Lastly, part of your response measures should include the breach notification processes.

In the end, if you already run an effective and efficient security organisation, the GDPR tells you to keep up the good work. If you are not quite on that level yet, the GDPR encourages you to get up there. All with the end goal in mind: if you want to be trusted with other people’s personal data, make sure you deserve that trust by properly securing it.