We've recently exchanged emails with one of our Data Processors, because they don't grant the ability to permanently delete hosted documents (pdf, png, etc.) on their platform. Such documents might contain personal information.

In the event where an end-user would want to permanently delete such documents, we don't have the ability to do it for them (because the Provider doesn't give us any tool for doing so). Thus, we can't comply with any privacy-related request from our end-users. It also seems even the Processor cannot perform such a request in the event where we would forward the request to them. (they don't seem to have the necessary tools, either)

Therefore, we believe they don't comply with GDPR because of the Right to erasure/rectification.

The Processor doesn't recognize their responsibility on this matter, and are stating they respect GDPR regulations. Although, they haven't provided us with any meaningful reply regarding that particular matter. They're basically saying they're doing things "by the book" and sending us links to their online documentation, which do not answer the issue at hand.

At this point, we're concerned about what to do next. It feels like they won't acknowledge the issue and won't take responsibility about fixing it. We're thinking about opening an official enquiry, but we're unsure how to proceed.

Edit: The data processor is based in the US, while we are based in France (EU). We have signed a DPA with them.

  • 5
    Cancel your contract and find one that does.
    – Dale M
    Commented Apr 27, 2021 at 11:27
  • It's a bit more complicated. We use their service already (but not the documents feature) and it's not a good move for us to change our data processor at this point. Our goal would be to make them compliant by providing us with the necessary tooling, rather than simply leaving. We were wondering if pressuring them would be effective, adn how to do so. Commented Apr 27, 2021 at 15:12
  • 5
    @Vadorequest: "it's not a good move for us to change our data processor at this point." - Unfortunately, that's your problem. GDPR contemplates that you will either change data processors or contractually obligate your current data processor to help you. If you do neither of those things, then as a consequence you (not the processor) violate GDPR.
    – Kevin
    Commented Apr 27, 2021 at 17:19
  • 1
    The data processor is in the US and thus is not bound by GDPR, unless they have signed a separate contract with you indicating they agree to be.
    – TylerH
    Commented Apr 27, 2021 at 18:25

1 Answer 1


The data processor is not responsible for complying with the GDPR. You are ultimately responsible, since you are the data controller. The data processor is merely required to assist you, but it's unclear what that means in the presented scenario.

Per Art 28(3)(e) GDPR, the DPA must require the data processor to provide reasonable assistance:

That contract or other legal act shall stipulate, in particular, that the processor: […] taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III;

However, per Art 28(1) you can only engage processors that you deem sufficient to protect the data subject's rights:

the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.

Here, it seems that your company failed to ensure that the processor provides the features you need for compliance. Many companies claim to be GDPR-compliant, but that doesn't mean that your use of their services will be GDPR-compliant as well. Depending on how the Art 28(3)(e) requirement was implemented in the DPA you may have a right to assistance even if the processor doesn't implement necessary features in their software, but enforcing this contract could require a lawsuit in a foreign jurisdiction (but that's par for the course for international B2B contracts).

It is worth noting that the GDPR right to erasure doesn't always apply. In a processing activity where no erasure right is likely to arise, it would be perfectly fine to use a data processor that doesn't offer any possibility for erasure. Similarly, it can sometimes be legal to use technologies like Blockchain or Git that make erasure difficult or impossible. However, it is the responsibility of the data controller to analyze the impact of such a choice up front, before commencing the processing activities. In some cases, this could require a Data Protection Impact Assessment (DPIA).

Note that transfers of personal data into the US are illegal or at least questionable in the wake of the 2020 Schrems II ruling. The Privacy Shield is no longer a legal basis for such transfers. Standard Contractual Clauses (SCCs) are technically allowed, but only “on condition that enforceable data subject rights and effective legal remedies for data subjects are available” (cf Art 46). The ECJ's judgement calls this into question. This could be a further incentive to migrate to a more GDPR-compliant service.

  • 1
    The data processor is not responsible for complying with the GDPR., unless they claim they are? I understand the responsibility is on us, although they claim they are GDPR-compliant, and we signed a DPA. For history's sake, we didn't need to store sensitive documents in the first place, but our need have changed since then and we noticed there is no way to erase any uploaded document. Worse, they're available to anyone who has the direct link, and nobody seems to be able to disable those links. Because they claim to be GDPR compliant, and because of the DPA, can't they be held responsible? Commented Apr 27, 2021 at 13:41
  • 2
    @Vadorequest Are you relying on marketing fluff, or contractual guarantees? Because this is B2B, and usual consumer protections regarding marketing don't apply. If they've violated the contract you can sue them, but that's about the contract and not about the GDPR (which doesn't really affect the US company). It also seems your company started new processing activities with that processor without re-evaluating whether this was still compliant. If the documents are publicly discoverable (e.g. guessable URLs) you might have a data breach.
    – amon
    Commented Apr 27, 2021 at 14:47
  • I was wondering if it was a good option to open a GDPR inquiry. We haven't used that documents feature yet, so we're good, but we want/need to for our next project, and it has become quite pressing, that's why I wanted to see if it was possible to apply a bit more pressure somehow. From my understanding, both the Processor and the Controller are responsible for complying with the GDPR. I understand we'd be at fault for using their services, but the fault would be shared, considering the DPA (based on SCCs) is supposed to bind them too. Commented Apr 27, 2021 at 15:06
  • 8
    @Vadorequest What do you mean with “GDPR inquiry”? Your DPA is a contract with the processor. The US-based processor has no GDPR obligations to you except as specified in this contract. It's up to you to enforce this contract. I don't think you have more powerful tools for pressure other than “the contract says you have to do this, you aren't, so we're suing you” or “if you won't do this we're taking our business elsewhere”.
    – amon
    Commented Apr 27, 2021 at 16:18
  • In France, the CNIL usually follow-up on cases where Processors/Controllers that don't respect the GDPR (privacy matters, in general, wider scope than GDPR only), using legal actions. I was under the impression there was some entity that might do something similar regarding the GDPR in the EU. I'll look more into the DPA, maybe it can help indeed. Commented Apr 27, 2021 at 20:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .