My role as Co-Founder of Digi-Board includes responsibility for our compliance with #GDPR. I trained at Henley Business School under Prof. Ardi Kolah and learned that a focus on compliance alone is the wrong way to put in place ‘privacy by design’.
Digi-Board is a customer of GoCardless to process online payments and I republish below an article (June 2019) sharing practical real world experience of GDPR from the Data Privacy Officer of GoCardless. A great read for senior management and data privacy professionals.
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
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
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
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
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
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
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.
Credit to GoCardless.