Preserving Evidence Before You Start Cleaning

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

You have found something horrible and every instinct says delete it right now. I understand the impulse and I have felt it myself. But the evidence you are about to destroy is the only thing that can tell you how they got in, how long they were there, and what they could reach — and once it is gone, those questions become permanently unanswerable.

Why this matters more than speed

A cleanup without evidence is guesswork. You can remove every malicious file you find and still have no idea which plugin let them in, which means you cannot close the door and the site gets hit again. That is the single most common reason people end up paying for a second cleanup.

It also determines what you owe other people. Whether customer data was reachable, and for how long, is a question with legal and commercial consequences, and the only way to answer it is with logs and timestamps you still have. Deleting first and asking later leaves you unable to say anything definite, which is a bad position to be in.

What to preserve

Four things, and none of them take long. A complete copy of the site files exactly as they are now, malware included — not a cleaned copy, the infected one. A database dump, taken before you change anything. Every access and error log you can get, including archives, since these rotate away on a schedule that does not care about your situation. And a written note of what you found and when you found it.

Add screenshots of anything visual: the defacement, the browser warning, the Search Console report, the suspicious user list, the email from your host. These become the record of what actually happened, and they are the details that get fuzzy within days.

How to do it quickly

Compress the whole site directory into a single archive and download it. Export the database through your control panel or with a command-line dump. Download the logs. Put all three somewhere off the server — local disk plus a cloud copy is sensible, since a hosting account that is about to be suspended is not a safe place to store your only evidence.

Fifteen minutes, realistically, on a typical site. Label the archive with the date and something like pre-cleanup so that future-you knows exactly what it is. If the site is actively serving malware to visitors, take it into maintenance mode first and then preserve — stopping the harm and preserving the evidence are not in conflict, they are just in that order.

Handling it safely afterwards

That archive contains live malware, so treat it accordingly. Do not extract it onto a production server, do not upload it to another hosting account, and do not restore it anywhere by accident — a mislabelled infected backup restored six months later is a genuinely common way sites get reinfected.

Keep it somewhere clearly marked, and if you examine the contents, do it locally with an editor rather than by executing anything. My guide on reading obfuscated code covers inspecting malicious files without running them.

Actually using what you kept

The evidence earns its keep at three moments. During the cleanup, file timestamps in the preserved copy let you establish when things appeared, which is covered in my guide on timestamp forensics, and the logs let you trace the entry point, which is covered in reading access logs.

After the cleanup, it lets you verify: comparing the infected copy against the cleaned site confirms you removed everything you found. And if you need to explain the incident — to your host to lift a suspension, to Google in a reconsideration request, or to customers — specific facts drawn from evidence are far more effective than general assurances.

When you need more than this

For most small business sites, the preservation described here is proportionate and sufficient. If the site handled payment card data, health records or a substantial volume of personal data, the bar is higher: there may be obligations about how evidence is handled, and touching things yourself can complicate a formal investigation.

In that situation, preserve what you can without altering the system further and get professional advice before cleaning. My guides on breach notification obligations and PCI compliance after a skimmer cover when that threshold is crossed, and my malware removal service handles the technical work with the evidence kept intact.

Common questions

Why not just delete the malware immediately?

Because the malware is your evidence. Deleting it removes your ability to determine how they got in, which means you cannot close the entry point, which means it happens again. Ten to fifteen minutes of copying preserves answers you cannot reconstruct afterwards at any price.

What exactly should I save?

A full copy of the site files in their current infected state, a database dump taken before any changes, all available access and error logs including archives, and screenshots of anything visual such as warnings or defacements. Store all of it off the server.

Is it safe to keep a copy of infected files?

Yes, provided you handle it sensibly. The files are inert while they sit in an archive — PHP only does anything when a web server executes it. Keep it clearly labelled, keep it off production servers, and never restore it by accident. That last point is the real risk.

How long should I keep the evidence?

At least until the site has been clean and stable for a few months, since that is when you would discover a missed backdoor and want to compare. If there is any prospect of a dispute, an insurance claim or a regulatory question, keep it considerably longer.

What if my site is actively serving malware right now?

Take it into maintenance mode first, then preserve. Stopping harm to visitors takes priority, but going offline does not destroy any evidence — the files, database and logs are all still there. It is deleting things that destroys evidence, not pausing the site.