LearnDigital Forensics & Incident Response

The Honest Answer

Usually you cannot prove data was not taken, and saying so plainly is the professional answer rather than the weak one.

3 min read

Not yet reviewed

This is the question everybody asks and the one you are least equipped to answer. It is also the one where the pressure to say something reassuring is strongest, because the honest answer usually disappoints.

Start from what evidence of exfiltration actually looks like, because there is less of it than people assume.

Would show it

Outbound bytes in your host or provider's traffic graphs
An access log entry for a large response you did not serve
A slow-query log holding an enormous SELECT
A file staged for collection - a tarball sitting in /tmp

Usually missing

Anything about what was inside an encrypted connection
Anything at all, if they read it a page at a time over a week
Logs from before your retention window

Most small servers keep no outbound byte accounting whatsoever. Its absence is normal, and it is exactly why "no evidence of exfiltration" is such a weak sentence on a box like this.

What you can usually establish

Three things are within reach even on a modest server, and together they bound the problem without resolving it.

1sudo -u www-data psql -c '\dt'
2# provider bandwidth graph, for the compromise window
3find /tmp /var/tmp /dev/shm -type f -newermt '2026-08-14' -size +1M

Line 1What the compromised account could reach. Not what it did reach - but a bound, and one you can state without guessing.
Line 2The one place a small host does keep byte counts. A flat graph is weak evidence of nothing happening; a spike is strong evidence that something did.
Line 3Staging. Data is usually collected into one archive before it leaves, and the archive is often still there because deleting it was step four of a plan that got interrupted.

Together these give you the blast radius - what the intruder could have reached - which is genuinely useful to state even when you cannot say what they did reach.

How to say it

Do not write this

"No data was taken."
"There is no evidence of a breach of customer data."

Write this

"The compromised account had read access to the customer table. We
 have no evidence it was queried, and we would not necessarily have
 such evidence: outbound accounting is not enabled on this host."

The first is a claim you cannot support. The second is longer, true, and still defensible in six months when something new turns up.

Wrenlearner

The second one sounds so much worse. Will that not just make people panic?

Rookmentor

Some will. But the first one is a promise, and if it turns out to be wrong you have not merely had a breach - you have made a false statement about one, which is the part people do not forgive. Say what you know, say what you cannot know, and make clear which is which.

Take care

In many places a breach involving personal data carries a legal notification duty with a short deadline, and the clock usually starts when you became aware, not when you finished investigating. This course cannot tell you your obligations. Find out what they are before you need them.

You cannot determine whether the customer table was read. What goes in the report?

Writing that sentence well is the deliverable of a real incident response, and it is the subject of the last chapter.