A security expert's view on overcoming the challenges associated with GDPR.
In my last blog we had a look at why GDPR has come about and why the heavily outdated Data Protection Act was no longer a valid means of regulating the privacy of everyday people. In this article, we will have a look at some of the basic principles of the regulation and piece together a list of the key challenges faced by organisations looking to become compliant.
Let’s start with some viewpoints on the basic principles of GDPR.
Designed to uphold the rights of ‘natural’ data subjects, GDPR is designed to protect the privacy of ordinary folk like you and me. It aims to do this by making sure that information held in documents, databases, or any other format that could be linked to a ‘natural person’ (for reference, a ‘natural person’ isn’t someone who eats organic whole foods), is protected and managed in a way that those rights are upheld.
Nasty financial penalties?
Failure to comply with the regulation could result in a fine which has a very high cap, the greater of €20,000,000 or up to 4% of annual global revenue. Nasty indeed, but contrary to some articles on the subject, non-complaint organisations won’t be arbitrarily fined on 27 May next year. Such organisations will arguably be safe until such time that either someone creates a GDPR certification scheme, or they get breached.
Another point to remember on fines is that they reflect the severity of how poorly an organisation has attempted (or failed to attempt) to be compliant. So, just because a breach happens, it doesn’t mean you have to get everyone rummaging down the back of the sofa. Prove that you have made sensible and adequate provisions for upholding the confidentiality, integrity and availability of personal data and you will be in a much better place.
Recognise the scope of the regulation
GDPR is not designed to protect information that doesn’t have personal identifiable information in. This is an important point! While GDPR is a good framework to secure all your digital stuff, only personally identifiable information is in scope. You won’t receive a fine if you lose some engineering data or some anonymised test results. This means that through a bit of spring cleaning you can potentially reduce the amount of data held that is in the scope of GDPR, and believe me, once you get on top of what you need to do for GDPR, you’re probably going to want to.
Once the scope is understood, you can get to work on that personal data. For example, perhaps using encryption to uphold the confidentiality of the information in the event of a breach or anonymisation to keep the information in a ‘useful’ format for big data mining while building a case for it to be outside of the scope of the regulation.
You control and I’ll process?
Just like the Data Protection Act before it, GDPR uses the construct of ‘data controller’ and ‘data processor’. There is also an important role in that of a ‘data protection officer’, though this is only required by public bodies or organisations that use systematic monitoring of data subjects on a large scale. Basically, the data controller determines what the information held should be used for and how it may be processed, in accordance with the regulation and UK law.
The data processor is basically anyone who processes personal data on behalf of the controller, and this is all too often where the threat to security and privacy lies (data processors have access to personal data and are dangerous). The data controller, therefore, has to find a trusted method of enforcing the authorisations of data processors and make sure he or she knows about any anomalies quickly.
In GDPR, information governance is key!
Learning to respond to data subject requests
As mentioned, GDPR does lots to enforce the rights of a natural person (presumably better than those of an unnatural person), referenced throughout the regulation as ‘the data subject’. The ‘data subject’ can request all sorts of things, from a neatly formatted overview of what information is held on them all the way to a request to ‘be forgotten’ (which we’ll discuss further in a later blog).
The majority of all of these are subject to a ‘without undue delay‘ tag, so your organisation will need to respond quickly and efficiently to all of them. These rights are covered in Articles 15-22 and Article 34 and come with a bucket load of caveats and subtleties that need your consideration. If you don’t have a process to deal with these in place by May they could very easily become a millstone around your neck, dragging you slowly towards non-compliance and some unwelcome attention from the Information Commissioner’s Office (ICO).
Breach readiness minimises pain
GDPR stipulates that in the event of a data breach the data controller should notify the ICO within 72 hours of becoming aware. That sounds pretty easy in principle, but in practice, dealing with breaches is a harrowing and often confusing affair. Are we sure they got in? Are we sure they accessed those records? Was the data removed? Who do we think it was? Did they get all the records or only some of them?
Getting things clear in your own mind before laying it bare before the information commissioner can easily demand more than 72 hours (even without sleep and a shedload of Red Bull). You really need to make sure you are ‘breach ready’ with a well-rehearsed response process that helps you get on top of things as quickly as possible.
The importance of showing your workings out
I touched on this earlier, but the GDPR is somewhat subject to interpretation. Don’t get me wrong, it kind of needed to be to ensure it had a long enough shelf-life to be useful, but this means that post-breach, your processes and threat mitigation measures may come under intense scrutiny.
To be fair, you will already be feeling pretty down on those measures if a breach has occurred, but you will have to defend your approaches and the decisions that lead to them, so it’s worth showing your workings out and maintaining a record of the thinking that went into your GDPR strategy. As maths never was my thing, I’m a great advocate of this approach; in fact, I would have probably flunked everything if I had merely written down the number I had worked out as the answer.
Compliance is much the same and given there very often isn’t a hard and fast right answer, so proving that what you came up with has merit may require some kind of audit trail. A good example of this is the regulation’s reference to taking into account ‘state of the art’ when designing and deploying systems designed to protect personal data. How do you prove that you have considered something as subject to interpretation as ‘state of the art’? What does it even mean?
GDPR isn’t going to be easy. For most organisations, this is a giant step change in basic information management let alone dealing with data subject requests and the like. Organisations will have to know where all of its data is and whether or not it holds personal (in-scope) information. While this sounds easy for a database of 100 records, what about all the associated e-mails, documents and scanned media that might also be in scope?
Now think about the fact that all of it is also probably backed up somewhere, possibly in the cloud, or maybe on a moth-eaten digital audio tape in a safe at a data centre somewhere. And think about being able to respond to a data subject request ‘without undue delay’. There is all of this to factor in and we haven’t even delved into data breach scenarios!
Trying to reduce the risk of over-simplification then, let’s boil this down into some recommended bite-sized challenges:
1. Appoint a data controller and, if you are a public body or run processing operations which require regular and systematic monitoring of data subjects on a large scale, a data protection officer
2. Understand where you are now from a high level and create a 35,000 feet view of where you are to help figure out how much work needs to be done and where
3. Create a data map to figure out where personal data exits and which of your data sets are in scope for GDPR
4. Establish what data you need, how it needs to be processed, and whether there is any opportunity for reducing the scope with removal or anonymisation of personal data
5. Complete a Data Protection Impact Assessment to gauge the impact of the envisaged processing operations on the protection of personal data
6. Design, deploy and test security mechanisms to uphold the confidentiality, integrity and availability of personal data. Maintain a record showing your workings out and considering ‘state of the art’ as often as practicable
7. Define an information marking taxonomy to make personal data easy to identify across databases and unstructured file stores
8. Find an effective method of enforcing the authorised handling of personal data by data processors and maintaining governance over such
9. Create processes for handling data subject requests and make sure the teams that will be expected to deal with them are trained
10. Select and monitor key security metrics based on the biggest threats to the data sets that contain personal data, and develop response plans for when a threat is detected
11. Prepare for a breach and make sure everyone knows exactly what is expected of them in this scenario. Test the process thoroughly
There are plenty more specific areas to look at of course, but these 11 elements form the basis of a robust and thorough foundation for GDPR readiness. They will also form the basis of our set of articles on getting “GDPR sorted”.
To this end, our next article in this series will be focussed on getting on top of your current data sets, evaluating what’s in scope and doing what you can to reduce the amount of data that is subject to the regulation.
The views expressed on this page do not constitute legal advice and are intended for information purposes only.