Digital Forensics
Understand the evidence behind a security incident and reconstruct what happened.
After an incident, the pressing questions are specific: how did they get in, how long were they there, what did they reach, and is it actually over. Answering them means working from evidence rather than inference.
Forensic work reconstructs a sequence from artifacts systems leave behind — authentication records, process activity, file changes, network connections. Individually these are fragments; assembled in order they become a timeline that either supports a conclusion or rules it out.
Artifacts become a timeline; a timeline becomes an answer.
- EVIDENCEDigital evidenceSources preserved from the systems in scope
- ARTIFACTSArtifactsThe specific records those sources contain
- TIMELINETimelineArtifacts placed in sequence across systems
- ANALYSISAnalysisWhat the sequence indicates, and what it excludes
- FINDINGSFindingsA documented account of what the evidence supports
Conceptual process. What can be recovered depends on what was preserved, what was logged and how long it was retained.
Evidence has a short shelf life
Much of what matters is volatile or short-lived. Memory contents disappear on reboot, logs roll over, temporary files are cleaned up, and a well-intentioned rebuild removes the record of everything that came before it.
This is why the response to a suspected incident should be to preserve first. Restoring service is the goal, but doing it before evidence is captured usually means the question of what actually happened can no longer be answered.
Artifacts placed in sequence.
Illustrative entries showing how a reconstructed timeline reads. These are examples, not real incident evidence.
Focus areas
Findings are constrained by available evidence. Where the data does not support a conclusion, the report says so.
When Do You Need to Know What Actually Happened?
Output your team can act on.
Which of these apply depends on engagement scope.
A clearer view of what activity is happening across the environment in scope.
What the monitored signals show over time, and what changed.
Activity identified as worth attention, with the reasoning behind it.
What was examined, what it indicated and what was ruled out.
A written account of an incident: timeline, impact and actions taken.
Recommended actions, and where a decision needs to sit with your team.
Where detection, logging or process could be strengthened.
The rest of the operations lifecycle.
Questions we get asked before an engagement.
Preserved evidence and context. In practice: affected systems left as they are where possible, whatever logs exist, and an account of what was observed and when. The earlier preservation happens, the more the investigation can establish.
Sometimes — it depends on the system, how much has been written since, and whether the storage was preserved promptly. We would rather set that expectation honestly at the start than imply recovery is routine.
Method and chain of handling are documented so findings can be reviewed and relied upon. Where an investigation may feed a legal or regulatory process, tell us early, because it affects how evidence is handled from the first step.
That is common, and the report says so explicitly. A forensic account should distinguish clearly between what the evidence supports, what it suggests and what cannot be determined — the last category matters as much as the first.
Discuss a Forensic Investigation
Tell us what happened, what has been preserved and what you need to establish. What is still available shapes what an investigation can answer.
