If you hadn’t have noticed we are now in an era of a final approved text of the long awaited General Data Protection Regulation. What exciting times we live in. My previous blog posts so far on the Regulation have talked about the principles as well as a general overview. Tonight Pinky, we are going to explore the GDPRs concept of breach notifications and what this may mean from a practical perspective (and then we will of course try to take over the world).

But first, if you’ve not downloaded the GDPR text app for your phone I highly recommend it. As a bit of a geek about such things I find it amazing that I can carry round a copy in my pocket and read at my leisure.

The most obvious starting point is the new legal requirements to notify both the supervisory authority as well as the data subject should personal data be ‘breached’. Article 4 (12) of the GDPR outlines a Personal Data breach to be “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.

Chapter 4, Article 33 (1) states that once a controller has become aware of such a breach (definition of aware not clear) the controller shall “without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority”. As the definition of ‘aware’ is disPicture1tinctly lacking I can see scope for a rise in ‘hear no evil, see no evil, speak no evil’. As it is many DPOs and compliance officers struggle to be made aware of such incidents so if the definition is going to be similar to that or making SAR or FOI requests whereby ‘notice’ can be given to anyone in the direct employ of that organisation this isn’t going to help us DPOs.

So when the business has finally informed you of this incident (or you’ve been lucky to capture it first hand) what does the GDPR ask you to provide the authority in your notification? Chapter 4, Article 33 (3) (a-d) states;

a) The nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned.
b) Communicate the name and contact details of the data protection officer or other contact point where more information can be obtained.
c) Describe the likely consequences of the personal data breach.
d) Describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measure to mitigate its possible adverse effects.

Starting with point (a), this could be a little more complicated than first impressions. This also relates back to the Article 30 requirement on records of processing activities. Article 30 requires Controllers to have an accurate and up to date list of what Personal Data they have, why they have it, where they have it and to whom they share it with (I’m paraphrasing there but you get the gist). When building that list if you can include references to the types of records you have should an incident occur and X record types are concerned you know immediately what personal data they contain and indeed if the personal data records are likely to identify more than one data subject per record.

To help manage this requirement if you are a DPO and don’t know who your records manager is, now is the time to find them and talk to them about the types of records you own. If you don’t have a Records Manager, then Records Management is about to become a big thing for you so I would see if there is merit in getting one (or looking at it yourself).

Point (b) is fairly self-explanatory and there is scope both here and in the Codes of Conduct provisions in Section 5 Article 40 (2) (i) that allow for a supervisory authority to encourage codes of conduct for how breaches are reported to both the supervisory authority and data subjects.

Point (c) is interesting as it specifically says the ‘likely consequences’ of the disclosure. Logically, if you don’t have an accept risk management practice in your organisation, then in order to manage this requirement (and not report absolutely every possible outcome) you’ll need an agreed way to manage information risks, determine their impact likelihoods and their consequences. I suspect that as we progress with the GDPR implementation we will see some common guidance from authorities / the Data Protection Board on what are generally accepted as likely consequences and what are not.

In order to fully meet and understand point (d) you’ll need (again logically) to demonstrate some sort of route cause analysis so you can say X caused Y and it will be mitigated with Z process changes, A actions with the data subject and B actions with the staff member (s) concerned.

Now this requirement does state that this information can be provided at a later stage but a general notification must be provided and it doesn’t state what an acceptable timeframe might be. One assumes that as the DP Board is allowed to clarify and fine tune this requirement, as well as Article 40 allowing for Codes of Conduct which can cover breach notification (as well as a few other areas).

In summary then, in order to start getting into the practice of effective incident management not only will you need a robust reporting and monitoring framework for incidents but this must also form part of a risk management framework for your organisation. If you have a well-established method for determining risk (and indeed likelihood of outcomes) the breach requirements here aren’t therefore that much of a massive headache. Yes they will be complex as incidents often are but at least you have a decent framework in place to help steer your incident management in the direction you need.