A disaster recovery plan that has never been tested is not a control. It is an assumption written down.
The distinction matters. A document may say that systems can be restored within four hours, that backups are available, and that staff know what to do. Until the business has attempted recovery under controlled conditions, those statements remain unverified.
For UK SMEs, Disaster Recovery testing is where compliance, business systems and technology cost meet. It provides evidence that continuity arrangements work, exposes dependencies that were missed during planning, and shows whether resilience spending is producing useful protection rather than duplicated tools and dormant contracts.
The right approach is not enterprise theatre. It is a proportionate, repeatable testing discipline led by business priorities.
Compliance is about evidence, not confidence
The National Cyber Security Centre’s Cyber Essentials scheme establishes five technical controls:
- Firewalls
- Secure configuration
- Security update management
- User access control
- Malware protection
Cyber Essentials is a valuable baseline, but it does not certify an organisation’s backup or Disaster Recovery capability. A Cyber Essentials certificate should not be presented as proof that systems can be restored after ransomware, infrastructure failure or supplier disruption.
That distinction is important for SMEs. The five controls should remain effective during and after recovery. Restored systems still need secure configurations, current patches, controlled privileged access, malware protection and appropriate network boundaries.
ISO 27001 provides the wider, risk-based governance layer through the Information Security Management System (ISMS). In particular, ISO 27001:2022 controls such as A.5.29, A.5.30 and A.8.13 connect information security during disruption, ICT readiness for business continuity, and information backup.
In practice, an auditor, customer or insurer may reasonably ask:
- What are your critical business services?
- What are their Recovery Time Objectives and Recovery Point Objectives?
- When did you last test restoration?
- What happened during the test?
- Which weaknesses were identified?
- Who owns the corrective actions?
- Has the plan changed as a result?
A signed policy answers very few of those questions. A dated test report, measured recovery times, system logs, lessons learned and tracked improvements answer far more.
The SME testing ladder
A sensible test programme increases confidence gradually. Each stage proves something different and carries a different cost in time, disruption and specialist input.
| Test | What it proves | Typical SME commitment |
|---|---|---|
| Tabletop walkthrough | Roles, decisions, communications and recovery priorities are understood | 60–120 minutes |
| Component restore test | A backup, application, database or dataset can be restored and used | Half a day to one day |
| Partial failover | A selected service and its dependencies can operate in a recovery environment | One day, usually with technical planning |
| Full failover | The end-to-end recovery model works against agreed business objectives | One to several days, depending on complexity |
1. Tabletop walkthrough
A tabletop exercise is a facilitated discussion around a realistic scenario: ransomware, loss of premises, cloud service outage, failed storage or a compromised administrator account.
Participants should include business process owners, IT or the outsourced technology team, senior management and relevant suppliers. The group walks through the first hour, the first day and the point at which normal operations resume.
The exercise should test practical questions:
- Who declares the incident?
- Which services are recovered first?
- How are staff contacted if email is unavailable?
- Who approves manual workarounds?
- What information can be shared with customers?
- Which supplier is contacted, and who has the contract details?
A tabletop is inexpensive and safe. It does not prove that systems will restore, but it often reveals that contact lists, recovery priorities and decision rights are unclear.
2. Component restore test
This is the minimum credible test for backup reliability. Select a representative file set, mailbox, database, virtual machine or SaaS dataset and restore it into a controlled environment.
Do not stop when the backup console says “successful”. Confirm that the restored information opens, that permissions are correct, that applications can use it and that the data is complete.
Record:
- The time at which restoration began
- The time at which the service became usable
- The timestamp of the latest recoverable data
- Any manual steps or errors
- Whether security controls remained active
This is where a theoretical RPO becomes measurable. If the business expects no more than four hours of data loss, the latest usable backup must support that objective. If it does not, the gap belongs on the risk register.
3. Partial failover
A partial failover tests one important service without attempting to recreate the whole business. This could involve restoring a core application, moving a selected workload to cloud infrastructure, or bringing a secondary network connection into operation.
The test should include dependencies, not just the primary application. A system may be technically available but unusable because identity services, DNS, APIs, certificates, licences or reporting connections are missing.
Partial failover is often the best balance for an SME: enough realism to find technical weaknesses, without the cost and operational risk of shutting down every production service.
4. Full failover
A full failover is an end-to-end exercise against an agreed scenario. It should test whether priority business processes can operate at a minimum acceptable level, rather than simply whether individual servers can be started.
A full test may involve staff working from an alternate location, using recovery connectivity, accessing restored applications, processing transactions and communicating through an alternative channel.
It is more expensive and should be carefully planned. However, it is the only stage that can demonstrate whether the complete operating model works under pressure.
Start with processes, then map the technology
RTO and RPO should be defined for business services, not selected from a technology supplier’s standard package.
For example:
- “Issue customer invoices within one working day” is a business requirement.
- “Restore the finance application within eight hours” is a supporting technology objective.
- “Recover transactional data to within one hour” is an RPO requirement.
This process-first approach identifies the dependencies that are otherwise easy to miss.
A typical dependency map should include:
- Identity and privileged access
- Internet connectivity and firewall services
- Network Solutions and remote access
- Voice and Connectivity, including telephony and call routing
- Cloud Solutions and SaaS platforms
- Email, document management and collaboration tools
- Finance, payroll and reporting
- Suppliers, integrations and payment services
- Legacy platforms and specialist applications
The test should identify what happens if one dependency is unavailable. For example, a restored finance system may still fail its acceptance test if users cannot authenticate or if a required integration endpoint is inaccessible.
Dynamics 365 Jump Start should include continuity from day one
A Dynamics 365 Jump Start programme should not treat continuity as a later infrastructure exercise. Business Central implementation decisions affect future recovery requirements.
During planning, confirm:
- Which data is migrated, archived or retained in the existing platform
- Where integrations begin and end
- Which reports are operationally critical
- How user access and privileged roles are managed
- What the phased roadmap means for parallel systems
- Which processes must continue if the implementation or a connected service is unavailable
A Business Central implementation that has been designed around business processes, clear integration boundaries and tested access roles is easier to recover than one built around undocumented customisations and informal workarounds.
The Microsoft implementation methodology for Business Central is a useful reference point, but continuity decisions still need to be owned by the business. A consultancy-first approach ensures that the implementation supports the operating model rather than becoming another isolated technology project.
IBM i dependencies deserve specialist attention
IBM i Management should be included explicitly in the recovery map wherever Power Systems or AS/400 workloads remain part of the business process.
Important test areas include:
- Privileged access reviews and emergency accounts
- Patch and maintenance planning
- Backup verification and restoration procedures
- Monitoring and alerting during recovery
- Connectivity between IBM i and cloud platforms
- Dependencies between IBM i data and newer business systems
- Batch jobs, interfaces, queues and scheduled processing
- Recovery order when a modern application depends on legacy data
A backup may be technically valid but operationally useless if the team cannot restore the correct libraries, jobs, permissions or integration settings. Equally, a new cloud application may recover successfully but fail to operate because its connection to the legacy platform has not been rebuilt.
The answer is not to remove legacy systems simply because they are old. The answer is to understand their role, document their recovery requirements and test them as part of the wider service chain.
Technology Expense Management belongs in the test report
Resilience spending is often accumulated one contract at a time. Over several years, an organisation may carry overlapping backup tools, unused standby capacity, connectivity contracts that no longer match its operating model, dormant support agreements and ongoing maintenance for systems that are no longer business-critical.
Technology Expense Management should therefore be part of the recovery review.
After each test, ask:
- Did every resilience tool contribute to the outcome?
- Were any licences, links or support agreements unused?
- Is standby capacity proportionate to the current business requirement?
- Are backup retention periods aligned with legal and operational needs?
- Is a manual recovery step creating a cost or staffing risk?
- Would a different architecture reduce both recovery time and recurring spend?
The cost review should also work in the other direction. If a service is being reduced, consolidated or decommissioned, its continuity plan must be updated. Saving money by removing a duplicate platform is sensible only when the remaining recovery route has been tested.
A practical quarterly resilience cadence
A workable SME programme can be structured around a quarterly review:
Quarter one: dependency and objective review
- Confirm critical business processes
- Revalidate RTO and RPO
- Review identity, network, telephony, SaaS and legacy dependencies
- Check major changes since the previous review
Quarter two: restore and tabletop testing
- Restore representative data
- Walk through a disruption scenario
- Check communications, contacts and decision ownership
- Record actual timings and issues
Quarter three: partial failover
- Test one priority service and its dependencies
- Validate access, integrations, monitoring and security controls
- Compare results with the agreed RTO and RPO
Quarter four: management and cost review
- Review all findings and outstanding actions
- Confirm corrective actions have been retested
- Update the continuity plan and version history
- Complete the Technology Expense Management review
- Agree the next year’s test scope
For every exercise, record the scenario, scope, participants, expected outcomes, actual timings, data recovered, security observations, failures, actions, owners and due dates.
The Fractal IT Director approach is useful here because it joins strategy to execution. Managed IT Services, Helpdesk Support, Network Solutions, Voice and Connectivity, and Cloud Solutions are valuable when they support an agreed recovery strategy: not when they exist as disconnected technical purchases.
That strategic view is available through Evestaff IT Support and Consultancy. Where continuity planning extends into wider operational dependencies, the Evestaff group gateway provides the broader organisational context.
The goal is not to claim that disruption is impossible. It is to replace assumption with evidence, evidence with improvement, and improvement with a recovery capability that is proportionate, secure and financially defensible.
SEO tags: Disaster Recovery, Disaster Recovery testing, UK SME IT resilience, ISO 27001, Cyber Essentials, RTO and RPO, Dynamics 365 Jump Start, IBM i Management, Managed IT Services, Technology Expense Management, Cloud Solutions, Network Solutions, Voice and Connectivity, Helpdesk Support
Join The Discussion