What is business continuity?

Disaster recovery is the technical process of restoring IT systems, data and infrastructure after an incident — restoring servers, recovering databases, rebuilding endpoints. Business continuity is the wider discipline of keeping the organisation functioning throughout, which includes disaster recovery but also manual workarounds, staff and premises arrangements, supplier dependencies, customer communication and decision-making authority. An organisation can have excellent disaster recovery and still fail commercially if nobody knows how to take orders, pay staff or answer customers during the days it takes to restore.

At least annually, and after any significant change to systems, premises, key suppliers or personnel. Testing does not have to mean a full failover exercise. A tabletop walkthrough — talking a realistic scenario through with the people who would actually respond — surfaces most weaknesses at very low cost, typically finding that contact lists are out of date, the plan is stored only on the system that would be encrypted, or a named responder left the organisation. Technical restore testing should be more frequent, ideally quarterly, since backup jobs that report success frequently fail to restore.

It depends on the function, not the organisation. Email and telephony often have short tolerances, since customer contact stops without them. Accounting systems may tolerate a day or two outside period-end but very little during it. Archived records may tolerate a week. Setting a single organisation-wide RTO usually produces either unaffordable infrastructure or unrealistic promises. The practical method is to list critical functions, ask what actually happens after four hours, one day and three days of unavailability, and set objectives where consequences become genuinely damaging.

Small organisations are more exposed to disruption, not less, because they have fewer staff who know how each process works and thinner cash reserves to absorb downtime. The plan does not need to be lengthy — a handful of pages covering critical functions, recovery steps, offline contact details and manual workarounds is far more useful than an unread fifty-page document. Written form matters because incidents happen when the person who understands the system is on holiday, unreachable or dealing with something else. Clients, insurers and tender processes also increasingly ask to see one.

In at least one place that does not depend on the systems it protects. A plan stored solely on a network share or in the Microsoft 365 tenant is inaccessible during exactly the incident it was written for — ransomware encrypting file servers, or a tenant compromise requiring accounts to be locked. Practical arrangements include printed copies held by key personnel, an encrypted copy on a personal device, or storage with a separate provider using different credentials. Contact details in particular should be available without access to corporate email or the phone system.