What Happens During a Forensic Investigation: A Timeline for Non-Technical Stakeholders

When a forensic investigation is underway in your organisation, the board wants to know three things: what happened, when will you know, and what is it going to cost. The DFIR team is in the middle of a technically complex process that is difficult to explain under pressure to non-technical stakeholders who have their own urgent questions from regulators, insurers, legal counsel, and the media. This gap in understanding between the investigators and the people managing the incident at a business level creates problems: unrealistic expectations, premature public statements, and decisions made without adequate information.

This article is written for the CEO, the CFO, the board director, and the general counsel who are being briefed on a forensic investigation but are not sure what the DFIR team is actually doing with their time. Understanding the investigation timeline, what each phase produces, and why certain questions cannot be answered immediately helps you manage the business side of an incident more effectively while giving the investigation team the space to do their work properly.

Phase One: Scoping and Evidence Collection (Hours 1 to 48)

The investigation begins with scoping: understanding what systems are involved, what evidence exists, and what questions need to be answered. This phase involves conversations with your IT team, review of your network architecture, and identification of the systems and logs that are relevant to the incident. In parallel, the team begins evidence collection: taking forensic images of affected systems, exporting logs from network devices, cloud platforms, and identity systems, and capturing volatile evidence from running systems before they are shut down for remediation.

Evidence collection takes longer than most people expect because it must be done carefully. A forensic disk image of a single server can take several hours depending on disk size and connection speed. Logs must be exported in formats that preserve their integrity. Every piece of evidence must be documented as it is collected. At the end of this phase, the investigation team has a body of evidence to work with, but they do not yet have answers. The question "what happened?" cannot be answered accurately until the evidence has been analysed. Any answer provided in this phase is necessarily preliminary and subject to change.

Phase Two: Analysis (Days 2 to 10)

Analysis is where the investigation team examines the collected evidence to reconstruct what happened. This involves examining disk images for artefacts of attacker activity: files created, tools deployed, accounts accessed, data staged for exfiltration. It involves correlating log data from multiple sources to build a timeline of attacker actions. It involves malware analysis if malicious tools were found. It involves reviewing authentication logs to understand what credentials were used and from where.

This phase takes days, not hours, because the evidence is voluminous and the analysis must be thorough. A forensic examination of a single server might require examining tens of millions of log entries and thousands of file system artefacts. Missing one persistence mechanism or one lateral movement step means the investigation is incomplete. The investigation team will typically provide interim briefings during this phase as significant findings emerge, but the full picture is not available until analysis is substantially complete. Pressure to provide final answers before analysis is complete produces premature conclusions that may need to be retracted later.

Phase Three: Scope Confirmation and Reporting (Days 7 to 21)

As analysis progresses, the scope of the incident becomes clearer. Additional affected systems may be identified that were not part of the initial collection. The timeline of attacker activity may extend further back than initially estimated, requiring additional log analysis. Data exfiltration, if it occurred, must be characterised: what data, from which systems, during which time periods. This scope confirmation work is critical for regulatory notifications and insurance claims, because both require accurate statements about what data was affected.

The investigation report is produced once scope is confirmed and analysis is substantially complete. A well-structured report covers the attack timeline, the initial access vector, the attacker's actions throughout the dwell period, all affected systems and data, persistence mechanisms identified, and recommended remediation actions. This report becomes the foundation for your regulatory notifications, your insurance claim, and your internal post-incident review. Cutting the investigation short to get the report faster means producing a report that cannot be relied upon for any of those purposes.

What You Can and Cannot Know at Each Stage

Managing stakeholder expectations requires being clear about what can and cannot be known at each point in the investigation. In the first 48 hours, you can know: what systems are confirmed affected, what evidence is being collected, and what the initial indicators suggest. You cannot yet know: the full scope of affected systems, whether data was exfiltrated, or the complete attack timeline. In the analysis phase, you can know: how the attacker gained initial access, what tools they used, and which systems they accessed. You may not yet know: the exact data that was accessed or the complete list of affected systems if the attacker's lateral movement was extensive.

The right response to a regulator or insurer asking for information that is not yet available is to provide what you know, describe what is being investigated, and commit to a timeline for the next update. Providing confident-sounding answers to questions that are not yet resolved creates problems when the investigation produces different findings. Regulators and insurers understand that investigations take time. What they do not accept is being given inaccurate information, even unintentionally.

We work with organisations and their legal and communications teams throughout forensic investigations to make sure the business side and the technical side are aligned. If you are in the middle of an investigation or preparing for one, contact us at info@cyberlinx.com.au.