Your site was hacked. Here is what a real incident report contains.

There is a strange gap in the market for hacked websites, and most people only discover it after they have paid to have one cleaned.

At one end, malware removal costs somewhere between one hundred and two hundred and fifty dollars. It is fast, it is usually effective at removing the files, and it comes with essentially no explanation. At the other end, corporate digital forensics starts around twenty-five thousand dollars and runs to several times that.

Between those two numbers there is almost nothing. And between those two numbers is where nearly every business that gets hacked actually sits.

The consequence is predictable. A company gets compromised, pays for a cleanup, gets the site back, and then, a week later, when the insurer or the payment processor or the enterprise customer asks what happened, discovers that nobody wrote anything down.

Why the site is clean is not the answer

Removing malicious files addresses the symptom. On its own it tells you nothing about four things that matter more.

How they got in. If the entry point is not identified, it is not closed. The most common way a site is compromised twice is that the first cleanup removed the payload and left the door.

What they reached. Whether customer data was accessible is not a technical curiosity. In Canada, PIPEDA requires organizations to report breaches of security safeguards that create a real risk of significant harm, both to the Privacy Commissioner and to affected individuals, and to keep records of every breach regardless. You cannot make that assessment without knowing what was reachable.

What they left. Attackers routinely leave a second way back in, and it is rarely the one they came through. A new administrator account, a scheduled task, a modified core file, an injected redirect.

Whether it can happen again. Which is a question about your configuration, not about the files that were removed.

A cleanup answers none of these. It was never meant to.

What should be in the document

A useful incident report is not long. It is specific. Six sections.

1. Entry point. How they got in, with evidence. A vulnerable plugin at a stated version, a compromised credential, an exposed admin interface, a server-level issue. Likely a plugin vulnerability is a guess. Version 3.4.1 of a named component, exploited via a request pattern present in the access log at a stated time, is a finding.

2. Timeline. First unauthorized access, what happened between then and detection, and how long they were present. Dwell time is usually the most uncomfortable number in the report and the most important one.

3. Scope of access. Which files were touched and which data was reachable: customer records, orders, credentials, connected services, anything holding an API key. Where the evidence distinguishes between reachable and actually accessed, it should say so, and where it does not, it should say that too.

4. Indicators of compromise. What was added, changed or left behind: file hashes, injected code, created accounts, scheduled tasks, network destinations. This is what makes a recurrence recognizable instead of mysterious.

5. Attack characterization. What kind of attack this was: an automated campaign against a known vulnerability, a targeted effort, a known toolkit or botnet. Attribution where the evidence determines it, and no further. Most website compromises resolve to automated exploitation of a known flaw by commodity tooling, and a report that says so plainly is more useful than one that implies more than it can support.

6. Remediation and recommendations. What was fixed, what was rebuilt, what was closed, and what should change so the same category of attack does not work again.

Anything claiming more certainty than the evidence supports is worth less than a report that marks its own limits. If logs were rotated away or the host does not retain them, the report should say which questions cannot now be answered. That is a finding too, and often the most actionable one, because it tells you what to start retaining.

Why the evidence usually is not there

The single most common reason a website compromise cannot be investigated is that somebody cleaned it first.

It is an entirely understandable instinct. The site is defaced or serving malware, and the priority is to make it stop. So the malicious files get deleted, the plugin gets reinstalled, a backup gets restored, and every timestamp, every log entry and every artifact that would have shown the entry point goes with them.

Restoring a backup is particularly effective at destroying the answer, because it overwrites the compromised state with an earlier one, taking the evidence and leaving the vulnerability.

If you take one thing from this: snapshot everything before you touch anything. Files, database, server logs, to somewhere the site cannot reach. It costs a few minutes. Without it, the honest report is one page long and says we cannot determine how this happened.

What it should cost

Somewhere in the middle, and the middle is wide.

A single-site compromise with intact logs, a clear entry point and no data-exposure question is a relatively contained piece of work. A multi-site compromise with rotated logs, a possible data breach and a regulatory notification decision behind it is a different job.

What should be true in both cases is that you are told the number before the work starts, and that a written report is included rather than sold separately. A cleanup service that charges two hundred dollars is not withholding the report to be difficult. Investigation is simply not in the price, and it never was.

The part people underestimate

The report is not paperwork. It is the artifact that other people ask you for.

Cyber insurers require an incident description to process a claim. PCI assessors ask what happened and what changed. Enterprise customers running vendor security reviews ask whether you have had an incident and what you did about it. Boards ask all three.

A business that can produce a clear, dated, evidence-based account of an incident and its remediation is in a categorically better position than one that can say only that it was cleaned up. The second answer often reads worse than the incident itself.

Where we sit

We investigate website compromises, recover the site, and produce the report, for clients on our care plans and for businesses we have never worked with before, which is most of them. If you are in the middle of one right now, the first-hour checklist is the place to start, and it does not require calling anyone.