GDPR: Who Should be Your Data Protection Officer? "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 4 December 2017 True Data Protection, data protection officer, DPIA, Gdpr, Product Management Role, Skills, Strategy, Mind the Product Mind the Product Ltd 2089 Product Management 8.356
· 10 minute read

GDPR: Who Should be Your Data Protection Officer?

On May 25th 2018 something big is happening which needs your attention. In what is the biggest shake-up to data protection legislation in 20 years, the EU’s General Data Protection Regulation (GDPR) will come into force.

The aim of the GDPR is to strengthen data protection for EU citizens and residents, to give them greater control of their personal data, and to simplify the regulatory environment. The GDPR will also apply to countries outside the EU who have customers within the EU. And even though the UK is leaving the union, the UK government has confirmed that the GDPR is here to stay.

The Cost of Getting it Wrong Will go up

The GDPR will mean heavier fines for companies where a data breach occurs. The maximum fine currently for a breach is £500,000 ($625,000), but this will rise to the larger of up to £17 million ($21 million) or 4% of global annual turnover for the preceding financial year. TalkTalk was fined £400,000 in 2016 for failing to have appropriate technical and organisational measures in place to secure its customers’ personal data, and for keeping their personal data for longer than necessary. Under the GDPR this fine could have risen to £73.5 million.

The GDPR will require a solid understanding of current data protection rules. If you see yourself as a data processor (meaning you process personal data on behalf of a data controller) rather than a controller (meaning you determine the purposes for which and the manner in which any personal data is processed) then GDPR is still relevant because data controllers will be coming to you to make sure you are ready. In the UK some data processors are already being asked for unlimited liability in their contracts.

Why Product Needs to Care

Why am I writing about this for the Mind the Product blog? The GDPR introduces the statutory position of Data Protection Officer (DPO), with the task of ensuring that a business complies with GDPR. As the newly crowned DPO at my company I believe a product person is the best placed to help a business implement a strong data protection policy in readiness for GDPR next year: after all, a product person should have an overview of the business and know where data is used.

Set out below are the lessons I’ve learned as our DPO, and some of the steps we’ve taken to get ready for the new regulations.

Do you Need a Data Protection Officer?

If your organisation is a public authority, or you deal with special categories of data like criminal convictions, or you carry out large-scale monitoring of data, then you will need a DPO. There are other recommendations which are relevant for startups and tech companies; if you process a large amount of personal data, for example more than 5,000 personal data records in a 12-month period, then I think you should have a DPO. I imagine many of you get more than 5,000 people signing up and using your service each year.

How Will GDPR Affect Your Customers?

The GDPR strengthens the rights of your customers in a number of ways, including:

  • The right to object. A customer can object if their details are being used for direct marketing, or if they have legitimate grounds to object on how their data is being processed.
  • The right of access. A customer can request access to their data. You need to know where the data you took came from, to whom it might be disclosed, and be able to tell the customer about any logic involved in any automated decision. You must reply to a request for data within one month, and a customer can also authorise a third party to get the data. A useful toolkit for subject access is here.
  • The right to be forgotten. If the processing of the customer is not in compliance with the GDPR the customer can ask for their data to be erased.
  • The right not to be subjected to purely automated processes. For example if a customer is refused insurance by an automated system they can call and ask for a manual review.

Clearly if your current IT processes don’t allow for the above you’ll need to do some work to prepare for this. Likewise your privacy policies and data protection policies may need to be reviewed.

What Does a Data Protection Officer do?

According to Article 39 of the GDPR, a DPO should:

  • Inform and advise the organisation and its employees about their obligations to comply with the GDPR and other data protection laws
  • Monitor compliance with the GDPR and other data protection laws, including managing internal data protection activities, advise on data protection impact assessments; train staff and conduct internal audits
  • Be the first point of contact for supervisory authorities and for individuals whose data is processed (employees, customers etc)

A DPO must be allowed to operate independently and report to the board. For example, if the DPO finds that the VP of marketing needs to remove data from their machine they should be able ask them to do this – and if they don’t, be able to report them to the board without fear of reprisal.

They should also be given adequate time and resources to do their job – this may mean extra training, time with the tech team to enforce secure passwords on key systems, and so on. An existing employee can serve as the DPO, or you are also allowed to get an external consultant in to cover this role. There are some restrictions if an internal employee is your DPO – they can’t, for example, be a head of HR, head of IT or a member of the senior leadership team. The DPO should have a good professional experience of, and knowledge of, data protection law.

If you don’t appoint a DPO where one is required, the fine can be as high as €10,000,000 or 2% of your company’s worldwide turnover, depending on which is higher.

A product person should already have a good knowledge of data protection. They will have worked with everyone in the organisation – the finance teams, customer support, marketing, tech, and growth. They will know where the data in their company lives and how it moves around. They are also likely best placed to write the data protection policies and risk assessments needed to show that the company is paying attention to GDPR requirements.

Do you need a Data Protection Impact Assessment?

A data protection impact assessment (DPIA) – also known as a privacy impact assessment or PIA – is a risk assessment when you propose to process personal data. Its aim is to help an organisation identify the most effective way of complying with data protection obligations and meet individuals’ expectations of privacy.

A DPIA can be used in a variety of situations. Those which I think are particularly relevant to product management include:

  • A new database system for storing and accessing personal data
  • A project where two or more organisations look to pool or link sets of personal data
  • A proposal to identify people in a particular group or demographic and initiate a course of action
  • Using existing data for a new and unexpected or more intrusive process
  • A new surveillance system or the application of new technology to an existing system (like adding automatic number plate recognition to an existing CCTV system)
  • A new database which consolidates information held by separate parts of an organisation

As I understand it, the requirement for a DPIA under the new legislation is still under discussion, though I imagine what will transpire is that any organisation dealing with “sensitive” data will need to show evidence of a DPIA. By sensitive data I mean a data set containing health information, disability, ethnicity, sexual orientation, political or religious affiliations or criminal records.

That said, even if you aren’t processing this kind of data, I think it’s still worth carrying out a DPIA. It can only help your company to handle data more securely and give your customers faith in your ability to look after their data.

Based on my experience, if you’re a data controller then I think you should start working with your data processors now to make sure they comply with the GDPR and include their responses in your DPIA.

I’ve already started this process and it’s a little scary how some of the data processors we use did not understand their responsibilities, and we will stop using them if they can’t show they comply with the GDPR in time. You may need to start entering into data processing agreements (DPA) with your data processors, especially if you process data in the EU which then leaves the EU, Amazon for example offers a DPA to AWS customers.

You should include in the DPIA:

  • The respective responsibilities of the data controller and the data processors you use
  • The purpose and means of the processing (i.e. I’m capturing address details to fulfill product delivery)
  • Flows on how user information is used (i.e. how personal information will be obtained, used, and retained)
  • The measures and safeguards you have put in place to protect the data
  • Details of your Privacy Impact Assessment (the ICO has great guidance on PIAs here)
  • The contact details of the DPO

Responding to a Breach

There is an excellent article on the Taylor Wessing blog which gives a full rundown of your responsibilities under the GDPR when responding to a breach.

As per data protection best practices you should be prepared for a breach with a recovery plan, a strategy for how to reassess risks associated with the breach. If the worst happens and you have a breach, you should perform a review of your response and update your security policies accordingly. The GDPR doesn’t require a full report about a breach from the outset, but I would recommend that you prepare the potential scope and the cause of the breach, mitigation actions you plan to take, and how you plan to address the problem.

Opt-ins and Consent

Some opt-in boxes are banned with GDPR, so you couldn’t have a form which says “by clicking the purchase button you agree to be sent marketing information”, you would always need to provide a tick box. Consent must be freely given with a clear affirmative action used. Consent must always be specific, informed and unambiguous. You need to keep good records of when and where people gave consent. People must always be able to withdraw consent, and be given the ability to withdraw easily. The ICO has an in-depth article on how to get consent, along with a useful checklist at the end. Since publication Rob Pomeroy has added some excellent advice on opt-in consent in the comments section below.

Next Steps

If you’re still not sure if you need a data protection officer or if you need to carry out a data protection impact assessment then the ICO has a good article with 12 initial steps you can take to get ready for GDPR. However if you’re still reading this article I’d hazard a guess that you are already dealing with sensitive customer data across multiple territories. I would recommend you do the following:

  1. Choose a data protection officer. This can be an existing employee, or you can hire an external consultant. If you choose an employee you are legally obliged to give them support, training and resources, and you should give them time to do their job. It’s taken me a couple of weeks to do the data protection and get my head round all the policies and procedures, plus I’ve set a morning each week aside to make sure any issues raised in my risk assessments are addressed
  2. Start thinking about how you ask for consent, stay away from pre-ticked boxes or opt-out form fields
  3. Carry out a Data Protection Impact Assessment – mainly to make sure that any data processors you use are also GDPR ready
  4. Following data protection best practice I would review all your company’s policies and risk assessments and make sure they are up to date – I would make sure they are all collated in once central place that all staff have access to. The GDPR requires evidence of this


Well done for getting this far, hopefully my experience has proved useful. If there is appetite I’ll add some sample policies and risk registers to the Mind the Product Slack channels.

Comments 4

Hello, Owen!
Considering a company should appoint a DPO, is it sufficient to publish the information, or should the DPO be formally appointed to a supervisory authority?
Thanks for your help by sharing your experience here.

Hi Owen.

A developer colleague of mine passed me a link to your article. This is a vast area isn’t it? Just some comments on your article based on things I’ve discovered in my own GDPR journey. They which might be of interest to you & your readers?

“Under the GDPR this fine could have risen to £35 million.” It’s probably worse than that. 2016 revenue for TalkTalk was £1,838m. 4% of that would have been £73.52m. (Ref. TalkTalk annual report, 2016)
“You must reply to a request for data within 40 calendar days”. Unfortunately 40 days is the current DPA regime. Under GDPR it’s one month. (Refs. GDPR Recital 59; Article 12(3)-(4)). Ouch.
“the requirement for a DPIA under the new legislation is still under discussion” I imagine the ICO is working on updating its impact assessment guidance in the light of GDPR. The GDPR offers some helpful guidelines though. (Refs. GDPR Recitals 84 & 89-92, Article 35.)
“Pre-ticked opt-in boxes are banned with GDPR” Not all pre-ticked boxes fortunately! The soft opt-in exemptions in PECR and the new ePrivacy Regulation still apply and they definitely allow pre-ticked opt-in (or unticked opt-out). Marketing departments can take some comfort from that. (Ref. ePrivacy Regulation, Article 16(2).)

Soft opt-in is the area I’d say I’ve wrestled with most, to understand. It’s not part of GDPR, but it supplements GDPR. The EU’s ePrivacy Regulation is drafted in the light of GDPR, and it retains soft opt-in, though it removes the previous possibility of capturing soft opt-in during a negotiation for sale. Now it only applies where a sale has actually taken place.

Soft opt-in will probably save a lot of marketing departments some grief. If they’re able to demonstrate they have GDPR/ePrivacy-quality soft opt-in consent, it may not be necessary to “re-permission” their entire marketing databases.

I hope this helps a little.


Hi Rob,
Thanks for taking the time to write this. Good to be generating these conversations. The article has been updated to reflect your comments, also I’ve directed people to your advice here around the opt-in consent.
All the best

Join the community

Sign up for free to share your thoughts

About the author