Is GDPR really an IT problem?
Owing to the word “data” in the Data Protection Act, and due to the lack of teeth and importance that data protection has historically been afforded, for the large majority of clients we have worked it is the IT team who have been tasked with ensuring an organisation is compliant (and usually it is the head of IT who is also told he is a “DPO”, despite that role being a markedly different beast under the GDPR!). This attitude seems to have persisted, as most people we speak to about the GDPR seem to think that it’s an IT problem and the IT team are often tasked with “getting GDPR in place”. I was in a meeting with the IT department of a large company recently who had been given an action plan and had been asked to get on with making the organisation GDPR compliant but when I went through it with the team, it was clear that the majority of GDPR cannot be implemented by IT (I have seen some consultants in this field state that the GDPR only bases roughly 3% of its full text on IT controls). I thought it was worth discussing where the GDPR has a direct impact on IT.
This problem has not been helped by salespeople in the realms of IT software now using GDPR as a means to scare people into purchasing new products by slapping GDPR compliant on the packaging. I have seen many software packages claiming to be a silver bullet when it comes to solving an organisation’s compliance woes. In actual fact whilst these packages may assist in dealing with certain issues (Right to be forgotten, dSARs etc.) they do little to solve larger structural problems. In certain instances this problem has not been helped by IT teams using the GDPR as a political means to push unrelated change (I was once asked by confused staff why the GDPR had made paper illegal, as the IT team had informed them it had as part of a push to go paperless).
The most obvious area is that concerning IT security controls referred in data protection parlance as technical controls or technical measures. Of course, some organisational measures also preside in the domain of IT such as IT policies which appears in the GDPR’s sixth data protection principle (Article 5(1)(f)), “Personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.” The objective of this is to ensure personal data has integrity and confidentiality. However, to offer an example, a shop does not need the same degree of IT security as a multi-national bank, which is why law makers have deliberately left this principle open.
Another area which does not exclusively impact upon IT departments but does have some effect is the seventh principle (Article 5(2)) which requires data controllers to be responsible for and be able to demonstrate compliance with the six data protection principles and just to be clear, a “data controller” in this context is not referring to one specific individual within an organisation but to the organisation itself. This seventh principle has two angles to it: being responsible for compliance and being able to demonstrate compliance, and the latter part can only be referring to evidential record-keeping systems which, over time build up a body of information which is able to demonstrate compliance (i.e. training records, internal compliance checking records, change controlled policies etc.).
Contrary to popular belief, the GDPR is not prescriptive in the controls it requires controllers to undertake but requires us to analyse our organisations’ data processing activities and determine what control measures are necessary for each specific use case using a risk based approach. As I have said on many, many occasions, this is usually the point that people begin to dislike data protection law because rather than give prescriptive answers like PCIDSS or other standards, data protection law grants us the flexibility to design and determine our own control measures that achieve its objectives. But with this flexibility comes responsibility which sadly many organisations shun.
It is absolutely true that IT have a crucial role in advising the types of controls that would be sensible to keep different types of data secure, or the best systems available to enable tight access control, or the most secure methods for transferring personal data from one person to another – but can we expect them to be responsible for all data processing in the entire organisation including paper-based data processing activities?
Other areas where IT departments can assist with GDPR compliance are in areas such as data retention whereby the IT team could loosely “police” retention by providing a monthly report on data creation, usage, destruction and retention. In the international dimensions of the GDPR IT teams could use a variety of tools to determine if data are being transferred to territories outside of the EEA, and when it comes to data subjects exercising their information rights, IT departments can help to locate, extract, erase, and/or ring-fence data to comply with information rights requests. But these are not what I’d call specific IT responsibilities clearly set out under GDPR.
Fast forward to Article 24 and the GDPR takes on more relevance for IT teams. Article 24(1) states, “Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary.” Article 24(2) states that, “Where proportionate in relation to processing activities, the measures referred to [above] shall include the implementation of appropriate data protection policies by the controller.”
Analysing the words in Article 24 they still allow flexibility – the obligation is to implement technical and organisational measures which are appropriate to being able to ensure (strong word) and to demonstrate that all data processing is performed in accordance with the GDPR. In determining what measures might be necessary and appropriate we are to take into account the nature of the data we are handling as well as the scope, context, and purposes of the processing and factor into our deliberations the risks to the rights and freedoms of data subjects (and potentially others) (i.e. the right to privacy and a private life). Our risk assessment should consider the likelihood of threats materialising (such as data breaches or unlawful processing) and the impact on people should they arise.
Article 24 tells us that we need to review the effectiveness of those measures we put in place which in other words is a periodic audit or some form of monitoring and in order to comply with the accountability principle (the 7th data protection principle) we need to have evidence of those reviews in order to be able to demonstrate compliance with the Regulation. Helpfully, the GDPR provides us with a mechanism for risk assessment in the form of a Data Protection Impact Assessment (DPIA) (formerly called a Privacy Impact Assessment (PIA)) which are mandatory in certain circumstances (Article 35).
The GDPR clearly expects data protection policies to be implemented as an organisational control measure but only where proportionate. In my view it would be proportionate for every organisation processing personal data to have a policy framework and I can think of few cases where it might be deemed un-necessary – perhaps in the case of a sole trader – but as soon as there are two or more people involved in an organisation, to me it becomes necessary to introduce control, discipline and order which should be defined in policy.
Article 32 of the GDPR also contains guidance for IT teams which again instructs us to “implement technical and organisational control measures to ensure a level of security appropriate to the risk” and goes further to give some specific examples including the encryption of personal data and the pseduonymisation of personal data. Article 32 instructs that those measures should include, “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” -i.e. protection against malicious software threats such as cryptolocker etc. and, “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident” – i.e. disaster recovery and business continuity. Finally in Article 32(1) the GDPR instructs us to implement “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing” – i.e. compliance checking. And don’t forget that the accountability principle means that records of all of the above should be maintained so that compliance can be demonstrated.
Article 32(2) provides guidance on the risk assessment process. “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” which helps us to identify what our controls are aiming to achieve.
The final paragraph in Article 32 tells us that controllers and processors shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by European Union or UK law which is something that operational managers need to get a grip of – not IT departments.
Even in the area of data breach handling the IT role is important but peripheral. Security incidents need to be identified by data handlers and reported to a central point (which in my opinion could well be IT) whereupon they must be investigated to determine the cause, the damage, and the remediation. IT departments in collaboration with data protection professionals are probably best-placed to be heavily involved in this process and given that controllers only have 72 hours from identification of potential data protection breaches to notify the ICO there is no time for delay. The GDPR does not specify who should report the breach but does make it a specific task of a DPO to cooperate with the ICO where a DPO is appointed and the current guidance issued by the WP29 advises that heads of IT are highly unlikely to be suitable candidates for a DPO role due to a conflict of interest.
The GDPR requires us to adopt a privacy by design and by default approach to running our organisations (Article 25) and again the IT team have a clear input to this but surely cannot be solely responsible?
So, considering all of this in the round, the job of IT in respect of the GDPR is to advise the business as to what measures both technical and organisational are appropriate to ensure secure processing of personal data and its availability, resilience, integrity and confidentiality. IT must implement disaster recovery and business continuity plans and ensure that the control measures in place remain in place and are effective. IT needs to introduce appropriate policies, procedures and work instructions into the information governance framework, and crucially they need to ensure that there is evidence of the work they undertake. The advisory role extends to DPIAs and breach containment but the business needs to take responsibility for defining and analysing the data handling operations and articulating them to the IT team in order to receive the best and most appropriate advice.