Handling Deletion Requests as a Data Processor

The GDPR, the CCPA, and now the Texas Data Privacy and Security Act all give people the right to have their personal data deleted. Most writing about that right targets the business the person dealt with. But when you are the data processor holding someone else's customer data, a deletion request is a different problem, and the first thing to get right is whose instructions you follow.

A processor acts on the controller's instructions, not the data subject's

As a data processor, you act only on the data controller's instructions, and the controller is usually your customer. Unless your contract says otherwise, a data subject who asks you to delete their data should be redirected to the controller.

That puts companies like email service providers in an awkward spot. Recipients expect to handle housekeeping like unsubscribes through the provider rather than the sender. Many will also try to save themselves several requests by sending one deletion request to a single common point of contact: the provider. It is an understandable instinct. It doesn't change your role: act on the controller's instructions.

When the person makes the request to the controller, the controller will come to you for your part. The controller has its own statutory deadline, generally one month under the GDPR and 45 days under the CCPA and the TDPSA, and your contract should give you a shorter one so the controller can meet its own.

A deletion request moves through four steps

Once a deletion request reaches you through the controller, the work breaks into four discrete steps.

1. Verify the request. You will usually rely on the controller's verification, and your contract may specify who can send you deletion instructions.
2. Find every instance of the person's data in your systems, including databases, logs, and backups. A provider with a mature privacy program will already have most of this in its data inventory and flow maps.
3. Permanently delete the data and confirm no residual copies remain in active systems.
4. Tell the controller the deletion is complete so it can confirm with the person.

Backups, retention duties, and technology complicate deletion

Deletion is rarely that clean in practice. Data is scattered across systems, including cold and offsite backups, and your procedures need to account for all of them. The CCPA regulations allow a business to delay deleting data held in archived or backup systems "until the archived or backup system relating to that data is restored to an active system or is next accessed or used for a sale, disclosure, or commercial purpose."¹ Article 17 of the GDPR has no comparable exemption for backups, although data protection authorities have issued guidance that helps address the question in practice.

Some data has to be kept for legal reasons, such as sales records retained for audit by taxing authorities. Take your guidance on those from the controller. And some technologies make complete deletion genuinely hard. Your processes need to address those limits honestly rather than assume they don't exist.

The contract should settle deletion before the first request arrives

This goes more smoothly when your contract with the controller spells out the process, including what happens when a request comes to you instead of your customer. It should say how the controller will notify you of deletion requests, how you will identify the right person's data, and how you will confirm deletion back to the controller.

Negotiate those terms before the first request lands in your support queue, because once it does, the person waiting for an answer has a deadline running whether your contract addresses it or not.

This post does not constitute legal advice. Readers should consult competent legal counsel before taking action based on the analysis presented here.