Recovery is not complete because the homepage loads or a scanner reports no malware. The claim requires evidence that malicious behaviour stopped, code/data are trusted, access was recovered, the entry path is closed and business functions work.
Use a written acceptance record with owners and remaining uncertainty.
Prove containment
Record when public redirects, phishing, spam, checkout risk or unauthorised access stopped and which controls enforced it. Confirm infected roots are non-executable and unknown sessions/tokens are revoked.
Containment is a prerequisite, not proof of cleanup. Keep rollback and rapid suspension paths through reopening.
Reconcile the incident window.
Prove software provenance
List WordPress core, plugins, themes and custom code with version/source/owner. Verify maintained packages against trusted releases and custom code against reviewed repositories.
Document removed abandoned components and replaced functionality. Unknown code must not enter production without ownership.
Retain comparison/checksum evidence without malicious payloads.
Prove database and upload integrity
Review administrators, roles/application passwords, options, cron, snippets, redirects, posts/templates and relevant custom tables. Validate media and prevent executable content where appropriate.
Record exact malicious rows/files removed and row-level rollback. Avoid claiming the whole database clean from one keyword scan.
Protect customer/order/form data in reports.
Prove the entry point is closed
State confirmed/likely vector, evidence, confidence and alternative explanations. Record patched/removed components, access rotations and architecture changes that close every plausible high-impact route.
If the vector is undetermined, document broader controls and monitoring rather than pretending certainty.
Check sibling sites and staging copies.
Prove control-plane security
Confirm approved WordPress/hosting/SSH-SFTP/database/email/DNS-CDN/source/payment users and tokens. Record MFA, session revocation and secret rotations without storing new values.
Review backups/deployment so old malware or bypass accounts cannot return. Remove all temporary responder access.
Use individual least-privilege accounts.
Build a requirement-to-evidence matrix
List every incident requirement—malicious redirect gone, unknown user removed, vulnerable component replaced, queue reconciled—and link it to an authoritative check, owner and date.
Mark evidence as pass, fail, incomplete or unavailable. A scanner, host review or one clean page cannot substitute for requirements it did not test.
Retain redacted identifiers so another authorised reviewer can reproduce the result.
Prove business integrity
Test login/reset, forms, WooCommerce checkout sandbox, payment/webhooks, orders/stock/refunds, cron, transactional mail, uploads, mobile/languages and analytics.
Reconcile paid orders, leads and users across backup/incident/cutover windows. One authoritative owner should approve exceptions.
Do not use real card data or uncontrolled test leads.
Test original and recurrence conditions
Reproduce search-referrer/mobile/first-visit conditions, cron cycles, cache warm-up and administrator login that previously triggered symptoms.
Monitor file/database/account changes during the test. Confirm no known indicator or unknown outbound domain returns.
Run tests from public DNS after cutover, not only a hosts mapping.
Confirm backups and deployments are clean
Run a fresh protected backup of the recovered site and test its restoration in isolation. Remove infected packages/bypass code from deployment repositories and automation.
Verify the next scheduled deployment cannot overwrite new secrets or restore abandoned components. Record the clean release identifier and backup timestamp.
Keep incident evidence separate from operational backups.
Record external verification
Capture hosting review, mail/provider recovery, payment-provider status and Search Console security/manual-action state where relevant. External approval is supporting evidence, not a replacement for internal testing.
Record dates, ticket/message IDs and scope without credentials or customer data.
Check that alerts use an independent channel.
Obtain independent review where warranted
Payment-page compromise, possible customer-data access, root/server changes or repeated reinfection justify a second qualified review. Provide the evidence matrix, not only the cleaner’s summary.
Resolve disagreements explicitly and document authorised risk acceptance. Independence is most valuable where the original responder designed both the fix and its test.
Define post-release monitoring
Set owners and thresholds for privileged-account creation, file/database changes, cron backlog, outbound mail/traffic and original indicators. Review after meaningful intervals.
Document remaining risks and the date they will be reassessed. Recovery can be complete with known low residual risk only when that risk is explicit and accepted.
Request an independent recovery review for payment/customer-data incidents or repeated reinfection. Share the evidence matrix and managed access—never full archives, secrets or customer databases publicly.