WordPress Hacked-Site Recovery Plan for 2027: Template and Tabletop Exercise

A hacked website has a particularly annoying talent: forcing every decision into the moment when nobody has time to think. Who can stop checkout? Where is the backup? Who speaks to the host, and who authorises selling again? When those answers live in one person’s head, recovery comes with an avoidable extra dependency.

This WordPress hacked-site recovery plan for 2027 helps you prepare those decisions before an incident and rehearse them without changing production. It includes a copyable recovery card, named responsibilities, reopening conditions and an original fictional tabletop exercise. It does not replace technical investigation or certify that a website is clean.

Already dealing with an incident? Start with a hacked WordPress recovery assessment. A prepared plan is useful; completing a document while visitors remain exposed should not delay appropriate containment.

Define the recovery outcome before choosing tools

Separate recovering control, restoring service and restoring business continuity. Signing into the administrator account addresses part of the first. Loading the homepage addresses part of the second. Neither proves that orders, enquiries or permissions are correct.

Write down what your business needs to operate safely: receiving enquiries, serving customer accounts, publishing information or taking payments. Prioritise those journeys and the people depending on them. A corporate site without a shop can still lose leads, private documents or control of recovery email.

Next, name the person who can accept an interruption and the information they need to decide. Avoid promising a recovery duration that nobody has tested. The plan should support a next step with incomplete information while keeping the uncertainty visible to everyone making that decision.

A recovery card you can copy

Keep a copy accessible when WordPress and the usual company mailbox are unavailable. Replace each prompt with an internal reference. The card records locations and ownership; passwords belong in the approved secrets manager.

WP-2027 RECOVERY PLAN | version and review date:
Production domain and environment:
Incident coordinator / deputy:
Independent communication channel / hosting contact:
Authority to contain service / approve expenditure:
Business journeys requiring protection:
Protected backup and log locations:
Last restore rehearsal / result / limitations:
Proposed tolerable data loss / approved by:
Proposed recovery-time target / supporting test:
Recent-data reconciliation owner:
Reopening criteria / reviewer:
Safe alternative if reopening fails:
Next review / open actions / owners:

An empty field is an action item, not permission to invent an answer. If nobody knows when a restoration was rehearsed, write “no test evidence available”. If the host confirms a log-retention period, record its answer and date without turning it into a wider guarantee.

Add the location of your supplier inventory: DNS, CDN, hosting, email, backups, source repository and payment provider where relevant. Link to those records rather than making this card an enormous directory whose details silently expire. Someone must own the linked records too.

Give four responsibilities a name

In a small organisation, one person may perform several roles. The dangerous arrangement is everyone assuming somebody else owns the decision. Record a primary contact, deputy and way to reach each role independently of the affected website’s email.

Commercial approval cannot make an untested technical requirement pass. Where roles disagree, record the specific question and escalate it. Possible customer-data or payment exposure needs the organisation’s relevant specialists and procedures; this planning document does not determine notification obligations.

Prepare access without adding another backdoor

Check that the owner can establish authority with the hosting provider and recover the relevant control channels. Record the route to use if the administrator mailbox is compromised too. Sending another reset link to that same mailbox does not resolve the dependency.

Define individual, limited responder access, how it is authorised and when it is revoked. Avoid leaving a shared administrator account “just in case” or storing passwords in the plan. The safe recovery guide for a locked-out WordPress administrator covers the technical access path.

Rehearse finding the contact and ownership records with the site owner. A name in an inventory does not prove that the person will answer, still has access or remains authorised. Finding that out in a preparation exercise is considerably more useful than discovering it during an outage.

Backups: identify what you would recover and lose

A useful backup record has a date, contents, location and test status. “We have backups” leaves too much unanswered. Establish whether files and database are included, who can obtain them and where restoration can be tested without overwriting the incident’s only surviving evidence.

The tolerable data-loss target is often described as the recovery point objective, or RPO. The service-recovery time target is the recovery time objective, or RTO. These are business targets, not achievements created by adding acronyms. If a rehearsal misses the target, record the gap and decide what change or investment is needed.

For a shop, compare the backup’s timestamp with later orders, payments and stock activity. For a lead-generation site, consider form entries and CRM records. Preserve the sources before choosing a restoration. Restoring without bringing the intrusion back requires evaluating code, access and data alongside availability.

A visual reference for organising decisions

The useful principle is connecting each incident to an owner and a status. A plain document can do that: “contained”, “awaiting verification” and “approved to reopen” need different meanings. A pleasing progress bar cannot stand in for a missing check.

Original tabletop exercise: the host offers yesterday’s backup

This scenario is fictional. It is a tabletop exercise designed for this template, without performing a compromise, restoration, purchase or charge. It is not a customer case or a recovery-time measurement. Present six cards in sequence and ask the team to record a decision before revealing the next one.

The scenario: a WordPress shop receives a redirect report. Hosting offers yesterday’s backup, the administrator cannot sign in, and payments exist after that backup. The question is not who can find the restore button first. It is what needs to be established before an intervention can be authorised.

1. Report with unconfirmed scope. Coordination records the symptom, time and source; technical staff propose containment appropriate to the risk. Scope remains unresolved. A disappearing redirect does not turn the incident into “clean”.
2. Backup available. Technical staff identify its timestamp, components and protected location. They request preservation of the current state and logs before overwriting anything. Availability alone does not establish a trustworthy recovery point.
3. Questionable recovery mailbox. The owner activates the alternative provider contact route. The record names who verifies ownership. Recovering a WordPress session does not yet close the access chain.
4. Later payments exist. Business staff identify the reconciliation window and owner. They do not repeat charges or force order statuses. Recovering recent data becomes an explicit condition linked to a protected evidence record.
5. The site loads again. Technical staff deliver checks and their limitations; business staff verify the agreed journeys. Incomplete tests keep that status. A visible homepage does not automatically authorise trading.
6. The symptom returns. Apply the approved containment alternative and preserve the observation. The plan does not send visitors back to an infected document root as a supposed rollback. Coordination reopens the incident and assigns the next investigation.

Afterwards, identify which decisions depended on an absent person or information nobody could produce. Those gaps are the exercise’s outputs: specific owned actions. If you want duration measurements, record them during your actual rehearsal with its conditions; this worked scenario supplies no observed recovery duration.

Turn the rehearsal into three actions you can actually close

In the scenario above, “improve backups” would be a rather comfortable conclusion. Turn each gap into an action with a checkable output. These three remain proposals within the fictional exercise, not completed work on a real shop.

• REC-01: alternative contact. The owner locates the hosting provider’s authority-verification procedure and establishes who can use it. Proposed closure: a procedure reference, confirmed primary contact and deputy. Do not copy identity documents into the recovery plan to make the field look complete.
• REC-02: isolated restoration. Technical staff propose an environment without public exposure or accidental messages, charges or synchronisation. Proposed closure: a rehearsed restoration with identified components, recorded outcome and documented limitations. Booking a date for the test is useful progress; it is not yet a passing result.
• REC-03: later business records. Business staff identify payment and order sources for the unresolved window. Proposed closure: an owner, authorised sources, reconciliation criteria and an agreed test. A sales total cannot replace the relationship between individual payments and the operations they represent.

Prioritise by the blocker each action removes and the people depending on it. If REC-01 prevents obtaining the backup, completing a handsome REC-03 document does not make recovery ready. The useful output is a clear distinction between what the team can execute and what still depends on missing information or authority.

Make reopening conditions reviewable

Prepare a list with four possible states: passed, failed, incomplete and not applicable with a reason. Every requirement needs an owner, evidence and date. Approval should refer to a particular recovered release and tested journeys, rather than an indefinite claim about “the website”.

Include account control, treatment of the entry route, software provenance, data review and the original reported symptom. Add affected business functions and what happens if the problem returns. Use the recovery completion evidence guide to develop the technical matrix and confirm its scope with the responder.

Returning to production and closing the incident are separate decisions. Authorised follow-up may remain, with an owner and deadline. Security blockers or uncertainty about paid orders require explicit resolution before the affected journey can be described as recovered. Do not hide them in a generic maintenance backlog.

What to ask a recovery provider

Request an initial written scope covering systems, preservation, required access, deliverables and conditions for extending the work. Distinguish initial response, diagnosis and verified recovery. They are different milestones and should be discussed separately in both the proposal and the delivery record.

Ask who coordinates with hosting, how recent business data will be handled and what evidence will be delivered. Confirm exclusions: email, server infrastructure, integrations and related domains may require another specialist or authorisation. A generic promise to clean malware does not answer those operational dependencies.

To prepare an emergency hacked-site recovery assessment, send the domain, symptoms, a short timeline, hosting provider and affected functions. State whether a backup exists and its date. Do not attach customer databases, infected archives or credentials to a public form. Managed access is agreed through an appropriate channel.

Keep the 2027 edition useful

Review the card when hosting, staff, payment provider, backup tooling or deployment changes. The year identifies this planning edition; it does not make a procedure suitable for every installation. Technical instructions still need checking against the versions and providers actually in use.

Store rehearsal findings with the plan: gap, corrective action, owner, intended date and evidence of resolution. Repeat the affected part after fixing it. Updating a document’s date without rehearsing its assumptions still leaves you with an untested document.

For background, consult the WordPress compromised-site documentation and backup guidance. The card and exercise here are our editorial tools for organising decisions, not WordPress certification or a forensic report.