The first month should test whether the site remains trusted through normal cron, traffic, updates and business cycles. Monitoring every request is noisy; focus on privileged change, executable persistence, outbound abuse and business mismatches.
Assign owners and independent alert routes before day one.
Day 0: preserve the recovery baseline
Record clean release, file/config hashes, component versions/sources, approved users/tokens, cron, DNS/CDN/tag manager and rotated-secret matrix. Store outside the web account.
Keep incident evidence separate and infected roots non-executable. Document unresolved low-risk items and rapid containment procedure.
Run full login/forms/checkout/mail/backups acceptance tests.
Days 1–3: watch high-risk recurrence
Alert on administrator/role/application-password creation, executable/config file changes, new cron/actions, unknown outbound domains/mail and original indicators.
Review hosting/SSH/SFTP/deployment and WordPress audit events daily. Check that logs/alerts still operate and do not contain secrets/customer bodies.
Investigate recurrence immediately rather than deleting it repeatedly.
Triage alerts every day
For each alert, record severity, evidence, owner, containment decision and resolution. Prioritise privileged users, executable/config changes, payment/checkout and outbound abuse.
Do not close recurring events as noise until a legitimate source is proven. Tune only specific expected paths/actions with review dates.
Check that independent log ingestion and alerts themselves remain healthy.
Days 1–7: reconcile business systems
Compare form entries with lead intake, WooCommerce orders with payment/stock/fulfilment, password resets and transactional mail. Review failed scheduled actions/webhooks.
Check customer reports, bounce/suppression and checkout conversion for unusual drops. Use counts/IDs, not full customer exports.
Resolve incident-window exceptions.
End of week 1: verify access inventory
Review WordPress, hosting, database, email, registrar/CDN, tag manager, payment, backup and source-control users/tokens. Remove temporary responders and obsolete integration access.
Confirm MFA and owner recovery routes. Test old credentials/tokens are revoked through their authorised platform—not by publishing them.
Check old staging/sibling sites.
Week 2: test recurring jobs and backups
Confirm WP-Cron/Action Scheduler/server cron completes normal cycles without unknown tasks or backlog. Verify backup creation and isolated restoration of the clean build.
Review deployment repositories/automation so abandoned vulnerable code or bypass users cannot return.
Test certificate renewal and scheduled reports where relevant.
Week 2: review search and reputation
Check Safe Browsing/Search Console security issues, manual actions, hacked URL recrawl and unknown owners/sitemaps. Review outbound mail reputation/blocklist/provider alerts if spam occurred.
Verify public URL status/canonical/sitemap. Search snippets can lag; live malicious behaviour cannot.
Record review requests and results.
Week 3: apply controlled updates
Review security releases and update through protected staging, tested backup and rollback. Replace abandoned dependencies rather than delaying indefinitely.
Run security and business regression tests after each group. Monitor file/user/cron changes during deployment.
Do not use the incident as justification to freeze all updates.
Week 4: repeat the full acceptance matrix
Re-run original referrer/mobile/first-visit conditions, login/reset, forms, checkout sandbox, webhooks, orders, mail, uploads, cron and analytics.
Compare current baseline with Day 0 and explain every retained difference. Verify no temporary allow rules/debug logs remain.
Get business owner sign-off on reconciliation.
Report trends, not raw volume
Summarise new privileged changes, unexplained file/database differences, failed cron/webhooks, mail/payment anomalies, security/search status and business reconciliation.
Compare against Day 0/week snapshots and explain every retained difference. Avoid filling reports with routine cache files or customer bodies.
Use the evidence to set the long-term cadence and response thresholds.
Day 30: transition deliberately
Classify open risks, monitoring that remains valuable and the normal maintenance schedule. Keep urgent alerts for privileged/executable changes and reduce only proven noise.
Retain incident evidence under policy and dispose of unnecessary working copies. Document owners and next review date.
Request recurring post-hack monitoring when one person cannot cover all control planes. Share the monitoring matrix and redacted alerts—never credentials, payloads or customer records publicly.