Data leakage at a third-party processor: GDPR Article 28 and controls

A data leak at a processor is an exfiltration of your data from a system you do not control directly: that of a service provider, a SaaS vendor or an integration connected to your information system. Under the GDPR, you remain the controller, even if the incident happens at the third party. The only serious response combines contractual guarantees (Article 28) with technical checks on what actually leaves your environment for that third party.

Why the third party has become the most likely leak path

Your data no longer lives only in your information system. It passes through an outsourcer, a payroll tool, a SaaS CRM, a support provider that accesses your workstations remotely, a connector that synchronises your email with a third-party application. Each of these flows is a legitimate egress channel. That is precisely what makes it dangerous: your controls are tuned to let it through.

Three situations come up again and again:

• The third party is compromised and the attacker retrieves the data you entrusted to it, or uses its access to get into your environment.
• The flow to the third party is too broad: a whole database is sent when the provider only needed three columns.
• The integration is forgotten: an API token created for a project that has ended still works, with extensive read rights.

What the GDPR really requires of you and of the processor

Article 28 of the GDPR governs the relationship with the processor. It requires the controller to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. It requires a contract (or another legal act) that sets out in particular:

• processing only on the documented instructions of the controller;
• confidentiality commitments from the persons authorised to process the data;
• implementation of the security measures provided for in Article 32;
• prior written authorisation before engaging any sub-processor, with the same obligations flowed down;
• assistance to the controller in meeting its own obligations, including breach notification;
• making available the information needed to demonstrate compliance, and allowing audits and inspections.

Article 33 adds a direct obligation for the processor: to notify the controller of any personal data breach without undue delay after becoming aware of it. The controller, for its part, has in principle 72 hours to notify the CNIL. In practice, that clock starts running on your side. If your provider takes a week to warn you, it is your crisis management that pays the price. The European Commission has published standard contractual clauses for this relationship (Implementing Decision 2021/915), and the CNIL offers a processor guide and sample clauses.

The contractual checks not to forget

Beyond the Article 28 baseline, a few clauses make the difference on the day of an incident:

Scroll the table →

The technical checks: what you control on your side

You have no control over the provider’s information system. You do control what you send it and the access you grant it. That is where most of the game is played.

Map the outbound flows to third parties

List every external destination that receives data: SaaS domains, partners’ SFTP servers, APIs, providers’ mailboxes. For each one, note the type of data expected. Without this list, no DLP rule can tell a legitimate flow from a leak. Data classification directly conditions this work.

Reduce integrations and tokens

• Inventory the OAuth applications authorised on your email and collaboration spaces.
• Remove orphaned API tokens and limit rights to the strict need.
• Require named accounts and strong authentication for providers’ remote access.

Check that your controls block what must not leave

A flow authorised to a third party must not become a universal tunnel. If your DLP lets any data through to the provider’s domain, an attacker who controls an account at that provider, or a look-alike domain, benefits from the same tolerance. The same questions arise for CASB and DLP controls on SaaS applications: does the rule cover the corporate instance only, or any instance from the same vendor?

A concrete scenario: the payroll provider

A mid-sized company (ETI) outsources its payroll. Every month, an HR export leaves for the provider’s platform. The contract complies with Article 28. The DLP allows the provider’s domain for HR files.

Three questions are enough to measure the real exposure. Does the export contain unnecessary columns, such as the social security number of dependants? Is an HR file sent to another domain, or to a personal instance of the same service, blocked? Does the SOC see an unusual upload by its volume or its timing? If you cannot answer with evidence, you do not know. Replaying these scenarios with synthetic data in production gives you the answer without exposing a single real payslip.

Checkpoints for your next supplier review

1. Processors handling sensitive data are identified and ranked by criticality.
2. Every critical contract contains a quantified notification deadline.
3. The list of sub-processors has been reviewed within the year.
4. Outbound flows to each critical third party are documented and minimised.
5. Unused integrations and tokens have been revoked.
6. An active test has verified that sensitive data only leaves for the intended destinations.
7. The incident response procedure covers the case of a leak at a third party.

This last point is often forgotten. On the day the provider calls, you need to know who decides, who gathers the facts and who prepares the notification. See our article on the first 24 hours of incident response.

Frequently asked questions