Author: Stewart Felstead, Security Architect, Oracle Consulting UKIE.
This figure is terrifying as a Gartner survey suggests that half of EU businesses may fail to be GDPR ready by May 25 this year, when GDPR becomes effective. Do you think your company will be ready for GDPR?
The triangle of Truth – a different view on the 3 points of risk
Everyone is worried about protecting the data at source, but should data be the main or only focus?
No, protection isn’t only about having an encrypted file system, or transparent encryption on all your databases, or even a privileged access control layer, as individually they won’t address all your GDPR requirements. Addressing GDPR compliance should also include your policies, controls and processes needed to be considered together with data. A lot of people are really focused just on the data and data subjects rights such as the right to be forgotten but the reality is that it is policy that drives the controls that are embedded into your processes to enable you to achieve an acceptable level of compliance.
Some definitions: A policy is one or more rules that the business decides must be adhered to. Policies are defined in response to things like legislation, ethics, efficiencies etc. A Control is a mechanism that implements the rules of a policy and the Process is where a Control is deployed to ensure the process is executed in a way that adheres to the rules of the Policy within your Business. A process may need to utilise multiple controls at different points of execution.
Example of Policy, Control & Process: The doorman.
Policy : By order of the management, no sports shoes are allowed.
Control: To make sure that no sports shoes are allowed, you hire a big suited security guard.
Process: Enabling the control - Does the security guard stand outside the venue in the rain, checking for shoes or do you decide to have him just at the door looking for people’s shoes? Are you going to decide to let people pay first and then have the guard inside, walking around looking for people with trainers? From a compliance perspective, as long as there are no people with trainers on compliance has been met.
Real World Example: CVs and The HR Department.
An HR on boarding policy might state that only people who work in HR are entitled to access a prospects candidate data (As required by Least Privileged Access). It would normally be straight forward if you have an electronic system where you upload the CV and only the HR person can login and access it before passing it to the hiring manager. However in the real world, people send CVs through the postal system and these then end up in the post room. This means that without proper controls in place the CV could be opened in the post room and in theory the personal in the post room could have access to sensitive personal data e.g. name, address, phone number possibly NI & passport number which could potentially be enough to excited Identity theft or a credit card fraud.
In this example you might want to consider putting a control in place as part of that process to ensure it can be executed in a complaint way. As the CV it’s not a technology control, it’s a process control. One of the key requirements of GDPR is understanding where data is in your organisation in all it’s forms, and understanding what processes act up in, and who the actors in those processes should be. Once that it understood you then need to ensure appropriate controls are in place to properly protect that data. In the example above a control is required to ensure job applications are not opened in the post room, this could be as simple as ensuring candidates address the envelope to a specific department and the post room are informed to forward mail to that department unopened – a simple but effective Process Control.
The point is that the control is a mechanism to meet the requirements of your policy and the policy will state in the same way ‘it said no trainers’ on the previous example, that only authorised people can see the candidate data. How you enable a control is dependent on the process but it is the mechanism that enforces the policy.
A control is either something that’s put in place from a technology perspective or something that you are include in a process to prevent or reduce the likelihood that someone does something against policy. How that control is delivered to your business is defined by your process.
It’s a fairly realistic assumption that today organisation will have existing policies and obviously have existing processes which may include some controls, but the likelihood of those policies, controls and assumptions being robust enough and applied with the appropriate levels of diligence to enable most organisation to be compliant is believed to be relatively low according to Gartner (see above).
Robust enough for GDPR?
You may be fortunate and have existing policies that are robust but, are the controls or the process that you put in place still enough to meet the demands of the GDPR? You could fail in any of these areas, and when you do so, it will by definition, put your business at risk.
By doing a risk assessment against the three points of risk, you are able to identify what risk you are carrying. To enable you to quantify that risk and therefore prioritise remediation you need to understand how it is related to the data. You might have a system that anyone can log in to, and see anything on it, but if it does not hold any PII data, it is likely to represent very little risk from a GDPR perspective.
So, ultimately all this is related to the data itself but understanding the data alone is the wrong place to start. Understand what data you hold, where it is, how it is stored, transported, exposed and maintained from conception to destruction is what will be assessed by the auditor.
Who? What? Where? When? Some Considerations
Who – The Data Subject, whose data is it and do you know. Where does it came from? If you rely on consent, are you sure you have you got the right consent that meets the stringent GDPR requirements?
What - Is it relevant/current/accurate? What you are doing with the data and is the consent consistent with the way you using it?
Where - Do you know where the data is? Who has access and is that access appropriate? What do you do when you no longer need the data? Can you remove it on request – do you know what other legislation impacts the data, for example PCI-DSS may require you continue to hold data even after a right to be forgotten has been initiated?
When - How can you prove who did what with the data? Can I actually identify whose data has been compromised and action a breach notification? How do you identify, record and report unauthorised access? Do you have up to date contact details for the individual?
Operational Implications – Making GDPR a BAU Process
Compliance cannot be considered a point in time activity. This is not just about May 2018. However, the key is not a one of compliance position but an ongoing operational process. As your compliance position will change over time, you need to be looking at simple, cost effective mechanisms to implement across your whole enterprise to deliver against the demands of GDPR the will enable you to drive change in the business. You make a specific change because you are carrying a known risk and you need this risk removed as it realisation will have a quantifiable impact on your business. It is highly probable that GDPR is going to introduce change, whether that be an update or replacement system or a change in behaviours. You are very likely to be required to develop new process and to do so you will need time and investment.
At Oracle Consulting we can help you, wherever you are on your GDPR Journey, from getting started to monitoring your ongoing GDPR policy requirements’ gaps, with GDPRSMART as an approach to risk Identification and Remediation. Contact EMEA Consulting (firstname.lastname@example.org).