A payment processor's status page switches to "investigating". Nothing inside the bank has failed, and the operations floor is fully staffed. Card authorisations are declining anyway, and the only engineers who can fix it work for a different company.
A third-party outage response is the part you still own: a live, time-stamped account of what you asked the provider for, what they told you, and which of your own people owned each exchange. The repair sits outside your control. The record does not.
When an incident starts at a supplier, the firm keeps every obligation and loses every control. Response work changes shape: instead of fixing the fault, teams chase status, verify claims, decide on workarounds and log the exchange. That log is what a regulator reads afterwards.
Most firms reach this moment well equipped for the wrong incident. Alerting works. The bridge call starts on time. What has no named owner is the contract line itself, and closing that gap is the whole job of a third-party outage response. It is also what resilience teams want from DORA compliance software: a way to show what their own people did while someone else's system was down.
What Does A Good Third-Party Outage Response Look Like?
A good third-party outage response records four things as they happen: what the provider has told you, what you asked them to confirm, what your own teams did in response, and who owned each of those steps. The provider's repair work belongs to the provider. The account of the response belongs to you.
Those two get confused constantly. A supplier's restoration timeline is their business. Your response timeline is a separate document, and it is the one you will be asked to produce. It answers four questions: who was told, what was done, what was decided, and when.
So a third-party outage response produces a short list of owned items that look nothing like the supplier's own work. Someone owns the call to the account manager, and someone owns the question of whether a reporting threshold has been crossed. A reviewer will expect each one assigned to a name.
Why Does The Response Stall When The Fault Sits With A Supplier?
A third-party outage response stalls because the usual playbook assigns work to people who can act, and during a supplier outage almost nobody inside the firm can act on the cause. Teams fall back on chasing. Chasing happens in inboxes, direct messages and phone calls, which leaves no structured record and no visible owner.
Three failures show up again and again when a firm is managing an outsourced provider incident.
The first is duplicated chasing. Technology, procurement and the relationship manager all contact the supplier separately, get slightly different answers, and the firm ends up holding three versions of the status.
The second is the silent gap. Everyone assumes someone senior is dealing with the contract, so nobody reads the notification clause, and the firm misses the moment it was entitled to a formal written statement.
The third is the missing decision record. Workarounds get used and limits get raised, and none of it is written down as a decision with a name on it. Weeks later the question is who authorised it, and the answer by then is a guess. That is what a structured third-party outage response exists to prevent.
Who Owns Each Action When The Outage Is On The Supplier's Side?
A third-party outage response splits at the contract line. The provider owns diagnosis and repair. Your firm owns everything around it: triggering the contractual notification, verifying the status you are given, deciding on workarounds, telling customers and staff, judging the reporting threshold, and confirming for yourself that service is genuinely back.
This table separates the work the supplier owns from the work that stays with your firm, and names the evidence each one should leave behind.
| Action during the outage | Who owns it | What usable evidence looks like |
|---|---|---|
| Diagnosing and repairing the fault | The provider | Their written status updates, kept with the time you received each one |
| Formal notification under the contract | The provider, triggered by your firm | A dated request, and the provider’s response or a logged note that none came |
| Verifying the provider’s status claim | Your technology or operations lead | A named owner, a time stamp, and what was checked |
| Deciding on a workaround or service reduction | Your incident manager or accountable executive | The decision, who made it, when, and what was rejected |
| Informing customers, staff and intermediaries | Your communications and operations teams | Message content, recipients, send time and acknowledgements |
| Judging the regulatory reporting threshold | Your risk or compliance function | The classification, the time it was made, and the reasoning |
| Confirming service is genuinely restored | Your firm, not the provider’s status page | Your own verification check, with an owner and a time |
The right-hand column is the part firms skip. Your own people produce every row of it, and every row is missing by default unless somebody records it while the incident is running. In a third-party outage response the evidence of good work is almost entirely about your own conduct.
What Do Regulators Expect You To Be Able To Show?
Regulators expect the firm to stay accountable for an incident it did not cause. Under the EU's Digital Operational Resilience Act, a financial entity reports major incidents to its competent authority and remains fully responsible for handling them. UK and Australian rules now add a register of material third-party arrangements and direct notification duties.
As at November 2026, three sets of rules shape what a third-party outage response has to produce. This is orientation, not legal advice, and firms should take their own view on scope and thresholds.
European Union. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 30 sets out what a contract for ICT services must contain, including service level descriptions and the provider's obligation to assist you when an incident affecting the service occurs, at no extra cost or at a cost agreed in advance. Article 22 is blunter about accountability: the financial entity "shall remain fully responsible for the handling and for consequences of the ICT-related incidents reported". The clocks come from Commission Delegated Regulation (EU) 2025/301 of 23 October 2024: an initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report no later than one month after the last intermediate report. A supplier who has not called you back pauses none of those clocks.
United Kingdom. The FCA published PS26/2 on 18 March 2026, alongside a parallel PRA statement. It defines a material third-party arrangement, requires firms to notify the regulator of new or significantly changed arrangements, and requires a register of those arrangements to be submitted annually. The rules come into force on 18 March 2027.
Australia. APRA's Prudential Standard CPS 230 on operational risk management has applied since 1 July 2025, with amended requirements and updated guidance in force from 1 July 2026. It requires a material service provider register and notification of new or changed material arrangements.
The common thread is unglamorous. Each regime assumes you can produce a contemporaneous record of a disruption someone else caused, and none of them treats the supplier's own account as a substitute for yours.
How Does Crises Control Help With Third-Party Incident Management In Financial Services?
Crises Control supports a third-party outage response by holding it as a structured, time-stamped incident record. Teams assign the chasing, verifying and deciding work to named owners, track completion, and export the result. The platform does not reach inside the supplier, and it does not shorten their repair.
Crises Control is an Operational Incident Coordination Platform, and the module for this problem is Task Manager, its execution layer. Its own page describes assigning response tasks to people or teams, maintaining clear ownership for every task throughout the incident, tracking progress from assignment through to completion, and configuring escalation rules for overdue or unclaimed tasks. It records task ownership, acceptance times, status changes, escalation activity and completion updates. Buyers hunting for the best software for tracking supplier actions during third-party outages are usually after this layer, sold as Incident Task Management Software rather than as another alerting tool.
Applied to a supplier outage, the owned items from the table above stop being verbal commitments. "Call the account manager and get a written status" becomes an assigned task with a named owner and a deadline, and the escalation rule fires when nobody claims it. The same mechanism carries the regulatory classification question, which is the one most often remembered too late.
What the platform produces afterwards is the record. Crises Control's material on compliance and audit records describes recording and time-stamping every action to create an audit-ready incident record, and puts the point plainly: compliance starts with accurate records, not manual reconstruction after an incident. The same reasoning sits behind DORA compliance software for regulated firms.
Two limits are worth stating, because a third-party outage response is often sold as more automated than it is. The platform can't assign work to the supplier's engineers or see into their systems. And it can't tell you whether an incident is reportable. It records the classification, the time it was made and who made it. The judgement stays with your risk and compliance people, which is where the rules intend it to sit. The pattern matches tracking critical actions inside your own organisation, with one difference: half the timeline belongs to someone else, and you can only evidence your half.
Third-Party Outage Response Checklist
Run this inside the first hour of a supplier-side disruption. A named person owns each item, not a team.
- Open an incident record even though the fault is not yours, and start the clock on your own timeline.
- Name one point of contact for the supplier and route every enquiry through that person, so you hold one version of the status.
- Read the contract's notification clause, request the formal statement it entitles you to, and log the request whether or not a statement arrives.
- Give verification of the supplier's status claim to someone inside the firm, with a time stamp on what they checked.
- Record the workaround decision as a decision: what was chosen, who authorised it, when, and what was rejected.
- Assign the regulatory classification question explicitly, in the first hour, with the reasoning written down.
- Log every customer, staff and intermediary communication with its send time and its acknowledgements.
- Verify restoration yourself before closing, and keep the third-party outage response open until your own check passes. The status page turning green is not the same thing.
The Record You Build While You Wait
A supplier outage is the incident where your firm has the least control and the most exposure. You can't shorten the repair, raise the capacity or fix the code. What you can do is decide in advance who owns the chasing, who owns the verifying, who owns the customer message, and who owns the call on whether a regulator needs to hear about it today. Those four owners, assigned and tracked, separate a defensible third-party outage response from a folder of forwarded emails.
The waiting is not dead time. It is when the evidence either gets created or gets lost. Firms that treat the gap as something to coordinate come out of a third-party incident with an account they can hand to a board, an auditor or a competent authority without rebuilding it from memory first.
To see what that record looks like while an incident is still open, request a demo and bring your own supplier scenario to it.
Frequently Asked Questions
What is a third-party outage in financial services?
A third-party outage is a disruption to a service a financial firm depends on but does not operate, such as a payment processor, cloud platform, market data feed or claims system. The firm cannot repair the fault, and keeps full regulatory accountability for how it responds. Under the EU's Digital Operational Resilience Act (DORA), the financial entity reports the incident and remains responsible for handling it.
Can incident management software assign tasks to our supplier's staff?
No, and no credible platform should claim otherwise. Incident coordination tools assign and track work inside your own organisation, including the work of chasing, verifying and recording what the supplier reports. The contract, not the software, is what obliges a provider to act. DORA Article 30 sets out those obligations for firms in scope in the European Union.
How is a third-party outage response different from ordinary incident management?
Ordinary incident tracking assigns the fix. A third-party outage response cannot, so it assigns the work around the fix: the chase, the verification, the workaround decision, the customer message and the reporting judgement. Roughly half the timeline belongs to another organisation, and you can only evidence your half.
When do we have to tell a regulator about an outage caused by our provider?
It depends on your jurisdiction and on how the incident is classified, so take your own compliance view. In the European Union, Delegated Regulation (EU) 2025/301 requires an initial notification within four hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. A provider's silence does not extend any reporting deadline.
Do we need a register of our third-party arrangements?
Increasingly, yes. DORA requires a register of information covering contractual arrangements for ICT services. The FCA's PS26/2 requires a register of material third-party arrangements, submitted annually, once the rules take effect on 18 March 2027. APRA's CPS 230 requires a material service provider register in Australia. Many firms run Incident Task Management Software alongside the register, so the response is as documented as the relationship.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
