Information checked: 21 July 2026.
A small-business disaster recovery plan should fit on a usable operating document while still covering authority, contacts, technical dependencies, data decisions and communication. It must work when normal systems and people are under pressure.
In brief: Create a concise plan, rehearse it and keep it accessible outside the systems it is intended to recover.
Plan contents
| Section | Required detail |
|---|---|
| Activation | Events, severity and person authorised to declare an incident |
| Contacts | Verified staff, hosting, developer, insurer and specialist details |
| Assets | Domain, DNS, hosting, CMS, email, data and integrations |
| Priorities | Recovery time and data-loss tolerance by service |
| Procedures | Containment, backup selection, restoration and testing |
| Communication | Internal, customer, supplier and regulatory routes |
| Evidence | Logs, decisions, costs and post-incident actions |
Write the recovery sequence
- Confirm command and open the incident log.
- Identify affected services and preserve evidence.
- Protect critical accounts through a clean communication route.
- Activate manual customer or trading arrangements.
- Select a trusted recovery point and clean target environment.
- Restore in priority order and validate business transactions.
- Reopen gradually with enhanced monitoring.
- Complete notification, reconciliation and lessons learned.
Include personal-data decisions
Record who assesses whether personal data may have been affected, how risk is evaluated and who can contact the ICO or affected individuals. The 72-hour reporting window for a notifiable breach starts when the organisation becomes aware, not when the underlying incident occurred.
Exercise the plan
Run a tabletop scenario and a technical restoration test. Record assumptions that failed, missing contacts, inaccessible credentials and unclear authority. Update the plan immediately.
Acceptance check
Keep a protected offline-accessible copy. The plan fails if it is stored only in the unavailable website, hosting account or one employee’s mailbox.
Exercise realistic constraints
A tabletop exercise should remove one or two resources the team normally assumes will be available: the hosting account, the business mailbox, the technical supplier or the latest backup. This exposes hidden dependencies without causing a real outage.
Records to keep
- Exercise scenario and participants.
- Decisions, timings and missing information.
- Actions with owner and deadline.
- Updated offline plan copy.
Owner test: Repeat the scenario after improvements and compare recovery time, uncertainty and number of undocumented dependencies.
Sources and date checked
This practical guidance was checked against the following primary sources. Legal duties depend on the organisation and service, so obtain qualified advice where the consequences are significant. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.