Third-party breaches are structurally different from direct attacks. The breach happened elsewhere. The attacker has already left. Your organisation gets the phone call, not the intrusion. And yet, under GDPR and UK data protection law, the clock starts ticking the moment you know.
You didn't choose the attacker. You didn't choose the vulnerability. You do, however, choose who owns the response and how well-prepared they are for the moment the notification lands.
What Is the Organisation's Liability When a Third-Party Supplier Is Breached?
Your liability begins the moment you become aware that personal data you control has been compromised, regardless of where the breach occurred. If your supplier processes data on your behalf, you are the data controller. You own the notification obligation, the risk assessment, and the ICO reporting window.
Most CISOs know this in theory. The gap is in practice. When the call comes in from a supplier at 4pm on a Friday, the question isn't what the law says. It's whether your team knows what to do in the next two hours and how fast they can actually do it.
How Does a Third-Party Breach Actually Unfold?
A common sequence: the supplier identifies anomalous activity, investigates for hours or days, and only then notifies you, so the exposure may have begun well before you hear about it. Your 72-hour ICO notification clock begins not when the supplier knew, but when you knew.
Third-party breach notifications often expose a gap in internal response. The team hasn't rehearsed this specific scenario. They've rehearsed direct attacks. A supplier breach creates immediate ambiguity: whose logs do we need? Who holds the supplier contract? What data did they actually have access to?
That ambiguity costs time. Time costs regulatory exposure.
What Data Do You Need to Assess Risk After a Supplier Breach?
You need four things immediately: the categories of data involved, the approximate volume of data subjects affected, the likely consequences for individuals, and what technical and organisational measures the supplier had in place.
The supplier will often give you two of those four willingly. The other two require pushing. Specifically, you need the measures they had in place. This matters because your notification to the ICO must include an assessment of risk, and that assessment depends on whether the data was encrypted, pseudonymised, or stored in plaintext. A supplier saying "we take security seriously" is not an answer to that question.
Who Owns the Response When a Supplier Notifies You?
Often not your security team. The people managing supplier relationships are account managers, procurement staff, legal teams, and operations leads. When a supplier breach notification arrives, it typically hits them first.
That makes ownership the first thing to settle. Each supplier that processes personal data on your behalf should have a named internal owner, and that owner should know one thing above all: who to pass the notification to, and how quickly. The incident lead then decides who assesses the risk, who talks to the supplier, and who owns the ICO notification decision.
The practical implication: if your organisation processes data through 40 or 50 suppliers, the people who receive the first call are probably sitting in finance or procurement. They are not reading your incident response runbooks, so the escalation route needs to be short, written down and tested in a tabletop exercise that includes them.
What Should the Internal Response Process Look Like?
The first decision is whether the incident meets the threshold for ICO notification. Not all breaches do. A ransomware attack against a supplier holding employees' names and work email addresses may not meet the threshold for likely risk to individuals. A breach exposing health data, financial information, or authentication credentials almost certainly does.
The threshold assessment should take under two hours if your team has rehearsed it. It shouldn't require three hours of legal counsel debating definitions while the notification clock counts down.
Document everything from the first notification. The ICO's interest in your response includes what you knew, when you knew it, and what you did next. A clear timeline, even a messy one, demonstrates that you took it seriously. The absence of a timeline demonstrates the opposite. Record decisions as well as events: who decided whether to notify, on what information, and who approved any change to the supplier's access.
How Do You Reduce Repeat Exposure From Third-Party Incidents?
Two ways. Better supplier due diligence before the incident, and better internal response capability before the next one.
On the first: your Data Protection Impact Assessments should cover not just what data suppliers hold but the technical controls they have in place and how they will notify you. "We will notify you promptly" in a contract is not a control. A defined notification window of four hours, with a named contact and a defined escalation path, is.
On the second: hold a post-incident review while the detail is fresh. Establish where time was lost, who had to be found before a decision could be made, and which supplier access was broader than it needed to be. Give each finding an owner and a date, and update the plan. The same discipline applies to AI services and agents that act on your data: an incident review needs to show who or what had access and who approved each action. For agent actions routed through it, IntelXview's AI Control Plane records the policy decision behind each one; activity outside it still depends on the supplier's and your own logs.
Third-party breaches will keep happening. Your suppliers' security posture is genuinely outside your direct control. What you can control is whether the right people own their part of the response when the phone rings, and whether that has been rehearsed before it is needed.
