1. Record what the outage actually stopped
List the business tasks affected, the teams involved and the information they could not reach. Include work delayed by missing email, unavailable files or failed sign-in. Note what still worked and which workarounds helped.
Separate the provider’s incident duration from the period your organisation was unable to work normally. Recovery of a service does not always mean your backlog and unfinished communications have been resolved.
2. Choose the work that must continue
Prioritise a small, meaningful operating scope. Identify the people who need access, the mailboxes and folders they use, the applications required and the maximum interruption the business can tolerate.
Record the cloud-only functions that will need a separate approach. It is better to have a tested route for essential customer work than to assume the entire cloud platform has been duplicated.
3. Check the copies and their timing
Establish what is stored locally, when it last synchronised and how a failed copy is reported. Open representative files and messages from the intended local environment.
Ask how exports of cloud-native documents are handled and which metadata, permissions or versions are retained. Keep an independent backup policy for deletion and unwanted changes; synchronisation and backup solve different problems.
4. Test access without the primary cloud
Test local authentication, permission boundaries, client software, name resolution and any keys needed to open data. Use a controlled exercise agreed with your IT owner. Include someone who was not involved in building the environment, so the instructions receive a realistic test.
Keep the activation instructions and essential contact details somewhere available during the outage. A plan held only in an inaccessible cloud folder is another dependency.
5. Define power, hardware and isolation
Size storage and compute for the selected users, workloads and data growth. Decide what power protection and hardware resilience are appropriate to the site. Identify the consequences of local hardware failure and loss of the building.
If the design includes a physical isolation control, document which connection it separates. Users still need a working local path to the appliance. Test that separation rather than assuming a switch makes every service independent.
6. Rehearse communication and the return
Choose who activates the plan, who informs staff and how customers receive essential updates. Define the checks before reconnecting, who reconciles local changes and how duplicate or conflicting work is handled.
Record the result of the exercise, the measured sync gap and the time taken to resume each agreed task. Retest when the cloud services, accounts, data or working procedures change.
Turn the checklist into a proposal
Bring your findings to a continuity planning discussion. Orwell can scope an on-site appliance around the selected services, people and data, with a documented procedure for continuing work.
The same review is a useful moment to consider data sovereignty and whether local AI could help staff work with the internal information you choose to hold on site.