GDPR one year on: 5 things we’ve learned about scaling a privacy programme

Remember when GDPR was coming into effect last year, and every organisation we’d ever had contact with decided to send an email?

Some asked for our consent, some just checked in. More knowledgeable companies, or those who had taken good advice, didn’t email at all, trusting that solid privacy practices in the lead-up to GDPR made it unnecessary.

At the time, we shared details of our privacy programme; one year on, we’ve had a chance to experiment. We’ve learned some of what works, and what doesn’t. And regulatory guidance, events and enforcement have started to shed light on what good looks like for GDPR.

Yet the discussion at every privacy event I’ve attended in the last year, and every panel I’ve spoken on, inevitably turns to one topic...

How do you achieve privacy at scale?

How do you comply with every prescriptive element of GDPR, and meet the principles of the regulation, in a way that minimises unnecessary distraction from your core business? In short: how do you create ‘privacy by design’?

Few companies hire enough people with ‘privacy’ in their job titles to meet all the requirements of GDPR. It follows then that if privacy sits on top of normal business processes, it won’t scale.

With that in mind, here are five things we’ve learned over the last year about embedding privacy in the business.

1. Speak the language of the business

We didn’t get this right the first time around. To build our GDPR-compliant register of processing activities, we used questionnaires sent out from an off-the-shelf tool.

We asked all our data processing teams a lot of questions – all the wrong ones, as it turns out. “Can you identify a lawful basis of processing for this activity?” “How are you meeting the principle of purpose limitation for this activity?”

We knew we had gotten it wrong when we looked at our GDPR-compliant register and saw dozens of different variations on the term “not sure”!

In v2.0, we took a different tack. We asked the business only the questions we knew they could answer, like – what are you trying to do with the data, what data do you need to do it, what systems help you accomplish it. As a result, our updated register is clear, actionable and easy to keep up-to-date.

2. Be where the business is

We can’t have a privacy expert in every meeting – there aren’t enough of us, and even if we could be everywhere all the time, it would just slow things down.

But that means almost every GoCardless employee will at some point have to make decisions that have a privacy impact… like scoping a new product, choosing a new supplier, or training a new data model.

I have seen even very well-designed privacy programmes fail when they just aren’t adopted by the business.

When people are asked to step out of their day-to-day role, they’ll tend to take the path of least resistance. It’s not because they don’t want to do the right thing! But even if they understand what we need them to do (and see point 1), the process we’ve created might just make it hard for them to do it.

Privacy processes can’t stand alone, they need to be part of business as usual. Our head of data puts it nicely: we need to make it really easy for people to do the right thing and really hard for them to do the wrong thing. Which leads to…

3. Automate as much as possible

As the privacy field matures, we’re starting to see tools offering out of the box automation and compliance.

The problem with many of these is that they offer a standalone experience: a tool for managing data processing agreements that doesn’t sit within a broader supplier contracting function; a tool for tracking data subject access requests that can’t be used by Support, a data protection impact assessment that isn’t part of the product development lifecycle.

Privacy processes that don’t fit within a broader business context will take people out of their day-to-day. Then, if they’re done at all, they aren’t done well.

We’ve found it more effective to start with the business – what does their day-to-day look like? What documents do they create, what tools do they use, what are their decision-making points?

Those are opportunities to ask the right questions at the right time, and to be able to escalate to the privacy team where necessary.

For example, when our data teams build a new feature, they’re prompted from within the process itself to identify a business purpose from our (now clean and up-to-date) GDPR register. If a business purpose isn’t present, the model can’t be built. And if there isn’t a suitable purpose listed in the register, then it’s an indication that something new is happening that needs privacy review.

The process also gives us an audit trail that we can test to make sure the right decisions are being made.

4. But beware of silver bullets

Automating privacy processes can end up working against you. Some companies make programmes scalable using checklists. But this approach can backfire.

Layers of bureaucracy badly applied disempower employees, keep them from being accountable for privacy impacts, and lead to unexpected risks (“this wasn’t on the checklist, so it must not be a problem”).

We’ve been careful to keep our processes simple, and focused heavily on training and guidance for our teams.

For example, we’ve launched training for our product managers and functional leads, giving them the resources to think about building privacy into our products from start to finish.

One resource has been a particularly useful part of our product scoping documents and privacy impact assessments: A tailored taxonomy of privacy risks that helps guide thoughtful conversations about minimising unintended or unlawful consequences from the use of personal data.

5. Listen to what your programmes tell you

GDPR allows data subjects to exercise their rights with the data controller. The two rights requests we see most often are subject access requests and subject deletion requests.

Early on, we made a decision that subject rights requests don’t go straight to our privacy team. They are handled first by our customer support agents using their own tools (Zendesk macros and our Support Hub), before they go to our rights request software to track to completion.

This has been very successful for two reasons: First, these requests don’t happen in isolation. Sending the requests to Support first brings them to the people who are best trained to identify and resolve the underlying problem (supported of course by training and resources from the privacy team).

Second, our Support team has an enormous amount of experience with metrics and KPIs. Using their tools allows us to keep close track of SARs as well as other complaints, questions and incidents.

How quickly and efficiently we can handle an access or deletion request tells us a lot about the health of our privacy programme, and tracking these metrics is one of our key risk indicators.

We track other risk indicators too, like marketing unsubscribe rates, supplier risk ratings and time to respond to data-related legal tickets. These tell us a lot about where the gaps are and allow us to optimise.

That feedback allows us to make constant incremental improvements to the programme, and also helps us meet the principle of Accountability, the heart of GDPR.

What tips do you have for scaling a privacy programme? Join me on LinkedIn to continue the conversation.