Corporate Data Protection & GDPR

GDPR – The Compliance Conundrum

There is one question related to the General Data Protection Regulation that will arguably cause more ulcers than any other: How much is enough?

In some portions of the GDPR ‘good’ is straightforward. In many others we are asked to respect principles of fairness and transparency while deciding what kind of control is ‘adequate’, ‘appropriate’, or enough to mitigate ‘high risk’. Then there are layered exceptions depending on data types, purposes, and processor roles. Some will be wrangling gargantuan, complex, distributed, cloudified, and aging networks. Others are working to do the right thing on the tiniest scale with no budget or specialist staff. All compounded by the slow drip feed of legal and regulatory clarifications and the tsunami of dangerous misinformation (something, something, GDPR, something FINES). In combination it’s feeling more like a regulatory Escher sketch, than a basis for budgets and plans.

14480963 - reflectiing spheres on puzzle surfacs

123rf Stock Image – Copyright rolffimages

Beneath the specific data protection aims, the GDPR was born from a need to to harmonise European data protection and enforce the same benchmarks when a personal data inside the EU is collected, accessed or processed outside the EU. Frustrated privacy pros are right: Making the least possible effort to tick a compliance box is directly counter to the spirit of the GDPR…but so is a dramatic variation in standards across industries and organisations.

That’s why, in the face of constant click-baity shouts of “Are you ready for the GDPR?” I’ve decided to explore around the edges of the compliance conundrum. All the folk who matter agree that prevarication is not a rational response, and it will take considerable effort to formulate, evidence, and defend an organisation-specific answer to that big question, no matter how risk tolerant and pragmatic the answer might turn out to be.

How much GDPR is enough?

All of the key stakeholders in a GDPR programme will constantly ask this question. Many legal and data protection teams are waiting nervously for opinions and clarifications from supervisory authorities, government departments, and the Article 29 Working Party (WP29). As clarifications arrive, specialist lawyers will help DPOs to interpret them in different organisational contexts (usually taking a cautious line). Resultant aiming points (rarely resembling practical benchmarks) will be handed off to security, IT, project managers, consultants, and operational areas. Then plans are refined. Or, if you have stalled work hoping the GDPR will go away, changes will be frantically scoped, costed, and planned.

But we have a significant and dangerous perception gap about how much is enough, as evidenced by the following (swipe left to see all the images if viewing on a mobile device):

This is a legal requirement.

You are either compliant, or you’re not.

General Counsel for a financial services firm

This slideshow requires JavaScript.

Focusing specifically on consent, responses from some data protection pros can be summarised as:

The rules are clear. Stop stalling and JFDI!

But are they? Probably more #GDPRubbish has been published about consent than almost anything else so far. The #GDPRubbish hashtag was created by Rowenna Fielding (top advisor with Data Protection service provider Protecture) and enthusiastically picked up by other data protection experts like Jonathan Armstrong (compliance and technology law partner at Cordery) and Jon Baines (Chairman of the National Association of Data Protection Officers – NADPO – and DPO at Network Rail).

On those consent related facts:

  • NO, you do not need explicit consent for all personal data collection and processing.

There are 6 legal bases for collection and processing of personal data (Article 6(1)) and consent is just one of them. Between the GDPR and the Privacy and Electronic Communications Regulations (PECR – due to be updated in May 2018) you have to unpick a fair and transparent approach for different subsets of data (e.g. personal data, convictions data, special data classes, child data), different collection mechanisms (face to face, phone, fax, post, email, sms, web), and different processing purposes (sales, marketing, legislative, medical, public service, etc). Rowenna gives you a starter for 10 to do that here.

  • NO, you cannot get away with sitting tight until May 2018 with pre-ticked boxes, or no boxes at all

So what if there’s still uncertainty? It’s a familiar place to be for anyone with half a strategic or risk management clue. If we are all honest we spend most of our time planning round it. But this time it’s someone else dragging their feet. That’s a welcome thread for some reticent folk to cling onto, but we can’t deny it also impacts those who rightly bit the bullet to get cracking with GDPR change.

Don’t lose sight of the basics: The GDPR was created to protect the rights and freedoms of individuals, while supporting the free flow of data: The lifeblood of modern service provision and trade.

Any additional cost, disruption, or delay caused by a lack of clarity can’t all be blamed on the ICO. Aforementioned GDPR misinformation has caused an incredible amount of doubt and distrust, as has a scarcity of good pragmatic data protection folk. That’s before we start in about organisation who should have laid GDPR foundations under pre-existing Data Protection law.

…but what the heck is ‘compliance’?

The above is all context for this kind of twitter exchange:

SC Magazine trumpeting the fact that firms claiming GDPR compliance don’t seem to be as compliant as they thought, Tim Turner bemoaning that as pointless nonsense, then Des Ward and Darah O’Brien pitching to ditch the C word all together.

These are seasoned pros who I trust to talk data protection sense, but what the heck do we aim for if it’s not complying with regulatory requirements? I’m yet to meet an auditor or lawyer who’ll swallow “It’s fine, trust me, I’m an expert”. So where do we go from:

GDPR ‘compliance’ = bad

GDPR ‘something’ = good

Drill a wee bit further and you’ll always hit the term ‘tick box’. It’s the hub around which criticism cycles. Most often applied to standards and attempts to audit against them. Audits and other assurance efforts will always involve a list of questions, plus a massively variable quality of diligence applied to getting and assessing answers. Plus, if you’re lucky, evidence to validate responses. Responses that mainly paint a point in time picture reflecting what folk can be persuaded – or strong-armed – to tell you.

Accountability is the standout change brought in by the GDPR. Right after Article 5 lists the other 6 principles in paragraph 1 it spreads accountability over all of them:

Accountability Priciple

The kind of data protection diligence and oversight that demands will be a step change for most organisations. Security governance in most large firms will be far more mature. Very few data protection teams (if there were even enough bodies to warrant the title ‘team’) have historically had adequate tools, capability, or capacity to take on a job this size. Add in the need to find a DPO who can influence at board level, oversee substantial people, process and technical change, PLUS create a framework for ongoing risk management, and it equals one of the first and biggest culture shifting challenges.

This is principles based legislation, not a set of controls.

Successful GDPR implementation is most about fairness, transparency, demonstrable accountability, good data governance, and effective risk management

Even when the roles, role holders, means, tools and processes are in place, there’s not yet a set of definitive GDPR questions, nor evidential benchmarks to back them up. Folk who can evidence adherence to existing UK Data Protection Law and good data governance practice will be in a great place compared to most, but diligence and the funding that enables it has been…how should I say this…patchy.

The GDPR does leave space for supervisory authorities to define codes of conduct and approve certification bodies to audit organisations against them. Being frank, I can’t see how investigation and enforcement will ever work if they don’t delegate some oversight this way, nor I suspect does our ICO. That’s why they planned to have a Privacy Seal – a data protection ‘stamp of approval’ – up and running by 2016, with UKAS accredited bodies to do the certification, but as yet none of that has happened.

Article 40

Articles 40 – 43 deal with codes of conduct, monitoring codes of conduct, certification, and certifying bodies.

Security suffered from the same problem, that’s why NIST SP 800 / 1800, the ISO27000 series of standards, Cyber Essentials and related certifications evolved. As an aside, speaking as someone who’s worked with ISO27k for over a decade, don’t assume ISO27001 certification equals GDPR compliance. IT DOES NOT. There is crossover – the ISMS (Information Security Management System) described in ISO27001 reflects more general ISO9000 good risk assessment and management practice, but if you stick to ISO27002 domains you will ignore critical parts of GDPR scope e.g. subject rights management and ensuring appropriate legal bases for processing.

ISO27002 Contents

ISO 27002:2013 Information technology — Security techniques — Code of practice for information security controls – Contents. From

BS 10012:2017 – the British Standard for a Personal Information Management System (recently updated for GDPR), ISO29100:2011 (a standard for a Privacy Framework) and other information rights and records management standards (e.g. ISO 15489-1:2016) add back the data governance and data protection specifics, but the fact remains that GDPR is still woefully light on measurable specifics and the ICO is showing no signs of helping us differentiate between what constitutes guidance vs an obligation, much to the frustration of the data protection crew.

That’s in stark contrast to the kind of specific benchmarks that make lawyers and auditors happy e.g. Payment Card Industry standards and the big 4 happy place: SOCII audits of IT General Controls. You should also find that kind of clarity in well written policies (the ones that differentiate principles from controls and control objectives, then clearly state if you ‘Must’ comply vs offering defined exceptions and risk based flexibility)

On that point: What were SC Magazine using as benchmark for their claims about compliance? Mainly a secondary report from Veritas Technologies (a data management tool vendor) following up on their 2017 GDPR Report. A total of 900 ‘decision makers’ were interviewed on their behalf by market research specialists Vanson Bourne. All were reportedly in a good position to speak for the state of GDPR play in their 1000+ employee organisations operating in a range of countries and sectors. Figures are based on further analysis of responses from the 279 (approx 31%) who originally stated they were GDPR compliant.

A few responses were highlighted as evidence of overly ambitious compliance claims. These are the two with graphics. You can look back at the report for more:

Though the work done by Veritas has awareness raising value, it doesn’t paint the whole – or even the most important part – of the picture.

Compliance: A middle way

I’m not in the same camp as Daragh’s DPO. I don’t think we can bin the term. Along the way we will have to have GDPR controls audited against some yet to be defined criteria and there will be legal cases tried. In those circumstances there will be no escaping it, so I believe our best course of action is to clearly state what it rationally means in a GDPR context and build local accountability and data governance capability to be able to formulate a constructive and flexible response.

Beginning with audit and financial regulation language, compliance has been defined as:

Certification or confirmation that the doer of an action (such as the writer of an audit report), or the manufacturer or supplier of a product, meets the requirements of accepted practices, legislation, prescribed rules and regulations, specified standards, or the terms of a contract.

From the Business Dictionary

More practically: Compliance is established after assessment of evidence demonstrating effective adherence to regulatory or legal requirements by a body or individual who is an expert in the standard or law with which you are attempting to comply. That may be pro-active: e.g. A planned audit by an accredited internal or external expert, or reactive: An investigation after an incident or breach by law enforcement officers, regulator appointed auditors, or the regulator themselves.

That all assumes we have a common understanding of GDPR requirements and what a well designed and effectively operated GDPR control looks like. When we don’t, not entirely, as I’ve been arguing thus far – and that can hobble effective communication, planning, and attempts to budget.

I’m not saying it’s all clear as mud. There are many parts of the GDPR where good practice is very obvious (e.g. Article 13 describes required privacy notice content in straightforward detail). Conversely, where it’s going to be a risk and local environment based judgement call, auditors and lawyers will get very nervous. That can create noisy and wasteful political pressure for folk just trying hard to make a difference.

An invitation to apply good risk management practice

These are a few of the places where the GDPR acknowledges that a risk based approach is necessary to inform rational planning and operational GDPR decisions:

Data Protection Impact Assessments:

These only need to be conducted where processing is likely to result in a high risk to data subjects’ rights and freedoms (Article 35(1)). The WP29 expanded on that here: Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk


Security Control Requirements:

“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(Article 32(1))

Breach Notification:

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons(Article 33(1)).

and more generally:

Article 24

Getting a solid handle on the current state of data governance and data protection is therefore essential. Then, when planning begins, you have to clearly lay out and log the basis for decisions. That doesn’t need a pricey GRC tool, or a specialist data protection lawyer. It’s the kind of good planning and governance practice that everyone understands and no-one has an excuse not to do.

You also need to bear in mind that the door has been left open for class action law suits (‘no win no fee’ merchants are already reportedly flexing their muscles, but it probably won’t be “the new PPI”, as some have enthusiastically suggested). That boldly underlines that ignorance will be no defense, so an acurate history of plans and planning decisions is vital to demonstrate what you’ve done, why you’ve done it, and, crucially, what you decide not to do.

One of those justifications for holding fire might be a lack of clarity about requirements if your organisation is at risk of implementing changes that cannot realistically be reversed or revised later, but that’s going to invite an intense amount of scrutiny. You need to be very, very honest about limitations and clear about any associated risk to data subjects you have decided to tolerate as a result.

8824385 - metal puzzle globe with euro coins on white background

123rf Stock Image – Copyright Eyesee10

That is familiar territory for me, having spent much of the decade preceding my move into data protection trying to balance security control absolutes with an approach reflecting risk reality. In doing so I distilled my thinking down to 4 key points:

  • Benchmarks for compliance should be a combination of regulatory / legal absolutes and broader risk based control objectives based upon assessed risk appetite.
  • Compliance cannot be situation agnostic, so non-compliance does not necessarily mean data subjects and organisations are at risk.
  • Being at risk is not the same as being at intolerable or proximate risk. A simple and effective process should exist to assess risk and permit formal acceptance of non-compliance where justified.

all glued together by this:

  • You cannot argue control adequacy without embedded accountability and scrupulous documentation of rationale for risk assessment and resulting acceptance, transfer, or remediation.

And that – point 4 – is the crux of it. No matter how the GDPR translates into change activity in your organisation:

We have to show our workings out and those workings out have to have fairness to data subjects at their heart.

That will move organisations further than anything else towards doing the right thing and being able to demonstrate and defend that to regulators, lawyers, partners, and clients.

Then, if GDPR clarifications move goal posts, note the changes. Get names and dates against resulting control decisions and version control that like your life depends upon it. Is it tough to do? Yep. Is it rocket science? No.

But this is LAW – I hear you cry. We have to get it 100% right because:

Something, something GDPR something FINES

WRONG. No-one will get this 100% right by 25th May 2018….or EVER. Principles based regulation doesn’t work that way. ‘Right’ for the data subjects you have responsibility to protect and your environment is going to be locally variable and the ICO knows it. They wouldn’t be taking so much time to issue guidance if the lines drawn were universally applicable and clear.

But you CAN’T ignore it.

You are not going to be slapped with a 4% revenue fine…even if fines come close for incredibly unscrupulous and repeat offending organisations. Ditto with being subjected to processing restrictions (many folk are not aware that the ICO can prohibit you from processing most or all of your client database as a sanction for a regulatory breach – spare a moment to consider implications of that). However, the ICO is not aiming to put people out of business who can demonstrate significant progress towards good data protection practice and show plans to continue improvement.

However, no matter how far you finally decide to travel, there’s absolutely no defense for remaining ignorant of your starting position: Your data governance accountabilities, your data collection points, the purposes stated for collection, your core data processing, the same for your suppliers and partners, and risks to the rights and freedoms of data subjects caused by any related control gaps.

Given the amount of time left before May 25th 2018 you then have to lay foundations for change: Common business-wide understanding of why change has to begin, and scoping things you almost certainly need to review and improve:

  • subject rights management
  • contracts
  • privacy notices
  • lawful bases for current processing, including consent
  • mapping of core and key secondary processing
  • reviewing coverage and status of related security controls,


  • nailing that data governance RACI and associated oversight from the top to the very bottom.

But you CAN ignore:

Scare mongering claims that it’s 100% compliance or bust, tacked onto pricey offers of silver bullets…unless you have bottomless pockets…or you prefer to procure some ruby slippers, click your heels together three times and say “There’s no place like Brexit”.

EDIT: On Monday 7th August the Department for Digital Culture, Media, and, Sport published their response to consultation on exceptions to the GDPR that may need to be written into our statute books and a statement of intent for the UK Data Protection Bill. The GDPR driven draft replacement for the Data Protection Act 1998.

As bonus material there is also an 189 page report on research and analysis to quantify the benefits arising from personal data rights under the GDPR.

On first review the intention is to mirror all of the GDPR. Those fines are in there at the same % revenue with an equivalent Sterling value for the maximum Euro amount (though it’s unclear if that will remain fixed with likely exchange rate fun). So are the subject rights and consent requirements that are causing most of our angst. However, it will take time to establish how the DP Bill might diverge in granular detail or by formal derogations. Jon Baines and Jonathan Armstrong have given their first take on that (the links are to the respective posts), but there will be much more to come.

None of which negates any of the points made above. If anything it should further focus minds on creating informed and flexible risk based plans and progessing change already in motion. Always allowing for details that might need to change along the way.

NOTE: None of the information here constitues legal advice. Please refer to your own legal advisors before basing any decisions on content.

THANKS: Sincere thanks to consumate data protection professionals Jon Baines and Emerald De Leeuw for reviewing this before it was published.

2 replies »

  1. Very good article. Your discussion of the application of risk assessment is very good. The obligation to apply risk assessments via DPIAs seems to be pretty well recognized. The application of risk assessment to controls, much less so. Clearly you are correct, organizations have to perform a risk assessment of existing systems as well as to all proposed systems. The DPIA applies to proposed systems but do you believe the same approach can be used to assess existing systems?

    Liked by 1 person

    • Apologies Marshall, I missed this reply. Put very simply…yes, we need to assess existing controls and keep assessing new controls after implementation or change. The GDPR very explicitly stated that firms should recognise that risks and required controls change over time and reassess accordingly:

      Art 35(11): Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.

      Art 24(1): 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.

      I would expect that to be a reactive process when there is formal change to data processing procedures or systems, and part of cyclical review activity. The DPIA refresh would identify whether risks have evolved to justify a deeper dive into control effectiveness. In some places that could link to cyclical and change driven security assurance/audit I’d expect to be happening anyway.

      As always caveated by the fact this is my opinion not a legal opinion, but can’t see it going well if there’s a breach thanks to inadequate control and the best evidence of due diligence you can rustle up is a 6 year old DPIA.


Want to add to the discussion?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.