Major Incident Coordination Across Third Parties Guide: Running One Response With Many Organisations

In a major incident the hardest problem is often not the attacker but the number of organisations that each hold part of the evidence, part of the authority and part of the budget. A ransomware or supplier compromise can involve your own responders, an external incident response firm, a managed service provider, one or more cloud and SaaS providers, outside counsel, a cyber insurer and its panel, regulators, law enforcement and, for large-scale events, national CSIRTs. Without agreed decision rights, channels and evidence rules, they duplicate work, contradict each other and miss notification deadlines. This guide covers who is involved and what each needs, how to set decision rights before the incident, operating rhythm and information handling, regulatory coordination, cases where the third party is the source, and how to exercise and measure all of it. It is for incident commanders, CISOs, legal and risk teams, and vendor managers.

Key takeaways

• One incident commander, many contributors. Every party has its own priorities; the organisation that owns the risk must own the decisions, and contracts should say so.
• Most coordination is decided before the incident. Retainers, insurer consent, provider escalation paths, evidence access and notification clauses are hard to negotiate at 3am.
• Clocks start at different times for different parties. NIS2 expects an early warning within 24 hours and a notification within 72 hours of awareness, and GDPR expects 72 hours for personal data breaches; processors and suppliers must tell you fast enough for you to meet those.
• Label and route information deliberately. Use TLP 2.0 labels, a single source of truth, and out-of-band channels; assume the corporate email and chat platform may be compromised.
• Shared responsibility limits your evidence. In SaaS and managed cloud services, the provider holds logs you cannot collect yourself; agree how you get them before you need them.

Who is in the room and what each party needs

For how incident response fits within the wider risk model, see the Three Lines Model for Cyber Risk Guide.

Decision rights and governance

Write down who decides what before an incident, and get every party with a contract to accept it.

• Single incident commander: external firms advise; they do not decide containment or disclosure. Say this in the scope letter.
• Executive bridge: separate the technical bridge from a short executive decision meeting so decisions are made and recorded on a known cadence.
• Decision log: one log, owned by the incident commander's scribe, with time, decision, evidence, decider and dissent. Parties' own notes are not the record.

See the Incident Response Plan Template and the Crisis Management Guide for how this links to business crisis management.

Pre-arrangements and contracts

• IR retainer: confirm response times, scope, whether the firm is on your insurer's panel, and that it can be engaged through counsel. See the Incident Response Retainer Buyer's Guide.
• Insurer: record the notification route and deadline in the policy, the panel vendors, and what spend needs consent. Pre-approve your chosen IR firm where possible. See the Cyber Insurance Guide.
• Counsel and privilege: decide in advance whether counsel engages the IR firm and how reports are distributed. See the Legal Privilege in Incident Response Guide.
• MSP and outsourcers: contracts should give you emergency change authority, access to logs on their tooling, cooperation with your IR firm, and the right to suspend their access. See the Compromised MSP Playbook.
• Cloud and SaaS: know your support plan level and how to open the highest-severity security case, which logs you can export yourself, and which only the provider holds. The AWS Security Incident Response Guide notes that forensic options depend on the service model, with fewer tools available the more abstract the service.
• Notification clauses: suppliers and processors must tell you about incidents fast enough for your own deadlines. NIST SP 800-53 SR-8 (Notification Agreements) is the control to point to.
• Contact sheet: names, roles, out-of-band numbers and escalation paths for every party, held outside corporate systems. See the Incident Response Contact and Call Tree Template.

Running the response: rhythm, channels and evidence

1. Stand up the structure in the first hour: incident commander, scribe, technical lead, legal lead, communications lead, vendor liaison.
2. Open out-of-band channels if identity, email or chat may be compromised. See the Out-of-Band Communications Plan Template.
3. Set a cadence: technical syncs every few hours in the acute phase, an executive decision meeting twice a day, and a fixed time for external updates.
4. Keep one source of truth for scope, timeline and indicators, controlled by the incident commander. Every party works from it and feeds it.
5. Label information with TLP 2.0: TLP:RED for named recipients only, TLP:AMBER+STRICT for your organisation only, TLP:AMBER for organisation and its clients on a need-to-know basis, TLP:GREEN for the community, TLP:CLEAR for public. Recipients need the source's permission to share more widely.
6. Control evidence: agree who collects what, where copies go, and the chain of custody, so the IR firm, MSP and provider do not each take incompatible images. See the Evidence Handling and Chain of Custody Guide.
7. Track third-party actions as tasks with an owner and due time: provider log exports, MSP credential resets, SaaS token revocations.
8. Close cleanly: agree when each party stands down and how their final reports are delivered and protected.

Where identity fits: the third parties in an incident usually hold standing access, from MSP admin accounts to SaaS integration tokens. Revoking and reissuing those credentials is a coordinated task across organisations, and one missed token restarts the incident. See the Identity Incident Response Playbook.

Regulatory and notification coordination

Keep a single notification calendar with the awareness time each clock runs from, owned by counsel. Make sure statements to regulators, customers, markets and the press come from one approved fact base. See the Incident Communication Plan Template.

When the third party is the source

A supplier compromise reverses the roles: the third party is both the victim and the source of your exposure, and its priorities may not match yours.

• Do not wait for the supplier's full report. Act on your own exposure: revoke tokens, disable integrations, rotate shared secrets, review logs for the supplier's identities.
• Ask specific questions: which of our data and credentials were reachable, what indicators should we search for, which time window, and what actions have you taken on our behalf.
• Record what the supplier did for you. Platform-wide actions such as mass token revocation (Salesloft and Salesforce revoked all Drift tokens on 20 August 2025) do not remove the need for each customer to search its own data and rotate secrets stored there.
• Concentration risk: when one provider fails or is compromised, many customers call at once. Plan for slow support responses. See the Third-Party Concentration Risk Guide.

National and EU-level coordination

For large-scale incidents, coordination moves beyond the organisation. In the EU, ENISA supports the CSIRTs Network, which links national CSIRTs for cross-border incidents, and CyCLONe, the cyber crisis liaison network that NIS2 describes as working between the technical and political levels during large-scale incidents and crises. Organisations do not join these networks directly; they reach them through their national CSIRT or competent authority. In practice this means your notification to the national CSIRT is also your entry into wider coordination, so make it accurate and keep it updated. National CSIRTs and law enforcement may also hold intelligence from other victims of the same campaign that can shorten your investigation.

Exercising and measuring coordination

• Exercise with the real parties. Invite the IR firm, MSP and insurer to at least one exercise a year, and run a supplier-compromise scenario. NIST CSF 2.0 ID.IM-02 expects improvements from tests done in coordination with suppliers. See the Cyber Incident Exercises Beyond Tabletop Guide.
• Test the paperwork: can you engage the IR firm through counsel and get insurer consent within the first four hours?
• Test provider escalation: open a high-severity security case with a major provider in an exercise and measure time to a human response.

Metrics:

• Time from declaration to all key parties engaged (IR firm, counsel, insurer, MSP).
• Share of critical suppliers with incident notification and cooperation clauses.
• Share of critical SaaS and cloud services where you know how to obtain provider-held logs.
• Notification deadlines met, per regime, over the last 12 months of incidents.
• Exercise findings involving third parties closed within their target date.

Framework mapping

Common failure patterns

• Two incident commanders. The IR firm and the MSP each run their own bridge; containment actions conflict and evidence is lost.
• Insurer told late. Spend made before consent, or a non-panel firm engaged without approval, creates coverage disputes during the incident.
• Help desk and outsourced access left open. In the Marks and Spencer cyberattack attackers impersonated a third-party user to get in; when the entry point sits with a supplier, its staff and access must be part of containment from the first hour.
• Waiting on the provider. Teams wait for a supplier's root cause while their own tokens remain valid.
• Uncontrolled distribution. Draft forensic findings forwarded widely, losing privilege and leaking indicators.
• Clocks misread. The 24-hour or 72-hour clock is counted from the IR firm's confirmation rather than from when the organisation became aware.

Lessons from incidents

The Salesloft Drift breach shows coordination at scale. A threat actor tracked by Google as UNC6395 used stolen OAuth tokens from one chatbot integration to export data from Salesforce instances between 8 and 18 August 2025, and Google estimated more than 700 organisations may have been affected. Three parties acted on behalf of everyone: the integration vendor and the platform jointly revoked tokens, the platform disabled the integration, and a threat intelligence team published guidance telling customers to treat connected tokens as compromised. Customers who had already mapped which integrations held which tokens, and who had a vendor owner with authority to act, could move the same day. Those who had not spent the first days discovering what Drift was connected to.

The Marks and Spencer cyberattack shows the other side: when the entry point is a third party's user, the outsourcer, the victim and later law enforcement all hold parts of the picture, and the cost of the incident (estimated at £300 million in profit before recoveries) far exceeds the cost of agreeing in advance how a supplier's accounts are suspended and investigated.

Scaling the approach

• Small organisations: the MSP may be the whole IT function. Agree in the contract who leads an incident, keep one IR retainer (often through the insurer's panel), and keep a one-page contact sheet. Do not let the MSP investigate itself if it may be the source; see the Cybersecurity for MSPs and MSSPs Guide.
• Mid-sized organisations: name a vendor liaison role in the incident structure and keep a register of critical suppliers with their incident contacts and log access arrangements.
• Large and regulated organisations: run a standing coordination cell during major incidents, with separate technical, legal and communications workstreams, a notification calendar per jurisdiction and pre-agreed escalation paths with national CSIRTs and sector regulators.

Practitioner checklist

• Name the incident commander role and write decision rights for each type of major decision.
• Hold a retainer with an IR firm that your insurer accepts, engageable through counsel.
• Record insurer notification routes, deadlines and consent rules in the plan.
• Add notification, cooperation, log access and access suspension clauses to MSP and critical supplier contracts.
• Document how to open top-severity security cases with each critical cloud and SaaS provider.
• Keep an out-of-band contact sheet for every party.
• Adopt TLP 2.0 labels and a single source of truth for incident facts.
• Maintain one notification calendar across all regimes, owned by counsel.
• Exercise a supplier-compromise scenario with real third parties yearly.
• Track coordination metrics and close third-party exercise findings.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• ENISA: Incident Response (CSIRTs Network and CyCLONe)
• FIRST: Traffic Light Protocol 2.0
• AWS: Security Incident Response Guide, Shared Responsibility

Related NHI Mgmt Group resources: Incident Response Guide · Three Lines Model for Cyber Risk Guide · Incident Response Retainer Buyer's Guide · Compromised MSP Playbook