Digital forensics
In incident work, digital forensics is the collection, preservation and analysis of evidence from affected systems in order to reconstruct what happened, in what order, and by whom. Its discipline is not the analysis but the preservation: evidence that cannot be shown to be unaltered answers questions in a technical meeting and nowhere else.
How it works
Collection follows the order of volatility, taking what disappears first. Memory holds running processes, injected code, network connections and keys, and it is gone at power off. Then live system state, then the disk image, then logs held elsewhere. Acquisition is done in a way that does not alter the source, and each item is hashed at the moment of collection so that any later copy can be shown to be identical.
Chain of custody records who held each item and when. Analysis then builds a timeline from file system metadata, event logs, application artefacts, browser and shell history, scheduled tasks and registry or configuration state, correlating those with network telemetry to answer the questions that matter: where the intrusion started, what identity was used, what was reached and what left.
What goes wrong
The evidence is usually destroyed by the response, not by the attacker. Rebuilding the affected host is the fastest way to restore service and it deletes the only record of how the intrusion started, which means the same route is open the following week. Rebooting to clear a problem discards memory. Logging in with a domain administrator account to investigate places fresh privileged credentials on a machine the attacker controls.
The second problem is retention. Reconstruction is limited by the oldest log you still hold, and intrusions are routinely older than the retention window on the systems that recorded them. If the endpoint tool keeps a fortnight and the intrusion began three months ago, the timeline starts in the middle. An attacker using a rootkit or operating entirely with signed system binaries leaves little that looks anomalous, so the record you kept is the whole case.
Where this shows up in an audit
We are an offensive practice, so our contribution is the other half: we know exactly what we did, in what order and at what time. After a red team exercise the timeline of our own actions is handed over and compared with what the client could reconstruct, and the gap between the two is the finding. That comparison tells a client more about their readiness than any tabletop, because it is measured against real activity on real hosts, and it feeds directly into incident response preparation.