A triage workflow for Wordfence alerts

Four questions that classify any finding

Every Wordfence finding answers to the same four questions, and the answers order the queue:

• Is this evidence of compromise? A hash-matched malicious file, an administrator created outside WordPress, malware in the database. These are not risks — they are things that already happened.
• Is this active exposure? A readable wp-config, a public database dump, a vulnerable plugin with a published exploit. Nothing has happened yet that you know of, but the door is open now.
• Is this standing risk? An abandoned plugin, a firewall in learning mode, a weak password on a low-privilege account. It gets worse with time, not with hours.
• Is this operational noise? A scan that hit its time limit, low disk space, GeoIP unavailable. It degrades your visibility rather than the site's security.

The order of work, by category

Wordfence's numeric severity mostly encodes the same logic, but category order is easier to hold in your head under pressure. Work them in this order: Malware first — any hash-matched file or database injection outranks everything, because every minute it stays is a minute of visitor exposure and evidence decay. Login findings second — an unexplained administrator account is compromise wearing a uniform, and a breached admin password is one login away from it. Public files third — exposed credentials are a compromise scheduled for later; rotate what was exposed, not just the file's visibility. Vulnerabilities fourth — patch the ones with published exploits today and batch the rest. File changes fifth — usually explainable, occasionally the malware finding's quieter sibling; read the diff before deciding which. Firewall and operational findings last — they are about your defences and your visibility, urgent only in aggregate.

Within a category, prefer the finding on the more exposed site: the shop taking payments outranks the brochure site, whatever the numeric severities say. Severity scores describe findings; only you know the sites.

When a finding stops being a fix

Most findings are fixes: update the plugin, delete the file, change the password, close the exposure. But some findings are evidence, and evidence means the job is investigation, not repair. The tells: a hash-matched known-malicious file; an admin account nobody created; malware findings recurring after removal; modifications to core files that add code rather than merely differing in whitespace.

At that point the checklist inverts. Do not clean first — record first: note filenames, timestamps and account names before deleting anything, because the cleanup destroys the timeline. Then contain (rotate credentials and salts, which invalidates stolen session cookies), then restore from known-clean sources, then find the entry point — a cleanup that skips the last step is scheduled to repeat. The individual glossary entries cover each finding's version of this in detail.

Record the decisions, not just the fixes

Half of triage output is decisions to not act: the abandoned plugin the client insists on keeping, the modified theme file that turned out to be a developer's deliberate patch, the medium finding accepted until the quarterly maintenance window. Record these where the next person will see them — Wordfence's own ignore function is the right tool, because it keeps the finding from re-surfacing as new in every scan.

An unrecorded decision is re-made from scratch at every scan, by whoever is on rotation, with less context each time. Fleets drown less in findings than in re-triaging the same findings weekly.

Make the queue finite

Triage only works against a queue that can reach zero. That means dispositioning everything: fixed, scheduled, accepted-and-recorded, or escalated to incident response. A queue where mediums accumulate indefinitely becomes a queue nobody reads, which becomes an inbox again.

This is also the honest pitch for working from one cross-site queue — whether that is WPSecureOps or anything else that aggregates: a per-site scan report cannot tell you that the same vulnerable plugin is on nine of your sites, and nine one-line fixes batched as one job is the difference between an afternoon and a fortnight of drift.

Common questions

Should I trust Wordfence's severity number as the work order?

As a first sort, yes — it correlates well with real urgency. But it scores findings in isolation: it cannot know that a medium on your commerce site matters more than a high on a parked brochure site, or that three unrelated mediums on one site tell a story severity math misses. Sort by the number, then override it with what you know about the sites.

How long should triage take?

Minutes, daily — the sorting itself, not the fixing. If the daily pass regularly takes more than fifteen minutes, the problem is upstream: too much noise reaching the queue (fix the alert thresholds), or decisions not being recorded so the same findings are re-triaged repeatedly (fix that with Wordfence's ignore-with-a-reason and a log).

What do I do when I genuinely cannot tell if a finding is a compromise?

Treat ambiguity asymmetrically: the cost of over-reacting to a false alarm is an hour; the cost of under-reacting to a real one is an incident. Isolate what you can cheaply (rotate the credentials, take the suspect file out of the web root rather than deleting it), and get a second pair of eyes on the evidence. Uncertainty plus admin-level findings is a reason to slow down, never to skim past.

Referenced in this guide

• A known malicious file was found Malware
• An administrator was created outside WordPress Login
• A file appears to be malicious Malware
• Wordfence alert explainer Free tool

The other guides

• How to manage Wordfence across 10, 20 or 50 client sites
• Too many Wordfence emails: what to turn off, and what must stay