Third-Party Incident Response Playbook: From Supplier Alert to Safe Recovery

What is third-party incident response?

Third-party incident response is the process your organisation follows when a supplier, vendor or other third party reports a cyber incident, from working out whether it affects you through to deciding when it's safe to return to normal.

It differs from internal incident response in one respect that shapes everything else. You don't control the affected environment. Most of the evidence you need to make good decisions belongs to another organisation, and you're dependent on them to share it.

A third-party cyber incident isn't the same as a third-party cyber threat. A threat, such as a newly published vulnerability, is the potential for an incident. It only becomes an incident once there's confirmed impact, and confirmed impact is specific to the organisation involved. A supplier having an incident doesn't automatically mean you have one too.

Ownership is often the first thing that breaks down. Third-party risk management usually sits with a governance or procurement-adjacent team, built around onboarding and periodic reassessment. Incident response usually sits with a security operations team, built around technical investigation inside environments they control.

A supplier incident falls across both, and if the relationship data lives with one team while the response capability lives with the other, the organisation loses time working out who owns the decision before it even gets to making one. The playbook below assumes both functions need to be in the room.

Supply chain incidents aren't rare exceptions. Our Every Link Matters Report found that 82.4% of UK organisations reported at least one in the past 12 months, and 41.8% reported two or more.

That frequency is why a defined process matters. Something this common can't run on improvisation each time.

‍

What needs to exist before a supplier incident happens

A third-party incident response process only works if your organisation already knows which suppliers matter, what they hold, and how to reach them. None of that can be assembled once an incident is already live. It has to exist beforehand, current and accessible, not sitting in someone's head or a spreadsheet nobody's opened since onboarding.

That preparation splits into two parts. The first is knowing your suppliers, the second is being able to reach them.

Knowing your suppliers means having, for each one that matters, a record of what they provide, what data they hold, what systems or APIs they connect to, and whether they carry privileged access. It means already knowing which suppliers are critical to which business services, and which hold your most sensitive data, because that's what decides where attention goes first when something happens, whether that's who gets asked or whose response gets reviewed first. This is the same groundwork covered in How Do We Identify Critical Suppliers In Our Supply Chain?.

Being able to reach them is a separate problem, and it's the one most organisations underestimate. It means having a named internal owner for each supplier relationship, a working contact route into the supplier itself, and clarity on any contractual notification requirements that apply. It also means having thought through continuity, so if a supplier does become unavailable, there's already a view of what alternative exists rather than working that out mid-incident.

This is where most organisations are genuinely behind. 55.4% of TPRM functions have only some or no established relationship with the security teams at their direct suppliers (Every Link Matters 2026). That means for well over half of organisations, even where a supplier is correctly flagged as critical, there's no guarantee anyone knows who to call when it matters.

‍

Stage 1: receive and validate the supplier incident notification

Receiving a supplier incident notification means establishing the basic facts of what's happened before deciding what to do about it. That's the whole job at this stage. Not exposure, not impact, not action. Just getting a clear, accurate account of what the supplier is reporting.

As soon as a supplier flags a problem, the pull is to jump straight to "are we affected." That question matters, but it can't be answered well on an incomplete or second-hand account of what's actually happened.

A handful of questions cover it: What happened, and when did it start? Which service, product or environment is affected? Is the incident ongoing, or has it been contained at the supplier's end? What has the supplier confirmed, and what's still suspected rather than verified? And who at the supplier is coordinating their response, so there's a single point of contact rather than a chain of forwarded emails.

First 30 minutes: minimum facts to establish

• What the supplier says has happened, in their words
• When it started, or when they first noticed it
• Whether it's ongoing or contained
• Which of their services or systems are involved
• Who's coordinating the supplier's response, and how to reach them

None of this requires judgement calls yet. It's a factual record, and it's the record everything else in this playbook builds on.

‍

Stage 2: work out whether it affects you

Working out whether a supplier's incident affects you means answering three questions and placing the answer into one of four exposure states, from no identified exposure through to material impact.

This is usually the largest decision in the whole process, and it's the one worth taking the most care over, because everything downstream, containment, escalation, recovery, depends on getting this right.

Start with the same three questions every time, regardless of what triggered the notification. Do you use the affected product, service or technology? That tells you whether the incident is even applicable to you. Has the supplier fixed it, or do they have a timescale for fixing it? That gives you the exposure window, how long the problem has existed and how much longer it's likely to run. Have they found any evidence of compromise? That tells you whether exposure has already turned into something worse.

Those three answers map onto the four exposure states.

No identified exposure: Means no affected service, data, system or access has been identified. This closes the question for now, though it's worth remembering that a "no" from a direct supplier doesn't automatically rule out something further down their own supply chain, which Stage 5 covers.

Potential exposure: Means a plausible connection exists, but impact is unconfirmed. This is the messiest state to sit in, because it's tempting to either escalate immediately or wait it out. Neither is right by default. It's the state that needs the next question answered fastest.

Confirmed exposure: Means the affected service, data or access directly relates to your organisation. At this point the incident is no longer hypothetical for you, even if the consequences are still being worked out.

Material Impact: Means confirmed exposure has created meaningful security or operational consequences. This is where containment stops being a decision you're weighing and becomes a decision you're acting on.

A supplier having an incident is not automatically an incident for you. Confirmed exposure is not the same as material impact, and material impact is not the same as your organisation being compromised. Each is a separate question, and skipping straight to the worst-case framing creates noise and pulls attention away from the suppliers where something might genuinely need checking.

‍

Stage 3: determine the business impact

Determining business impact means translating confirmed exposure into a plain answer to one question: if this supplier remains unavailable or compromised, what actually happens to our organisation? 

The inputs are the same ones you'd already have if supplier criticality is properly mapped.

• What does this supplier support?
• Is any sensitive data involved?
• Do they hold privileged access?
• How operationally dependent is the business on this specific service, and for how long could you manage without it?
• Are there alternatives or redundancy in place, and are there customer-facing or regulatory consequences if this runs on?

An organisation that already knows which suppliers are critical and what they touch can answer this in minutes. One that doesn't is starting the criticality conversation from scratch, in the middle of an incident, which is the slowest possible way to answer a question that shouldn't be new.

A supplier sitting at confirmed exposure but supporting a low-criticality service with no sensitive data might warrant logging and monitoring, nothing more. A supplier at the same exposure state but supporting a critical service with privileged access is a different conversation entirely, even though the technical exposure looks identical on paper.

For a deeper look at how to weigh that consequence, see How Could A Critical Supplier Failure Impact Our Business?.

‍

Stage 4: contain the exposure

Containing exposure means choosing an action that matches what you actually know, not defaulting to the action that feels safest. The instinct when something's wrong is to cut the connection. That's sometimes right, but treating it as the automatic answer ignores that disconnecting a supplier is rarely free, and the cost of getting it wrong runs in both directions.

• The options run from lightest to most disruptive.
• Increase monitoring on the connection.
• Rotate credentials that may have been exposed.
• Restrict access, particularly anything privileged.
• Disconnect the supplier entirely.
• Or continue as normal, deliberately, because the business impact of shutting things down outweighs the risk currently on the table.

Each of those decisions carries a trade-off. Increasing monitoring is close to free operationally, but it only works if detection capability is actually good enough to catch something. Rotating credentials is disruptive to a lesser degree, but only if the operational interruption of doing so is manageable. Restricting access depends on how much the business relies on that access to function day to day. Disconnecting entirely is the most protective option and the most expensive one, and it should be reserved for material, ongoing exposure rather than applied as a precaution.

The decision also depends on what's already known from the previous stages. A supplier confirming they use the affected technology but have already patched it needs logging, not action. A supplier confirming they use it, haven't patched it, and can't give a date is a different case, and the right response depends on what that supplier holds and touches. Confirmed compromise changes the calculation again, moving the situation closer to an active incident than a managed risk, and the case for acting immediately, even at real operational cost, gets substantially stronger.

‍

Stage 5: investigate fourth-party and shared dependencies

Investigating fourth-party dependencies means asking one more question before you close the book on a supplier that's told you "no." A direct supplier confirming they don't use the affected technology answers for themselves. It doesn't answer for what sits behind them.

This isn't a check to run on every supplier that responds cleanly. It matters most for the ones you'd already flagged as high priority, where a clean "no" from the direct supplier still leaves enough at stake to ask what they depend on.

Was the incident caused by something further down the chain? Which underlying provider or component is actually affected? Do any of your other suppliers rely on that same thing? Could the blast radius extend beyond the supplier that notified you in the first place?

Some of the most disruptive incidents in recent years followed exactly this pattern; the direct relationship looked fine, but a shared dependency sitting underneath multiple suppliers turned a single point of failure into a much wider one. Working out whether that's happening here is the point of this stage.

‍

Stage 6: what to ask the supplier

What you ask a supplier during an active incident builds on the same core three questions covered in Which Suppliers Should We Contact First During A Supply Chain Incident?, are you affected, have you fixed it, is there evidence of compromise. If you haven't identified which suppliers matter for this yet, start there.

Once you're past that point and already coordinating with a supplier on a confirmed or likely incident, the questions need to go further. This is where most first-response emails fall short, they stop at applicability when the situation has already moved past it.

Extend into the specifics. When did exposure actually begin, not just when it was noticed? Which of your services, data or systems does this touch, by name rather than in general terms? Has unauthorised access been confirmed, or is it still suspected? What containment has the supplier already completed, and what's still open? Are any of their own providers or subcontractors involved? What's their estimated remediation timeline? What evidence can they share to support what they're telling you, not just assert? And when should you expect the next update?

A supplier mid-incident is often fielding the same questions from several other customers at once, so keep the request specific and time-bound rather than open-ended.

If there's a live compromise, treat unexpected requests or unusual account activity from that contact with extra caution until containment is confirmed. The supplier's own channel may not be fully reliable yet.

Supplier cyber incident, first-response questions:

• When did exposure begin?
• Which of our services, data or systems does this touch specifically?
• Has unauthorised access been confirmed, or is it still suspected?
• What containment have you completed, and what's still outstanding?
• Are any of your own providers or subcontractors involved?
• What's your estimated remediation timeline?
• What evidence can you share to support that?
• When will we get the next update?

‍

Stage 7: escalate and report

Escalating a third-party incident means deciding who needs to know, and when, based on business impact rather than on how alarming the supplier's report sounds. A confirmed incident at a supplier holding no sensitive data and no privileged access might not need to go beyond the team already handling it. A potential exposure at a supplier tied to a critical service might need leadership visibility immediately, even before anything is confirmed.

Escalation becomes more likely as one or more of these apply: a critical service is affected, sensitive data is involved, privileged access has been exposed, compromise is confirmed rather than suspected, the operational impact is running long, or there are regulatory or customer implications attached. 

None of these need to be present alone. A confirmed compromise with no critical-service link might still warrant escalation on its own; a critical service with no confirmed compromise yet might warrant it too, on the strength of what's at stake if it turns out to be real.

Once you've decided to escalate, what leadership actually needs from that update, and how to keep it short rather than technical, is laid out in full in What Does Good Supply Chain Threat Response Look Like?. 

Reporting is a separate question from internal escalation, and it depends on where you sit regulatorily. Financial entities in scope of DORA need to consider whether an incident constitutes a major ICT-related incident requiring notification, and whether it touches a critical or important function delivered through a third party.

In the UK, firms already subject to the operational resilience rules from the Bank of England, FCA and PRA need to assess impact against their own tolerances for important business services. The UK's Cyber Security and Resilience Bill, introduced to Parliament in November 2025, will extend direct statutory duties to suppliers designated as critical under its new regime, which matters here because it changes who else might have reporting obligations of their own when a designated supplier is involved.

These obligations move fast and vary by sector, so check current guidance from your regulator directly before treating any specific deadline as fixed.

‍

Stage 8: decide when it's safe to recover or reconnect

Deciding when it's safe to recover means answering a different question from the one that's been driving the process so far. Up to this point, the question has been what's affected and how bad it could get. Now it's whether you have enough evidence to justify restoring the level of trust and access you had before the incident.

That distinction matters because most guidance on third-party incidents stops at containment. Recovery gets treated as something that happens on its own once the supplier says they've fixed it, but a supplier confirming they've resolved something is one input, not the whole answer.

The evidence worth having before reconnecting covers eight things:

1. The root cause is understood well enough to be confident it's actually been addressed, not just patched over.
2. Containment is complete, on their side and, if it extended that far, on yours.
3. The specific vulnerability or weakness has been remediated, not just mitigated temporarily. Any compromised credentials have been rotated.
4. There's no remaining evidence of persistence, nothing suggesting an attacker could still have a foothold.
5. Relevant systems have been tested rather than assumed fixed.
6. Monitoring has been increased, at least for a period, around the connection that was affected.
7. And the supplier has confirmed service restoration on their end.
8. If any risk remains outstanding, accept it explicitly rather than letting it go unaddressed by default.

This last point is different from deciding the risk is fully resolved, and treating "probably fine" as equivalent to "confirmed resolved" is how residual risk quietly becomes permanent risk nobody actually agreed to.

Don't ask only whether the supplier has fixed their problem. Ask whether what they've told you, combined with what you can verify yourself, is enough to justify the decision you're about to make.

‍

Stage 9: conduct a post-incident review

Conducting a post-incident review means turning what just happened into something that improves the next response, rather than closing the file and moving on. This stage gets skipped more often than any other in this playbook, usually because by the time recovery is confirmed, everyone involved wants to get back to their actual job. 

The review works through a set of honest questions rather than a self-congratulatory summary.

• How quickly did you identify exposure, and where did the delay actually sit, if there was one?
• Did you know who owned the relationship with this supplier before the incident started, or did that itself take time to establish?
• Could you contact them quickly, or did the contact route turn out to be a general inbox nobody monitored closely?
• Was the supplier information you were working from actually current, or did some of it turn out to be stale?
• Did any hidden dependencies emerge during Stage 5 that weren't on anyone's radar beforehand?
•  Did you understand this supplier's business criticality accurately, or did the incident reveal it mattered more, or less, than assumed?
• Were the escalation criteria clear enough to act on, or did people hesitate over whether to escalate?
• What supplier evidence was missing when you needed it?
• What should change in onboarding or ongoing assurance so the next incident starts from a stronger position?

If contact routes were unreliable, that's a gap to close in how suppliers are onboarded going forward, not just a note for this incident's file. If criticality assumptions were wrong, that's worth correcting in the underlying data rather than treating it as a one-off surprise. If contractual notification terms didn't hold up in practice, that's worth raising with procurement or legal before the next renewal, not after the next incident.

This closes the loop back into third-party risk management properly. The incident that just happened is, itself, now part of the supplier context that makes the next one easier to handle.

‍

How we approach this at Risk Ledger 

The hardest part of responding well to a supplier incident is having the right information already in place when the notification arrives, not building it in the moment. That's the problem we built Risk Ledger around.

We don't treat this as a separate exercise sitting on top of a supply chain programme. Every time a supplier goes through an assurance review, it isn't a one-off box-ticking exercise, it adds to the record we hold on that supplier and strengthens the communication channel already open with them.

That means when something does happen, we don't have to start a manual conversation from scratch, we can go back to a supplier we already have context on and get an answer faster.

Working out whether an incident reaches further than the supplier who notified you usually depends on understanding what that supplier itself relies on, and most organisations can't see that far down their own chain. The mapping we do of a customer's supply chain gives visibility into those deeper dependencies, including suppliers a business didn't realise were connected to them at all, a fifth or sixth party that turns out to matter because one of their direct suppliers uses one of theirs. Tracing that through is often what reveals whether an incident actually has an impact, rather than just looking that way on the surface.

None of this replaces the judgement calls involved in deciding whether to contain, escalate or recover. It just means those calls get made with information that's already there, instead of being reconstructed under pressure.

Would you have the supplier context you need, today, if a notification came in this afternoon?

Take the Supply Chain Exposure Assessment →

‍

Third-Party Incident Response Playbook FAQs

What's the difference between third-party incident response and normal incident response?

Third-party incident response covers what to do when a supplier, vendor or other external party reports a cyber incident, rather than something happening inside your own environment. The key difference is control. In an internal incident, you own the systems being investigated. In a third-party incident, most of the evidence belongs to another organisation, and you're dependent on them sharing it accurately and on time.

Who should own third-party incident response?

It needs joint ownership between the team that holds supplier relationship data and the team that runs incident response, rather than sitting entirely with one or the other. A supplier incident falls across both areas, and treating it as purely a governance matter or purely a technical one tends to slow down the decision about who's actually responsible for acting.

When should you disconnect a supplier after a cyber incident?

Disconnection is usually reserved for confirmed, material exposure, not applied automatically the moment a supplier reports a problem. Lighter options, increased monitoring, credential rotation or restricted access, cover most situations where exposure is only potential or unconfirmed. Disconnecting has real operational cost, so it should match what's actually known rather than how alarming the report initially sounds.

What should you ask a supplier after a data breach?

Start with whether they're affected and by which specific technology or service, whether they've fixed it or have a timescale for doing so, and whether they've found evidence of compromise. If the incident is confirmed rather than just potential, extend into when exposure began, what containment they've completed, what evidence they can actually share, and when you'll get the next update.

How do fourth parties affect incident response?

A direct supplier confirming they're not affected only answers for themselves, not for what they depend on. If that supplier uses a hosting provider, identity provider or other dependency that is affected, the incident can still reach you even though your direct relationship gave a clean answer. This matters most for suppliers already flagged as high priority, where a "no" still leaves enough at stake to ask one more question.

When can a supplier incident be considered resolved?

Not simply when the supplier says they've fixed it. Look for the root cause being properly understood, the vulnerability actually remediated rather than temporarily mitigated, any compromised credentials rotated, no remaining evidence of persistent access, relevant systems tested, and monitoring increased for a period afterwards. Any risk that's still outstanding should be accepted explicitly, not left unaddressed by default.

‍

_Sources

^{NCSC - Supply chain security guidance
NCSC - How to assess and gain confidence in your supply chain cyber security
Regulation (EU) 2022/2554 - Digital Operational Resilience Act (DORA), EUR-Lex
Bank of England / PRA - SS1/21: Operational resilience, impact tolerances for important business services
Bank of England / PRA - SS2/21: Outsourcing and third party risk management
UK Parliament - Cyber Security and Resilience (Network and Information Systems) Bill}