Business continuity programs were built for a world in which the organization owned its failures: its building burned, its data center flooded, its people could not get to work. The failures that now stop organizations mostly belong to someone else. The payroll provider is hit by ransomware, the logistics contractor goes into administration, the cloud region is down, the sole supplier of a packaging component has a fire, the security agent everyone runs crashes every machine at once. Continuity planning has not caught up: most supplier files hold a certificate saying the supplier has a plan, and most continuity plans assume the suppliers will be there. This guide is about closing that gap. It sets criticality-tiered continuity requirements for suppliers, the evidence that proves resilience rather than asserting it, the arithmetic that links a supplier’s recovery objectives to your own tolerances, exit and substitution planning that is realistic about time, the contract clauses that matter in a crisis, joint exercises, an audit program, and a worked example from a food manufacturer whose first CAE found the problem in the first ninety days.
It bridges two clusters on this site. From the third-party side it follows the third-party risk management program guide, vendor due diligence by risk tier and fourth parties and vendor concentration; from the continuity side it extends how to audit business continuity and resilience and the cyber resilience audit guide. The IIA’s Third-Party Topical Requirement, effective 15 September 2026, and its Organizational Resilience Topical Requirement, effective 30 April 2027, meet at exactly this subject, and internal auditors will be asked to evidence both.
In this guide
- Why supplier failure is now the main continuity scenario
- Criticality-tiered continuity requirements for suppliers
- Evidence beyond the certificate
- The arithmetic: their recovery objectives against your tolerances
- Exit and substitution planning, realistically
- Contract clauses that matter in a crisis
- Joint exercises and the supplier-failure scenario library
- Between exercises: the four signals that a supplier’s resilience has changed
- The audit program: twelve tests
- Worked example: a food manufacturer’s five suppliers that could stop the plants
- Related guides
Why supplier failure is now the main continuity scenario
Three shifts made supplier failure the dominant continuity risk. Outsourcing moved the processes that used to fail inside the organization to providers whose failures the organization cannot see coming. Cloud and software-as-a-service moved the infrastructure with them, so that the recovery site the continuity plan describes is, for most organizations, someone else’s region. And the same providers serve everyone, so a single failure is now a simultaneous failure for every customer, which removes the informal fallback most plans quietly relied on: borrowing capacity from a peer or a competitor who, it turns out, is down too. Regulators recognized the shift first. The UK’s operational resilience regime, in force since March 2022 with its transition ended on 31 March 2025, made firms set impact tolerances for important business services regardless of who delivers them; DORA made ICT third-party risk a pillar of digital resilience; the US interagency guidance made operational resilience a named due-diligence factor; and the IIA now has two Topical Requirements that meet on the subject.
The gap in most programs is not awareness but evidence. Supplier files hold certificates and policies, which prove that the supplier has a document. What continuity needs is different in kind: the supplier’s recovery objectives for the specific service, the results of the supplier’s last test against them, the supplier’s own dependencies, and the organization’s own plan for the interval in which the supplier is gone. A supplier that has never been asked for a test result will send a policy; a supplier that is asked every year for the result sends the result, and the difference in what the organization knows is total.
Criticality-tiered continuity requirements for suppliers
Continuity requirements follow the tiering in the program guide, and they are set by the organization from its own impact tolerances, not accepted from the supplier’s standard terms. The table gives the default requirement by tier, in five dimensions: the recovery objectives the supplier must commit to, the evidence it must provide, its participation in the organization’s exercises, the organization’s own fallback for the supplier’s loss, and the exit provision. Tier 1 is deliberately demanding; it applies to the handful of suppliers whose failure would breach a tolerance, and the demands are the price of that position.
| Dimension | Tier 1: critical | Tier 2: significant | Tier 3 and 4 |
|---|---|---|---|
| Recovery objectives | Contractual recovery time and recovery point objectives for the service, set inside the organization’s tolerance with margin for the organization’s own restart | Recovery objectives stated in the contract or the supplier’s published service terms, checked against the organization’s needs | None required beyond the standard terms |
| Evidence | Annual: the supplier’s test results for the service against its objectives, its dependency and location map, its incident history, and confirmation of no material change; the assurance report’s availability and continuity controls read | Annual confirmation that a plan exists and was tested, with the date and the headline result | None |
| Exercise participation | Participates in at least one of the organization’s exercises a year; joint recovery test with the organization’s data volumes at least every two years | Consulted in scenario design where the supplier is in scope; no participation required | None |
| Organization’s fallback | A rehearsed degraded-mode procedure for the loss of the service for the tolerance period, plus a tested exit or substitution route for a longer loss | A documented workaround for the loss of the service for the period until an alternative can be engaged | Business owner’s judgment; no plan |
| Exit provision | Exit plan written and walked through; data portability and transition assistance contracted; escrow or step-in where the service is software the organization cannot replace | Exit approach documented; data return contracted | Notice and data deletion |
The tiering decision for continuity purposes has one twist relative to the general tiering: a supplier can be Tier 1 for continuity without being Tier 1 for anything else. A packaging supplier holds no data and no access, but if it is the only qualified source of the component that closes every bottle, its failure stops the plant, and the continuity tier is set by what stops when the supplier does, not by what the supplier can see.
Evidence beyond the certificate
The evidence problem is specific enough to tabulate. For each document a supplier typically offers, there is a stronger document that answers the question the first one only gestures at. The right-hand column is what to ask for; suppliers that serve regulated customers have all of it, and suppliers that do not have it are telling you something about their tier.
| What the supplier offers | What it proves | What to ask for instead, or as well |
|---|---|---|
| A business continuity policy or a certificate (ISO 22301 or similar) | A management system exists and, for a certificate, was audited for the scope on the certificate | The scope statement; the plan for the specific service; the date and result of its last test |
| A statement of recovery time and point objectives | A target | The recovery time and point achieved in the last test, and in the last real incident, with dates |
| A SOC 2 report with the availability criteria in scope | Controls over availability were designed and, for a Type 2, operated over the period, with any exceptions | The complementary subservice organizations carved out (the supplier’s own recovery dependencies) and their assurance; the exceptions in the availability controls read and assessed |
| A disaster-recovery test summary | Something was tested | The scenario, the systems in scope, whether the test used production data volumes, whether customers participated, the recovery achieved, the issues found and their remediation status |
| A statement that data is backed up | Backups exist | Backup frequency, immutability, off-platform copy, restore test results and time to restore the organization’s data specifically; the evidence standard in the backup and recovery audit guide |
| A statement of geographic redundancy | Two locations | Which provider and region hold the primary and the recovery; whether they share a provider, a region or a control plane; failover test results |
| An incident response policy | A process exists | The notification period committed in the contract; the last three incidents affecting customers, with detection and notification times; the incident history for the service |
| A key-supplier or subcontractor statement | Awareness | The dependency map: the suppliers and platforms the service cannot run without, with locations and the supplier’s continuity arrangements for each |
Two of these matter more than the rest. The last test’s achieved recovery, with production data volumes, is the only number that tells you whether the objective in the contract is real; a supplier whose test recovered a small subset in four hours has not shown it can recover your estate in four hours, which is exactly what the bank in the concentration guide found when its core provider’s cloud recovery, tested by the provider, was first run with the bank’s data. And the dependency map is the supplier’s own fourth-party view, without which the organization’s concentration register is incomplete.
The arithmetic: their recovery objectives against your tolerances
Continuity requirements for a supplier are derived, not negotiated, and the derivation is arithmetic most programs skip. Start from the organization’s own tolerance for the business service the supplier supports: the maximum period the service can be unavailable before harm becomes intolerable, set by the business and, in regulated sectors, formally as an impact tolerance. The supplier’s recovery time objective must fit inside that tolerance with room for three things the supplier’s clock does not include: the time for the organization to detect and confirm the failure and invoke its own plan, the time to restart the organization’s own processes once the supplier’s service returns, and the backlog that accumulates while the service is down and must be cleared before the business is genuinely recovered. A supplier RTO equal to the tolerance is a plan to breach the tolerance every time. The same logic applies to the recovery point: the supplier’s data loss window plus the organization’s re-keying capacity has to fit the business’s tolerance for lost transactions.
Written down for each Tier 1 supplier, the arithmetic becomes a one-line resilience statement that the business owner, the supplier and the auditor can all test: tolerance, supplier objective, organization’s overhead, margin, and the last achieved recovery against all of it. Where the margin is negative, and it often is once the overhead is counted honestly, the organization has three choices: renegotiate the supplier’s objective, shorten its own overhead with a rehearsed degraded mode, or accept a tolerance breach knowingly and record it. The method is the same one the business continuity audit guide applies to the organization’s own processes; the supplier is simply a process the organization does not run.
Exit and substitution planning, realistically
Exit plans fail by being written for the planned case. The planned exit, at the end of a contract with a transition period and a cooperative supplier, is a project; the case the plan has to serve is the stressed one, when the supplier has failed, been breached, gone bankrupt or been directed out, and the transition period is zero. Realistic planning starts by admitting that for most Tier 1 services no substitute can be stood up inside the tolerance, and that the plan is therefore two plans: how the organization survives the tolerance period without the service (degraded mode), and how it replaces the service over the weeks or months a substitution actually takes. The table sets out the four exit routes with honest timelines.
| Exit route | What it involves | Realistic timeline for a critical service | Preconditions to have in place now |
|---|---|---|---|
| Degraded mode (ride out the outage) | Operating the business without the service using manual or reduced procedures | Hours to days; the only route that works inside most tolerances | A rehearsed procedure, the people trained, the paper or spreadsheet fallbacks ready, the limits agreed (what the business will not do in degraded mode) |
| Switch to a pre-contracted alternative | A second provider under contract, with data synchronised or portable and the integration built | Days to weeks if genuinely pre-built; months if the second contract is a letter of intent | The alternative tested with real data at least once; data portability in the primary contract; a decision authority for the switch |
| Bring the service in-house | Rebuilding the capability internally, often on the failed supplier’s software under escrow | Months; software escrow that has never been tested typically adds weeks | Escrow with verified deposits; the skills identified; the infrastructure available; a tested escrow release |
| Replace through a new procurement | Selecting and onboarding a new supplier under stress | Three to twelve months, longer in regulated sectors | A shortlist maintained; the requirements and the data model documented; the due-diligence file from the last selection kept current |
An exit plan is credible when it names which route applies for which duration, has been walked through with the business owner and the supplier’s relationship manager, and has been tested at least as a tabletop; a plan that exists only in the vendor management tool as a checkbox is what assessors mean by “exit plans in place but not evidenced”. Concentration adds the overlay from the fourth-party guide: where the alternative provider shares the failed provider’s region or fourth party, the switch route is illusory, and the plan should say so rather than offer it.
Contract clauses that matter in a crisis
In a supplier failure the contract is read for the first time by people who did not negotiate it, at speed, and what they need from it is different from what procurement optimized for. The clauses below are the ones that decide what the organization can do in the first seventy-two hours and the first three months; the test column is what an auditor checks in the executed Tier 1 contracts, because the template is never the problem.
| Clause | What it does in a crisis | What the auditor tests |
|---|---|---|
| Recovery objectives as obligations | Turns a target into a breach with remedies; gives the organization standing to demand the test results | Objectives are in the contract, not a policy the contract references; remedies and reporting are specified |
| Incident and outage notification | Starts the organization’s own plan on time; feeds regulatory clocks | A fixed period in hours, a named channel, coverage of subcontractor incidents; evidence of past notifications against the period |
| Priority and allocation in a shared incident | When the provider is down for every customer, decides whether the organization is restored first, last or in turn | Whether any priority or minimum-capacity commitment exists; for regulated firms, whether the supplier commits to regulatory priorities |
| Data return and portability | Makes the switch and in-house routes possible; without a format and a timeline, data return in a crisis is a negotiation | Format, timeline, cost, and continued access to data after termination; whether a data export has ever been tested |
| Transition assistance and continued service | Obliges the supplier to keep the service running for a transition period after termination, including on the supplier’s insolvency where enforceable | Period, pricing, scope; whether the obligation survives termination for cause and change of control |
| Step-in and escrow | Lets the organization or a nominated third party operate the service, or release the software, when the supplier cannot | Trigger events defined; escrow deposits verified and current; a release tested or at least walked through |
| Subcontractor and location change notification | Prevents the recovery site or the delivery location moving without the organization’s knowledge | Notification or consent required; the current schedule matches the dependency map |
| Regulatory access and cooperation | For regulated organizations, lets supervisors and the organization’s auditors see the supplier during and after an incident | Present, unrestricted by the supplier’s own confidentiality terms, exercised or exercisable |
Joint exercises and the supplier-failure scenario library
An exercise is the only evidence that a continuity plan, the organization’s or the supplier’s, works, and supplier failure belongs in the organization’s exercise calendar as a standing scenario type rather than an occasional theme. Two formats do the work. The tabletop, two to three hours with the business owner, the supplier’s relationship manager, technology and risk, walks through a scenario against the plan and produces a list of what nobody could answer; it is cheap, and it is where most exit plans are discovered to be checkboxes. The joint recovery test, in which the supplier recovers the organization’s service with the organization’s data and the organization restarts its own processes on top, is expensive and is the only way to know the achieved recovery time; Tier 1 suppliers should be contracted to participate in one at least every two years. The scenario library below gives five supplier-failure scenarios that between them exercise the plan’s weakest joints; each is written as an injection for a tabletop.
Scenario 1: The silent outage. The Tier 1 processing provider has been down for ninety minutes and has not notified anyone; the first sign is a customer complaint. Questions: how did we find out, who invokes the plan, what does the contract entitle us to demand, and what does degraded mode look like at hour two, hour six and day two?
Scenario 2: The shared failure. A cloud region used by two of our Tier 1 suppliers and by our own recovery site is unavailable, and the suppliers are restoring all customers at once with no priority for us. Questions: which services stop, in what order do we bring them back, what can the business do in the meantime, and which of our exit routes are actually available given that the alternative provider is in the same region?
Scenario 3: The insolvency. The logistics contractor that runs our depot deliveries enters administration on a Friday; drivers are told not to work Monday. Questions: what does the contract give us, can we hire the drivers or the fleet directly, which customers do we serve first, and how long until a replacement contractor is operating?
Scenario 4: The breach. The payroll provider reports a ransomware incident affecting its platform and possibly our employee data, eleven days after it began. Questions: what are our own regulatory notification obligations and their deadlines, how do we pay people this month, what does the notification clause say about eleven days, and do we continue the relationship?
Scenario 5: The directed exit. A regulator, or the board after a due-diligence finding, directs the organisation to leave a Tier 1 supplier within six months. Questions: which exit route, what has to be true by month two, what does data portability actually look like, and who owns the program?
Between exercises: the four signals that a supplier’s resilience has changed
Evidence gathered annually and exercises run every two years leave long gaps, and a supplier’s resilience changes inside them. Four signals should reopen the resilience file out of cycle, and each has a cheap source. The first is a change in the supplier’s dependency map, learned from a subprocessor notification, a status-page incident attributed to a new provider, or a renewal conversation; a recovery site that moves is the classic case. The second is an incident at the supplier or one of its dependencies, whether or not it reached the organization, because the supplier’s own recovery in a real event is the best test result it will ever produce and should be requested within the month. The third is a financial or ownership signal, since an acquired supplier’s continuity arrangements are usually rationalised by the acquirer within a year and a distressed supplier stops paying for its recovery site before it stops paying its engineers. The fourth is a change in the organization’s own tolerance, when the business service becomes more important, its volumes grow, or a regulator sets a tolerance the old arithmetic no longer meets. A monitoring calendar that lists these four triggers next to the annual evidence date, with an owner for each, is the difference between a resilience file that is current and one that was current when it was built.
The audit program: twelve tests
The tests below can be run as the resilience section of a third-party program audit or as a standalone review of 150 to 250 hours, and they evidence the Third-Party Topical Requirement’s control processes on due diligence, contracting, monitoring and offboarding as well as the resilience-related risk requirements; where the Organizational Resilience Topical Requirement applies from April 2027, they cover its third-party dependencies as well.
1. Obtain the list of Tier 1 suppliers for continuity purposes and reconcile it to the business services and impact tolerances; confirm suppliers whose failure would breach a tolerance are Tier 1 regardless of data or access. 2. For each Tier 1 supplier, obtain the resilience statement: tolerance, supplier objectives, organisation’s overhead, margin, last achieved recovery; re-perform the arithmetic. 3. Test the evidence file against the “instead” column: test results, dependency map, incident history, assurance report availability controls read; list suppliers with certificates only. 4. Confirm the supplier’s recovery objectives are contractual obligations with remedies for the sample. 5. Read the executed Tier 1 contracts against the crisis clauses; list departures and acceptances. 6. For each Tier 1 supplier, obtain the degraded-mode procedure and evidence it was rehearsed in the last two years. 7. Obtain the exit plan for each Tier 1 supplier; confirm it names the route by duration, has been walked through, and that its preconditions (portability, escrow, alternative tested) are in place. 8. Confirm at least one supplier-failure scenario was exercised in the organisation’s continuity program in the last year, with the supplier participating where Tier 1, and trace the actions arising to closure. 9. For suppliers with escrow, confirm deposits are current and verified and a release has been tested or walked through. 10. Overlay the concentration register: identify exit routes that depend on the same provider, region or fourth party as the primary. 11. For supplier incidents in the period, compare the notification received with the contractual period and the organisation’s own plan invocation time. 12. Confirm reporting of third-party resilience status (Tier 1 population, evidence currency, exercise results, exit plan readiness) to the risk committee or board in the period.
Worked example: a food manufacturer’s five suppliers that could stop the plants
Brightwater Foods is a 180-million-dollar food manufacturer with 600 staff across three plants, a first-time chief audit executive hired the year the board formed an audit committee, and a co-sourced audit partner that had already delivered a cybersecurity framework assessment and a ransomware readiness review, the latter finding no immutable backup copy, an ERP restore of 41 hours against a 24-hour objective and nine days to full recovery against a five-day tolerance. The CAE’s draft strategy put technology and resilience assurance through the co-source partner as one of three objectives, and the first engagement under it was a third-party resilience review, 180 hours, built on the twelve tests above. Its first step was the one this guide insists on: the continuity tier, set by what stops when the supplier does, not by data or access.
That test produced five Tier 1 suppliers, only one of which the company had ever thought of as critical. The sole qualified supplier of the closure component used on every bottled product across all three plants, with three weeks of stock on hand and an eight-week qualification process for any alternative. The cold-chain logistics contractor that delivered to the company’s retail customers, whose failure would breach delivery commitments within two days. The cloud payroll provider, whose failure at month-end would leave 600 people unpaid. The co-packer that produced one product line the company had no capacity to make itself. And the industrial refrigeration maintenance contractor, whose two qualified engineers were the only people who could restart the freezer plant at the largest site, where a twelve-hour outage would cost the stock. The managed IT provider, which the company had assumed was its main dependency, tiered at two: its failure would be painful, but the ransomware review had already produced the degraded-mode procedures for the loss of the ERP.
The evidence test found the pattern the guide predicts. The logistics contractor’s file held a continuity certificate and nothing else; asked for its last test result, it produced a desktop exercise from three years earlier that assumed its own depots were the only thing that could fail. The payroll provider’s contract committed to “prompt” notification and to recovery “in line with industry standards”; its SOC 2 report, read in full for the first time, carved out the cloud platform on which the whole service ran and listed an availability control exception the reviewer had never seen. The co-packer had no exit provision of any kind. The refrigeration contractor had no continuity arrangement because nobody had asked; its two engineers were both over sixty. The packaging supplier, the largest exposure, had a good continuity plan of its own, and the company had never asked for it. The resilience arithmetic, done for the first time, showed negative margin for four of the five: the tolerances were two days for logistics, three days for packaging supply, one payroll cycle, one week for the co-packed line, and twelve hours for refrigeration, and only the packaging supplier’s plan fitted.
The response was written as exit routes by duration. For the closure component, stock was raised to eight weeks and the qualification of a second supplier started, at a carrying cost the finance director accepted in writing against a plant stoppage he had not previously priced. For logistics, a tabletop of the insolvency scenario established that the contract allowed the company to engage the contractor’s drivers and lease its vehicles on termination, which nobody had known; the clause was confirmed with counsel and a degraded-mode plan for direct delivery to the ten largest customers was rehearsed. For payroll, the contract was amended at renewal to a twenty-four-hour notification period and a recovery objective, the cloud carve-out was mapped, and a manual pay-run procedure using the last period’s data was tested. For the co-packer, a data and recipe escrow was put in place and a second co-packer identified and trialled. For refrigeration, the contractor agreed to train and certify two of the company’s own engineers, which removed the dependency for the cost of a course. The audit committee received a five-line register: five suppliers, five tolerances, five routes, and a date for each. Fourteen months later the second closure supplier was qualified, and the CAE reported the first Tier 1 exit route the company had ever tested.
Related guides
- Third-Party Risk Management End-to-End: The Full Lifecycle Program
- Vendor Due Diligence: What to Actually Check, by Risk Tier
- Fourth Parties and Vendor Concentration: The Risk Behind the Risk
- How to Audit Business Continuity and Resilience
- Auditing Cyber Resilience: Can You Actually Recover?
- How to Audit Backup and Recovery
- How to Audit Incident Response
- How to Review a SOC 2 Report
- Third-Party Topical Requirement: The 17 Requirements, Mapped for 15 September 2026
- DORA for Internal Auditors
- Your First 90 Days as Chief Audit Executive
- Business Continuity and Resilience (category)
- Operational Risk (category)
- Organizational Resilience Topical Requirement: A Workbook — the 20 requirements and how to assess them.
- Operational Resilience Explained: Services and Tolerances — important business services, impact tolerances, scenario testing and the regimes compared
- How to Run a Business Impact Analysis: RTOs, RPOs, Method — how to run a BIA that produces RTOs, RPOs and dependencies management will defend
Leave a Reply