Appian provides a low-code development platform that accelerates the creation of high-impact enterprise software applications – from idea to app in 8 weeks with a guarantee.
Data processing and GDPR - the business case
How will GDPR change the responsibility of the Data Processor and what impact will Brexit have on this? Steve Mellings, founder of ADISA and COO of DP Governance Limited, explores
The current hyperbole surrounding both GDPR and Brexit is at times reaching frantic proportions as the demands for column inches seems to surpass the need for insightful commentary. Add into this mix the recent ‘exposure’ of data harvesting from free-to-use social media platforms and is it no wonder that many within organisations are a little punch drunk and are left thinking….now what?
With many marketeers using this environment to peddle fear to aid their sales process, I’m often left to wonder if this is indeed Y2K all over again where the facts seemed to be an inconvenient truth. However, unlike Y2K, the changes on our business horizon are not going to go away in an instant once all those count down clocks hit 00:00.00. Yes, 25 May is a seminal date – when the GDPR will be shrined into UK law – but the real work starts and continues each and every day after that point.
Compliance to this piece of law doesn’t require a sprint up to a specific date, it doesn’t require one of the many pop up GDPR compliance services and some generic policy documents; it requires a business wide undertaking where data creation, management and protection is embedded into employee’s psyche, business process and third-party management. My article looks specifically at Data Processors, designated third parties who process data on behalf of organisations and the impact which GDPR is going to have on them and those who use them.
The Brexit impact
To start, let’s address one of the myths regarding GDPR concerning its adoption and the relationship with Brexit. First and foremost, we have already committed to adopting GDPR and so don’t believe that it will go away once terms for leave have finally been agreed and the UK and EU part ways. Furthermore, the draft legislation for its UK replacement – the UK Data Protection Bill – is already going through Parliament and within that, GDPR is prominently featured with the ICO recommending that the two are read alongside each other. The rationale here is sensible and logical; the law itself is actually very good and took a number of years to craft and fine tune, to restart from scratch would be expensive, time-consuming and ultimately fruitless. Furthermore, as the UK will be classed as a Third Country under GDPR it is essential for us, if we are to be permitted to transfer data from the EU into and out of the UK without complex structures in place, to offer equivalent approaches not only to law, but also its application.
So, GDPR and the UK Data Protection Bill are reality and whilst many organisations are adopting a watching brief or playing lip service preparation, the risk associated with this stance is quickly playing out in front of us. The current challenges being made by regulators on the big tech companies is where the battle lines are being drawn. It’s heartening that it seems no company is out of reach of the regulators or is going to be permitted to ignore the rights and freedoms of data subjects which is the ethos underpinning much of the GDPR - at least not publicly.
One key change within GDPR is the relationship between the Controller and Processor. At times this can be complex, depending on data flows as each party, on specific data sets, may be controller whilst the other is a processor and visa versa. What I’ve seen helping several organisations in their preparation for GDPR, is that during the creation of their ‘Records of Processing Activities’, several partners have been identified as being a Data Processor which were previously hidden away from both Infosec and Compliance and largely managed by Contracts/Procurement. Bringing all Data Processors into scope is critical for GDPR as the controller is required to behave in a specific way when selecting, engaging with and then managing Data Processors. Historically, the Processors themselves have been governed by their own due diligence or by terms within contracts, but under GDPR they are brought firmly into scope with a series of explicit requirements for them to comply with.
New obligations for Data Processors
A starting point is the acknowledgement of current behaviour. Whilst this may come as a surprise to many, it is already a requirement of UK Data Protection Act 98 for Data Controllers to have a contract in place with Data Processors and yet we know many do not. In fact, a freedom of information study, undertaken by ADISA, was able to evidence that approximately 66 per cent of local authorities and police forces did not have a contract in place with Data Processing partners. So what will change under GDPR?
Under GDPR, Article 28 outlines a wide range of requirements for Data Processors to comply with. The most obvious is that it is now a legal requirement for a Data Processor to have a contract in place with their controllers. This completes the circle as all parties are now under the same obligation which, in brief, is to ensure they work with each other in a formal and structured way where the services undertaken are detailed and roles and reasonability’s agreed.
It’s perhaps interesting to note that a Data Processor cannot process data unless under the written direction, and prior approval, of their controller. In situations where they do process data without this being in place they are not only breaking the law, but, this behaviour would see the Processor being viewed as a controller in their own right (A28 10).
Another difference is that Data Controllers are required to show far greater controls over the selection and management of data processing partners. There is now a requirement for Data Controllers to screen their data processors prior to use. Looking for sufficient guarantees of the service being provided including evidence of ‘appropriate technical and organisational measures’ (Article 28 1). It’s here where Data Processors will be required to look to accreditations to evidence this in place. This will typically be general data security standards like the ISO 27000 family or specific industry accreditations to reflect the service being undertaken – such as the ADISA Standard. In addition, their behaviour will be governed by defined requirements agreed with the controller and also their willingness to sign up to industry code of conduct. (The latter is currently a moot point as the UK ICO is yet to release guidance on what such codes of conduct will require.)
Another change is regarding the use of sub-processors. Data Processors are not allowed to use subprocessors without the prior written approval of the Data Controller. Complex data processing downstreams is something we’ve seen in various clients at DPG. For one recent GDPR engagement, we helped identify over 40 previously unknown sub-processors within an organisation’s data processing partner network. The issue stemmed from poor or non-existent contracts and service specifications being in place and many of these sub processors were completely unknown to the Controller. All of these are now in scope and subject to proper onboarding, management and assessment. Without this type of granular review, a data breach in any one of these would leave the data controller almost certainly, holding the liability on their own.
With any law change, organisations will fear the impact it will have on their operations and rush to buy services which offer wrap-around comfort. GDPR is something different. No external company or software can make you GDPR compliant, only your organisation can do that. The extension of requirements specifically applying to Data Processors is an excellent move as it makes sense that those third-party organisations to whom data is entrusted are brought firmly into scope.
It is unfortunate that many data processors might be smaller and they will view these changes as a huge cost burden. However, that does not need to be the case. The ethos behind the requirements is really about accountability, transparency and structure. In short, formalise what you do, how you do it and ensure that the way you do it protects the data sets which you are processing.