Research
Checking Business Continuity Claims in Outsourcing Proposals
How to test a provider's continuity plan against power, connectivity, staffing, and site failures before the claim becomes a contract clause.
On this page
Key stats
The U.S. Federal Emergency Management Agency publishes business continuity planning guidance, and the ISO 22301 standard sets requirements for a business continuity management system, including recovery objectives and tested response arrangements.
Methodology
This note reviews business continuity guidance from the U.S. Federal Emergency Management Agency, the ISO 22301 standard, the U.S. Cybersecurity and Infrastructure Security Agency, and Philippine business and disaster resilience material from the Department of Trade and Industry. It asks how a buyer can test the continuity claims in an outsourcing proposal without treating a plan document as proof of recovery. The analysis is a due-diligence aid for one support lane, not a certification or legal opinion. It does not claim that a provider with a plan will recover within a specific time. It also separates the provider's internal recovery from the client's decision to invoke a failover. The review is designed to be repeated at renewal rather than treated as a one-time check.
Evidence summary
Read the continuity claim as a set of specific promises rather than a general capability. A proposal may say the provider has a business continuity plan, maintains redundant connectivity, or can operate from another site. Each statement needs an object, a trigger, and a test. Ask what fails, what happens next, and how the provider knows the response works. A sentence that cannot be reduced to those parts is a marketing line.
Ask for the plan's scope. A plan may cover the provider's own office but not the client's systems, or it may cover a primary site without the tools the team uses. Check whether the support lane appears in the scope and whether the client's account is named. A corporate plan that never mentions the work the team performs is not evidence for this contract. Request the section that applies, not the whole binder.
Test the recovery objectives. A recovery time objective states how long the service may be unavailable, and a recovery point objective states how much data may be lost. Both should connect to the client's own tolerance, not to a generic industry figure. Ask how the provider measured the objective and when it last tested it. Ask for the measurement method, not only the target. An objective with no test is a target, not a capability.
Examine the dependencies one by one. Power, connectivity, hardware, software access, staffing, and transport can fail independently, and a backup for one does not cover another. Ask what happens when the office loses power but the network is fine, or when a storm closes roads but the team can work remotely. Write the answer for each scenario. The gaps usually appear in the combination rather than in a single system.
Check the staffing assumption. A continuity plan may assume that a percentage of the team can relocate or work from home, and that assumption may depend on equipment and connectivity the provider does not supply. Ask how the provider contacts people when the primary channel is down and how it confirms who is available. A call tree that depends on the same phone system that failed is not a fallback. Test the alternate channel. Record who confirms availability and how the confirmation reaches the team lead.
Look for evidence of an exercise. A plan that has never been exercised is a document, and an exercise that only walks through a checklist does not test the difficult parts. Ask for the date, the scenario, the participants, the issues found, and the corrective actions. A useful exercise produces at least one change. If every exercise reports no findings, ask how the scenario was designed.
Review the client-side responsibilities. The client may own identity, data backup, or the approval to invoke a failover, and the provider cannot complete the recovery without those decisions. Write the decision owner and the contact path for each step. A continuity plan that assumes the client will answer within minutes should be tested against the client's actual coverage. The seam between the two organizations is a common failure point. Name a backup for each client-side decision owner.
Compare the plan with the contract. The service agreement should state the continuity obligations, the notification timeline, and the evidence the provider will supply after an event. A proposal claim that is not in the contract is difficult to enforce. Ask how a service credit or a remedy applies when the recovery objective is missed. Keep the definitions consistent across both documents. Ask which document controls if the two descriptions differ.
Check the site and the local context. The Philippines has weather, power, and transport conditions that vary by location, and a plan written for one city may not fit another. Ask about the provider's history of disruptions in the actual delivery location and what changed after the last one. Treat a generic national description as context. The question is what happens at the desk where the work is performed. Ask what changed after the most recent local disruption.
State the limits of the review in the decision note. A plan review cannot prove that a future event will be handled well, and a successful exercise cannot cover every scenario. Record what was tested, what was accepted on the provider's evidence, and what remains unverified. Set a review date and a trigger for a new exercise. The note should let a later reader see the basis for the decision rather than only the conclusion. That record should be short enough to reread before the next renewal.
Define the claim
Reduce each continuity statement to a failure, a response, and a test. Name the site, system, and role it covers. Ask when it was last exercised. Record the claim in the due-diligence note. Do not accept a general capability statement as evidence.
Check the scope
Confirm that the plan covers the client's account, tools, and delivery location. Request the applicable section rather than a corporate summary. Note any dependency the plan excludes. Ask who owns the excluded part. Review the scope when the service changes.
Test the objectives
Ask for the recovery time and recovery point objectives and how they were measured. Compare them with the client's tolerance. Request the last exercise result. Record the gap between the target and the evidence. Set a date for the next test.
Map the dependencies
List power, connectivity, hardware, software, staffing, and transport separately. Write the response for each failure and for a combined event. Identify the backup that covers each one. Test the contact path when the primary channel is down. Update the map when a tool or site changes.
Review the exercise
Ask for the scenario, date, participants, findings, and corrective actions. Check that the exercise produced a change. Confirm that the client-side decision owner participated. Record what remained untested. Schedule the next exercise before the contract renewal.
Write it into the contract
State the continuity obligations, the notification timeline, and the evidence required after an event. Align the definitions with the proposal. Name the remedy when an objective is missed. Keep the client-side responsibilities visible. Review the clause when the service or site changes.
FAQs
Does a business continuity plan prove a provider can recover?
No. A plan describes intended arrangements. Recovery evidence comes from exercises, measured objectives, and corrective actions. Ask what was tested, what failed, and what changed as a result.
What is the difference between a recovery time and recovery point objective?
A recovery time objective is the target for restoring service, while a recovery point objective is the acceptable amount of data loss measured in time. Both should connect to the client's tolerance and be tested.
Should continuity claims be in the contract?
Yes, the obligations, notification timeline, evidence, and remedy should be written into the agreement. A claim that exists only in a proposal is difficult to enforce after an event.
How often should the plan be reviewed?
Review it at contract renewal and whenever the site, tool stack, staffing model, or client scope changes. A significant disruption in the delivery area is also a reason for an earlier review.