A payroll bureau emails you on a Friday afternoon. Their file transfer platform was exploited, they are working with a forensics firm, and they will confirm which of your employee records were taken "as soon as that analysis completes". You have never heard of the software vendor involved. Your supplier questionnaire from four months ago came back clean, with a current ISO 27001 certificate attached.

That gap between the paperwork and the reality is where almost every third party data breach lives. The 2023 exploitation of Progress Software's MOVEit Transfer, where the Clop group abused a zero-day in a managed file transfer product, reached UK employees through the payroll bureaus and processors sitting between them and the vendor. Plenty of affected organisations had never contracted with Progress at all.

Questionnaires are not useless. They are just the wrong dataset for this problem. What follows are five specific things vendor assurance keeps missing, and how to watch each one from the outside, continuously, without needing the supplier's permission.

What a third party data breach looks like from your side of the contract

A third party data breach happens when attackers compromise a vendor, processor, contractor or software supplier, and reach your data through that relationship rather than through your own perimeter. Your controls held. Someone else's did not, and the contract joined you together.

The three routes that actually get used

• The supplier holds a copy of your data. Payroll bureaus, marketing platforms, claims handlers, document processors. The data leaves your estate by design and lands somewhere you cannot patch.
• The supplier holds credentials or an integration into your systems. An API key, a service account, a VPN login, a support desk with read access to a customer database. Compromise the supplier, inherit the access.
• The supplier's software runs inside your estate. Agents, plugins, update channels and managed appliances. The trust relationship is the delivery mechanism.

Why you usually hear about it last

Under Article 33(2) of the UK GDPR, a processor must notify the controller of a personal data breach without undue delay. That phrase is a legal standard, not a deadline you can plan a response around. In practice, a supplier discovers something odd, engages incident responders, waits for scoping, checks with legal and communications, then contacts customers. Weeks can pass between intrusion and inbox.

What the ICO expects once you are aware

The clock that matters to you is your own. As a controller, you must report a notifiable personal data breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. Awareness starts when you have a reasonable degree of certainty that a breach has occurred, which is not the same as having the supplier's final forensic report. "Awaiting supplier confirmation"is not a pause button, and the ICO expects you to report on the information you have and follow up in phases.

Gap 1: a certificate proves scope on one date, not exposure today

Assurance paperwork and live exposure are different datasets. A supplier can hold a valid ISO 27001 certificate on the same morning that an unpatched, internet-facing file transfer appliance is sitting on one of their subnets, because the certificate describes a management system inside a defined scope, assessed at a defined point in time.

Read the scope statement before you read anything else. The service you actually buy is frequently outside it. A certificate covering "the provision of hosted payroll services from the Manchester office"tells you nothing about the development team in another country running your integration, and the Statement of Applicability will show you which controls were excluded and why. Check the certification body is UKAS-accredited, check the surveillance audit dates, and check the certificate has not quietly lapsed since procurement filed the PDF.

The same limitation applies across the board. Cyber Essentials Plus involves hands-on technical verification, and SOC 2 Type II tests operating effectiveness over a period rather than a single day, which makes both stronger than a self-assessment. Neither one tells you a remote access appliance is unpatched this morning.

Track accreditation as a live field instead of a folder: expiry dates, scope changes, lapses and downgrade from Plus to basic. A certificate that quietly expires and is not renewed is one of the cheapest early warnings available, and most programmes never look. Use certification as a floor that filters out genuinely immature suppliers, then stop treating it as assurance.

Gap 2: the supplier's external attack surface, which nobody in your process ever looks at

Your questionnaire asks whether the supplier performs vulnerability scanning. It never asks what their internet-facing estate looks like from an attacker's chair. You can find out without asking, because the same reconnaissance an attacker performs is available to you: domains, subdomains, IP ranges, exposed admin panels, VPN and file transfer appliances, cloud storage buckets, staging environments and forgotten test sites that were never decommissioned properly.

Mass exploitation campaigns land on exactly that kind of infrastructure. Not the well-governed production platform your due diligence covered, but the appliance nobody owns and the subdomain pointing at a cloud service that was cancelled two years ago. Unknown asset discovery across supplier domains is the part that turns a supplier register into something operationally useful, because shadow IT is invisible to any process that relies on the supplier telling you the truth about their own inventory.

Prioritise the exposures that touch your data. The portal you upload files to. The API endpoint your integration calls. The SSO tenant your staff authenticate against. A critical finding on a supplier's unrelated marketing microsite is worth logging; an exposed management interface on the platform holding your customer records is worth a phone call today.

Raise it with evidence, not with a risk rating. Suppliers dispute scores. They rarely dispute a named host, a service banner and a CVE reference, and specific findings get remediated far faster than a generic amber rating in a spreadsheet nobody reads.

Gap 3: infostealer logs and leaked credentials belonging to your supplier's staff

Infostealer malware harvests saved browser passwords, autofill data and active session cookies from a single infected device, then packages them into logs that circulate on criminal markets and Telegram channels. When that device belongs to an employee or contractor at one of your suppliers, the log can contain credentials for your shared portal, your SSO tenant or your ticketing system.

Session cookies are the part that changes the shape of supplier risk. A stolen session can be replayed straight past multi-factor authentication, which means "we require MFA"as a questionnaire answer is a weaker control than it sounds unless it is paired with short session lifetimes, device binding and phishing-resistant factors. Ask the follow-up question. Most suppliers have not thought about it.

Consumer breach-check sites will not close this gap. They index old credential dumps, not fresh stealer output, and they almost never tell you which corporate application the credential unlocked. What you want from a dark web monitoring service is your own domain appearing inside credentials stolen from a supplier's machine, contractor accounts with no MFA enrolled, and reused administrator logins spanning several vendor tenants.

Then build the response before you need it. Contractual expectation that any supplier staff touching your systems use phishing-resistant MFA, plus your own playbook for invalidating sessions, rotating shared secrets and forcing re-authentication on vendor accounts within hours of a credential hit.

Gap 4: the fourth parties and shadow data nobody put in the register

Your supplier has suppliers. Under Article 28 of the UK GDPR, a processor cannot engage another processor without your authorisation, and you have the right to be informed of intended changes so you can object. Those subprocessor lists are the cheapest form of fourth-party visibility available, and most organisations file the DPA annex without ever reading it.

Shadow data lives in the gaps that annex misses: copies in test databases, records piped into an analytics platform, backup snapshots at a third provider, an offshore support desk with read access. None of it appears in procurement's records because none of it was purchased by you.

Most supplier registers are built from spend data, which is precisely why the highest-risk vendors are so often missing. The small SaaS tool a team bought on a company card. The marketing agency holding CMS admin rights. The contractor with a standing VPN account. Tier by data sensitivity and system privilege instead of contract value:

1. Tier one: holds special category or customer financial data, or carries privileged access into your estate. Continuous outside-in monitoring.
2. Tier two: holds business data with no system access. Periodic review with targeted checks.
3. Tier three: holds neither. Annual review is proportionate.

Concentration is the failure mode people underestimate. Four suppliers that look independent on paper may all sit on the same hosting platform, the same payroll bureau or the same document processing service, and one incident becomes a multi-supplier event. EU financial entities now maintain an ICT third-party register under DORA for this reason; the discipline is worth borrowing even where the regulation does not apply to you.

Gap 5: criminal chatter, leak sites and lookalike domains naming your vendors

The fastest early signal of a supplier compromise is rarely the supplier. It is a ransomware leak site listing that names them as a victim, a post in a criminal Telegram channel offering access to their network, or a sudden cluster of their staff credentials appearing in fresh stealer logs. Extortion groups publish victim names to apply pressure, which routinely puts the disclosure in public days before the customer notification email arrives.

Add your tier-one supplier names, domains and brand terms to your monitoring keywords. That single change converts the disclosure lag into your head start: time to rotate credentials, restrict integrations, brief your DPO and prepare a holding position before anyone asks what you knew.

Lookalike domains are the other live signal. A typosquat registered against a supplier's brand, with a mail record configured, is infrastructure being prepared for invoice fraud or credential phishing aimed at your finance and operations teams. When a fake supplier portal appears, an internal email telling people to be careful is the weakest available response. Collect the evidence, report the domain to the registrar and hosting provider, and pursue takedown while blocking it at your own gateway. Continuous monitoring of brand and domain registrations is what makes that timeline realistic rather than reactive.

Turning this into a continuous supplier monitoring routine

Build the outside-in view first, because it needs nobody's cooperation. Supplier domains and subdomains, exposed services, certificate status, credential exposure and criminal chatter, refreshed continuously rather than annually, in the spirit of continuous threat exposure management. The NCSC's supply chain security guidance makes the same underlying point: assurance has to be proportionate and ongoing, not a one-off gate at onboarding.

Then set thresholds that actually trigger work:

• A new critical or internet-facing exposure on a tier-one supplier.
• Fresh credentials tied to your domain appearing in stealer logs from a supplier device.
• A leak site or forum mention naming a supplier.
• A lapsed or narrowed certification, or a new subprocessor added without notice.

Wire those alerts into Slack, Microsoft Teams or Jira so each finding gets an owner and a date. Dashboards nobody opens do not reduce risk. And contract for the rest: a hard notification number such as 24 hours rather than "without undue delay", a named and maintained subprocessor list, evidence of remediation rather than assertions of it, and the right to re-test after an incident.

Report it upwards monthly, in one page. Which suppliers moved, what changed, what you did. Boards understand trends far better than they understand a static red-amber-green grid, and supplier exposure is the sort of risk that only makes sense as a line over time. If you want to see what that outside-in view looks like against your own vendors, start with a free DarkInvader account or talk to the team about scoping tier-one suppliers into continuous monitoring. The third party data breach you eventually have to report will have been visible from the outside long before the notification email lands.

Frequently Asked Questions

What counts as a third party data breach?

Any incident where attackers compromise a vendor, processor, contractor or software supplier and reach your data through that relationship rather than through your own systems. That includes a supplier holding a copy of your data, a supplier whose credentials or integration give access into your estate, and supplier software running inside your environment. Your own controls can be entirely intact and you can still be the organisation notifying regulators and individuals.

Who has to report a third party data breach to the ICO, you or the supplier?

The controller reports to the ICO. If the supplier is acting as your processor, they notify you under Article 33(2) of the UK GDPR and you decide whether the breach is notifiable and make the report. If the supplier is a controller in its own right for that data, it carries its own obligation, which is exactly why the controller and processor roles should be settled in the contract rather than argued about during an incident.

How quickly must a processor tell you their systems have been breached?

The UK GDPR requires processors to notify the controller without undue delay, with no fixed number of hours attached. Because your own 72-hour reporting clock starts when you become aware, that vagueness works against you. Contract for a specific figure, commonly 24 hours from the supplier's detection of a suspected breach, along with an obligation to provide information in stages rather than waiting for a complete forensic picture.

Does ISO 27001 or Cyber Essentials certification reduce third party breach risk?

They reduce it at the low end by filtering out suppliers with no functioning security management at all, and Cyber Essentials Plus and SOC 2 Type II both involve testing rather than self-declaration. What none of them do is tell you the state of a supplier's internet-facing infrastructure today. Read the ISO 27001 scope statement and Statement of Applicability carefully, because the service you are buying is frequently outside the certified boundary.

How can you monitor a supplier's security without their permission?

Everything an attacker can see from the internet is available to you as well: domains and subdomains, exposed services and admin interfaces, certificate and DNS records, cloud storage, lookalike domain registrations, leak site posts and credential exposure tied to the supplier's staff. Passive reconnaissance and open source intelligence require no access to their systems and no contractual clause. Active testing against a supplier's infrastructure is a different matter and needs written authorisation, so keep the two firmly separated.