The folder has been restored. The project team is still waiting.
Perhaps their account cannot sign in. Perhaps the application that uses the files is unavailable. Perhaps the client operates the platform and your own provider is waiting for an update too.
For the person trying to submit a record or open the current drawing, these distinctions are invisible. For the people responsible for recovery, they decide what happens next.
Start the continuity discussion with the work that needs to happen, then trace the services behind it.
Pick one activity people actually need to complete
Avoid beginning with a complete list of every technology the business owns. Choose a project activity important enough to expose the useful questions: opening an approved drawing, recording an inspection, submitting project information or using a scheduling application.
Ask the project lead what must continue, what could wait and what restrictions apply. “Keep everybody working” is not a sufficient instruction if some work needs current approved information and some can use a defined temporary process.
Any fallback for safety-critical work needs the appropriate competent approval. An old downloaded drawing should never become the assumed answer merely because it is available.
Map the dependencies
| Part of the working arrangement | What to establish |
|---|---|
| Application or project platform | Who operates it and how an incident is escalated |
| Identity | Which organisation controls the login and recovery of access |
| Device | What approved device and configuration the activity needs |
| Connectivity | Which connection the task depends on and what an alternative would change |
| Information | The current authoritative source and any approved temporary process |
| Recovery | What your business can restore, what has been tested and what depends on another provider |
| Restart | Who confirms that normal working can safely resume |
Illustrative example: a subcontractor needs to upload an inspection record to the principal contractor's platform. The subcontractor's IT provider can investigate its own account, device and connection. If the platform itself is unavailable, the principal contractor or platform operator must handle that service. The project team needs an agreed way to manage the work and records in the meantime.
That is a dependency to plan for, not a reason to promise that one supplier can fix everything.
A backup and a fallback solve different problems
A backup supports restoration of the information or systems within its coverage. A fallback describes how the business will operate while a normal service is unavailable. A spare device, an alternative connection and an approved temporary recording process may each help with different failures. Microsoft also distinguishes backup and restore from disaster-recovery failover orchestration; they are related capabilities with different purposes. Microsoft backup overview.
None automatically replaces the other. An additional SIM will not restore a failed platform. A restored document will not necessarily re-establish the account or application needed to use it. A temporary spreadsheet will need a controlled handback to the normal process.
NCSC recovery guidance stresses the dependencies around recovery, including applications, identity and configuration, rather than data alone. It also addresses planning restoration and reconciling information created through temporary workarounds. NCSC technical recovery guidance.
Be clear about the service you can control
Separate three categories in the discussion:
- Systems your organisation operates and is responsible for recovering.
- Services a supplier operates under an agreed support arrangement.
- Client or third-party platforms on which the project depends.
For the first, establish recovery coverage and test evidence with IT. For the second, confirm the service responsibilities, escalation and applicable commitments. For the third, agree the operational response and the information needed from the owner.
Confirm geographic and on-site requirements rather than assuming a support contract includes attendance. A proposal should explain what is delivered remotely, what attendance would require and what is outside scope.
Make the exercise useful to both IT and Operations
Run a discussion using the dependency map. It is a tabletop exercise, not proof of technical recovery.
The project lead explains the work and tolerable interruption. IT and the provider explain the systems and available evidence. The relevant information owner sets the rules for temporary records and resuming the normal process.
Write down the first action, the person authorised to take it and a way to reach them when the usual collaboration tool is unavailable. Keep the plan accessible through an agreed secure arrangement. Do not put passwords or sensitive recovery secrets into the worksheet.
Any hands-on recovery testing should be authorised, scoped and performed in an appropriate environment by the responsible team. The worksheet does not instruct readers to interrupt production systems.
Check the handback as well as the restart
After the normal service returns, temporary records may need validating and transferring. People need to know which source is authoritative again. The team should confirm that permissions and access are appropriate rather than leaving an emergency arrangement running indefinitely.
Record what happened, what was learned and which action is still open. A short, accurate record is more useful than a long plan no one can explain.
Next step: Use the Backup Recovery Test Checklist for the systems your organisation is responsible for protecting. It helps structure preparation and test evidence. It does not verify that a restore works or recover a client-operated platform.
