Website Incident Response Plan: What To Do When Hacked

When your website is hacked, work in this order: write down what you see, contain the damage, keep a copy of the evidence, find how the attacker got in, then remove the hack and rebuild. Restoring a backup or changing passwords on its own often fails, because the way in is still open. Tell your host first.

What do I do in the first hour?

The first hour has three jobs: record, contain and preserve. On a small site one person does all three, but the order matters. Containing without recording loses the story, and cleaning before preserving destroys it.

How do I record what happened?

The WordPress.org guide starts with documentation, before any cleanup: what you see, the time and timezone you noticed it, and what changed recently, such as a new plugin or a theme edit. That note becomes your incident report whether you fix the site yourself or hand it over. The same guide counts a Google or Bing warning, a host suspension, new users you did not create and visitor antivirus alerts as clear signs of a hack.

• Write down what made you suspect a hack, with the time and timezone.
• List every change in the past week: plugins, themes, new admin users, new access given to a freelancer or agency.
• Note your host, plan type and everyone with panel, FTP, database or CMS access.

How do I contain it?

The FTC guide says to move quickly, take affected equipment offline, and update credentials, but not to power machines off until forensic experts arrive. For a hosted website, that translates to asking the host to suspend or isolate the site while leaving the account and files in place. A static maintenance page covers visitors in the meantime.

Then reset access. The WordPress.org guide names the points to change: hosting panel, FTP or SFTP, the database user, the CMS admin and every other user. It also says to replace the secret keys in wp-config.php, which signs out anyone still logged in. It also suggests scanning your own computer, since attackers sometimes start from a trojan that captures logins there.

How do I preserve evidence?

CISA's playbook says to collect logs and, where a machine needs forensic analysis, a memory and disk image, and to keep a detailed log of what was collected, how, when and by whom. The FTC adds that you should not destroy forensic evidence. WordPress.org recommends one more snapshot of the environment before cleaning, even if it is infected.

This is the question to send your host today:

My site example.com may be compromised. Please do not delete or restore anything yet. Can you suspend or isolate it without removing files, export the web server access and error logs for the last 30 days, tell me how long you keep logs, and tell me whether other sites on the same account or server show the same activity? Please also tell me the time you first saw anything unusual.

In what order does the work run?

NIST SP 800-61 Rev. 3 (April 2025) and CISA's playbook checklists describe the same arc. This version is cut down for a website.

Why do new passwords and a restored backup fail on their own?

Because each fixes one possible way in and leaves the others. CISA's playbook warns that attackers often hold several persistent access points and can return to areas you believed were finished if eradication is not thorough.

Three causes account for most repeat compromises:

1. The weakness the attacker used is still there, whether an outdated plugin, a runtime, or a reused credential.
2. A backdoor file or admin account survived the cleanup.
3. The restored backup already contained the hack, or predates updates that closed the hole.

One detail from WordPress.org is easy to miss. Its guide says to reinstall core files by SFTP rather than with the one-click reinstall in the admin, because that installer tends to overwrite existing files while hacks add new ones. Replacing /wp-admin and /wp-includes wholesale covers the files the installer would leave behind.

How do I find out how they got in?

Start with the ordinary candidates: an unpatched component such as a plugin, theme or the PHP runtime itself, a stolen or reused credential, a third party with access (an agency tool, a host panel), or a file that should never be public, such as a .git folder, an .env file or a backup archive. Server logs and the file change history decide between them. Nothing outside your server can.

A lookup from outside still narrows the list. The free Red scan reads the stack your site serves and matches each version to known vulnerabilities, and checks for .git, .env, backups, open directory listings, and panels and consoles left online. One scan per domain, no card. It is a lookup: it can say a version is affected, not whether your setup is exposed, and it cannot tell you whether you were compromised.

If the answer is the PHP runtime, see PHP2Shell: affected versions and fixes. If you cannot tell who owns the fix, read who patches my website.

What do I restore from, and what do I rebuild?

Google's clean and maintain guide sorts the answer by the backup you have. In every case, confirm first that the backup was made before the hack.

The same page tells you to remove software you do not use, perform a clean installation instead of an upgrade on each server, transfer only known-clean content, and change every site-related password after each stage. It treats bringing the site back online as the last step, once cleanup is confirmed.

CISA's checklist for the same phase includes reimaging or rebuilding systems from trusted sources, replacing compromised files with known-good ones and installing patches. After that, keep watching for new activity. If any appears, return to analysis rather than assuming the first cleanup was complete.

Who do I have to tell, and by when?

Duties depend on where you and your customers are and what was exposed. The FTC guide says to determine state, federal and sector rules, and to consult your own legal counsel. This table is a map for that conversation. It is not legal advice.

Two details from the regulators are useful. Under Article 33(2), a processor must tell the controller without undue delay once it learns of a breach, so if a host or agency runs your site, ask in writing when they first knew. The ICO says you must record every breach, reportable or not, and that information can be given in phases if the investigation is not finished within 72 hours. Write down the time you became aware of the problem, because the clock is counted from it.

How do I get Google's hacked warning removed?

Google's request a review guide lists four prerequisites: ownership verified in Search Console, the hacker's changes removed, the vulnerability fixed, and the cleaned site back online. Check your pages with curl or wget first, and make sure robots rules and noindex are not blocking Googlebot.

Delete hacker-created URLs and make them return a 404. In the review request, explain what you did for each category of hack, for example the spam removed and the plugin update that closed the hole.

• Phishing flags: about a day.
• Malware flags: a few days.
• Hacked spam: up to several weeks.
• If Google finds the site fixed, warnings come down within 72 hours. If not, the Security Issues report may list more sample infected URLs and the warnings stay.

Is my site still compromised? Where you stand

Does patching the bug end the incident?

No. A patch answers whether the hole is closed. It does not answer whether anything got in before it closed. The PHP project's 21 October 2026 notice shows the pattern: fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (checked 24 October 2026). That fact does not settle whether your site was entered during the days before your patch. The PHP2Shell page covers the 17 to 21 October window, and the October 2026 tracker lists the other incidents.

What do I tell customers?

The FTC guide advises naming a single point of contact, avoiding misleading statements, and not withholding details that help people protect themselves. It also says to post plain-language answers on your website where people can find them. A good notice says how the breach occurred, what information was involved, what you did about it, and how to reach you. The FTC also suggests telling people how you will contact them in future, so they can recognise phishing that copies your notice. A ready-to-edit customer breach email saves drafting it under pressure.

What should a plan contain before anything happens?

For a website, a one-page plan is enough if someone has actually read it. What malware cleanup costs is worth knowing before you need it, and the other incident response guides cover the rest.

• One named owner and one deputy, with phone numbers that work at night.
• A list of everyone and everything with access: host panel, DNS, CMS, FTP, database, agency tools, payment account.
• Your host's emergency contact and the support question above, saved.
• A backup you have restored at least once into a test copy, with its date written down.
• Where logs live and how long your host keeps them.
• A short list of who gets told, copied from the table above and edited for your country and sector.
• If you take cards, the incident plan that PCI DSS Requirement 12.10 expects, tested.

The NCSC publishes a free response and recovery guide written for small organisations and sole traders.