A third party breach is one of the few security events where the failure happens somewhere you cannot see, on infrastructure you do not control, and the regulatory clock still starts ticking on your side of the contract. Your payroll provider, your CRM, your marketing agency with DNS access, the contractor whose laptop holds an active session to your file share: any of them can be the entry point, and in most cases the first version of the story reaches you through a customer, a journalist or a ransomware leak site rather than a formal notification from the supplier.

This article treats a supplier compromise as an operational event with a deadline, not a governance topic. It covers the outside-in signals that usually surface before disclosure, a 72-hour response runbook aligned to UK GDPR, and the contract and monitoring changes worth making before the next one lands.

What Counts As A Third Party Breach (And Why Your Name Ends Up In The Headline)

A third party breach is a security incident at a supplier, vendor, contractor or service provider that exposes your data, your systems or your customers. The compromise sits with them. The consequences, in reputation and in regulatory terms, frequently sit with you.

The Three Routes In

Supplier exposure reaches you along three distinct paths, and each demands a different response.

• A supplier holding your data. Payroll bureaux, HR platforms, CRM and marketing systems, cloud storage and backup vendors. Compromise here is a confidentiality event affecting records you are still accountable for.
• A supplier with network or API access. Managed service providers, developers, integration partners, monitoring agents, VPN accounts and service principals. Compromise here is an access event, and the risk is lateral movement into your estate.
• A supplier embedded in your own web pages. Analytics tags, chat widgets, payment scripts, consent banners and A/B testing tools all execute JavaScript on your domain. If that vendor's delivery infrastructure is tampered with, the malicious code runs on your checkout or your enquiry form and skims data directly from your customers, on your URL.

The third route is the reason supplier risk belongs to the attack surface conversation rather than the procurement filing cabinet. No questionnaire tells you what a tag is doing on your payment page this afternoon.

Controller Versus Processor Under UK GDPR

If you decide why and how personal data is processed, you are the controller. Your supplier, processing on your instructions, is usually the processor. Under Article 33(2) of the UK GDPR, a processor must notify its controller of a personal data breach without undue delay. Under Article 33(1), the controller carries the obligation to notify the Information Commissioner's Office. That asymmetry is the point: the ICO's correspondence comes to you, and "our vendor was breached"is context, not a defence. The ICO's personal data breach guidance sets out the reporting expectation in detail.

Fourth Party Risk: The Sub-Processors Nobody Listed

Your supplier has suppliers. The SaaS platform you assessed may run on a hosting provider, use an offshore support partner, push email through a delivery service and back up to a fourth party you have never heard of. Article 28 of the UK GDPR requires processor contracts to address sub-processor engagement, including authorisation and equivalent obligations, but the practical failure is that most organisations never request the current sub-processor list, never subscribe to change notifications and discover the chain only during an incident.

Why Annual Questionnaires And A Certificate Date Tell You Nothing About Last Night

An ISO 27001 certificate confirms an information security management system met the standard at audit time, within a defined scope. It is worth having. It does not tell you whether a developer at that supplier had an infostealer land on a personal device last Tuesday, or whether the vendor's admin portal now appears in a credential dump. Point-in-time due diligence and continuous monitoring answer different questions, and mature programmes run both.

The Early Warning Signals That Surface Before A Supplier Notifies You

Supplier breaches are usually visible from the outside before they are disclosed. While the vendor's statement sits in legal review, the evidence is often already public, semi-public or circulating in criminal channels. That gap, sometimes hours, sometimes days, is where your access revocation should be happening.

Leaked Credentials And Stealer Log Output

Infostealer malware harvests saved passwords, browser cookies and session tokens from infected devices, then those logs are traded and dumped. This changed the shape of vendor risk. The question is no longer only whether your supplier's corporate network was hacked, but whether a contractor's home laptop was infected and exported a live session cookie to a system holding your data.

Two operational consequences follow. Monitoring vendor domains through continuous OSINT and credential exposure monitoring gives you a head start on revocation. And when you respond, remember that a password reset does not kill an existing session. Token and session invalidation has to sit alongside credential rotation, or the attacker simply carries on inside the authenticated session you left running.

Ransomware Leak Sites And Telegram Chatter

Ransomware operators publish victim names on leak sites and in Telegram channels as leverage, frequently before the victim has issued any public statement. If a named supplier appears there, treat it as an actionable trigger to begin access review and revocation on your side, not as gossip to wait out. You are not confirming the breach for the world; you are protecting your own access paths on the balance of probability.

Lookalike And Newly Registered Domains

Domain registrations built around a supplier's brand are a reliable precursor to invoice fraud and credential harvesting aimed at that supplier's customers. Sometimes they precede the incident. More often they follow it, because post-breach phishing is the second wave: once an incident is public, attackers register domains blending the vendor's name and yours, then email affected users with a convincing "security update"or "reset your account"lure that arrives exactly when people expect one.

Shadow IT And Forgotten Supplier Infrastructure

Most organisations do not have a complete view of their external attack surface, and the supplier-managed portion is the least documented part of it. Agency-hosted campaign microsites, a staging environment stood up for a project three years ago, a subdomain CNAME'd to a platform nobody renewed, DNS records still delegating control to a partner whose contract ended. An external asset discovery pass routinely surfaces infrastructure nobody in-house remembers commissioning, and those are precisely the assets nobody patches and nobody monitors.

Where Noise Reduction Matters

Raw credential feeds and duplicated scanner findings will drown a three-person security team inside a fortnight. AI-assisted triage earns its place by correlating duplicates, ageing out already-rotated exposures and classifying identities, so that a privileged internal admin account in a fresh stealer log outranks a marketing contact appearing in a decade-old list breach. Prioritisation by identity, not by volume, is what keeps the process survivable.

Your First 72 Hours: A Third Party Breach Response Runbook

Article 33 gives controllers 72 hours from becoming aware of a personal data breach to notify the ICO where the breach is likely to result in a risk to individuals. Awareness begins when you have a reasonable degree of certainty that a breach has occurred, so a short, documented verification period is legitimate. Drifting for a week while you wait for the supplier is not.

Hours 0 To 4: Confirm, Scope, Log

Establish what is actually claimed and by whom. Then map scope against two axes: which data categories the supplier holds for you, and which access paths that supplier has into your estate (VPN accounts, API keys, OAuth grants, SCIM provisioning tokens, service accounts, federated identities, DNS delegations, third party scripts on your pages).

Open a single evidence log at the same time, with timestamps. Every subsequent decision, including the decision that a delay was reasonable, will be judged against that record.

Hours 4 To 24: Cut Access And Hunt

Revoke supplier credentials, rotate API keys and secrets, disable VPN and remote access accounts, and revoke active sessions and refresh tokens in your identity provider rather than relying on password changes alone. Force resets on any shared or reused identity, and check whether an admin account exists across multiple supplier portals with the same credentials.

In parallel, hunt in your own logs for the period before the claim became public: authentication from unfamiliar locations or ASNs, unusual API call volumes, mailbox rule creation, new OAuth app consents, data exports. Your continuous monitoring of internet-facing assets is useful here for spotting anything newly exposed or changed on the perimeter.

Hours 24 To 72: Assess Reportability And Draft In Parallel

Bring the DPO and legal in with facts, not speculation. Assess whether personal data is involved, the likelihood and severity of risk to individuals, and whether Article 34 notification to data subjects is triggered by a high risk. Draft the ICO submission, the customer wording and the internal FAQ at the same time rather than sequentially, because the drafting is the slow part, not the sending. If you must report late, Article 33(1) requires reasons for the delay, so record them as you go.

Defensive Work Running Alongside

From the moment the story is public, watch for spoofed domains against both the supplier's brand and yours, and have a rehearsed takedown process ready: evidence pack, registrar abuse contact, hosting provider, and the relevant reporting route for phishing content. In week one, domain surveillance and a working takedown path protect more people than any questionnaire will.

Who Says What

Executives need scope, exposure and decisions pending. The board needs a page: what happened, what data, what you have contained, what regulatory position you are taking, what it may cost. Customers need to know what was affected, what you are doing and what they should do, plus a clear statement that you will never ask them for credentials by email. Telling people something is not the same as telling them something useful, and vague reassurance ages badly once the detail emerges.

The Mistakes That Turn A Vendor Incident Into Your Incident

The failure patterns repeat across organisations of very different sizes

• Offboarding treated as a finance task. The contract ends, the invoices stop, and the API key, VPN account, third party subdomain and DNS delegation all stay live. This is the most consistent failure in supplier security, and abandoned supplier-managed assets are the ones nobody patches.
• Assuming the vendor will share technical detail. Ask in writing for indicators of compromise, affected data categories, dates of unauthorised access, whether your tenant was in scope and what has been remediated. Expect a lawyer-shaped answer and plan your assessment around not receiving the rest.
• Shared and personal identities on supplier portals. One admin login reused across several vendor platforms turns a single supplier breach into a multi-platform one, and executives authenticating to vendor tools with personal accounts sit entirely outside your visibility and your revocation process.
• Chasing every credential hit. Without identity classification, teams spend a week on stale marketing-list exposures while a genuinely privileged account goes unaddressed.
• No pre-agreed notification clause. Learning about the breach from a journalist or a customer is a contracting failure, not bad luck.

Building Continuous Supplier Visibility Instead Of Annual Paperwork

Start by mapping which suppliers actually touch your external footprint, then rank them by data sensitivity and access level rather than contract value. In a typical mid-market estate this reverses the order procurement assumed: the six-figure facilities contract drops down the list, while the small marketing agency holding DNS control and the low-cost form plugin embedded on your enquiry pages move to the top.

Layer live signals over the paperwork. Keep certification and accreditation tracking, including ISO 27001 renewal dates, and run supplier threat intelligence alongside it so you can see what changed this week: new credential exposures on vendor domains, leak site mentions, newly registered lookalike domains, changes to their internet-facing estate. Score each supplier on sensitivity plus live exposure, then escalate movement rather than restating the same static rating every quarter. This is the model behind DarkInvader's external attack surface management platform, which extends discovery and monitoring across supplier and human attack vectors as well as your own infrastructure.

Add executive and employee identity monitoring, because supplier compromise usually arrives as a credible email to a named person rather than as an exploit. And make the reporting survivable: a weekly "what has changed"update, per-supplier risk movement, and one page a non-technical director can act on. Findings should land in Slack, Teams, Jira, your ticketing system or your SIEM through API integration, so they become tickets with owners rather than PDFs with no follow-up.

Contract And Governance Changes Worth Making Before The Next One

Four changes consistently shorten response time when the next supplier incident lands

1. Notification windows in hours. "Without undue delay"is a legal standard, not an operational one. Specify a number of hours, name a technical contact and their out-of-hours route, and commit the supplier to sharing indicators of compromise and affected data categories, not only a holding statement.
2. Article 28 clauses used properly. Right to audit, documented sub-processor list, prior notification of sub-processor changes with a right to object, assistance with your Article 33 and 34 obligations, and deletion or return of data at contract end with evidence. The text of Article 28 is available via legislation.gov.uk.
3. Tabletop exercises with the right people. Run a supplier breach scenario with procurement, legal, comms and a service owner in the room, not just security. The bottlenecks that appear are almost always contractual and communications ones.
4. Re-baseline after any incident. Tighten access review cadence for supplier identities, add credential hygiene and session revocation checks to offboarding, and put continuous external monitoring on your highest-sensitivity suppliers rather than your highest-spend ones.

The organisations that handle a third party breach well are rarely the ones with the thickest questionnaire library. They are the ones that already knew which suppliers held what, could revoke every access path in an afternoon, and saw the signal in a leak site post or a credential dump before the notification email arrived. If you want to see what that visibility looks like against your own supplier footprint, talk to the DarkInvader team or start with a free DarkInvader account.

Frequently Asked Questions

What is a third party breach and how is it different from a data breach at your own company?

A third party breach is a security incident at a supplier, vendor or contractor that exposes your data, systems or customers, rather than a compromise of your own infrastructure. The technical failure sits with them, but if you are the controller of the personal data involved, the regulatory duty to assess and report sits with you. The practical difference is visibility: you have logs and control over your own estate, and neither over theirs.

Do you have to report a third party breach to the ICO within 72 hours?

Under Article 33 of the UK GDPR, a controller must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to individuals. That clock applies whether the breach happened on your systems or your processor's. If you report later than 72 hours, you must explain the reasons for the delay.

How would you find out about a supplier breach before the supplier tells you?

Through outside-in signals: credentials tied to the supplier's domains appearing in leaked databases and infostealer logs, the vendor being named on a ransomware leak site or in criminal Telegram channels, and lookalike domains registered against their brand. These often surface while the supplier's own statement is still in legal review, which gives you hours or days to start revoking access.

Who is liable when a vendor loses your customer data under UK GDPR?

Liability depends on roles and on the facts. The controller is accountable for choosing processors that provide sufficient guarantees and for having Article 28 terms in place, and remains responsible for notifying the ICO and, where risk is high, affected individuals. Processors have direct obligations too, including notifying the controller without undue delay, so both parties can face regulatory action depending on where the failure occurred. Take legal advice on your specific arrangement.

What should be in a supplier contract to speed up breach notification?

A notification window expressed in hours, a named technical contact with an out-of-hours route, a commitment to share indicators of compromise and affected data categories rather than only a holding statement, a documented sub-processor list with change notification, right to audit, and clear data return or deletion obligations at contract end. Pair those clauses with an offboarding checklist that revokes API keys, VPN access, sessions and DNS delegations, because the contract only helps if someone acts on it.