When a website gets compromised, the instinct is to fix it immediately – patch the plugin, delete the malicious file, restore from a backup, and move on. That instinct is exactly what destroys the evidence needed to understand what happened, notify the right people, and stop it from happening again. Preserving evidence after a compromise is a distinct discipline from incident cleanup, and the two need to happen in a specific order or the evidence is gone within minutes.
This matters more than most site owners realize. Under GDPR, a breach involving personal data has to be reported to the supervisory authority within 72 hours of becoming aware of it – and that report needs specifics: what was accessed, how many records, what the attacker did. Without preserved evidence, that 72-hour clock runs out with nothing but guesswork to submit. Cyber insurance claims work the same way; most policies require a forensic timeline, and insurers routinely deny claims where the insured wiped logs or reimaged servers before an investigator looked at them.
What “evidence” actually means on a compromised website
Evidence isn’t just the malicious file itself. On a typical WordPress or Laravel stack, useful evidence includes web server access logs (Apache, Nginx), PHP error logs, database query logs if enabled, file modification timestamps, the malicious files and any webshells found, admin panel login history, and outbound connection logs from the host’s firewall if available. Cloud hosts like Cloudways, Kinsta, or a raw DigitalOcean droplet retain these logs for wildly different periods – some rotate access logs after 7 days, some keep 30. Check retention settings before an incident, not during one.
A common mistake: assuming the hosting provider automatically preserves this data during an incident. Most shared and managed hosts do not. Kinsta and WP Engine will preserve snapshots if you open a support ticket and explicitly ask, but the default behavior on most budget hosting is log rotation on a fixed schedule regardless of what’s happening on the account.
The order of operations that protects both evidence and the business
The sequence matters more than any individual step.
First, isolate without deleting. Take the site offline via maintenance mode or a firewall rule, not by deleting the compromised files. If the site runs on a VPS, a full disk snapshot at this point is worth more than any manual log review – it captures file timestamps, memory state where possible, and everything in one shot before anything changes.
Second, copy before you touch anything. Pull a complete copy of the web root, the database, and all available logs to a separate, isolated location – not back into the same server, not into the same cloud account if avoidable. rsync or a host-level snapshot both work. The goal is a frozen point-in-time copy that survives whatever cleanup happens next.
Third, document what you observe before you remediate. Screenshot defaced pages, note the exact URLs serving malicious redirects, record the timestamp you first noticed the issue, and log every admin action taken from that point forward with a timestamp. An incident without a timeline is an incident nobody can reconstruct six months later when a customer asks what happened to their data.
Fourth, only then remediate – remove the malware, rotate every credential (database, admin, API keys, SSH keys, FTP), and patch the entry point. Cleanup that happens before steps one through three means the forensic trail is gone permanently; there’s no reconstructing deleted access logs.
The myth that backups solve this problem
A persistent misconception is that restoring from a clean backup counts as evidence preservation. It doesn’t – it’s the opposite. Restoring immediately overwrites the compromised state with an old one, destroying the only record of how the attacker got in, what they touched, and how long they had access. A backup from three weeks ago tells you nothing about whether the attacker also planted a webshell in the uploads directory that survived the restore, which is a routine outcome after a WordPress plugin compromise. Restore only after evidence has been captured and the entry point identified – otherwise the same vulnerability reintroduces the same attacker within days.
Common mistakes teams make under pressure
Three patterns show up again and again in post-incident reviews. Teams delete the malicious file the moment they find it, out of instinct, before copying it anywhere – losing the one artifact that would identify the malware family or campaign. Teams reboot the server to “clear things up,” which on many configurations flushes in-memory data and resets log buffers that hadn’t yet flushed to disk. And teams skip documenting the discovery timestamp, which later makes it impossible to answer the GDPR-mandated question of when the organization became “aware” of the breach – a date that starts the 72-hour notification clock and has real legal weight.
A practitioner handling this for the first time under pressure usually wants to fix things fast to limit damage. The better instinct is to spend the first 30–60 minutes capturing state, because that window is small relative to the weeks of cleanup, legal review, and reporting that follow – and it’s the only window where the evidence still exists in its original form.
How ongoing monitoring changes this equation
Detection speed determines how much evidence survives. A compromise found within hours has intact logs, fresh timestamps, and a narrow window of attacker activity to investigate. A compromise found after three weeks, which is still common on unmonitored small business sites, means log rotation has likely already erased the access records that would show the initial entry point. Daily automated scanning narrows that detection window considerably compared to relying on a customer complaint or a Google Safe Browsing flag – see how daily malware scanning protects your business for how that detection timing works in practice.
Frequently asked questions
How long should log files be retained to support an investigation?
A minimum of 90 days for access and error logs covers most incident scenarios, since attackers often gain initial access weeks before executing the payload that gets noticed. Regulated industries (PCI DSS environments, healthcare) typically require 12 months.
Do I need a forensic specialist, or can an internal team handle evidence preservation?
Small incidents – a single defaced page, an obvious plugin exploit – can usually be handled internally if the team follows the isolate-copy-document-remediate order. Incidents involving customer payment data, suspected data exfiltration, or anything that will require a formal GDPR notification benefit from a specialist, since insurers and regulators weigh professionally documented forensic timelines differently than internal notes.
What should be included in the breach notification if personal data was involved?
The notification needs the nature of the breach, categories and approximate number of records affected, likely consequences, and measures taken or proposed – all of which depend entirely on having preserved evidence. The specific timelines and thresholds are covered in data breach notification GDPR timelines explained.
Building the evidence-preservation sequence into a written runbook beforehand, alongside the standard steps covered in building an incident response runbook for web teams, removes the guesswork exactly when a team has the least time to think clearly. The single most useful habit is a five-minute checklist taped next to the incident process: isolate, snapshot, copy logs, document timestamps, then clean up – in that order, every time. Once the site is stable again, the full remediation path is covered in how to secure your website after a security breach.