Being a Data Protection Officer is a very interesting, challenging job if you’re interested in business processes, data security, lifelong learning, lively discussions and sharing legal views or interpretations. While a lot of the job revolves around the GDPR, it is much more varied than that. I hope I’ve been able to give you some insight in what a DPO does from day to day!
A day in the life of a Data Protection Officer
In our last blog post about GDPR, we looked at the state of GDPR 8 months after it went into effect. Today, we’ll look at what the content of the job of a Data Protection Officer exactly is. What could a Data Protection Officer (DPO) possibly do besides looking at implementation methods for a European regulation, or answer questions from his customers about the same topic? A day in the life of a DPO, what’s that like?
Data protection impact assessment
A typical day starts at 8:30am in the offices of a customer where meetings (one after the other) take up the whole morning. Preparation for these meetings is key. There’s professionals in front of you: CFOs, legal counsels, CIOs, CEOs, ICT development & ICT infrastructure managers, GDPR coordinators, … These people know their business, so you better come prepared!
A recent example of such a morning is with a customer where we need to finalize a data protection impact assessment (DPIA). A DPIA is a way to assess the privacy risks of data processing beforehand. The methodology we use is the CNIL application approach. That day, we discuss the consequences of the ‘DPO validation step’ which I prepared the day before. The meeting’s attendants are the COO, the HR director and myself and although the DPIA did not produce a ‘high or very high risk’ for the assessed processing activity, we find that we do need to define certain actions or mitigations for some smaller risks related to some flaws we found in the process. Being the Data Protection Officer, I had defined the required actions to mitigate each of the documented risks that we found and these now need to be discussed, approved and added to the action list with deadlines and responsibilities.
Compromise is key...
It is worth noting that a DPO only has an advisory function and does not have the mandate to take decisions. However, if, in this case, the COO or HR director would not agree with one or more of my proposed to-dos and we can’t agree to an alternative with the same result, the company needs to document and motivate the reason(s) why they didn’t follow the DPO’s advice.
Fortunately, we had a good meeting with a very good discussion on one of the mitigating actions with an interesting compromise as a result. This is why the discussion is so important: an external Data Protection Officer needs to understand that the knowledge of the business processes, the business risks, the business value and commercial proposition is far better known by the company than by themselves and it’s mandatory to listen to the customer. But, and this is a very important but, it doesn’t mean that we can bend the rules! In this case, we came up with a valid compromise but in other cases (with another customer) we hadn’t, which implied my advice wasn’t accepted and the required documented motivation was written.
As the meeting came to an end sooner than I expected, I had some time left. The marketing manager took this opportunity to discuss the possible impact of the GDPR on the next marketing campaign that was still under development. The campaign itself was very nice and creative, but since interactivity with the (potential) customer was a key part of it, the GDPR indeed had a certain impact. This meeting took a bit longer than “just a quick question”. 😊
... and so is context!
For that particular day I went to our office for the afternoon. When I’m at the office, I mostly prepare customer meetings, review Data Protection Agreements, prepare policies, presentations, trainings (e.g. Privacy by design for IT development) and DSAR (Data Subject Access Request) concepts. Additionally, I answer questions from our customers:
- "I have been asked to... Can I do this?"
- "I would like to add this functionality to our website. Does the GDPR have any impact on it?"
- "We would like to implement an MDM tool. Is that OK?"
- "An ex-employee sent a DSAR and would like to receive this specific information. Do we need to give it to them?"
Of course, these are just a few examples. In reality, there are many more questions of all types all from different companies with different processes, different culture and policies. The same question may have different answers, depending on the situation or company. Knowing the legislation (and this means more than only the GDPR) is a basic requirement but unfortunately, that’s not enough. The interpretation for specific situations and knowing how to explain these within different types of companies in such a way that people accept it is one of the more challenging aspects. After all, not everybody loves the GDPR… 💔