What to Decide Before Your WordPress Site Gets Hacked, Not After

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

Most WordPress site owners have a plan for what happens if their site gets hacked. It’s called panic, followed by a frantic search for “how to recover a hacked WordPress site” at whatever hour the red warning screen shows up. A real incident response plan is the thing you write while nothing is wrong, so that the worst hour of a bad week is spent executing decisions instead of making them.

In my experience, the sites that come back from a breach fastest are rarely the ones with the most expensive security plugin. They’re the ones where someone already knew who had admin access, where the last known-good backup lived, and what their host would actually do if they called at 2am. Everything else, malware removal included, is just execution once those questions are already answered.

What Actually Belongs in a WordPress Incident Response Plan

Stripped down to what a small site or agency actually needs, a WordPress security incident response plan answers five questions in advance: who is allowed to take the site offline the moment something looks wrong, where the last verified-clean backup lives and how old it’s allowed to get before that’s a problem, what your host’s own incident-support process actually covers, what gets preserved as evidence before any cleanup starts, and whether a breach involving customer data triggers a legal notification requirement (GDPR’s 72-hour clock is real; several other jurisdictions have their own). Everything below expands on each of those, but if you write down answers to just those five, you already have a functioning plan.

A Cleanup Guide Is Not a Plan

Veravix already has a guide for recovering a WordPress website after a security breach, and it’s genuinely useful once you’re in the middle of one: isolate the site, assess scope, restore or clean, rotate credentials, patch the hole, request a review. What that guide can’t do is make those steps fast, because every one of them depends on information you either have ready or have to go find while the site is actively compromised. Knowing the recovery sequence and having already decided who executes it, from where, using which backup, are two different levels of preparedness. A plan is the second one.

The Framework This Is Actually Based On

Formal incident response planning isn’t a WordPress-specific invention. NIST’s Special Publication 800-61 has been the reference framework for incident handling since 2004, and for over a decade it described the same four-phase lifecycle: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. That four-phase version is still what most “incident response” advice you’ll find online is quietly built on, WordPress-specific or not.

Worth knowing if you look this up yourself: NIST replaced that model in April 2025 with Revision 3, its first update since 2012. The standalone four-phase lifecycle is gone, folded instead into the six functions of NIST’s Cybersecurity Framework 2.0, specifically Govern, Identify, Protect, Detect, Respond, and Recover. The practical shift for a small site owner is small (preparation and post-incident review are still the two phases everyone skips), but it explains why a lot of older incident response content, including some of what you’ll find written specifically for WordPress, describes a framework NIST itself has since moved past. The plan below maps to both versions without needing you to pick one: decide things in advance (Govern/Prepare), know what normal looks like so you can spot when it isn’t (Identify/Detect), have a documented response (Respond/Contain), and actually review what happened afterward (Recover/Post-Incident).

What to Decide and Document Before Anything Goes Wrong

The single biggest time-waster in a real incident is figuring out, live, who is even allowed to act. On a one-person site that’s trivial. On anything with a client, an agency, and a hosting relationship layered on top, it isn’t. Write down, in one place both you and anyone else with access can find quickly:

• Who has admin-level WordPress access, and who among them is authorized to take the site offline or into maintenance mode without asking permission first.
• Who owns the hosting account itself, since some actions (suspending the account, restoring from a host-level snapshot, opening a support ticket with account-holder verification) can only be done by whoever’s name is on the invoice.
• What your specific hosting plan’s incident-support process actually covers. This varies more than people assume, since some hosts offer 24/7 malware-cleanup support as part of the plan, others only offer to restore a backup and leave the rest to you. Hostinger, for example, publishes its own security and malware-removal support scope directly in its help center rather than leaving it to a support-ticket surprise, which is worth checking against whatever host you’re actually on before you need the answer.
• A single point of contact for anyone outside the technical team (a client, a business owner) so status updates don’t turn into five people independently emailing the developer mid-incident.

None of this needs to be a formal document with a cover page. A pinned note in whatever tool your team already uses is enough, as long as it’s somewhere that survives the site itself going down.

Backups Aren’t a Plan Until You’ve Tested Restoring One

A backup schedule tells you a backup exists. It doesn’t tell you the backup actually restores cleanly, that it includes the database as well as the files, or that whoever needs to run the restore during an incident knows how to do it under pressure. The plan should name a specific person who has, at some point in the last few months, actually restored a backup to a staging environment and confirmed the site came back working. If nobody on the team can say that with confidence, the backup schedule is a false sense of security, not a recovery plan.

It’s also worth deciding in advance how old a backup is allowed to be before you’d rather manually clean the live site than lose that much recent content or order history. There’s no universal right answer, but “we’ll figure it out when it happens” is the wrong one, because that’s exactly the decision people make badly under time pressure.

Preserve Evidence Before You Clean Anything

This is the step most WordPress-specific advice skips entirely, because it’s about documentation, not cleanup. Before you delete a single infected file or roll back a single database table, capture what happened: a copy of the injected code, the timestamps of the affected files, and the activity log from whatever security plugin is running. Both Wordfence and Sucuri, the two most commonly used security plugins covered in our own comparison, keep a login and file-change activity log by default, and that log is often the only record of exactly when the compromise started and which account was used, and it gets overwritten or lost if you don’t export it before you start cleaning.

Why this matters beyond curiosity: if the breach turns out to involve customer or visitor data, that evidence is what lets you actually answer “what happened and when” instead of guessing, which the next section makes considerably more important than it might otherwise sound.

If Visitor or Customer Data Was Exposed, the Clock May Already Be Running

If your site has any EU or UK visitors and a breach exposes personal data, GDPR Article 33 requires notifying the relevant supervisory authority “without undue delay and, where feasible, not later than 72 hours” after you become aware of it. That clock starts the moment you have reasonable awareness a breach likely occurred, not once you’ve finished the full technical investigation, which is exactly why the evidence-preservation step above needs to happen early rather than after the fact. Even if you conclude the breach is unlikely to pose a real risk to anyone and notification isn’t required, GDPR still requires documenting the facts, the effects, and the remedial action taken, specifically so a regulator can verify that judgment later if asked.

If your visitors are mostly US-based, there’s no single federal equivalent to GDPR’s 72-hour rule, but that doesn’t mean there’s no obligation. Every US state has its own data breach notification law, with its own definition of “personal information” and its own notification deadline, and which one applies depends on where the affected individuals live, not where your business or your server is. The practical takeaway either way: decide now whether you’d know how to check what applies, rather than discovering the question exists in the middle of an actual incident.

A Plan You Can Actually Write in an Afternoon

Put this somewhere it survives the site going down, not only inside the WordPress admin:

• Who can act: named people with admin access, and who among them can take the site offline unilaterally.
• Hosting account owner and support scope: who owns the account, and what your specific plan’s incident support actually covers versus what you’d have to handle yourself.
• Backup location and last-tested-restore date: where the current backup lives and when someone last confirmed it actually restores.
• Evidence checklist: export the security plugin’s activity log, screenshot or copy injected code, note first-observed timestamp, before any cleanup begins.
• Notification decision tree: does the site collect EU/UK personal data (GDPR 72-hour clock), US visitor data (check the relevant state law), or neither.
• Single point of contact: who gives status updates to whoever isn’t doing the technical work.
• Post-incident review date: a specific commitment to revisit what happened within a set number of days, not “eventually.”

Practical Tips

• Run through the plan once a year even if nothing has happened, the same way a fire drill works even in a building that’s never caught fire. Confirm the named people still have the access the plan assumes they have.
• Store the plan somewhere accessible if the WordPress admin itself is unreachable (a shared document outside the site, not a page inside it).
• If you manage sites for clients, keep a version of this plan per client rather than one generic copy, since who’s authorized to act and what data each site actually collects genuinely differs.

Common Mistakes

• Treating “we have backups” as equivalent to “we have a tested restore process.” Those are not the same claim.
• Writing the plan for a single-admin site when the reality involves an agency, a client, and a host, none of whom have agreed in advance on who does what.
• Deleting infected files or restoring a backup before exporting the security plugin’s activity log, which erases the only clear record of when and how the breach started.
• Assuming a GDPR-style notification obligation only applies to EU-based businesses. It applies based on whose data was exposed, not where the business is registered.
• Writing the plan once and never revisiting it, so it still names an admin who left the team two years ago.

Test It Before You Need It

The gap between a plan on paper and a plan that actually works under pressure is whether anyone has run through it. Once a year, walk through the plan as if a breach had just been detected: confirm the named contacts are current, confirm someone can actually restore the backup to staging, confirm you still know your host’s real incident-support scope. If a real breach does happen after that, our recovery guide is the next document to open. The plan’s entire job is making sure that’s the only decision left to make.