GDPR: Who's Responsible for the Right to Be Forgotten in the Client-Agency Relationship?

Welcome to the next part in my series of GDPR posts exploring the practicalities of the GDPR in the client-agency relationship. You can view my previous posts here. This time around, I’ll be exploring the “right to be forgotten”, specifically what it is and what impact it has on the implementation and operations within a project.

What Is It?

The “right to be forgotten” (or “right to erasure” – removal, not the 80s band!) came out of a pretty famous court case from 2014 involving Google Spain. The ideas and rulings from that court case have been channeled directly into the GDPR.

To put it simply, a customer can ask you to forget everything you know about them. At this point, the Data Controller has to remove all customer data that they are holding.

As with most things, there are certain exceptions, e.g., if the data is needed for health or scientific research, or if the data is needed for a legal claim. That aside, this is an important piece of functionality and needs consideration.

There is a subset of this related to profiling using marketing software such as Kentico EMS or Marketo to track customers on the website, gathering implicit and explicit information. The customer is within their rights to request that any profiling ceases immediately if they so choose.

What Do We Need to Consider?

On the face of it, this seems like a simple request—delete a record when asked. However, the reality is very different. Data is not always held in one system so “removing that record” swiftly becomes “removing multiple records”. To complicate this further, the process itself could be initiated through a range of channels (e.g. website, direct email, mobile application) but it’s important that the process remains the same across the business.

When you are looking to build out your “right to be forgotten” process, you need to consider four specific items:

• The mechanism(s) that the customer can interact with to initiate the process
• The mechanism(s) for removing the customer’s data
• The audit trail
• The reporting mechanism to the customer (e.g., email notifications of the deletion process)

When it comes to profiling, you need to follow a similar process:

• The mechanism(s) that the customer can interact with to initiate the process
• The mechanism(s) for halting profiling and, if requested, removing the customer’s data
• The audit trail
• The reporting mechanism to the customer (e.g., email notifications of the deletion process)

How Can Your Agency Help?

As I’ve mentioned in previous posts in the series, the scope of customer data available to the agency (Data Processor) is a few pieces of the jigsaw. There’s a larger challenge facing you (the Data Controller) and you will be ultimately responsible for getting this process in place but the agency (Data Processor) has a part to play in fleshing out the process.

This can be broken down into a set of steps for the client and agency to work through to plan out this process and then implement it.

• The process starts with identifying the systems and channels that the agency is working on for you, e.g., website, marketing software. We need to be clear on what should be covered in the process.
• We then need to understand what functionality is provided by the CMS or solution underpinning the project. We’re specifically focusing on functionality related to the “right to be forgotten”.
• After that, we must identify the gaps. The DPO can provide support here to lay out the entire functionality required to achieve compliance, and we can then identify missing functionality and map out the work involved in fleshing out these gaps. This is going to include ensuring that there is a sufficient audit framework/trail in place.
• With all of this in place, we can then implement the required functionality.
• We should also consider wider timescales involved in stopping profiling and/or removing a customer’s account and determine the mechanism for informing the customer of this.

The entire process should be documented for auditors/investigators and may need to be factored into SLAs and contracts established between the client and the agency.

What’s Next?

The “right to be forgotten” is an important process within the GDPR and hopefully this post has given you some insight into the conversations you should be having with your agency. In my next post in the series, I’ll be taking a look at data portability.

Kentico 11 and GDPR

I will be hosting a GDPR webinar on November 23 at 3:00 PM - 3:30 PM GMT to tie in with the upcoming release of Kentico 11. I’ll be exploring the regulation in relation to the CMS platform and looking at how you can ensure your websites are compliant. If you would like to register, you can do so here.

Do you have any opinions or feedback based on the article you have read? If so, I would love to hear from you. Please share them in the discussion section below. The topic of GDPR is one that is dear to our hearts. Check out some of the critical points you should be addressing here.

DISCLAIMER: All data and information provided in this blog post are for informational purposes only. Kentico makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information contained herein. We recommend consulting with a lawyer for any legal advice pertaining to GDPR compliance.