A supplier’s security policy is useful, but it does not show whether your business could keep operating through an outage. Ask for a recovery exercise that follows one important service from failure to a checked restart.
Start with the business service, not the badge
When a critical supplier stops answering, the immediate question is practical: which customer promises can still be met? A certificate, insurance schedule or security questionnaire may inform due diligence, but none, on its own, demonstrates how a particular service will recover. Oakhampton’s recommendation is to add a small, timed continuity exercise to the procurement and renewal process. The aim is not to inspect every technical control. It is to establish what the buyer can safely do while the supplier is unavailable, and what evidence will justify returning to normal operations.
NIST presents CSF 2.0 as a resource for organisations to reduce cybersecurity risks. [1] Oakhampton recommends using it as a starting point for a shared discussion between management, operations and technical specialists, rather than treating it as a promise that incidents cannot happen. Apply that discussion to one business dependency: order processing, shipment visibility, payroll preparation or access to transaction documents. Name the service owner, the records required and the people authorised to decide on a workaround. A vague commitment to restore “the platform” is not enough to plan tomorrow’s work.
Put the recovery claim through a small exercise
Choose a scenario with a clear boundary, such as losing access to the supplier’s normal portal. Ask the supplier to explain how customers will receive verified updates, how urgent cases will be prioritised and how essential records can be recovered. Record the starting condition, each dependency and the evidence produced. A discussion is a useful first step, but describe it as a discussion; do not turn a tabletop scenario into a claim that a technical restore succeeded.
CISA’s StopRansomware Guide recommends offline, encrypted backups of critical data and regular tests of their availability and integrity in a disaster-recovery scenario. It also recommends maintaining and exercising incident-response plans. [2] For a buyer, this suggests a more useful question than “Do you have backups?” Ask what was restored during the last relevant exercise, who checked it and whether access to the restored information depended on the same account or supplier that had failed. A successful file restore is still not proof that a whole service can resume.
Measure the buyer’s side of the interruption
A supplier may complete its technical work before the customer can use the result. Staff may need replacement credentials, an integration may have a backlog, or a document may need checking against a newer version. Include these steps in your exercise. Record elapsed time to the point at which an authorised employee can complete a representative task, not merely the time at which a server starts. Keep the test small enough to repeat without disrupting customers or exposing their information.
Also test the fallback you actually intend to use. If the alternative is a spreadsheet or a telephone instruction, determine who may update it, where it is stored and how changes will be reconciled later. Do not assume that email remains available in every outage. The NCSC’s small-organisations guidance treats backups, devices, accounts and scam awareness as practical responsibilities across the team, rather than a job for one person. [3] That is a useful principle for continuity: the fallback must work for the people at the desk, including someone covering an absent colleague.
Keep commercial decisions separate from recovery work
An outage can create pressure to accept a new subcontractor, release a payment or share data through an unfamiliar channel. A continuity plan should identify those decisions in advance without quietly pre-approving them. Define who may change a delivery promise, authorise an expense or disclose a customer record. Verify an unexpected request through an established contact route. Operational urgency changes the priority of the decision; it does not establish the identity or authority of the person requesting it.
These are recommended buying and operating practices, not assertions about a supplier’s existing contract or a substitute for legal advice. A small provider may offer a workable manual recovery route, while a larger provider may have sophisticated infrastructure but a difficult customer handover. Compare the actual service, the dependency chain and the evidence. Do not infer that one architecture, badge or company size provides a universal answer. The relevant question is whether the proposed arrangement matches your business’s tolerance for interruption.
Finish with one repair and one retest
The useful output is a short list of observed gaps with an owner and a retest date. Perhaps nobody could locate the fallback contact, the recovered record was out of date, or the restored account lacked the permissions needed for the task. Fix the most consequential gap first and repeat the affected part of the exercise. Keep the original result alongside the new one so that improvement is visible rather than assumed.
A timed test cannot predict every incident, and a successful rehearsal is not a guarantee of recovery during an attack. It can, however, replace an unsupported assurance with something concrete: a defined business service, an observed recovery path and a known next action. That is a stronger basis for supplier selection and renewal than a folder of policies that nobody has tried to use.