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.
The scenario most businesses are least prepared for
The failure people prepare for is a hack. The one that catches them out is losing access. A domain registered to a former employee. A hosting account tied to an email address nobody can reach. A Google profile verified by an agency that no longer answers.
None of that is dramatic and all of it is slow to unwind, because recovering access from a third party involves proving ownership to a support process rather than fixing something technical. An afternoon spent documenting who controls what prevents nearly all of it.
What should I document?
Domain registrar and who holds the account. Hosting login and billing contact. DNS provider if separate. Website administrator accounts. Google profile ownership. Analytics and ad account access. Store it somewhere you can reach without the website, which rules out storing it only on the site.
How do I get access back from a former supplier?
Ask plainly first, since most transfer without difficulty. Where they do not, registrars and platforms have ownership dispute processes, and documentation showing you paid for and control the asset is what those processes need. It is slow, which is the argument for holding the accounts yourself from the start.
How often should the recovery plan be tested?
At least once a year, and after any change to hosting, staff, or suppliers. Testing means actually performing a restore to a staging environment rather than confirming that backup files exist. A plan that has never been executed is a document rather than a capability, and the gap between those two only becomes visible during an incident.