The first 90 minutes after a possible WordPress breach
A practical incident plan helps you limit damage, preserve evidence and bring your business website safely back under control.
Category: Cybersecurity
An unfamiliar administrator, redirects to unknown websites or sudden content changes may indicate that the WordPress website has been compromised. It is then easy to act too quickly: update everything, delete suspicious files or restore a random backup. Such actions can remove important evidence without closing the entry point the attacker used.
The first 90 minutes should therefore follow an agreed sequence. The goal is to limit the consequences, preserve necessary information and avoid reopening the website with the same vulnerability. The plan below is suitable for typical business websites, but must be adapted to the organisation’s technical setup, data processing practices and notification requirements.
Before the incident: Clarify who can make decisions
An incident plan is of little use if no one knows who has the authority to take the website offline or contact the hosting provider. Appoint an incident lead and a technical lead before anything happens. For smaller organisations, these may be the managing director and the web agency or hosting provider.
The plan should include contact information that is accessible outside WordPress. It should also specify where backups are stored, who controls the domain, who administers the hosting, and which external services the website exchanges data with. Do not keep the only copy of the plan in a system you may lose access to.
Also clarify in advance who can decide to:
- Put the website into maintenance mode or take it temporarily offline.
- Disable user accounts and integrations.
- Commission assistance and approve costs.
- Inform customers, employees and any affected partners.
- Assess whether the incident involves personal data or other protected information.
0–15 minutes: Confirm the alert and create an incident log
Start by recording what was discovered, when it was discovered and who discovered it. Take screenshots of visible anomalies and note which pages, users or functions are affected. Create a single shared incident log in which all actions are recorded as they occur.
Do not assume that every anomaly is the result of a breach. A failed deployment, an expired integration or a conflict following an update can produce similar symptoms. At the same time, treat the situation as genuine until it has been clarified.
Check, among other things:
- Whether new administrators or other unfamiliar users have been created.
- Whether content, menus, settings or tracking codes have been changed.
- Whether visitors are being redirected to other websites.
- Whether the hosting provider, security tools or monitoring have recorded unusual logins or file changes.
- Whether the website is sending an unusually large volume of email or has experienced sudden operational problems.
Avoid making extensive changes before you have gathered basic information. A mass update can alter timestamps and files that could otherwise help you understand the incident.
15–30 minutes: Limit the damage without destroying evidence
When there is reasonable suspicion of a compromise, you must reduce the attacker’s room to manoeuvre. The appropriate action depends on the importance of the website and which functions are affected.
A standard informational website can often be placed in maintenance mode while the investigation is under way. For an online store or self-service solution, you must weigh the risk of continued operation against the consequences of downtime. If data may be read, altered or sent to the wrong recipient, security should take priority over availability.
Preserve a copy of the affected environment before cleanup begins. The copy should include files, the database and relevant logs. It must be kept separate from any subsequent clean production environment. This is not the same as taking a regular operational backup for recovery; the purpose is to preserve the state of the environment as it was when the incident was discovered.
Do not delete an unfamiliar administrator or suspicious file before documenting the discovery. The account can be blocked and access can be restricted, but information about when it was created and its activity may be important for identifying the entry point.
30–60 minutes: Disable access in the right order
A WordPress website is managed across several layers. Changing passwords in WordPress is of little help if unauthorised parties still have access to the hosting account or the email account used for password resets.
Start with the accounts that can control the others. A suitable order is often:
- Secure the email accounts of administrators and technical contacts.
- Secure the accounts for hosting, the domain and any cloud services.
- Change the login credentials for WordPress administrators.
- Change the database password, file transfer credentials and other technical keys.
- Revoke active sessions, application passwords and integration keys.
Use unique passwords and multifactor authentication wherever available. If an administrator has used the same password elsewhere, those accounts must also be addressed. Do not create new permanent shared users as a shortcut during the incident. Each person should have their own account, even when time is pressing.
At the same time, review which integrations may have been affected. A contact form may send data to a customer management system, while an online store may be connected to payment, shipping, accounting and email marketing services. Keys and access credentials should be replaced whenever they may have been exposed.
60–90 minutes: Choose between cleanup and restoration
You must now decide how to bring the website back online. There are two main options: clean the existing installation or rebuild the solution from a known clean state.
Cleanup may be appropriate when the scope is limited, the cause is clear and the changes can be identified with confidence. Even so, it requires more than removing a single suspicious file. The WordPress core, themes, plugins, uploaded files, database content, administrators and scheduled tasks must all be examined.
Restoring from a backup may be safer when the changes are extensive or difficult to isolate. However, the backup date must be compared with the time of the breach. An older backup may already contain the backdoor, while a very old copy may be missing important orders, form submissions or content changes.
Before the website is reopened, the original point of entry must be addressed. This may mean updating a vulnerable plugin, replacing an outdated component, removing an abandoned user account, or correcting faulty server settings. If the cause is unknown, you also lack a sound basis for claiming that the solution is secure.
Updates should close the cause, not conceal it
Updates are a central part of remediation, but timing is important. First, document and secure the current state. Then update WordPress, themes and plugins in a controlled copy or test environment.
Components that are no longer maintained should normally be replaced rather than simply reactivated. The same applies to plugins you do not use. A deactivated plugin may still have files on the server and should be removed if it is not needed.
Verify that the update does not break forms, login, payments or other critical functions. The goal is not merely to get a green update panel, but to close the vulnerability without introducing new operational issues.
Check before reopening the website
A technically accessible homepage is not enough to declare the website safe. Carry out a brief, documented review of both security and functionality.
- Confirm that only approved users have administrator privileges.
- Check that all active components are necessary and maintained.
- Investigate whether any unknown files, scheduled tasks or code changes remain.
- Test forms, search, login, outgoing messages and any purchasing flows.
- Check that logging and monitoring are still working.
- Make sure a new backup is taken and can be read by the correct system.
Consider reopening the website in stages. Internal testing can be carried out first, followed by limited production operation with additional monitoring. Pay particular attention to new administrators, failed logins, file changes, unexpected traffic and outgoing email.
The follow-up determines whether the incident will happen again
Once operations are stable, you should bring those involved together for a brief review. Describe what happened, how it was detected, which measures worked, and what caused delays. Distinguish between technical causes and organizational weaknesses. A vulnerable plugin is a technical cause; a lack of responsibility for updates is an organizational weakness.
Then update the procedures for authentication, access management, updates, backups and monitoring. Remove old accounts, reduce administrator privileges and decide who will follow up on security alerts. Also agree how often recovery procedures and the incident plan should be rehearsed.
An effective response is not about making as many changes as possible in the shortest time. It is about working in the right order: document, contain, secure access, remove the cause, verify the solution and follow up. This reduces both downtime and the risk of the same entry point being used again.
