Hacked Website Recovery Verification: A Business Handover Checklist

Define the evidence needed for acceptance

Before the final test, agree the recovery scope with the business owner. List the websites, hosting accounts, databases and connected services included in the work. Record anything deliberately excluded. A statement that “the website is clean” becomes much more useful when everyone can see which assets and risks were actually assessed.

Build a handover record around decisions and evidence: incident symptoms, known or suspected entry route, reconstruction method, access changes and the tests used to support reopening. Separate verified findings from reasonable assumptions and unresolved questions. Do not convert a lack of logs into a statement that no unauthorised access occurred.

The NCSC's response and recovery guidance supports planning recovery and learning from incidents. This checklist turns that broad responsibility into reviewable website-specific questions; it is not a substitute for specialist investigation where the compromise extends beyond the agreed scope.

Verify access and executable content separately

• Confirm the organisation controls the hosting, domain, recovery-email and deployment accounts required to operate the site.
• Review privileged users, keys, tokens, application credentials and scheduled work against the approved inventory.
• Confirm unauthorised access was revoked and legitimate integrations use replacement credentials where needed.
• Record where executable code came from and how altered or unexplained files were handled.
• Review business content and relevant database settings separately from application package files.

WordPress's core checksum command compares core files against expected checksums and is designed to avoid loading WordPress during that comparison. Plugin verification has a different scope. Use trusted tools and reviewed configuration in an appropriate environment, and record unsupported or custom components that need another comparison method.

Neither comparison establishes that every customer record, upload, account or host setting is correct. Treat a clean result as evidence for the files actually checked. Where integrity cannot be established through selective cleanup, explain why a rebuild from trusted sources is the more defensible recovery route.

Test the business journeys customers depend on

Create a small test plan based on the real service rather than clicking every page without a purpose. For an enquiry site, test the form, validation, intended recipient and acknowledgement. For a store, coordinate safe test orders, tax and delivery behaviour, stock updates, payment-provider test mode and order notifications. Never use real customer card information to investigate a compromise.

1. Check the homepage and priority landing pages in a clean browser on desktop and mobile. Follow direct links as well as normal navigation.
2. Test customer inputs with synthetic information and confirm that data reaches only the intended destination.
3. Check login, logout, password reset and role restrictions where accounts exist. Make sure restored access has not unintentionally expanded permissions.
4. Run agreed scheduled processes and a normal deployment or update path, then verify that the repaired site remains unchanged in unexpected ways.
5. Record any feature intentionally disabled during recovery so staff do not mistake a temporary limitation for an unnoticed defect.

Use the same clean public behaviour for ordinary visitors and crawlers. If the incident affected redirects, forms or scripts, inspect those paths explicitly rather than relying on the visual appearance of the homepage.

Check search, mail and infrastructure dependencies

Verify representative response codes, canonical URLs, sitemap entries, public crawl rules and certificate behaviour. Check that emergency maintenance or noindex controls no longer block pages that the business intends to publish safely. Review applicable search-provider security findings and retain the status or review reference without promising an indexing outcome.

Confirm mail recipients and the authorised sending route. A successful form submission should not silently deliver enquiries to an old or unauthorised address. Where DNS or hosting settings changed, test the affected hostnames and mail workflow with the relevant provider. Keep provider confirmation distinct from tests performed by the website developer.

Record the actual hosting runtime and patch evidence supplied by the host. Application source changes cannot prove that a server's PHP workers, operating system or surrounding services are patched. If the responder cannot inspect those areas, name the verification limit and the owner responsible for closing it.

Agree reopening, observation and escalation

Imagine a hypothetical agency receiving a repaired client website with a clean scan but no record of its cron tasks or deployment access. The agency cannot confidently explain which process might change the site after handover. Completing the access inventory and exercising the deployment path makes the handover more useful than adding another unsupported security score.

Choose a monitoring period and review schedule appropriate to the incident and available telemetry. There is no universal number of quiet hours that proves a website cannot be compromised again. Monitor the behaviours related to the incident: new privileged access, unexpected files, redirect changes, mail bursts or altered script destinations.

• Name the business approver and technical owner for reopening.
• Keep restricted incident evidence and recovery material according to an agreed retention plan.
• Document outstanding work with owners and target dates.
• Define which recurrence signals require immediate restriction and escalation.
• Update the backup and maintenance runbook using what the incident revealed.

CyberXperts can help turn recovery findings into a clear website handover and a practical follow-up plan. The strongest completion statement describes the evidence and its limits, so the business understands both what has been restored and what still needs attention.