Creating a backup and continuity plan people can actually follow

1. Start with essential activities and acceptable interruption

List the services the organisation delivers and identify which activities need priority during an interruption. Ask the people responsible what can pause, what has an approved alternative, and what becomes harmful or unmanageable if unavailable. An NGO may need to maintain an essential contact route while postponing routine reporting; another organisation may have entirely different priorities. The plan must reflect the actual work.

For each priority activity, identify the people, information, applications, devices, connectivity, and suppliers it depends on. Include less obvious dependencies such as sign-in services, approval rights, and access to physical premises. A restored application is not useful if the team cannot authenticate or obtain the records needed to use it.

Agree how much interruption and potential data loss the organisation can tolerate. Recovery time objectives describe the desired time to restore an activity; recovery point objectives describe the acceptable gap in recoverable data. These are planning requirements, not guarantees. Validate them against technical capability, staffing, and budget before relying on them.

2. Know what is protected and what is missing

Create an inventory of important data and systems, including cloud applications, shared drives, local devices, configuration files, and information held by suppliers. Identify the authoritative copy and the owner of each set of records. Do not assume that central storage contains everything simply because staff have been asked to use it.

Map each item to its recovery method, retention, location, and responsible person. File synchronisation is not the same as an independent backup: an unwanted change or deletion can be synchronised too. Native cloud recovery features can be valuable, but their scope and time limits need checking against the organisation's requirements. Supplier assurances should be translated into specific restoration capabilities.

Consider how backup access and storage are separated from everyday accounts and systems. Depending on the environment, protected offline copies or immutable storage may support recovery from broader compromise. These controls need correct configuration and testing; a label alone is not evidence. Protect backup content through suitable access controls and encryption, and ensure recovery keys remain available to authorised people.

3. Write a recovery sequence people can use

Define who can declare an interruption, coordinate the response, approve restoration, and confirm that work can resume. Name alternates rather than relying on one knowledgeable person. Keep supplier contacts, account references, and escalation arrangements accessible through an approved route independent of the affected system. Protect sensitive details and separate credentials from broadly distributed instructions.

Set out the order of restoration based on dependencies and operational priorities. It may be necessary to restore identity, networking, or a supporting service before the main application. Describe where instructions are held and what access or equipment is required. Use plain language for decision steps and link to technical procedures for the people performing them.

• Confirm the scope of the interruption and who is coordinating it.
• Identify an appropriate recovery point before restoring information.
• Restore in an approved location and order, preserving evidence where relevant.
• Check data, access, and essential workflows with their owners.
• Record the decision to resume service and any remaining limitations.

4. Prepare workable alternatives and communications

Decide how essential work will proceed while recovery is under way. An alternative may be a different approved communication channel, access to a controlled offline reference, or a temporary manual record. Assess the information involved before creating copies or encouraging personal devices. A workaround should not create a second, unmanageable problem through inappropriate access or lost records.

Explain which activities must pause because there is no acceptable alternative. Staff need permission to stop unsafe or unreliable work rather than improvise. For each temporary process, record its owner, the information it collects, where that information is protected, and how it will be reconciled with the normal system afterwards.

Prepare a communication approach for staff, suppliers, and affected external contacts. Name the person who approves messages and the route used if normal email is unavailable. Provide factual updates about known impact and available alternatives without speculating about causes or promising an unverified recovery time. Where legal or contractual notifications may apply, involve the relevant responsible people promptly.

5. Test restoration and decisions, not just backup jobs

Check backup results as an operational routine, with someone responsible for investigating failures. Then test restoration separately. A successful job confirms that a process completed; it does not demonstrate that the right content, permissions, versions, or application dependencies can be recovered. Choose representative records and a safe restoration destination that will not overwrite live information.

Ask a business owner to verify the restored result through an ordinary task. Record the recovery point used, the steps taken, elapsed time, missing elements, and any assistance required. Compare the outcome with the agreed recovery needs and address gaps. Testing should produce a useful improvement list rather than an unsupported declaration that everything is covered.

Run a discussion-based exercise as well. Walk through a plausible outage, the absence of a key colleague, or unavailable cloud sign-in. Ask who makes each decision and where they obtain the necessary information. Do not disrupt production systems merely to make an exercise feel realistic. A controlled rehearsal can reveal unclear authority and inaccessible instructions without putting live services at risk.

6. Keep the plan usable as the organisation changes

Keep a concise action guide for the first response and supporting detail for recovery work. Give the plan an owner, an approved storage location, and a review process. Ensure an authorised copy remains available during the kinds of interruption it describes. Protect it according to its contents; recovery documentation can reveal sensitive information about systems and access.

Review the plan when important applications, suppliers, staff responsibilities, or service priorities change. Update it after exercises and real interruptions while the difficulties are still understood. Remove obsolete contacts and instructions rather than simply appending new material. A short, current plan is easier to follow than a long history of conflicting procedures.

Connect continuity to everyday handover and training. Staff should know how to report a problem, where to find approved instructions, and which decisions are not theirs to improvise. Leadership should understand the remaining limitations and the investment needed to address them. That shared understanding makes the plan an operational tool rather than an IT document held in reserve.