Disaster recovery is the plan for the day something goes seriously wrong: a compromise, a failed update that takes the site down, a hosting outage, a domain expiry nobody caught, or a deletion nobody meant to make.
It is distinct from backups, though the two are frequently confused. Backups are one component. Disaster recovery is the answer to a broader question: when this happens, who does what, in what order, using which credentials, and how long should it take.
The plan matters more than the tools
Sites stay down for days not because restoring is technically difficult but because nobody agreed in advance who is responsible. The hosting login belongs to a former employee. The domain is registered to an agency nobody has spoken to in two years. Nobody is certain which backup is clean.
Every one of those is a paperwork problem rather than a technical one, and every one of them is solvable on a calm afternoon rather than during an incident. That is the entire value of having a plan written down before you need it.
What usually goes wrong
The most common serious incidents for small business sites are predictable. A compromise through an unpatched plugin. A failed update that breaks the site during business hours. An expired domain or certificate. An accidental deletion by someone with more access than they needed.
Almost all of these are recoverable within an hour if the preparation exists, and almost all of them turn into multi day outages if it does not. The difference is rarely skill. It is whether the information needed was gathered in advance.
Compromises deserve a particular note, because restoring a hacked site incorrectly is how businesses get compromised repeatedly. Restoring a clean backup without patching the entry point simply reinstalls a vulnerable site, and reinfection typically follows within days.
How we prepare
- Document every account, credential, and who holds it, including domain and DNS which are the most commonly forgotten
- Define who does what during an incident, so nobody is deciding roles under pressure
- Establish which backup to use and how to verify it is clean before restoring
- Test a restore in advance rather than assuming the process works
- Set expiry monitoring on domains and certificates, since both fail silently and on a schedule
- Write down the sequence, including patching the entry point before restoring rather than afterwards
What you receive
- A written recovery plan covering the realistic failure scenarios
- A current inventory of accounts, credentials, and access
- A tested restore rather than an assumed one
- Monitoring on domain and certificate expiry
- A defined sequence for compromise recovery that does not reinstall the vulnerability
Questions we get asked
Is this not just backups?
Backups are one part. Recovery is the rest: access, sequence, roles, verification, and knowing which copy is safe to use. A business with excellent backups and no plan still loses days, because the delay is almost always organisational rather than technical.
How long should recovery take?
For a typical small business site with preparation in place, under a few hours from decision to live. Without preparation, days is common, and a week is not unusual when domain or hosting access has to be recovered from a former supplier first.
What is the first thing to do if my site is hacked?
Do not restore immediately. Take the site offline or into maintenance mode, identify how access was gained, then restore a clean copy and patch the entry point before bringing it back. Restoring first is the most common mistake and it leads directly to reinfection.
How do I know if a backup is clean?
By working out roughly when the compromise occurred and choosing a copy from before it, then scanning that copy before it goes live. This is why retention matters. If your only backups are from the last week and the compromise is a month old, every copy you hold is already infected.
Who should hold the domain registration?
You should, in your own name, with billing and recovery details you control. Domains held by former agencies or former employees are one of the most common and most painful recovery obstacles, and it is entirely preventable.
How often should the plan be reviewed?
Annually at minimum, and whenever staff or suppliers change. Recovery plans go stale quietly. A plan listing a credential nobody has used in two years is not much better than no plan at all.
We will document what you currently have and tell you where the gaps are. That exercise is short, and it is usually the first time anyone has written down who actually controls what.