The Elephant Man, GDPR and four Ps to prevent panic

I recently acted in a local community production of ‘The Elephant Man’ by Bernard Pomerance . It’s a moving and thought-provoking play which I can recommend if you get a chance to see it.

One of the thoughts it provoked for me, somewhat bizarrely, was about GDPR and similar regulations and standards, and specifically, the angst we always tend to suffer when faced with them.

The play is based on the true story of Joseph Merrick, an intelligent and shrewd man with a wicked sense of humour, who battled throughout his life with the major birth deformities which give the play its title.

He is rescued from the freak show circuit by Frederick Treeves, a surgeon at the London Hospital, who takes him in, recognises his intelligence and starts educating him to ‘be like us’. To do this, Treeves imposes rules and standards on Merrick to make his behaviour socially acceptable.

He repeatedly tells Merrick these are ‘for his own good’. The phrase becomes a mantra for Merrick, but later, as he begins to question some of the rules imposed on him, he starts to use it ironically, implicitly rebelling against orders when he doesn’t see a reason for them.

That’s where I made the connection. Faced with an external requirement like GDPR, PCI, Sarbanes Oxley or ISO270001, and a deadline to implement it, we can tend to leap straight into action mode: “this looks pretty horrible but just tell us exactly what to do and we’ll do it.”

The challenge is that these requirements aren’t generally defined to a level where you can just take a set of detailed instructions and implement them. Rightly so, as the requirement has to be sufficiently broad for each business to be able to interpret and apply it appropriately to their particular case.

Cue GDPR panic, boom time for consultants and proliferation of “Your GDPR made simple, no, really, this one really does make it simple, honest guv!” guides.

How do we overcome this panic and head scratching to make these things work?

A wise person once said that, whatever you’re working on, it’s worth taking the time to step back, unless you happen to be working on scaffolding.

This post is about taking that step back; it doesn’t refer to the specific requirements of GDPR, as there is more than enough material on that already, rather it lays out the basics of an approach to any externally driven legislation, standard or system.

Taking a step back in this case means thinking beyond the specific detailed requirements and tasks and considering what I’ve referred to here as the four ‘Ps’ – Principles, Pertinence, Practicability and Pragmatism.

The first P is Principles.

Take time to understand the underlying principles which drive the requirement, and how they apply to your situation.

Standards, regulations and legislation start with someone identifying a problem, then defining the principles for a solution, then designing, building and implementing a consistent system based on those principles.

It’s worth taking time to go back to the same starting point and consider the implications of the problem and principles as they apply to your business.

Getting to grips early with the basic problem and principles avoids misunderstanding, missed opportunities and frustration when you apply the system.

You don’t want to be the hotel night manager dealing with a polite old lady who comes down 27 times to request change for the bottled water vending machine. On her 28th appearance he asks if she needs more change, only to be told ‘No, thank you, young man, I don’t believe my room is on fire any more.’

It’s important to understand the problem, not just the task you’re being asked to do.

I was involved in implementing quality systems in the early days, and I believe a lot of resistance came from a failure to understand the underlying principles.

A stock criticism of ISO9000 was that it didn’t stop you producing crap, it was just consistently crap.

This criticism fails to understand a key principle of these systems, which is that consistency and repeatability are an essential foundation for continuous improvement.

In the case of GDPR,  the fundamental principle is that your personal data is your personal asset.

If you entrust it to me there must be a clear contract and benefit to you, and I must look after that asset, only using it for the contracted purpose, being entirely transparent to you about how I am using it, and ensuring that there is no avoidable disbenefit to you.

This is the same principle which drove the previous legislation, it’s just that personal data is being used in new ways so the legislation needs to be extended.

Once we’ve properly understood the problem and principles, the next step is to look at the specific regulations or standards and consider their Pertinence, both to the problem and principles and to how you apply them in your organisation.

Questioning how well the specific rules of a standard or legislation apply to its underlying principles may seem like a pointless exercise at best, and dangerous heresy at worst. After all, it’s the law, so you have to comply regardless.

However, if you’re in the unfortunate position of doubting the relevance of some of what you are being told to do, I believe it’s better to deal with this consciously and transparently from the start, rather than wait for corrosive cynicism to set in later.

The old ‘five whys’ analysis technique can come in handy here.

Where legislation or a standard requires you to do something specific, keep asking ‘Why?’ until you get back to the underlying principle. If you don’t get there, it means that the specific action or regulation is questionable in terms of its principles.

I hasten to add that I reckon the people who put together the GDPR legislation have done a good job of making sure that all its measures are pertinent to the underlying principles, and it easily passes the ‘five whys’ test.

When it comes to standard methodologies and quality systems you often have a little more freedom to act according to how pertinent you feel the specifics are to the underlying principles.

For example, with PRINCE2 I tend towards the mildly heretical as I find myself throttling back on some of the documentation, simply because I don’t feel it’s all pertinent to the PRINCE2 principles and it’s more effective for the project manager to use their professional discretion. So shoot me now.

Regardless of what you think of the legislation or standards themselves, you still need to consider their pertinence to your business. I believe this is best done by going back to the principles rather than dealing with the specifics.

For example, If your organisation’s use of personal data extends only to keeping customer names and email addresses for a mailing list, you still have a responsibility to safeguard these customer assets, but clearly some of the GDPR mechanisms will be less pertinent or can be implemented with trivial effort.

If you focus too much on the specifics rather than the principles you can end up overspecifying the solution and wasting time and effort on measures which aren’t pertinent to you.

Which brings us to Practicability and Pragmatism . Whatever measures you put in place need to be practicably achievable and sustainable for your business, and need to be implemented in the most pragmatic, cost-effective way possible.

This is particularly relevant to small and medium sized businesses in a business environment where non-core business functions are outsourced and businesses work in dynamic, agile relationships to meet rapidly changing business needs.

It’s clearly not practicable for a small business making £30k a year operating profit to employ a full-time data controller on a £45k salary, and it may be hard to give the data controller role to an existing employee if  everyone is already working flat out.

I was always taught that the key difference between responsibility and accountability is that you can delegate responsibility but not accountability, and I believe this distinction is key to managing requirements like GDPR in the present business environment.

You need to make someone in the organisation accountable for data. That individual cannot offload that accountability to a third party, but they can make a third party responsible for definition and execution of the policies and processes which allow the individual to fulfil their accountability.

This is often the most pragmatic approach as a third party can deliver the economies of scale to make this solution the most cost-effective.

I know this is all pretty much Management 101, but I am concerned that when it comes to GDPR, cybersecurity and the like, the critical importance of the challenge can blur that accountability/responsibility distinction and allow inefficiencies and duplication to creep in.

At worst we can end up ‘buying a dog and barking ourselves’ as a former manager of mine liked to put it.

If I am accountable for cybersecurity in my SME, and all IT services including my firewall are outsourced to a third party service provider, how do I fulfil my accountability?

One approach is for me to hire or acquire the skills to audit my service provider, do forensics on cyber attacks specifically targeted at my organisation, and so on. I have seen instances of external regulators apparently seeking this level of diligence.

This may give confidence to me, my board and my regulators that I’m fulfilling my accountabilities in an undoubtedly critical area, but it also creates duplication and inefficiency.

For one thing, if that service provider has 50 customers all demanding regular audits of their cybersecurity setup, each with their own audit checklist, it’s going to be a significant drag on their ability to provide the service.

For me, I would want my service provider to be ISO27001 certified and I would contract for them to have a mechanism to report to me, in business rather than technical terms,  cybersecurity risks and incidents specifically impacting on my organisation, along with  business level recommendations on what to do.

That way, they do the IT and I keep accountability for the business impact without the need for internal IT expertise – I buy the dog and I stop barking myself.

That’s a brief skim through the four ‘Ps’ and why I think they are important. If you latched onto the keyword ‘GDPR’ and expected this post to answer all your prayers, you may now be sitting there in frustration muttering about motherhood and apple pie. I’m sorry if you are, but I felt that sometimes it’s good to step back (not on scaffolding) and get back to first principles with this kind of thing.

On the other hand, if you’ve found this post has been helpful, thought-provoking or at least entertaining, I’m glad. It also gives me the opportunity for a shameless plug, as there’s more on my website, and I’m open for consultancy and writing assignments on a ‘pay as you like’ basis.


One thought on “The Elephant Man, GDPR and four Ps to prevent panic

Leave a Reply

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

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

Facebook photo

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

Connecting to %s