It’s time to face reality, if your DPO is not technical then you’re missing out. In this episode I discuss why tech skills matter when it comes to privacy, why delegating tech responsibility isn’t ideal and what General Counsels should be looking for when it comes to hiring a DPO for their team.

Audio

Transcript

Hello and welcome to the GDPR Guy. I’m Carl Gottlieb, your host and resident privacy advisor.

In this episode I want to talk about something that I think about most days, and while it’s somewhat of a controversial opinion, I’m pretty resolute on it.

Your DPO does need to be technical.

I’m sorry that this might annoy a few people out there, but, actually, no I’m not sorry. The clue is the name. DATA protection officer. If you don’t understand data then you’re in the wrong job.

And you need to really understand it. Not just having a good appreciation of it, or you’ve read a few books, or been on a course. You need to know this stuff.

Okay, but “how technical?” I hear you ask. Well, in my view the more technical the better. As a DPO you have a lot of responsibilities, but one of the major ones that plays out in the real world, and isn’t mentioned in any privacy regulation, is that it’s often your job within the Legal team to be the translator – the intermediary between technical people, the business and legal compliance. You might have a product manager proposing a change or an engineer asking a question about a backend data flow change, and more often than not, the legal and compliance team will not be technical enough to understand it. And asking techies to explain it in your non-technical language doesn’t help because they will always represent their work using their own lens.

For instance a product manager will often describe matters in visual terms, such as a bunch of figma product diagrams.

“Here is where the user logs in.”
“Here is where we ask them for their phone number.”
“Here is where they log out.”

But they’ll often not be able to describe how data actually flows and what happens behind the scenes for each of these interactions.

Engineers are similar. They see their own siloed world and often won’t be able to tell you about what else is using that piece of data or what the lifecycle of a data element is.

It’s not that people are hiding the truth or deliberately lying to you when you ask them for all the technical details. They’re just thinking about their own world and giving you what they know.

A DPO needs to be a consultant here, probing, auditing and investigating to find out exactly what is happening. And that involves challenging those subject matter experts about their own domain. You need to be asking those product managers about user experience. You need to be asking those engineers what data is in that communication with the API.

And most importantly you need to be able to smell the BS, spot the gaps and get technical.

And as much as you need to be technical for your own DPO auditing and advising work, your legal and compliance team is relying on you to translate it back to them in full, in a language that they can then comprehend.

And even bigger than that, as a DPO you need to represent the company both to regulators and to customers. And you had better know your beans when you have to talk to them live. I mentioned this on a previous podcast but as a DPO your organisation should be able to wheel you out to talk to customers to help them understand and gain trust in your products. And this can mean talking to a customer who is both technical and motivated to scrutinise exactly what you’re doing with their data.

If I had to list some examples of what I’d expect a DPO to do technically, it would be something like this:

Build a website themselves using any tool they like.
Deploy Google Tag Manager onto that website to deploy Facebook pixel.
Integrate a cookie banner into Google Tag Manager and require consent for the Facebook pixel.
Create a zapier workflow with webhooks to integrate applications together.
Analyse a website for what scripts and cookies are running on it.
Put a CDN such as Cloudflare in front of their website, and reconfigure the DNS.
Create a Facebook custom audience and launch targeted ads on your website.
Create a subscription mailing list and send emails with a tool like Mailchimp

Now these are all basic things, but being able to do all them easily equips you with a good all-round knowledge of web technologies and enables you to talk with most product managers, engineers and marketing people out there.

And if you consider the alternative, how are you going to handle a situation where an engineer tells you that your company’s app will now support webhooks and is that okay?

The DPO is a senior figure in the organisation, or at least it should be. And a DPO will lose credibility if they can’t understand at a basic level what basic tech does. The DPO should always ask questions and feel free to ask about what they don’t understand. You can’t be all technical. No one is. But there is a basic level you do need to start from.

I get that for some DPOs out there, their attitude will be that they’re not technical and don’t want to be technical. And that’s fine, but you pigeon-hole yourself into a tight spot where your value to the organisation is limited and you’re always reliant on having a team around you to explain it to you. And anything you do then pass on to your legal team is second-hand knowledge that might not be 100% accurate. And in tech, accuracy matters.

If I was a General Counsel hiring a DPO I would ask the potential DPO these questions:
“Can I rely on you to be the technical liaison between legal and the product, engineering and marketing teams?”
“When we have those technical meetings can you take the lead for our department?”
“Show me or explain some examples of technical work you’ve done in the past.”

Again, technical prowess for a DPO comes down to how good a DPO they want to be. And DPOs should want to be the best, and their managers should demand the best.

The best DPOs do need to be technical.

Thanks for listening.

More Episodes of The GDPR Guy