Website Security Incident Plan: A One-Page Template

Most website owners only think about a hack while one is happening. That is the worst possible moment to work out who has the hosting password, whether the backups are real, or who is allowed to take the shop offline. People end up searching old emails at midnight while the site keeps sending visitors to a spam page.

A short written plan, made on a quiet day, removes most of that scramble. It does not need to be a corporate document. One page is enough for a small business, as long as it answers the questions you will be too stressed to answer later. This post walks through what to put on that page and why each line earns its place.

Why one page, and not a binder

Large companies write long incident response documents with roles, escalation trees and legal sign-offs. A business with one website and a handful of staff does not need that, and a long document has a real cost: nobody reads it, nobody updates it, and on the bad day nobody can find the part that matters.

One page forces you to keep only what someone will actually use under pressure. If a line would not help a tired person at 11 at night, cut it. You can always keep longer notes somewhere else and point to them from the page.

Where the plan should live

Do not keep the only copy on the website, in the hosting account, or in the email inbox tied to your domain. Any of those can be the thing that is broken or locked. Good places are:

• A printed copy in a drawer at the office.
• A note in a password manager that the owner and one trusted person can open.
• A file in a personal cloud account that is not linked to the business domain.

Two copies in two different places is a sensible minimum. Write the date at the top so you can tell how old it is.

Section 1: Who decides, and who acts

The first block of the page is names and phone numbers. Keep it short:

• Decision maker. The person who can say “take the site offline” or “pause online orders” without asking anyone. In a small business this is usually the owner. Write down a second person in case the owner is travelling or unreachable.
• Technical contact. Whoever looks after the site: an in-house person, a freelancer, or an agency. Note how to reach them urgently, not just their office email.
• Hosting support. The support channel for your host, plus your customer or account ID, because support teams ask for it before anything else.
• Payment provider contact, if you take payments on the site. You may need to ask them questions about a suspicious transaction or a checkout problem.

Settle one thing in advance: who is allowed to take the site down. Arguments about lost sales are much calmer when the rule was agreed months earlier.

Section 2: The access list

This is the part most owners discover they do not have. A cleanup touches several accounts, and each one is a separate login, often created by different people over the years. List every account the site depends on, who owns it, and where its login is kept. Do not write the passwords themselves on a printed page. Write where they are stored.

Filling in that table often surfaces a problem on its own. A former developer still owns the registrar account. Nobody knows which Google account verified Search Console. The hosting login belongs to an employee who left. Fixing those gaps now is far easier than proving ownership to a registrar while the site is compromised.

While you are at it, check that the important accounts have two-step login turned on. For the WordPress side, our guide to adding a second login step in WordPress covers the practical options.

Section 3: Backups you have actually tested

“We have backups” is one of the most common things owners say, and one of the least checked. For the plan, write down three facts:

1. Where the backups are. On the same server, in the hosting panel, in a plugin’s remote storage, or somewhere else entirely.
2. How far back they go. A hack is often found days or weeks after it happened. If you keep only the last few copies, every one of them may already contain the infection.
3. When someone last restored one. A backup that has never been restored is a hope, not a backup.

A copy stored only on the hacked server is weak, because an attacker with server access can reach it too, and some hosts remove account files during a malware suspension. At least one copy should sit somewhere the website itself cannot write to. Our walkthrough on keeping off-server WordPress backups explains how to set that up. Once a year, restore a copy to a staging area and click around it, so you know the process works and roughly how long it takes.

Section 4: The first moves, written in advance

The plan should not try to be a cleanup manual. Its job is to stop people doing harmful things in the first hour and to point them at the right help. A handful of lines is enough:

• Write down what you saw, when, and on which device, with screenshots.
• Do not delete files, plugins or users yet. They are evidence and some are needed to understand the entry point.
• Do not restore a backup over the live site before someone has looked at it.
• Contact the technical contact from Section 1.
• If the decision maker agrees, put the site into maintenance mode or ask the host to restrict it.

If you want a fuller checklist for those first steps, there is one in a first-hour checklist for hacked sites. The plan only needs the short version, in your own words, with your own contact names filled in.

Section 5: Who you might need to tell

Depending on what the site does, a hack can affect people outside the business. Prepare a short list of who would need to hear from you, so you are not inventing it under pressure:

• Staff who answer the phone or WhatsApp, so they can give a calm, consistent answer to customers who notice something odd.
• Customers, if the site stores accounts, orders or personal details.
• Your payment provider, if checkout pages may have been changed.
• Partners or resellers who link to you or embed your content.

Whether you have a legal duty to notify anyone depends on your country, your customers’ countries and what data was involved. The plan does not need to settle that question. It should note who you would ask, such as your lawyer or accountant, so that decision is not delayed. This is general information, not legal advice.

A two-line holding message for staff is worth writing now: something like “We are aware of a problem with the website and are working on it. Your details are not being asked for by phone or message.” Adjust it to your business. It stops staff guessing.

Section 6: What counts as an incident

People hesitate to act because they are not sure whether something is serious. A short list of triggers helps. Treat it as an incident if:

• Google shows a warning on your search result or in Chrome.
• The host emails about malware, suspends the account or limits it.
• Visitors report being sent to another website.
• An administrator account appears that nobody created.
• Customers report unexpected payment problems after using your checkout.
• Your domain starts bouncing email or landing in spam suddenly.

Smaller oddities, such as a slow page or a plugin error, can go through normal support. The point of the list is that anything on it skips the queue.

Section 7: Early warning, so you hear first

A plan works better when the business notices problems before customers do. Three low-effort things help:

• Search Console email alerts. Make sure the right person receives messages from Google about security issues and manual actions. Many owners verified the site years ago with an address nobody reads.
• Uptime and content checks. A monitor that pings the site and alerts you if it goes down or a key page changes. Our post on what uptime monitoring should watch goes into the options.
• Host notifications. Check which email address your host uses for abuse and malware notices, and change it if it points to an old inbox.

Section 8: Write down how you will reach outside help

If you do not have a regular technical contact, the plan should name who you would call. Write down how to reach them and what to send in the first message. A useful first message includes the website address, what you saw, when you saw it, and whether you can still log in to WordPress and the hosting panel.

If that outside help is us, the line on your plan can simply say: message WebMaintor on WhatsApp and start with the word HACKED. That flags the message as urgent so it is picked up ahead of routine requests. Our hacked website repair page explains what happens after that first message.

Keep it current

A plan goes stale quietly. People leave, hosts change, someone switches the email provider. Pick a moment you already have in the calendar, such as the domain renewal or the start of the financial year, and spend fifteen minutes reading the page top to bottom. Ask three questions:

• Is every name and number still right?
• Can each listed person still log in to the account next to their name?
• When was the last test restore?

Update the date at the top. If you made changes to the site during the year, such as adding a shop or a membership area, add the new accounts to the access list.

A quick practice run

You do not need a full drill. Once, sit with the person named as technical contact and walk through a pretend morning: “Google shows a warning on our listing. What happens next?” Follow the page. Wherever someone says “I am not sure” or “I would have to find that”, you have found a gap. Fill it in and move on.

This also tells you how dependent the plan is on one person. If every line leads back to a single freelancer who might be on leave, note a backup option.

What the page looks like when it is done

A finished plan for a small business usually fits on one side of paper: names and numbers at the top, the access table in the middle, backup facts, the short first-hour list, the trigger list and who to tell at the bottom. It is not impressive to look at. It is useful, which is the only test that matters.

If you would like someone to be the technical contact on that page, or you want to know exactly what we do when a hack is reported, our urgent hacked-site support page sets out how we work, without any pressure to sign up for anything in advance.

Next in this series: Hacked Email vs Hacked Website: How to Tell Which