GDPR Fines: Can You Be Fined for Your Vendor’s Breach?

Your vendor had a data breach. You think: their systems, their failure, and so, their problem.

Except it isn’t. Not entirely.

Under GDPR, you are the data controller. That means you are responsible for what happens to personal data, even when you hand it to someone else to process. Outsourcing the work does not outsource the liability.

This is the part many businesses miss. They sign a contract with a vendor, add a data processing agreement, and assume they have done their part. But regulators do not see it that way. When personal data is mishandled, the question they ask is not just what the vendor did wrong. They also ask what you did to choose, instruct, and oversee that vendor.

The GDPR fine you receive will depend on your choices and your actions, not only your vendor’s.

So what does that mean in practice? When are you exposed? When are you protected? And what should you have in place before something goes wrong?

That is exactly what this article breaks down.

The Controller–Processor Relationship Is Where Liability Lives

Before you can understand your exposure, you need to understand your role.

Under GDPR, every organisation that handles personal data falls into one of two categories: a controller or a processor. The controller decides why personal data is collected and what it is used for. The processor handles that data on the controller’s behalf. In most vendor relationships, you are the controller, and your vendor is the processor.

This distinction is the foundation that regulators use to decide who is responsible when something goes wrong.

As the controller, you own the purpose. You decided to collect the data. You decided what it would be used for. You chose which vendor would process it. That chain of decisions starts with you, and regulators know it.

Your vendor, as the processor, follows your instructions. They do not set the purpose. They execute it. That is an important difference. It means that even when a breach happens inside your vendor’s systems, regulators will look at whether you gave the right instructions, whether you chose the right vendor, and whether you had the right safeguards in place.

Both controllers and processors can be fined under GDPR. They can each be investigated and held accountable independently. But the controller carries the heavier duty. You are the one who brought the data into existence for a purpose. That responsibility does not transfer when you hand the data to someone else.

When a Vendor Acts as a Controller

However, not every vendor relationship follows this pattern. Sometimes a vendor does more than execute your instructions. They may independently decide how certain data is used, or pursue their own purposes with that data alongside yours. When that happens, the vendor is no longer acting purely as a processor. Under Article 26, they become a joint controller.

Joint controllership changes the liability picture. Article 26 requires joint controllers to enter into a formal arrangement that sets out their respective responsibilities for GDPR compliance, including who handles data subject rights and who is responsible for breach notifications. Importantly, data subjects can exercise their rights against either joint controller, regardless of what that internal arrangement says. Where a breach occurs in a joint controllership situation, both parties can be investigated and fined for failures that fall within their agreed responsibilities, and regulators will look at whether the arrangement itself was adequate.

The practical implication is this: before you classify a vendor relationship as controller and processor, look carefully at what the vendor actually does with the data. If they are making independent decisions about its use, the relationship may be joint controllership in substance, even if your contract says otherwise. Mislabelling the relationship does not protect you. It simply means you lack the right agreement and the right safeguards for the relationship that actually exists.

What GDPR Requires Of Controllers Before and During the Relationship

Yes, GDPR regulates what happens when something goes wrong. But it also sets out clear obligations for what you must do before you even share personal data with a vendor, and what you must continue doing throughout the relationship.

Choose the right vendor from the start

Before engaging a vendor to process personal data, a controller is required to carry out due diligence. GDPR uses specific language here. One must only work with processors who provide “sufficient guarantees.” That means you need evidence that the vendor can protect personal data properly. Not a promise or a checkbox. Actual evidence.

This could include reviewing their security certifications, asking how they handle data breaches, understanding where data is stored, and assessing whether their technical and organisational measures are strong enough for the type of data involved. If a controller skips this step and a breach occurs, regulators will ask what checks were carried out before handing over the data. The absence of an answer is itself a problem.

Put a Data Processing Agreement in place

A Data Processing Agreement (DPA), is not optional. GDPR makes it mandatory for every controller and processor relationship. The agreement must cover specific things. It must set out the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data involved, and the obligations and rights of both parties.

Generic contract clauses are frowned upon. The DPA needs to reflect the actual processing taking place. It must also require the processor to act only on the controller’s documented instructions, implement appropriate security measures, assist you in responding to data subject rights requests, and also notify you promptly in the event of a breach.

If you do not have a compliant DPA in place, you are already in breach of GDPR before any incident even occurs.

Keep overseeing the relationship

After signing a DPA, GDPR expects you to maintain ongoing oversight of how your vendor processes personal data. That means periodically reviewing whether they are still meeting their obligations, reassessing their security measures as your use of the data evolves, and staying informed about any changes in how they operate.

If your vendor is handling particularly sensitive or high-volume data, the expectation of oversight is even higher. A vendor relationship is not a one-time compliance event. It is a continuing responsibility.

When Regulators Will Hold You Responsible for a Vendor Breach

A vendor breach does not automatically mean you will be fined. But there are specific failures that shift regulatory attention firmly in your direction as the controller. The following scenarios reflect the factors that supervisory authorities actually examine when investigating incidents involving processors. And the enforcement record shows that regulators will act.

You skipped or had a weak Data Processing Agreement

GDPR Article 28 requires that processing by a processor be governed by a binding contract. That contract must set out the specific obligations listed under Article 28(3), including instructions on how data must be processed, security requirements, breach notification obligations, and the processor’s duty to assist the controller.

If you had no DPA in place, or if your DPA was vague, incomplete, or did not reflect the actual processing taking place, you have already failed a core legal requirement. In that situation, regulators do not need to look further. The breach exposes a pre-existing compliance gap that sits with you.

You failed to vet the vendor’s security practices

Article 28(1) of the GDPR states that controllers must only use processors who provide sufficient guarantees to implement appropriate technical and organisational measures. This essentially requires the controller to actively assess the vendor’s security practices before engaging them.

The British Airways case is a clear example. In June 2018, an attacker gained access to British Airways’ network using compromised credentials belonging to a third-party supplier, Swissport, a cargo handler. The compromised account did not have multi-factor authentication enabled. British regulators found that the fine resulted largely from British Airways not having the necessary security protections in place that could have prevented the breach. The ICO explicitly stated that the engagement of a third-party IT security service provider cannot reduce the controller’s degree of responsibility, and that both British Airways and Marriott, as data controllers, were considered wholly responsible for the breaches. The final fine against British Airways was £20 million.

You had no monitoring or audit mechanism in place

Article 28(3)(h) requires that processors allow controllers to conduct audits and inspections, and that they provide all information necessary to demonstrate compliance. This provision exists because controllers are expected to maintain active oversight, not just sign a contract and step away.

The Vodafone cases make this point sharply. Germany’s Federal Data Protection Authority found that Vodafone had no effective processes for selecting, auditing, and continuously monitoring its partner agencies, even though those partners had access to extensive personal data, including sensitive contract data and account information. This breach of Article 28 resulted in a fine of €15 million. In a separate action in Spain, the Spanish Data Protection Authority imposed a €4 million fine on Vodafone España for hiring processors who did not comply with adequate safeguards and for the lack of control by Vodafone over those processors. In both cases, the regulator’s focus was not solely on what the vendors did. It was also on what Vodafone failed to do as the controller.

You knew of risks and ignored them

Article 83(2) of the GDPR sets out the criteria that supervisory authorities must take into account when deciding whether to impose a fine and how much to impose. Among those criteria are the degree of responsibility of the controller and any relevant previous infringements.

If a controller had reason to believe a vendor posed a risk and took no action, regulators will treat that as an aggravating factor. In the Vodafone España case, the AEPD noted as an aggravating factor that Vodafone had already been sanctioned with fines or warnings on more than 50 occasions between January 2018 and February 2020, and that 161 complaints had been received in just two years. Repeated warnings that go unaddressed are not treated as evidence of bad luck. They are treated as evidence of neglect.

When You Are Less Likely to Be Fined, or Fines Are Reduced

On the other hand, being investigated after a vendor breach does not automatically lead to a fine. Regulators have a legal obligation under Article 83(1) of the GDPR to ensure that penalties are effective, proportionate, and dissuasive. That proportionality principle works in your favour when you can show that you took your responsibilities seriously. The enforcement record makes clear that how you behave, both before and after an incident, can significantly shape the outcome.

You had a solid DPA and the right measures in place

The first thing a regulator will look at is what a controller had in place before the incident occurred. Under Article 83(2)(d), the degree of responsibility of the controller, taking into account the technical and organisational measures implemented, is a specific factor in determining the fine. When an investigation opens, the presence or absence of documentation is the first thing regulators assess. It directly determines whether the conversation becomes a fine or a remediation order.

A compliant DPA that accurately reflects the processing, specifies security requirements, and sets clear obligations on the processor demonstrates that you exercised proper control. Certifications held by your vendor, documented due diligence records, and evidence of periodic reviews all contribute to lowering your degree of responsibility in the eyes of a supervisory authority.

You acted promptly when notified of the breach

Speed matters. Under Article 33 of the regulation, controllers are required to notify their supervisory authority of a personal data breach within 72 hours of becoming aware of it. Acting within that window, and doing so with full information, signals to regulators that you are taking the matter seriously.

For the British Airways case, despite being fined £20 million, a fine that was already far below the initial proposed figure of £183 million, a £6 million reduction, representing 20% of the proposed base fine, reflected the ICO’s account of mitigating factors. These included the immediate steps taken to mitigate and minimise damage to data subjects, and BA’s prompt notification of the breach to affected individuals and relevant regulatory authorities. Prompt action after a breach will not erase accountability, but it is formally recognised as a factor that reduces it.

You cooperated with the supervisory authority

Article 31 requires controllers and processors to cooperate with supervisory authorities on request. Going beyond minimum compliance and actively cooperating throughout an investigation can make a real difference to the outcome.

The Knuddels case from Germany is one of the clearest examples on record. In 2018, the German chat platform suffered a breach that exposed the personal data of around 330,000 users. The potential for a significant fine was real. However, the Baden-Württemberg data protection authority issued a fine of just €20,000, citing the company’s “exemplary cooperation” and transparency as the reason it did not deliver a more severe punishment. When Knuddels became aware of the breach, it immediately notified the supervisory authority, provided detailed information to affected users without delay, and implemented extensive measures to improve its IT security within a matter of weeks. Stefan Brink, the data protection officer involved in the case, stated: “Those who learn from harm and act transparently to improve data protection can emerge stronger as a company from a hacker attack.”

The contrast with organisations that do not cooperate is stark. Regulators treat a lack of cooperation as an aggravating factor under Article 83(2)(f), which can push fines in the opposite direction.

What the enforcement record tells us

The pattern across decided cases is consistent. In both the British Airways and Marriott cases, the ICO considered as mitigating factors that each company had cooperated with the investigation, promptly notified the affected data subjects and appropriate regulatory bodies, and that neither had received any financial gain as a result of the breach.

The lesson is straightforward. You cannot control whether a vendor breach will happen. But you can control how prepared you are, how you respond, and how you engage with regulators. Controllers and processors can limit the amount of a fine by mitigating the damaging nature, gravity and duration of the violation, reporting the violation as soon as possible, and cooperating with the supervisory authority. Those are factors built into the law itself.

The Practical Checklist: What to Do Right Now

Understanding your legal exposure is only useful if it leads to action. The good news is that the steps regulators expect to see are not complicated. They are documented, deliberate, and repeatable. Here is what you should have in place.

Audit your current vendor DPAs

Start by reviewing every Data Processing Agreement you currently have with vendors who process personal data on your behalf. Article 28(3) sets out a specific list of what a compliant DPA must contain. Your agreements need to cover the subject matter, duration, nature and purpose of the processing, the type of personal data involved, and the obligations of both parties.

Ask yourself whether each DPA reflects what is actually happening. A DPA that was signed years ago and never updated may no longer accurately describe the processing taking place. That gap is a compliance risk in its own right. If a DPA is missing, generic, or silent on key obligations, it needs to be replaced or updated before an incident occurs.

Assess whether your processors meet GDPR security standards

Article 28(1) requires you to use only processors who provide sufficient guarantees that they will implement appropriate technical and organisational measures. That assessment cannot be a one-time exercise. It needs to reflect the current state of your vendor’s security practices and the current nature of the data being processed.

In practice, this means requesting and reviewing your vendor’s security certifications, such as ISO 27001, asking how they handle access controls and encryption, understanding where data is stored and whether international transfer rules apply, and reviewing their breach response procedures. The depth of your assessment should be proportionate to the sensitivity and volume of the data involved. A vendor processing special category data warrants significantly more scrutiny than one handling general contact information.

Document your due diligence. This is your paper trail.

This point cannot be overstated. Under Article 5(2), the accountability principle requires controllers to be able to demonstrate compliance, not just achieve it. In its guidance, the ICO has made this clear, stating that organisations must have appropriate documentation in place to show the measures they have taken.

If regulators investigate you following a vendor breach, your documentation is what stands between you and a finding of negligence. Keep records of how you selected each vendor, what due diligence you carried out, what your DPAs require, and what ongoing oversight you have conducted. When an investigation opens, the presence or absence of this documentation is the first thing regulators assess, and it directly determines whether the conversation becomes a fine or a remediation order.

Verbal assurances from vendors do not count. Emails saying security is “taken care of” do not count. Documented assessments, signed agreements, and audit records do.

Know your 72-hour breach notification obligation

Article 33 requires controllers to notify their supervisory authority of a personal data breach within 72 hours of becoming aware of it, where the breach is likely to result in a risk to the rights and freedoms of individuals. This obligation sits with you as the controller, regardless of whether the breach originated with your vendor.

This means two things in practice. First, your DPA must require your processor to notify you of any breach without undue delay, as Article 33(2) specifically requires. If your vendor takes days to tell you about an incident, your 72-hour window starts running from the moment you become aware, not from the moment they decide to inform you. Second, you need an internal process that can move quickly once a notification arrives. Delays in notifying the supervisory authority are treated as a separate failing and can independently attract regulatory action.

The British Airways investigation is a reminder of what happens when breach detection is left to chance. ICO investigators found that British Airways did not detect the attack itself but was alerted by a third party more than two months after the attack began. That failure to detect the breach independently was treated as a serious failing in its own right.

Your vendor contract should not be the last line of defence. Your organisation needs its own detection and response capability that does not depend entirely on your vendor telling you something has gone wrong.

The Bottom Line

A vendor breach is basically a test of everything you did before it happened.

GDPR places the responsibility for personal data firmly with you as the controller. You chose the vendor. You defined the purpose. You decided what safeguards were good enough. When something goes wrong, regulators will follow that chain of decisions back to you.

The businesses that fare best in investigations are not necessarily the ones that avoid every incident. They are the ones who made the right choices upfront, kept records of those choices, and responded well when things went wrong. That combination does not eliminate risk entirely, but it changes the conversation with regulators significantly.

The law is clear. The enforcement record is clear. What remains is a practical question: if a regulator looked at your vendor relationships today, what would they find?

If the answer gives you pause, now is the time to act.