Transforming Data Protection by Design and Default


If you feel your organisation’s interest in all things GDPR has waned a little over the past 18 months, or you’d like to read about how other companies are reengaging their colleagues’ interest in data protection - then this article is for you.

So cast your mind back to 18 months ago – in 2018, the GDPR scored higher in Google’s search rankings than either Beyoncé or Kim Kardashian, notching up over 300,000 media mentions.

Nearly every CEO, CFO, Board, and group of trustees worried about the possibility of mountainous fines that could reach up to 4% of global turnover, whilst every DPO on the planet rejoiced that their profession was cool at last.

So, all was well, we were feared across the globe. It was mandated under the GDPR that we were taken out of the backroom and now reported into the highest management level in the organisation. Our skills were in enviously high-demand – organisations registered an estimated 500,000 DPOs across Europe.  

Then the 28th May 2018 came, and it went.

And we waited. And we waited for those fines that would exonerate us for all the hard work we’d put in, and the costs our businesses had notched up over the past couple of years in preparation for the GDPR

Yes, initially they were slow to arrive, and we looked like we might have cried wolf a bit, but over the past 12 months the fines across the EU have grown.

In case you need reminding, and so you can share the facts with your potentially disillusioned colleagues, the top performing fines can so far be split into the following categories:

  • 49 fines - Article 5: “Non-compliance with general data processing principles.”
  • 30 fines - Article 6: “Insufficient legal basis for data processing.”
  • 27 fines - Article 32: “Insufficient technical and organisational measures to ensure information security.” (This is the one that got both British Airways and Marriott International)

This is a useful enforcement tracking website if ever you have an hour to spare to keep an eye on who’s the latest to get fined and for what. In fact, if you’ve got a rogue function or two in your own business, and you need a case study example to show your boss why they need a bit of tidying up, you can usually find something that looks pretty similar to what your company might be doing, and why it’s a good idea to change course.

One example shows Delivery Hero, in Berlin, which had not deleted accounts of former customers in ten cases, even though those data subjects had not been active on the company's delivery service platform for years - in one case even since 2008. In addition, eight former customers had complained about unsolicited advertising e-mails from the company.

Do you want to hazard a guess at the size of this fine for insufficient fulfilment of the data subjects rights? 195,000 Euros.

Another one is PWC, in Greece, where the organisation was processing employees’ data under consent rather than contract – which earned them a 150,000 Euro fine.  

So maybe showing colleagues how fines are affecting other similar companies may help reengage them but what else can you do to keep the dream alive?

There is the option of fanning the flames by showing the extended impact of a data breach on a company’s share price and trading position, as well as the damaging effect adverse PR can have on a company. But even here, it would seem some companies do have an ability to bounce back.

Take Equifax for example.

The organisation suffered one of the biggest breaches of all time. It cost them about $300m in non-recurring costs. The PR was damning. There are still at least 19 pages under the search term “Equifax Data Breach”. And yet their share price has bounced back to the pre breach levels

Another one of my favourite bounce-back-from-a-data-breach examples is Ashley Madison. Yes, the dating website that encourages married partners to have an affair because life is short.

For those of you who aren’t familiar with the company or its past – at the time of the 2015 data breach the business had amassed a userbase of around 30 million cheating spouses, in more than fifty countries around the world.

According to the FTC complaint post-hack, Ashley Madison "had no written information security policy, no reasonable access controls, inadequate security training of employees, no knowledge of whether third-party service providers were using reasonable security measures, and no measures to monitor the effectiveness of their system security."

You would think that the wholesale leaking of the data of 30 million cheating spouses might prove existential.

It did not.

Initially, the massive data breach cost the company a quarter of its revenue, plans for a reported IPO on the London Stock Exchange, which would have valued the company at $1 billion, were unsurprisingly scuppered.

That should kill a company off, right?

As things stand today, Ashley Madison has re-amassed around 32 million new users since the hack, and they ended up rebranding their name to Ruby in 2016.

But the more interesting change they made was cultural, and that’s what I’m writing about today.  There's now proper recognition of the damage the data under their charge can cause.

Their CEO, Paul Keable explains "We have members' privacy at the heart of everything we do," In fact, we were even awarded the Privacy by Design certificate run by the former privacy commissioner of Ontario.”

And it’s the importance of Privacy by Design that I want to concentrate on here, and how transformative embracing this concept can be to a business - even one like Ashley Madison.

By which, I mean putting privacy at the heart of everything a company does - effectively baking it into the company’s DNA.

Privacy by Design is a concept which was originally developed back in the 1990s by Dr Ann Cavoukian - the Ontario Data Protection Commissioner that the CEO of Ashley Maddison referred to. She set out her seven foundation principles with the notion that it’s not enough for a company to be compliant with the regulation - privacy must be embedded into the design and architecture of IT systems and reflected in the policies and procedures of the entire company.

Shortly after this, the term Data Protection by Design and Default was encouraged to be incorporated into the emerging legislation. It was felt that the data protection principles within GDPR were insufficient in themselves to ensure that privacy principles would be embedded into technology.

And so Article 24 and 25 emerged with the Responsibilities of the Controller.

These require controllers to implement “appropriate technical and organisational measures to demonstrate proper processing”, and measures such as data protection policies were encouraged, as well as the approved codes of conduct.

Article 25 gives more specifics around the sort of measures that could be used, such as pseudonymisation and data minimisation, as well as the implementation of measures which assure data protection by default.

When read in conjunction with Article 32 (which covers security), this extends the measures a company should consider for privacy engineers and IT professionals, as well as extending the need for the recognised importance of privacy across all parts of the business.

The requirements of default controls carry the obligation for companies to minimise the amount of data they collect and the extent of the processing, storage and accessibility. Recital 78 adds even more detail, and states developers of technology are required to design products from the get-go, in such a way as to enable controllers to put in place the necessary measures.

Despite all of this, the general conclusion seems to be that whilst adopting Data Protection by Design and Default is not optional - it’s a legal requirement after all – practical implementation is challenging. The Norwegian Data Protection Authority have been very helpful here, and have issued guidelines for software developers. Their guidelines look at how you should approach:

  • Training, which covers the most important areas on which to provide training and why, how to do it, and which tools to use. 
  • Requirements, this describes the measures needed to ensure effective data protection and security, and the tolerance levels an organisation should set for data protection and security.
  • Design, this takes the requirements one stage further by dividing them into data oriented and process-oriented design requirements.
  • Coding, this underlines the importance of developers using the approved tools and frameworks, disabling unsafe functions and modules, and regularly carrying out static code analysis and code review.
  • Testing, this involves a recommendation to test whether data protection and security requirements are implemented properly, and a description of what sort of security testing should be carried out.
  • Release, this looks at how an incident response plan should be established, and how a full security review of the software should be carried out.
  • Maintenance, this looks at the upkeep of the software and how to respond to incidents.

This set up is exactly what Ashley Madison – or Ruby - was effectively forced to do, but there are other examples that are a little closer to home.

We’ve been working with one of the world’s largest entertainment corporations to try and inspire the change in mindset needed to truly embed data protection by design, rather than just issuing employees with a set of guidelines and rules – which let’s face it, can be pretty turgid.

The company views Privacy by Design as part of its global vision, with every single employee needing to bake privacy into their practices. Recognising that accountability comes not just from senior management, but from every developer, designer or project member meant they needed an innovative method that could bring the privacy regulations to life in a practical way. The organisation wanted to increase the prominence of privacy throughout the project lifecycle, and between cross functional teams including key system architects and developers.

No easy feat, but we rose to the challenge and designed a two-day programme using experiential learning techniques that could really engage the highly creative teams’ imagination, and not just trot out PowerPoint slides. The programme is designed to get people thinking about their everyday projects, and how to make privacy a positive sum gain to the entire organisation – which incidentally, is one of Ann Cavoukian’s seven principles. In other words, the project should work for both the consumer and is an additive for the business. So it’s not privacy at the cost of a poor user experience, it’s having a great user experience go hand in hand with privacy.

This programme it has truly changed the organisation’s mindset to data protection, with the key privacy principles baked in right from the start and as the default in all services both current and new moving forward. Those who’ve been through the programme (and it’s now being delivered in 20 different global locations), have all said it’s changed the focus in their work. One was even moved enough to say “I have almost fallen in love with the GDPR.”

However, what if your organisation doesn’t have the deep pockets of a global entertainment network for a full-on training programme?

Well, there is one other thing you could consider and that’s
ISO 27701.

No, I’m not talking about the very similarly named security version - ISO 27001 - but the new addition to the ISO family, and the one which extends the security standard into our world of privacy.

It aligns with all the GDPR articles, and also allows organisations to use the standard to encompass other privacy laws, regulations and requirements such as CCPA – in case you’re dealing with that batch of weeds at the moment.

Organisations looking to get certified to ISO 27701 in order to comply with GDPR will either need to have an existing ISO 27001 certification, or implement ISO 27001 and ISO 27701 together as a single implementation audit.

Plus, if your overlords have ever asked if there is a standard for the GDPR, or a way of being GDPR “certified” – after having invested so much into trying to become compliant in the first place, you can now reveal that there is and it’s got a name.

Certainly, I can foresee within 6 months that procurement functions will start asking if a company has this standard, in the same way they ask about its security sister ISO 27001. The standard has now been introduced and certification companies are getting ready to certify, but hold your horses - you’ll need to get yourself a gap analysis first, which is essentially an assessment of how near or far you are from the standard.