Enterprise incident response plans run to forty pages and nobody reads them during an actual incident. What a small business needs is one page, written in advance, that answers the questions you will not want to think about at 7am on a Saturday.
An incident response plan is not really a security document. It is a decision document — because the expensive part of an incident is rarely the technical work. It is the hours spent working out who is allowed to decide things.
Why this matters more than it sounds
Consider two businesses hit by the same compromise.
The first spends four hours establishing who can authorise taking the site offline, another two finding out who has hosting access, and discovers the backup credentials belonged to a developer who left. The clean-up takes three hours. The incident took two days.
The second follows a written page, takes the site into maintenance mode within ten minutes, and has the right person working on it by lunchtime.
The technical work is usually the smallest part of an incident. Everything around it is what makes it long.
What the page needs
1. Who decides
Name one person who can authorise taking the site offline, and one deputy. Not a committee — one name, with a phone number.
Taking a revenue-generating site offline is a commercial decision made under time pressure. Deciding in advance who owns it removes the longest delay in most incidents.
2. Who to call
A list with actual contact details, kept somewhere reachable when the website is down:
- Whoever handles your website technically — agency, freelancer, or internal
- Your hosting provider's support, including your account number
- Your payment processor, if you take payments
- Your insurer, if you have cyber cover
- Whoever handles legal or data protection questions
Store this outside the website. A contact list on the site you cannot reach is not a contact list.
3. Where the keys are
Not the credentials themselves — where they live and who can retrieve them. Domain registrar, hosting panel, WordPress admin, database, DNS, and backups.
If the answer to any of these is "the developer has it", that is a finding in itself. Our guide to auditing an inherited website covers establishing access properly.
4. The first thirty minutes
Four actions, in order, that anyone on the list can carry out:
- Contain — maintenance mode if the site is actively harming visitors; disable checkout if card data may be at risk
- Preserve — take a full copy of files and database, and download the logs before anything is changed
- Lock — change passwords and regenerate the security keys in
wp-config.php - Pause advertising, so you stop paying to send people to a compromised site
Our guide to what to do in the first hour covers this in more depth, including the three instincts that make things worse.
5. Who you may have to tell
The part most plans omit, and the one with legal deadlines attached.
If personal data may have been accessed, notification obligations apply — generally 72 hours to the regulator under GDPR, with comparable windows under PDPL. That clock starts when you become aware, not when you finish investigating.
Write down who assesses whether data was involved, who drafts the notification, and who signs it off. Deciding this during an incident is how deadlines get missed.
6. What you will say
A short holding statement, drafted in advance, that can be adapted in two minutes. Something honest and non-committal: you are aware of a technical issue, you are investigating, you will update by a stated time.
Writing this calmly beforehand produces far better wording than writing it while stressed.
The things worth deciding in advance
Two questions that always come up and always cause argument in the moment.
At what point do we take the site offline? Agree the threshold now. A reasonable default: offline immediately if it is serving malware, redirecting visitors, or potentially skimming card details. Stay online while investigating if the symptoms are spam pages or defacement.
Do we restore from backup or clean in place? The instinct is to restore, and it is usually wrong — the recent backup often contains the infection, the vulnerability remains, and you lose every order since. Decide the principle now: establish when the infection started before restoring anything.
Testing it
A plan nobody has tried is a hypothesis. Two low-effort tests are worth doing.
Once a quarter, restore a backup to staging and confirm it works. Once a year, spend twenty minutes walking through a scenario verbally — who does what, in what order. You will find at least one broken assumption every time, usually an access credential nobody has.
Keeping it usable
One page. Stored somewhere reachable when the website and possibly your email are down — printed, in a password manager, or on a phone.
Reviewed when people join or leave, when you change hosting, and once a year regardless. An incident response plan naming a developer who left eighteen months ago is worse than none, because it creates false confidence.
The uncomfortable question it raises
Most businesses writing this for the first time hit the same realisation partway through: there is no line for "how we would find out".
The plan assumes someone notices. But if nothing is monitoring the site, discovery comes from a customer, from Google, or from your host suspending the account — typically weeks in, by which point most of the damage is done.
A response plan is worth having. It is worth much less than detection, because it only starts working once you know. Our security monitoring service covers that first step.
If you would rather not be the one responding
For most small businesses the honest position is that the technical steps are not something you want to be performing under pressure at the weekend.
Our security and error fixing service handles the response itself — containment, clean-up, backdoor removal and delisting.
Get in touch and we will tell you what your plan is currently missing. Usually it is the access list.
Get Shielded
We build, host, secure and monitor business websites — cleaning up hacks and keeping sites online for clients across the UK, USA, Australia and the UAE.
