What a Proper Cleanup Report Should Contain

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

The invoice is paid, the site is back, and what you have to show for it is a message saying the malware has been removed and the site is now clean. That is not a report, it is a receipt. A proper report tells you what was wrong, what was done, how it happened and what to do next — and you need those details for reasons that go well beyond curiosity.

Why the detail matters

Three practical reasons, none of them academic. You may need to tell Google what happened in a reconsideration request, and a specific account is what gets those accepted. You may need to tell your host what was found in order to lift a suspension. And you may need to decide whether customer data was exposed, which is a legal question you cannot answer from a reassurance.

There is a fourth reason: it is how you judge whether the work was done. A report full of specifics can be checked. One that says the site was scanned and cleaned cannot be distinguished from someone who ran a plugin and did nothing else.

What was found

The report should list what was actually discovered: specific file paths, what each file did, injected code and where it lived, database rows or tables affected, unauthorized user accounts with the names and dates they were created, scheduled tasks, and any changes to server configuration.

Detail matters because it is verifiable. If a report says a backdoor was found at a named path in the uploads directory and it recreated an administrator account, you can understand what happened. If it says malware was removed, you have learned nothing and cannot check anything.

How it happened

The entry point, or an honest statement that it could not be determined and why. A named vulnerable plugin with a version number. Credentials compromised. Another site on the same hosting account. Access through a stolen session. Whatever the evidence supports.

Sometimes the evidence genuinely does not support a conclusion — logs rotated away, or the compromise predates retention. Saying so plainly is a perfectly good answer and much better than a guess presented as a finding. What is not acceptable is silence, because without the entry point you cannot close it, and the site gets hit again.

What was done about it

The actions taken, specifically. Which files were removed or replaced. Whether core, plugins and themes were reinstalled from clean sources or repaired in place. What database cleanup was performed. Which accounts were deleted. Which credentials were rotated, and which ones you still need to rotate yourself.

That last distinction matters a great deal. Some credentials only you can change — your registrar, your email provider, your payment processor keys — and the report should tell you clearly which ones are your responsibility, so they do not simply get missed. My guide on rotating credentials covers the full list.

The timeline and exposure

When the compromise began, as far as the evidence shows, and how long it ran. That comes from file timestamps and log analysis, covered in my guides on timestamp forensics and reading access logs.

Then what that window means: whether the database was reachable, whether customer records or payment data were in scope, and whether there is evidence of data being accessed as opposed to merely being accessible. That assessment is what you need to decide about notification obligations, and an honest report distinguishes clearly between what is evidenced and what is assumed.

What happens next

Concrete recommendations rather than generic advice — the specific plugin to replace, the specific setting to change, the specific account to close. Plus verification: what checks were run to confirm the site is clean, and how you can check it yourself.

And the terms: how long reinfection from the same cause is covered, and what to do if something looks wrong next week. If what you received was a message saying the site is clean now, it is entirely reasonable to go back and ask for the details in this guide — and if you are choosing who to use in the first place, my guide on red flags when hiring covers the questions to ask before you pay. This is the standard I hold my own malware removal service to.

Common questions

What should I do if I only got a one-line confirmation?

Ask for the detail. Request the specific files found, the entry point, what was changed, and the estimated timeline of the compromise. A competent provider has that information from doing the work and can supply it. Reluctance to produce it is informative in itself.

Why do I need to know how the site was hacked?

Because you cannot close an entry point nobody identified, and an unclosed entry point means it happens again. It is also what Google and your host will effectively ask for — a reconsideration request or a suspension appeal that cannot say how it happened is much weaker.

Is it acceptable for a report to say the entry point is unknown?

Yes, if it explains why — logs rotated away, or the compromise predating available retention, are legitimate reasons. An honest unknown is far better than an invented cause. What is not acceptable is not addressing the question at all.

Should the report tell me about customer data?

It should address whether data was reachable and whether there is evidence it was accessed, keeping those two things clearly separate. That distinction drives your notification decisions, and it is not something you should have to infer from a technical list of files.

What credentials will I still need to change myself?

Anything the provider has no access to: your domain registrar, your email provider, payment processor keys, and any third-party service accounts. A good report lists these explicitly as your responsibility, because they are the ones most likely to be overlooked entirely.