Category: information risk

By Scott Sammons

Risk Management is one of the things that many people claim to know about. Often though, their lack of knowledge is exposed when they end up either focusing on the wrong risks or creating some complicated process that educates no one and leads everyone on a merry dance. And truth be told it can be quite difficult to understand; which may explain why people switch off it or create complex processes to support the basic principles of managing risk.

However, the future is here and managing risks to information is about to go from a reasonably unknown practice into a full blown framework and way to help manage your GDPR compliance. (And selfishly as someone that has done Information Risk Management for a few years now I can finally say, “Yippeeee!”).

The General Data Protection Regulation (GDPR) is going to be implemented in May 2018. Throughout the GDPR there are references to the capturing and management of data protection risks. Combine that with the need under GDPR to demonstrate compliance, and therefore demonstrate the management of risks to that compliance, we are likely to see a quick rise in Information Risk as a discipline / practice / skill.

‘Information risk’ up until today has been a varied discipline. If you were to Google the term, or speak to any recruitment agency they would say that Information Risk was the domain of ‘Cyber Security’. Currently, outside of the NHS toolkit, the only other country wide frameworks that make reference to information risk management is ISO27000 and 27001. But not everyone goes for these, or indeed has a need to, so what we are left with, is an information risk management practice that varies greatly in approach and usefulness.

The GDPR doesn’t give you chapter and verse on how to implement it. However, it does in several areas, reference the need to do it and indeed as it starts to become embedded we will start to see further standards on what it should look like.

Firstly, and in the most obvious place, is Article 25 ‘Data Protection by Design and Default’. This article outlines the requirements for embedding Data Protection principles into the very core of new designs and ideas for products and services. Article 25(1) outlines that Data Controllers should implement appropriate technical and organisational measures to mitigate the risks posed against the rights and freedoms of the natural person by the processing proposed. Now, in order to determine what is ‘appropriate’ as a control you need to have first determined the likelihood and impact of that particular threat materialising.

Voila! A risk management process is born.

Similarly Article 35, ‘data protection impact assessment’ (DPIA) talks about a very similar process with regards to risks to Data Protection. In a DPIA, a Data Controller would assess the risks to the rights and freedoms of natural persons by the processing in scope and determine, with the DPO where appropriate, what controls should be put in place that are appropriate to the level of risk. This assessment shall contain at least;

1. a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
2. an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
3. an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; and
4. the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.

Or, in other words, everything that you would expect to see in a risk assessment under current risk assessment practices (especially if you already engage in information risk as a discipline).

Article 32 ‘Security of Processing’ goes a little further and states the below;

1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

1. the pseudonymisation and encryption of personal data;
2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; 
3. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; 
4. a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

1. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.

Here we see the familiar areas of Information Security Risk Management, with some little tweaks to make it relevant for GDPR. But again, the principle of knowing what your threats and vulnerabilities are so that you can assess them and then ensure your technical and organisational measures are appropriate to the level of risk. You can’t effectively know one without the other.

Another key area that risk and risk assessments come into play relates to Breach Notification in Article 33 (the Authority) and 34 (the data subject). In both articles the requirement to notify is necessary unless the breach is ‘unlikely to result in a risk to the rights and freedoms of natural persons’.

Please note however that in article 34 wording swaps this around and says the duty to inform the data subject is there if there is a high risk to the rights and freedoms of natural persons.

In other areas that either reference the need to risk manage or instances where as above only become necessary where a risk management process determines it are;

• Prior Consultation (article 36)
• Tasks of the Data Protection Officer (article 39)
• Derogations for specific situations (international data transfers) (article 49)
• Tasks of the Supervisory Authority (Article 37)
• Tasks of the Data Protection Board (Article 70)

As we all know the GDPR is long and has the potential to become infinitely complicated depending on what processing you are doing, therefore you cannot possibly hope to comply with 100% of it 100% of the time. Find me someone that can and I’ll show you a magician. Therefore you need to ensure that you have a robust and easy to understand risk management process in place to manage your GDPR risks and determine what areas need more focus and what areas are ‘low risk’.

If you’ve not started your GDPR implementation programme yet, one thing that has worked well for me when determining where on earth to begin with this is to complete a data inventory, which includes why information is being processed, and to do a risk assessment on that inventory. What areas show up as massive gaps in current compliance let alone GDPR and what show up as minor tweaks? Once you have a reasonable level of overview you can then start to prioritise and logically see how things fit into place leading up to 2018. You can also see what areas of risk you can carry forward past May 2018 as currently there is no expectation from any of the supervisory authority that you will have / be 100% compliant by day 1.

Scott Sammons CIPP/E, AMIRMS is an experienced Data Protection & Information Risk practitioner and blogs under the name @privacyminion. He is on the Exam Board for the GDPR Practitioner Certificate.

Read more about the General Data Protection Regulation and attend our full day workshop.