Classify the current situation first. Then record the control, proof, responsible party, corrective action, due date, and retest across the site, hosting, accounts, recovery, and incident response.
| Situation | Examples | Immediate decision | Do not conclude |
|---|---|---|---|
| Routine review | Supplier comparison, insurance question, planned audit | Build and verify the evidence register | A clean public scan proves the site is secure |
| Control gap | Unsupported extension, unknown backup, missing MFA, unclear owner | Assign corrective work, due date, and retest | A gap proves compromise |
| Suspicious signal | New admin, redirect, file change, spam, unexpected scheduled task | Preserve evidence and escalate before broad cleanup | Deleting the visible symptom removes the cause |
| Confirmed incident | Host or qualified responder confirms compromise | Use the incident, privacy/legal, and communication processes | This checklist can declare the site clean |
| Control area | Record | Evidence | Decision when incomplete |
|---|---|---|---|
| 1. Inventory and support | Core, PHP, themes, plugins, custom code, integrations, support state | Dated inventory, source, version, responsible party | Remove, replace, update, isolate, or accept exception |
| 2. Accounts and recovery | WordPress, hosting, DNS, database, repository, service users | Individual users, roles, capabilities, MFA, recovery test, former-user review | Restrict, recover, replace shared access, or revoke |
| 3. Change and patching | Advisory, affected version, exposure, decision, release path | Test, approval, rollback, production verification | Mitigate, patch, isolate, or document deferral |
| 4. Hosting and hardening | Supported stack, HTTPS, encrypted administration, permissions, secrets, environments | Host configuration, access test, current support versions | Correct configuration or assign provider action |
| 5. Extension and code trust | Need, source, maintainer, licence, update state, custom-code path | Repository or vendor source, support date, review result | Remove, replace, review, or document exception |
| 6. Backup and recovery | Files, database, independent copy, retention, dependencies | Last successful restore, result, duration, missing data | Fix coverage and repeat the restore test |
| 7. Monitoring and logs | Uptime, authentication, file changes, application/server events | Recipient, retention, alert test, response record | Route, retain, tune, or replace the control |
| 8. Incident readiness | Contacts, containment authority, evidence, privacy/legal, communication, return to service | Current runbook and completed exercise or incident record | Assign decisions and test the handoff |
| Evidence request | Host or platform | Maintenance supplier | Company |
|---|---|---|---|
| Current inventory | Runtime and platform versions | WordPress, extensions, custom code, integrations | Business owner and accepted dependencies |
| Access control | Panel, server, database, recovery | WordPress, repository, deployment, service accounts | Approvers, former users, MFA and recovery contacts |
| Change record | Host-managed updates and infrastructure changes | Advisory decision, test, release, rollback, verification | Risk acceptance and change window |
| Recovery | Snapshot or backup service and restore mechanics | Application recovery test and validation | Recovery objective and return-to-service approval |
| Monitoring and response | Infrastructure signals and escalation | Application alerts, triage, maintenance or incident boundary | Recipients, privacy/legal, customer communication |
| Transfer and exit | Account, configuration, logs, and export process | Runbooks, inventory, code, open risks, credentials | Company accounts and acceptance record |
Record the production site, business-critical journeys, data involved, current suppliers, and why the review is happening. State whether active compromise is suspected.
Gather the inventory, user and role lists, update state, hosting facts, backup records, restore evidence, alerts, logs, and current incident contacts.
Record what is verified, what is missing, and which signal needs investigation. A version finding or scanner warning does not by itself prove exploitation.
Give each accepted gap a responsible party, action, due date, release or escalation path, and retest. Close it only when the agreed evidence exists.
Send us where your site stands today. We reply with the risks that carry real exposure, not a generic checklist.
Use security patching explained for one vulnerability: intake, exposure, decision, testing, release, rollback, and verification. Emergency mitigation may use a different path when the responsible operator records the risk.
Use the WordPress maintenance plans for recurring updates, backups, monitoring, support, and response terms. Ask the supplier to attach the evidence above to the service it sells.
No public checklist can certify a whole installation as secure. WordPress guidance treats security as risk reduction. Review the actual site, host, extensions, accounts, code, recovery, monitoring, and response boundary, then record verified controls and open risk.
A plugin can provide a specific control such as authentication, scanning, logging, or application-level filtering. It cannot prove host configuration, account recovery, source trust, backup restoration, incident readiness, or correct response. Record its scope and test its output.
Use the affected version, exposure, exploit information, business impact, available mitigation, test path, and rollback to make the decision. WordPress recommends keeping core, themes, and plugins current, but the release path and urgency are site-specific.
A successful restore into an isolated environment, followed by checks of files, database, media, users, pages, forms, and required integrations. A green backup job proves that a job ran; it does not prove complete recovery.
Record the symptoms and time, preserve available logs and recent-change evidence, contact the host and incident owner, and use qualified help for containment and recovery. Escalate possible personal-data impact to the company privacy or legal decision-maker.
WordPress documents hardening and layered risk reduction, the security foundation, updates and backups, roles and capabilities, and two-step authentication.
The German BSI publishes a protection-needs-based method for an information-security web check. Scope and evidence matter more than a universal scanner score.
Written by
Vineet Talwar
Co-founder, Tech & Operations at Some Tech Work. WordCamp speaker across Europe and Asia, and host of the WP Shoutout podcast.
Tell us what needs fixing
We read every brief and reply within one business day.
Prefer to talk first?or request a tech stack audit →or email us directly →
Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.
