Topic hub

Disaster Recovery

Disaster recovery is the organised restoration of priority business services after a serious technical or cyber incident. It begins before failure by defining decisions, dependencies, recovery order and communication.

3 published guides0 subtopicsUpdated 21 July 2026

Start here

The main guide for this topic

Step-by-step

What to Do When Your Website Goes Down

When a website goes down, confirm the scope before making changes. A rushed DNS edit or restore can turn a short provider incident into a longer outage or lost data.

Open the complete guide →

Published guides

Articles in this section

Step-by-step15 September 2026

What to Do When Your Website Goes Down

When a website goes down, confirm the scope before making changes. A rushed DNS edit or restore can turn a short provider incident…

Read guide →

Step-by-step8 September 2026

Recovering from a Hacked Website

Recovering from a hacked website means returning to a trusted state and closing the route used by the attacker. Simply deleting vi…

Read guide →

Practical guide21 July 2026

Website Disaster Recovery Plan for Small Businesses

A small-business disaster recovery plan should fit on a usable operating document while still covering authority, contacts, techni…

Read guide →

About this section

Information checked: 21 July 2026.

In brief: Prioritise trusted business service restoration, not merely republishing website files.

Separate incident response and recovery

Response and recovery roles
Phase	Main objective	Typical decisions
Identify	Understand what is happening	Scope, evidence and severity
Contain	Limit further harm	Isolation, access suspension and fallback
Recover	Restore trusted priority services	Recovery point, order and validation
Communicate	Give accurate information	Staff, customers, suppliers and regulators
Learn	Reduce recurrence	Control, process and contract changes

Define priorities before an incident

Customer contact and status information.
Domain, DNS and email control.
Website or transaction service.
Payments, bookings and order records.
Administrative access and supplier communication.
Evidence and personal-data breach assessment.

Plan for degraded operation

A full website may take longer to restore than a controlled status page, phone line or manual booking process. Document safe temporary methods and the point at which they are activated.

Acceptance check

Recovery planning is credible when an authorised team can run a tabletop exercise without relying on one unavailable person, one supplier or credentials stored inside the failed system.

Use recovery tiers

Not every service needs to return at once. Define a minimum viable customer service, then restore supporting features in a controlled order. For example, contact information and a manual booking route may be restored before account dashboards or historical content.

Records to keep

Service priority and dependency map.
Manual fallback procedure.
Recovery authority and acceptance criteria.
Exercise findings and actions.

Owner test: Run a scenario where the website, normal email and primary developer are unavailable and identify the first usable customer service restored.

Set recovery acceptance criteria

A service should not be declared recovered merely because pages load. Define acceptance for data integrity, customer transactions, administration, security controls, monitoring and staff handover. If one secondary feature remains disabled, record the workaround, owner and deadline rather than hiding the limitation.

Sources and date checked

This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.