Start an outage plan with the work that must continue. List urgent customer contact, access to existing bookings, supplier communication and checks on outstanding payments. Assign an owner to each task so the plan describes actions the team can take.

Use a controlled exercise to develop the process. Do not interrupt live systems or create real bookings merely to see what happens. The purpose is to uncover missing decisions before an actual disruption forces the team to improvise.

Define the service you need to recover

Agree what “working again” means for your business. For example, being able to open a dashboard is different from retrieving the latest booking and confirming its supplier status. Write the required tasks as acceptance checks so recovery has a clear endpoint.

Identify the services on which each task depends. Ask the relevant providers who owns recovery, where updates will be posted and which contact route applies. Keeping those answers together makes an outage easier to coordinate across more than one organisation.

Set two different recovery objectives

NIST distinguishes the recovery point objective, which concerns the point in time to which data must be recovered, from the recovery time objective, which concerns the length of system recovery before business operations are affected. Source: NIST: recovery point objective Source: NIST: recovery time objective

Discuss both with the team. Ask how much recent work could be reconstructed and how long each important task could remain unavailable. Record the reasons for the chosen requirements, because they should follow the business need rather than a generic interval.

Compare those requirements with the provider’s actual commitments and test evidence. Keep an internal target separate from a contractual promise, so the plan does not imply a service level that has never been agreed.

Check the backup and restoration arrangement

The NCSC recommends identifying essential data, making backups and knowing how to restore them. It also advises checking that a backup contains the important information. A copy existing somewhere is only part of that review. Source: NCSC: backing up your data

Ask what is covered: booking records, documents, settings and any connected records the team relies on. Record exclusions explicitly. This helps identify where a separate recovery route is needed.

Use the approved test process to inspect a restored sample. Check that the information is readable and can support the agreed recovery tasks. Record the test date, scope and result so the plan has evidence behind it.

Give uncertainty a clear place in the process

During the exercise, introduce a fictional booking whose latest supplier outcome is unknown. Ask the team how it would establish the current position before repeating the action or reassuring the customer. This tests judgement at the point where an assumption could create more work.

Keep a temporary case record through an approved process. Include the known facts, open questions, owner and next check. Limit the information to what is needed and arrange how it will be reconciled with the normal system after recovery.

Rehearse handovers and customer updates

Prepare a short update that states what is known and when the next review is due. Avoid promising a recovery time that the provider has not confirmed. Give customer-facing staff a single agreed source for updates so messages stay consistent.

NIST describes disaster recovery plans as documented procedures for recovering lost system capability. Make yours practical by asking a colleague who did not write it to follow the exercise. Source: NIST: disaster recovery plan

Record the gaps, assign changes and repeat only the affected steps. After a real disruption or a material system change, revisit the plan so its contacts, assumptions and recovery checks still match the business.

Written and updated by Travelgenix. Sources checked on 16 October 2026. Worked examples and checklists are editorial illustrations and recommendations, not customer results.