The backup is restored. Can people resume their work?

Start with something people depend on: allocating field appointments, accepting orders or preparing invoices. Ask who is affected when that activity stops and what can reasonably wait. This gives the exercise a practical boundary and helps the business owner decide where to invest attention first.

Describe what being able to work again actually means. A planner may need confirmed appointments, staff availability and completed-job information together. Access to an application is only part of that outcome. Discuss temporary working arrangements too. Telephone coordination is useful only if colleagues know which information to trust and where to record new commitments.

The UK NCSC's technical recovery guidance recommends testing restoration processes regularly and prioritising business-critical services. The exercise below is our practical application of that principle to one business workflow. It is not a complete incident response plan.

Agree two things before discussing a technical solution: how long the activity can remain unavailable, and how much recent information the team could reasonably reconstruct. These are business decisions. A demanding target has little value if nobody has considered the people and evidence needed to meet it.

Consider a fictional service company rehearsing with an 08.00 backup and a simulated failure at 10.00. Three appointments were changed during that interval. Restoring the earlier copy brings back the old schedule. The planner still needs a reliable way to establish which commitments now apply.

Those times and quantities are exercise assumptions, not recommended limits. In another business, losing even a short interval of changes could be unacceptable. Ask the colleague doing the work to explain the consequences: which customer would need a call, which confirmation could resolve uncertainty and which work must remain on hold?

Use that discussion to challenge the recovery proposal. Can the partner demonstrate the required outcome, and what contribution is expected from your team? A promise to restore files should not be mistaken for an agreement to reconstruct every business event that happened afterwards.

Have the technical partner define the isolated recovery environment, authorised participants and choice of data. Appropriate test data may support part of the exercise. If an actual backup is needed to demonstrate restoration, its confidentiality and access restrictions must remain protected throughout the test.

Before starting, verify that outbound connections cannot send real customer messages, initiate payments or create live jobs. Restored background tasks may be ready to run. Record which connections are blocked and which services are simulated, so everyone understands what the exercise will and will not establish.

Separately review the protection of the backups themselves. The NCSC's ransomware-resistant backup principles explain that neither local nor cloud copies are automatically resistant to destructive attacks. Ask who can change or delete copies. Being able to restore one backup does not prove that it would survive every incident.

The technical partner should assess the restoration mechanics. An operational colleague should then check whether the restored information and permitted actions support the actual job. Give that person authority to flag a discrepancy that prevents work from continuing, rather than asking them merely to witness a technical demonstration.

Check	Evidence to look for during the exercise
An existing appointment	The expected customer, date and completion status are present
A supporting document	The correct version is available to the intended role
A next action	An authorised colleague can complete the agreed test activity
A missing change	The discrepancy can be identified and has an owner

For example, let a planner reschedule a test appointment and ask another colleague to check the resulting information. Include something that should remain impossible: a user without the relevant authority must not be able to open a restricted document. Keep a readable account of the outcome alongside the technical measurements.

Measure more than the time taken to copy data back. Record the time spent obtaining access, checking the result and resolving differences. This makes it possible to distinguish when the application became available from when the business activity was ready to resume.

An earlier copy cannot automatically know about later commitments. Assign someone to compare temporary records with the restored information. The NCSC's recovery guidance also calls for validating and integrating data created during an interruption.

In the service-company example, a customer may already have accepted a new appointment by telephone. Sending the old confirmation again would create another problem. The planner needs to establish the current agreement and decide who updates the customer. An import routine should not silently make that business judgement.

Prepare a short resumption decision: which activities are ready, which discrepancies remain and who is handling them? Employees need a clear account of what they can rely on and where to raise doubts. They do not all need to understand the recovery infrastructure to make sound decisions within their responsibilities.

Keep a record of the scenario, backup and application used, the reviewers and the remaining limitations. Assign each material finding to an owner and agree when to check the relevant part again. Choose a repeat frequency suited to the importance of the service, and revisit the exercise after changes that materially affect recovery.

Include an authorised deputy in a later rehearsal. If the procedure works only because one developer remembers undocumented steps, an important dependency remains. Our article on handing software to another partner explores how to make that knowledge transferable.

A sensible first assignment is therefore bounded: demonstrate how colleagues can resume one important activity after restoration. Our quality and operations approach connects technical evidence with the work customers and employees need to complete. The resulting improvement might be a clearer responsibility, better instructions or a targeted software change, without replacing the entire platform.