A backup is not preparedness until it has been tested: Practise restoring WordPress

A green status next to “backup completed” only tells you that a process has run. It does not tell you whether the backup is complete, whether it can be restored, or whether you can find the right access credentials when the website is unavailable.

That is why organisations should practise WordPress recovery. The goal is not only to restore files and the database. You must be able to establish a known, clean starting point, control who has access, address the cause of the incident and verify that business-critical functions work.

This type of exercise is suitable for both simple business websites and larger solutions with forms, online shops or integrations. It provides a more realistic picture of your preparedness than a checklist alone.

Start with a concrete incident scenario

An exercise is more useful when it is based on a specific situation. Avoid the vague scenario “the website is down”. Instead, describe what you know, what you do not know and which decisions need to be made.

A suitable scenario could be that an administrator discovers unknown users in WordPress while some pages are redirecting visitors to unwanted content. You do not know when the changes began. The website is still accessible, but cannot be considered safe.

This scenario forces important questions:

• Should the website be taken completely or partially offline?
• Which backup can be considered clean?
• How can you prevent the attacker from retaining access?
• Which passwords, keys and integration credentials need to be changed?
• How do you verify that the problem will not return?
• Who decides when the website can be reopened?

The exercise can be conducted without a real security incident. Use an isolated test environment, and clearly agree that the production website must not be affected.

Determine what must be recoverable

A WordPress website consists of more than the content in the database. A usable backup will normally need to include the database, media files, themes, custom code changes and necessary configurations. At the same time, you should know which components should not be reused uncritically after a breach.

Plugins and the WordPress core can often be reinstalled from known, clean packages. This is safer than copying all program files directly from a backup that may contain manipulated code. Custom themes and bespoke extensions should be retrieved from the organisation’s approved code repository, if one exists.

Also map dependencies outside the WordPress installation itself:

• DNS and domain administration
• Web hosting, server or operations platform
• Certificates and security settings
• Email services and form submissions
• Payment solutions, analytics tools and other integrations
• External fonts, media or content sources
• Jobs that run automatically in the background

If no one knows where these components are managed, that is a preparedness problem even if the backup is technically sound.

Define acceptable data loss and downtime

Before the exercise, management should clarify how much data the organisation can afford to lose and how long the website can be unavailable. The need depends on how the website is used.

A simple presentation website may be recoverable from yesterday’s backup without major consequences. For an online shop, the same choice could mean losing new orders, stock changes and customer data. A website with many form submissions could lose enquiries that are not stored in other systems.

Make the requirements concrete. “Back online quickly” is not an operational target. Instead, specify how old the recovery point may be at most and how long the team has to establish a controlled solution. These requirements determine how often backups must be taken, how they are stored and who must be able to start the recovery.

Check the backup before you need it

A backup should be stored separately from the website it protects. If the production environment and the backup can be deleted or encrypted using the same administrator account, you have a shared point of failure. Access to the backup should require strong authentication and be limited to people who genuinely need it.

Before the exercise, you should check the following:

• That scheduled backups are actually completed
• That multiple historical recovery points are available
• That the backup is not stored only on the same server as the website
• That the contents are protected against unauthorised changes and deletion
• That at least two designated people know how to retrieve the backup
• That failed-backup alerts are sent to a channel that is monitored

Do not use the exercise to share the master password by email or chat. Use named accounts, password vaults and a documented emergency procedure. Emergency access should be usable, but difficult to misuse.

Recover in an isolated environment

The recovery itself should first take place in an environment that is not publicly accessible and cannot send email, charge payment cards or overwrite data in external systems. Otherwise, production copies may trigger actions that appear genuine.

1. Record the start time and who is responsible. Note who is leading the exercise, who is performing the technical tasks and who approves the outcome.
2. Choose a recovery point. Explain why the point in time is considered safe. The most recent copy is not necessarily the right one if there is suspicion of a prolonged compromise.
3. Establish a clean baseline environment. Install the operating system, server components and WordPress from controlled sources instead of reusing an environment you do not trust.
4. Import the necessary data. Restore the database and media files, but assess application files separately.
5. Reinstall approved code. Use maintained versions of themes and plugins. Remove components that are no longer necessary.
6. Disable outgoing actions. Prevent email delivery, automatic order processing and calls to external services until the solution has been checked.
7. Test the functionality. Check representative pages, login, forms, search, editing and any purchase flows.

Record all manual interventions. If the recovery depends on one developer remembering a specific server setting, the process is too vulnerable.

Change access credentials, not just the administrator password

In a real breach, changing the password for a single WordPress user is rarely sufficient. The attacker may have created multiple accounts, extracted integration keys or gained access through web hosting and email.

Create a fixed list of access points to review:

• WordPress administrators and editors
• Web hosting, server and control panel
• Database users and file transfer
• Domain and DNS administration
• Backup accounts
• Email accounts that can reset passwords
• Keys for payment, form and analytics integrations
• Developer tools and automated publishing processes

Remove unknown and obsolete accounts. Require multifactor authentication wherever possible, especially for administrative access points. Avoid shared users, as they make it harder to see who performed an action.

Changing a password will not help if a vulnerable plugin still provides access. Therefore, identify the likely entry point before reopening the solution. Update or remove the affected component, and investigate whether a similar weakness exists in other environments.

Verify that the restored solution is secure

The fact that the front page is displayed does not mean the website is ready. Carry out a review that combines security, functionality and data quality.

Look for unknown administrators, changed system settings, new scheduled tasks, suspicious files and code loaded from unexpected locations. Compare your own code files with approved versions. Also verify that WordPress, themes and plugins are up to date and still supported.

Then test the most important user journeys. Send a form to a controlled recipient. Carry out a test purchase without an actual charge if the website has an online store. Verify that consents, email notifications, search and login work as expected.

Monitoring must also be brought back online. Confirm that you receive alerts for unavailability, failed backups, unexpected file changes and administrative logins that require follow-up. Alerts must have a named recipient and an agreed action.

End with decisions, not just minutes

After the exercise, the team should answer three questions: What stopped us, what took unnecessarily long, and what depended on individuals?

Turn the findings into concrete tasks with an assigned person and a deadline. This may include establishing separate backup storage, documenting DNS access, introducing multifactor authentication, removing old users or automating backup checks.

Then update a concise recovery plan. It should describe who can declare an incident, how the website is isolated, where backups are stored, which access credentials must be changed, which functions must be tested and who approves reopening.

Repeat the exercise when the website gains significant new functionality, the operations provider is changed or key people leave. Preparedness is not a document that is ever finished. It consists of procedures that still work when the usual assumptions fail.