← WordPress Security for High-Stakes Sites
What should a WordPress incident response plan include?
A named decision owner, a contact list, backups you have restored, logs that show what happened, a rule for when to preserve evidence before cleanup, and a decision made in advance about who can take the site offline. The plan exists so that the first hour of an incident is spent acting on decisions that are already made.
If something is wrong right now, skip the plan and go to fixing a hacked WordPress site.
What should be in place before anything happens?
Four things. Some cannot be created after the fact, such as past logs and a clean backup; the rest take too long to build under pressure.
- Backups you have restored. Stored off the server and restored at least once to a separate environment.
- Logs of access and change. Who logged in, what configuration changed, and what content was edited, kept where an attacker on the site cannot rewrite them. See what an audit trail should capture.
- File change monitoring. A scan against a known-good baseline gives the responder a list of files to start from. See WordPress file integrity monitoring.
- A current list of who has access. Accounts on WordPress, the host, DNS, the domain registrar, and any CDN. During an incident you need to know every credential that has to be rotated and who holds it.
Store the plan, the access list, and the contact list outside the site and outside the systems an incident could take down. A plan kept only on the compromised server is not available when it is needed.
Who decides, and who gets called?
One person decides, and that person has a named backup. Without a single decider, an incident turns into a group conversation while the problem continues.
Write down the decision owner and the authority that comes with the role. The most important decision to settle in advance is who can take the site offline, and under what conditions. Taking a revenue site down is expensive, and leaving a compromised one up can be worse, so agree on the criteria before the pressure.
The contact list covers:
- the person or firm who maintains the site, and how to reach them outside business hours
- the hosting provider’s support channel for the account
- whoever handles customer and legal communication for the organization
- anyone who needs to know because of a contract or a regulatory requirement
Which notifications the law requires, including any formal breach notice to customers, depends on the organization and its regulators. Put the question to counsel before an incident, and record the answer in the plan.
Keep the owner and the list current. They go stale when staff, hosts, or vendors change, so review them whenever one does.
What should customers be told?
The steps being taken to recover and to stop it happening again, in wording someone has approved. NIST’s incident response guidance, SP 800-61r3, calls for public updates “shared using approved methods and messaging,” and recommends explaining “the steps being taken to recover from the incident and to prevent a recurrence.”
Name in the plan who in your organization approves those messages and which channel they go out on, so nobody is improvising them mid-incident.
What belongs in the plan document?
One short document that a person under stress can read quickly. It names the decision owner and backup, states the conditions for taking the site offline, and lists the contacts. It points to where the access list lives, where the backups are and how to restore one, and where the logs are.
It says when to preserve a copy of the site’s files, database, and logs before anything is cleaned or restored, because cleanup and restores destroy the evidence. NIST’s SP 800-61r3 notes that formal evidence handling with chain-of-custody procedures “might not be performed for every incident that occurs,” but that “collected incident data is still considered evidence.”
NIST advises seeking legal guidance if an incident could lead to a prosecution or a lawsuit. Either way, preserve everything before it changes, which is why fixing a hacked WordPress site starts with backing everything up exactly as found.
It also says where decisions get recorded during an incident. A running log with times beats memory when someone later has to explain what happened. How to find and remove malicious code belongs in the cleanup guide, not in the plan.
How do you test the plan?
Walk through a scenario with the people named in it and find the gaps while nothing is at stake. The scenario can be short: an administrator account is used from a location nobody recognizes, or an alert reports a changed file in a plugin directory.
Ask the practical questions. Who is told first? Who can approve taking the site offline? Where is the latest backup, and has anyone restored it? Which credentials would need to change, and who holds them?
Look for plain gaps: a contact who left the organization, a host account only one person can log into, a backup nobody has restored.
What happens once something is found?
Contain the problem, preserve a copy, find how the attacker got in, remove what they left and close the way in, then restore the site. That order follows NIST SP 800-61r3, which puts containment before eradication and recovery.
To contain, investigate, and clean, follow fixing a hacked WordPress site. Afterward, keep the site stable after a rescue.
Which credentials should change after an incident?
All of them, for every user with access, not only the account that was misused. The WordPress.org hacked-site FAQ lists the access points as “FTP / SFTP, WP-ADMIN, CPANEL (or any other administrator panel you use with your host) and MYSQL,” and says this “must include all users that have access to the environment.” It also says to replace the secret keys in wp-config.php, which “will force anyone that might still be logged in off.”
Do it once the way in is closed. NIST lists changing passwords among recovery actions, which come after the attacker’s access is removed. Otherwise the attacker can capture the new credentials too.
If you want someone to take over the incident, our Website Security service includes incident response, and we also take on emergency cleanups for sites we don’t maintain. Contact us to start.
