IT business continuity plan for UK SMEs

A business continuity plan for a UK SME sets out how essential work will continue during disruption and how normal service will resume. It gives people priorities, authority, contacts and workable alternatives. A list of backups or an IT supplier's telephone number is only part of that plan.

Start with one question: which business service must keep running, at what minimum level, and for how long could you tolerate its loss? Build the first version around the answer. A small plan that people have rehearsed is more useful than an extensive document whose recovery assumptions have never been tested.

Separate continuity, incident response and IT recovery

Business continuity concerns the whole operation: people, premises, suppliers, communications, equipment, information and technology. IT disaster recovery concerns restoring the technology and data that those operations need. Incident response investigates and contains the event, including security incidents where relevant.

These activities overlap. During a ransomware incident, the response team may isolate systems while operations starts a manual workaround and IT prepares a clean recovery environment. Waiting for incident response to finish before considering continuity could leave customers without a service for longer than necessary.

Give each activity an owner, but agree their decision points together. A system should not be reconnected simply because it has been restored if the incident team has not assessed whether it is safe. Equally, a business manager needs to know which work can continue safely while that assessment takes place.

Begin with a business impact analysis

A business impact analysis, often shortened to BIA, establishes the consequences of losing a service over time. Ask the people responsible for delivering that service, not only the team responsible for its software.

Consider customer harm, missed contractual obligations, financial loss, safety, regulatory duties and the growing backlog. A short disruption at a quiet time may be manageable; the same disruption during payroll or a delivery deadline may not be.

Create one record for each critical activity:

Avoid declaring every activity equally critical. If payroll is due tomorrow and a reporting dashboard can wait, that difference should appear in the recovery order. Record where priorities change by date or season.

The NCSC's incident preparation guidance recommends identifying critical information, processes and systems, arranging cover for key responsibilities and making plans accessible when normal equipment is unavailable. Those are useful foundations for the wider continuity plan.

Set recovery objectives that can be tested

Use three measures consistently. Maximum tolerable period of disruption describes the point beyond which the disruption has unacceptable consequences. Recovery time objective, or RTO, is the target time to restore an activity or system to the agreed level. Recovery point objective, or RPO, describes the acceptable amount of data loss expressed as a period of time.

Define where the clock starts and what counts as restored. A server being available is different from staff being able to process orders correctly. Allow time for validation and clearing urgent work, not just rebuilding the application.

For example, an RPO of one hour means the business is planning around losing no more than approximately one hour of relevant changes when recovering to a usable point. It does not prove that hourly backup jobs deliver that result. Failed jobs, corrupted backups or an earlier last-known-good state can increase the loss. Test the usable recovery point.

An RTO of four hours is a business target until there is evidence that people, suppliers and systems can achieve it. If a supplier can only begin recovery after that period, the plan contains a gap. The choices are to improve the capability, create a workable alternative or explicitly accept a different service objective.

Choose scenarios that expose dependencies

Plan around useful classes of disruption rather than attempting to predict every cause:

• Premises unavailable, with staff unable to collect equipment or paper records.
• A key person unavailable, including the only person who holds an administrative role.
• A critical cloud or communications provider unavailable.
• Data inaccessible or unreliable, including a security incident that makes normal systems unsafe.
• A supplier unable to deliver a service or essential material.

For each scenario, ask which dependencies fail together. An alternative office does little good if staff still need the same unavailable identity service. A spare laptop does not help if its setup instructions are stored inside the affected account.

Identify common dependencies across supposedly separate recovery options. Different products can rely on the same network, administrator, supplier or credentials. Record those shared failure points rather than counting product names as resilience.

Write procedures people can follow under pressure

The front of the plan should name the incident lead, deputy, business owners and technical contacts. State who can activate continuity arrangements, approve exceptional spending, stop an unsafe process and authorise a return to normal service.

For each critical activity, write the first actions in order. Include the information needed to choose a workaround, how to access it, who can approve it and how long it can operate. A manual process needs forms, access rules, secure storage and a reconciliation procedure. "Use a spreadsheet" leaves those decisions unresolved.

Keep contact information in a controlled location that remains accessible if the primary systems fail. Restrict access appropriately, maintain an offline or otherwise independent copy where suitable, and test that the designated people can reach it. Include supplier contracts and the actual support entitlement, not just a sales contact.

Specify escalation triggers. The duty manager might be authorised to start the manual order log when the service owner confirms that recovery will miss the agreed threshold. A security concern may require a different trigger because continuing work could spread the compromise or corrupt evidence.

Make backup and recovery assumptions explicit

Inventory what must be recovered: application data, configuration, identity dependencies, keys, integration settings and the instructions required to restore them. A data export may not contain everything needed to rebuild the service.

The NCSC's backup guidance explains that the familiar 3-2-1 approach does not, by itself, ensure that any copy is offline. Keeping a copy in the cloud provides a different physical location, but does not automatically protect it from a compromised account that can delete or overwrite it.

Assess separation of access, administrative credentials, retention and deletion permissions. Understand the protection your backup product actually provides. Confirm who can change retention or disable protection, and what remains recoverable if production credentials are compromised.

Test restoration to an appropriate isolated environment. Check that the data is usable, the application works, permissions are correct and the restored service can support the agreed business process. Record the time, recovery point and missing dependencies. A green backup status is evidence that a job completed, not that the business can recover within its objective.

Do not overwrite production data during an exercise without a separately controlled plan. Tests should have an owner, scope, rollback arrangements and a clear way to stop if they affect normal work.

Worked example: recovering order processing

Consider a hypothetical distributor that needs to accept urgent orders during an outage. Its managers set a four-hour recovery target for a reduced order service and a one-hour data-loss objective. They agree that the reduced service means recording orders accurately and confirming realistic delivery dates, rather than restoring every report.

The first exercise shows that the application restore takes three hours, but staff then spend another two hours reconstructing access and validating stock information. The four-hour target has not been met. Calling the restore a success would conceal the operational failure.

The team creates a controlled manual order log with unique references, named users and instructions for checking stock through an independent approved record. It also documents the missing access steps. In the next exercise, staff can accept a limited volume of urgent orders while IT restores the service.

Before returning to normal, the operations owner reconciles the manual entries against recovered orders to prevent omissions or duplicates. The team records which orders were accepted during the outage, which need customer confirmation and who checked the reconciliation.

The resulting plan contains an evidenced reduced service, an explicit capacity limit and a recovery procedure. The numbers belong to this example; another business must set its objectives from its own impact analysis.

Plan communication and reporting

Prepare short templates for staff, customers and suppliers, but leave room for facts to change. State what is affected, the action recipients should take and when the next update will arrive. Do not invent a recovery time to make a message sound reassuring.

Name the person who approves external updates and identify an alternative channel if email is unavailable. Keep an incident decision log so different teams do not send contradictory accounts. Separate confirmed facts from working hypotheses.

Assess legal, contractual and insurance notifications with the appropriate owners. A UK SME does not acquire every sector's reporting duties merely by using IT. Identify the rules that actually apply to its activities and contracts. For personal data incidents, follow the ICO's breach guidance, including the risk-based notification test and the awareness-based 72-hour deadline where notification is required and feasible.

Exercise, record failures and maintain the plan

Begin with a discussion exercise. Give participants a scenario and ask them to use the actual plan to make the first decisions. Observe missing contacts, inaccessible records, unclear authority and assumptions about supplier support. Do not supply answers that the plan should contain.

Follow with technical recovery tests proportionate to the risk. Review the plan after significant changes, incidents and exercises, and set a recurring review schedule based on criticality. A calendar review alone does not prove readiness. A new supplier, office move or authentication change may justify testing before the next scheduled date.

For each finding, record its impact, owner, due date and retest evidence. Close it when the problem has been corrected and checked. If it cannot be resolved immediately, document the temporary arrangement and have the accountable manager decide whether the remaining risk is acceptable.

Keep version control and remove obsolete copies from operational use. Retain the history needed to explain decisions, but make the current instructions easy to identify.

Build the first usable version

Start with one critical activity, its dependencies and its minimum service. Agree the objectives, write the first actions, run a small exercise and repair what fails. Then extend the method to the remaining priorities.

Our IT management service can help connect business priorities to recovery capabilities, while security consulting can help examine the incident and access risks behind the plan. Arrange a consultation with your most important service, its recovery target and the latest restore or exercise result. That gives the discussion a concrete gap to resolve.