Most guides stop at “malware removed.” But a breach is not over when the files are clean — it is over when you know what was exposed, the people affected know, the browsers trust you again, and the same door cannot be reopened. That is the second half of the job.
1. Assess what was actually reachable
Use the evidence backup from the cleanup to work out scope. When did the compromise start (file timestamps, log entries)? What could that access reach — the user table, order history, form submissions? A defaced homepage and six months of silent database access are very different incidents, and everything that follows depends on which one you had.
2. Meet your notification obligations
If personal data was exposed and GDPR or similar law applies to your users, there may be a legal clock running for notifying a supervisory authority and, in serious cases, the affected people. This is a legal question, not a technical one — get proper advice rather than deciding by gut. Whatever the law requires, forcing a password reset for all users after any user-table exposure is simply the decent minimum.
3. Repair your standing with Google and browsers
If the site was flagged — “This site may be hacked” in results, or a red browser warning — the flag does not lift on its own. In Search Console, use the Security Issues report to request a review once the site is genuinely clean. Reviews are usually processed within days; requesting one while remnants remain restarts the clock, so scan thoroughly first.
4. Prevent round two
Reinfection within days is common, because the original lesson goes unlearned. Hold a short post-mortem: how they got in, what let it go unnoticed, which of the two you are fixing this week. Then schedule the boring controls — updates, monitoring, tested backups — that would have made this a non-event. If nobody owns that schedule, that is what ongoing maintenance is for.