I recently jumped on the GDPR bandwagon with a blog post about it, and I couldn’t resist coming back to it.

In that post I argue the importance of the ‘Four Ps’ in complying with the regulations: does your implementation address the fundamental principles, are those principles all pertinent to your organisation, and are your GDPR measures practical and pragmatic for your organisation?

After all the hype and angst leading up to the regulations coming into force, I’m taking a step back and revisiting how we are doing against these Four Ps, remembering that, like a puppy at Christmas, GDPR is for life, not just for May 25^th.

Our understanding of GDPR, and most importantly, the efficiency and effectiveness of implementation and enforcement, needs to evolve and develop a long way before we can say it’s mature.  That goes for all stakeholders, from regulators to businesses and the people who GDPR is meant to protect.

That’s why this post is personal.

What I’ve seen in the last few frenetic weeks makes me think that, to put it politely, we’ve still got a way to go. Less politely, it has sometimes made this mild-mannered blogger want to go out and shake some people, and I sense I’m not alone.

Here are just some examples of GDPR madness which have pressed my buttons:

The steady stream of ‘we have updated our privacy policy’ emails, with pages of privacy policy attached which someone has spent a lot of time and effort on but I suspect few people actually read.

GDPR questionnaires from companies to their home working contractors, asking if their business premises are covered by CCTV and if they have appointed a data protection officer.

Articles telling organisations they are responsible for GDPR compliance throughout their supply chain, and that this means they are going to have to start auditing all their suppliers.

Threads on social media going into great detail and agonising over how to deal with backups.

Webinars telling small businesses they need to spend money on the full range of GDPR measures because they process files containing personal data on another company’s behalf, even though they’re not doing anything with that personal data outside those contracts.

Seeing these and similar examples, and faced with the urge to give some people a good shoogle*, I remind myself that any undertaking like GDPR is almost bound to throw up cases like this.

GDPR has to cover all the many different ways we process personal data, and it needs to cover them across a huge variety of sizes and types of business, so we should expect this kind of anomaly.

However, the anomalies still need to be addressed so that GDPR is deployed in the most efficient way, and to avoid the bad press which can damage its credibility and thus its effectiveness.

This is largely about all stakeholders in GDPR continually reviewing and improving their implementation against the four P’s.

We should constantly challenge ourselves, not just on whether we are adhering to the letter of the GDPR requirements, but on whether we are satisfying the underlying principles, whether all our GDPR activity is pertinent to those principles, and whether our implementation is as practical, pragmatic and therefore as cost effective as it can be.

I think we should also take a hard look at some of the specifics and seek ways to deliver them more efficiently without compromising GDPR principles. For example, I think there’s a need to:

Rationalise Privacy policies – There seems to have been an industry around creating new privacy policies, updating existing ones, and producing templates for organisations which have never had one before.

Yet surely every privacy policy is saying mostly the same thing, namely stating a promise that I will adhere to the GDPR regulation in the way I handle your personal data, and letting you know what to do if you have a problem with it.

As a customer, I’m not really interested in any more detail than that unless and until I have a problem with what your doing.

I believe there’s a lot of potential to simplify and standardise in this area.

Every day I entrust third parties with things that are valuable to me without being bombarded with their policies on how they protect them.

I use a locker at the gym but I don’t expect to see a policy assuring me the gym’s not going to flog my stuff on eBay; When I board the 27 bus I don’t expect to see the bus company’s mechanical safety policy,  and if I have to get past the supermarket’s food hygiene policy to buy a scotch egg I’m going to get cross.

Of course, these examples aren’t exactly similar to GDPR because there are well established standards and regulations in these areas which we take for granted, and abuse isn’t generally an issue. If there was a sudden global epidemic of thefts from gym lockers I might expect to start seeing my gym’s policy being displayed.

We need to think in terms of moving personal data regulation in the same direction so that the policies can become implicit rather than explicit and we can save all the effort on generating bespoke privacy policies which fundamentally don’t say much.

Offer Certification – Certification is another way to simplify GDPR implementation, minimise duplication of effort and give more assurance to customers.

When I go to the dentist, I want to know that they are qualified and certified to work as a dentist, I don’t just want to see their ‘Why I’m a careful dentist’ policy

If I’m recruiting new drivers for my taxi company, I’ll take a clean driving licence as reasonable, independent evidence that a prospective employee is a safe driver. I won’t go creating my own version of the driving test to check them out.

I can’t see any reason why similar certification should not be applied for GDPR, yet I see little evidence of it. ISO27001 provides certification standards for Information Security Management, and there are programmes like Cyber Essentials for cyber security, but neither has anywhere near the scope or penetration to underpin GDPR implementations.

Without appropriate certification we run the risk of companies trying to protect themselves by all coming up with their own GDPR compliance evaluations for their suppliers, and suppliers being deluged with slightly different requirements from  all the companies they supply.

With certification, this process can be carried out once for each company, in a consistent way.

Differentiate passive from passive processing – We should apply appropriate safeguards depending on whether an organisation is processing personal data actively, as an integral part of a business process, or passively, where it is incidental to that process.

If I’m running a database backup, or if I’m translating, proofreading or reformatting a file, that’s passive processing. Some organisations only ever process personal data passively, for someone else.

The ICO registration self-assessment partly recognises this distinction, so you do not need to register with the ICO if you only process personal data on behalf of another organisation, but I think there is still some confusion around it.

I know of instances of GDPR consultants advising small businesses doing only passive processing that they still need to register and put in place privacy policies and all the full machinery of GDPR.

On the flipside, I shouldn’t be absolved of all the personal data protection requirements if I’m only processing data passively; for one thing, I still need to protect that data from theft.

There’s a reasonable argument that I shouldn’t be processing personal data at all if it’s incidental to the business process. Redacting all personal data where it’s being processed passively would certainly remove a headache, but it’s largely impracticable without automation, which I discuss below.

Given that we don’t have the required level of automation, I think we should consider putting passively processed personal data into a separate category, subject to basic data protection requirements but out of scope for disclosure, deletion and the other GDPR requirements pertaining to active data processing.

Passive processing is normally carried out as part of a subcontracting process, so if I am processing personal data passively on behalf of a client I should have to declare in my simplified Privacy Policy that I meet the GDPR requirements for passive processing of personal data, i.e I will protect the data from theft or abuse and I will not use it actively for any purpose.

Exploit Technology  

GDPR faces some similar challenges to those faced by PCI (Payment Card Industry) requirements a few years back. PCI was about having auditable measures in place to protect payment card data, and GDPR is  doing the same for personal data.

The challenges of PCI inspired technology-based solutions; mechanisms to redact card numbers from call recordings, to spot and block the export of card data in emails, and to hold card data in secure data vaults, with untraceable tokens replacing the card number in transactions.

This last innovation also delivered customer benefits, enabling us to make repeat online purchases securely using this token linked to a card record held securely in the vault, rather than having to re-enter card details every time.

I believe GDPR has the same potential to drive innovation, and the specifics look similar to the technology which made PCI less painful.

I see an ideal world where the master version of all my personal data is held in a single secure vault, with a token managed by an independent broker to control all other access. When I enter a contract, it grants use of the token and sets up rules for the contractor to be able to access the master data needed to fulfil the legitimate purpose.

So if I’ve said that I don’t want the contracting organisation to share my data, I know for sure that they can’t. If they do share my token, it’s no good to anyone else because they won’t be able to get past the broker to access my data.

I can sleep more soundly, and the contractor can rest assured they can’t make a mistake and get that early morning call from the ICO.

This kind of identity management is a whole separate subject in itself, with a load of work in progress on it. Nonetheless, there are many ways in which technology could help GDPR become more effective and efficient.

Token technology could be applied at a business level so that at least there is just one master record of all customer data within an organisation. Tokens can then be used in secondary data sources and backups to simplify the processes around access and deletion requests. You have one version of the truth, and if you delete the master the tokens become meaningless.

Even without tokens, current technology should allow us to be able to sweep and collect or delete all personal data across all databases, or redact personal data from backups and archives.

I trust that some of this technology will make it into mainstream use soon, especially given that there’s a buck or two to be made from it.

 

 

GDPR is clearly the right thing to do in a world where we’ve seen that personal data is an increasingly powerful and dangerous tool in the wrong hands.

So far, I think it’s being pushed in without enough regard for efficiency or practicability, particularly for small organisations.

I’m partly reassured by statements from the ICO statements indicating that it’s about showing intent and working together to meet the principles rather than jumping on small businesses from day one.

In spite of that I still think we have a lot of rabbits caught in headlights, and a lot of people selling them sunglasses.

That’s why I think we need to start thinking seriously about GDPR the sequel and how we really make it work, and I hope the ideas I’ve put forward in this post might at least start a few people thinking in the right direction.

* Shoogle (verb, Scottish vernacular) – to agitate or vibrate.