How Long Does a Digital Forensics Investigation Take?

A digital forensics investigation runs in three stages, and only the first is fast: a preliminary read within days, a working investigation measured in weeks, and a defensible written report after that. The number you have probably seen quoted is measuring something else entirely. IBM's 2026 Cost of a Data Breach report (a vendor-published study, and the most widely cited longitudinal series available) put the global mean time to identify and contain a breach at 247 days (183 to identify, 64 to contain), but that clock is mostly attacker dwell time plus containment, and most of it runs before anyone calls an investigator. The variable that actually sets your calendar is log availability, which was decided months before the incident.

Nobody can give you a defensible date range without seeing your log inventory first, so this article does something more useful: it explains what consumes time in each stage, the four things that move the schedule most, and the statutory clocks that will not wait for the report to be finished.

Key takeaways

• The widely quoted 247-day figure from IBM's 2026 report measures identification and containment of a breach, not the length of a forensic engagement. Planning against it is planning against the wrong number.
• Investigations run in three stages: preliminary findings, the working investigation, and the written report. The first stage is days, the later ones are weeks, and the gap between them is where buyers get surprised.
• Four variables set the calendar: log availability, the number of systems in scope, whether the environment is cloud or on-premises, and how fast your side makes decisions.
• The notification clocks start on discovery, awareness, or materiality determination, not on report delivery. "Still investigating" is not a defense to a missed deadline.
• Any firm that quotes you a fixed timeline before seeing your log inventory is guessing, and the guess will be optimistic.

The number you have seen is measuring something else

IBM's report is the source most people are half-remembering when they say a breach investigation takes eight months. What that mean actually covers is the time from the start of the intrusion to the point it is identified and contained. It is a measure of how long attackers go unnoticed and how long containment takes once they are noticed. The forensic engagement is a slice inside the tail of that period, and in many incidents it begins on roughly the same day containment does.

Conflating the two produces two opposite mistakes. Executives who have absorbed the 247-day figure conclude they will not have answers for most of a year, and delay notification decisions they should be making in days. Executives who have absorbed a vendor's "rapid response" marketing expect a complete answer in seventy-two hours, and are then blindsided when the report they need for their insurer arrives a month later.

Both mistakes come from the same missing distinction: preliminary findings and a defensible report are different products with different timelines.

Three stages, and what happens in each

The ranges below are the pattern we see in mid-market engagements rather than a published benchmark, and we would rather name that than dress a firm observation up as an industry statistic. Your environment will move them.

Stage one, the preliminary read. Within the first couple of days, a competent team should be able to tell you the likely initial access vector, which systems are in scope, whether the attacker still has access, and which questions the available evidence can and cannot answer. That last item is the one to insist on, because it is the earliest honest signal of what the whole engagement will be able to deliver. This stage is quick because it works from live telemetry and existing logs rather than from acquisitions.

Stage two, the working investigation. Acquisition and examination: imaging the systems that matter, hash verification, timeline reconstruction, malware and persistence analysis, and the exfiltration assessment. This is where weeks go, and the dominant cost is not analysis but volume. Every additional system carries acquisition time, processing time, examination hours, and storage. It is also where the answer to "did data leave" is usually settled, and that answer often requires reasoning from network and cloud records rather than from a single decisive artifact.

Stage three, the report. The written deliverable arrives after the working investigation, not alongside it, and the gap surprises people. A report intended for counsel, an insurer, or a regulator has to state scope, method, evidence relied on, findings with confidence levels, and what could not be determined. It gets reviewed by counsel and revised. If the mailbox or file-share content review is part of the engagement, which for a data-theft incident it usually is, that review runs in this window too and is frequently the longest single task in the matter.

The practical consequence: ask for the stage-one briefing to be a contractual commitment with a date, and treat the report date as an estimate that gets re-baselined when scope moves.

The four variables that set your calendar

Log availability. The dominant variable, and it is not close. If your endpoint telemetry, authentication records, and network logs reach back far enough to cover the intrusion, scoping questions get answered from data. If they rolled over, the team has to image systems and reason from disk artifacts to establish facts that a log line would have settled in a minute. Vendor defaults are short: Microsoft's documentation puts Purview Audit (Standard) unified audit log retention at 180 days, and AWS keeps CloudTrail Event history for 90 days in the console unless you have configured a trail of your own.

Systems in scope. Investigation time scales with imaging volume more than with anything else. A flat network turns one compromised workstation into a question about everything; segmentation gives the examiner a defensible boundary to scope against. This is why "image everything to be safe" is a schedule decision as much as a cost one.

Cloud versus on-premises. Cloud evidence is generally faster to collect (it is an export, not a physical acquisition) and more constrained in what it contains, because you get what the provider logs and nothing more. On-premises evidence is slower to acquire and richer once acquired. Hybrid environments get both problems, and the seams between them, which is where timelines quietly stretch.

Your own decision speed. The variable clients underestimate. Investigations stall waiting for admin credentials, for approval to image a production server, for someone to decide whether a subsidiary is in scope, or for a legal review of the collection plan. Naming one decision-maker with authority, before the engagement starts, routinely saves more calendar time than any technical measure.

The deadlines that will not wait for your report

None of the statutory clocks are keyed to report delivery. They start on discovery, on awareness, or on a materiality determination, depending on the regime, and several of them are shorter than any realistic investigation. GDPR's supervisory-authority notification runs 72 hours from awareness; HIPAA's individual notification runs 60 days from discovery; the SEC's disclosure requirement for public companies runs four business days from the determination that an incident is material. Contractual clocks are frequently shorter than all of them. The full crosswalk, including which event starts each clock, is in Breach Notification Deadlines: Every Clock You Are On.

The reconciliation is that regulators generally expect notification based on what you reasonably know at the deadline, with supplemental detail to follow, rather than a completed forensic report. That only works if your investigation is producing decision-grade interim findings on a schedule counsel can use. Which is another argument for making the stage-one briefing contractual: it is the input to the notification decision, and the report is the input to everything that comes after.

What actually makes it faster

Before an incident: extend retention on the three or four log sources that would carry initial access, keep an asset inventory that a stranger can read, know where your evidence would be acquired from, and agree the engagement structure with counsel so that day one is not spent on paperwork. Nothing on that list requires headcount.

During an incident: name one decision-maker with spending authority, have privileged access ready for the responders rather than requesting it per system, resist the urge to reimage anything before it has been imaged, and give the team a single point of contact instead of five people forwarding partial information. Do not ask for a mid-engagement report; ask for a briefing. Reports written twice take twice as long.

And one that saves weeks at the end: agree the report's audience and format at the start. A document written for IT and then rewritten for counsel is not a revision, it is a second report.

When the honest answer is that you will never know

The against-interest section, because this is what we would tell you before invoicing.

If the intrusion predates your log retention, the affected machines were reimaged before acquisition, and no memory was captured, then the timeline question is the wrong question. The right question is whether a document recording what could not be determined is worth buying, and sometimes it is: insurers and regulators frequently want the attempt on record, and a carefully bounded "cannot be determined" is a stronger position than an unsupported assurance. Frequently it is not worth it, and a firm that takes the engagement without telling you which case you are in is charging you for a report whose conclusion it can already predict.

There is also a legitimate reason to slow an investigation down. If the report will be relied on by a regulator or in litigation, the pace that produces a defensible document is not the pace that produces a fast one, and pushing a forensics firm to compress the report stage is asking it to write something that will be harder to defend. Speed is a virtue in stage one and a risk in stage three.

Where Top Floor fits

We run digital forensics with the stage-one briefing as a committed deliverable, because the earliest useful thing an investigation can produce is an honest statement of what your evidence will and will not support. That statement is what lets counsel start the notification analysis and lets you decide how much further investigation is worth buying.

Where an incident is live, the same team handles incident response, which removes the most common source of avoidable delay: containment and preservation decisions being negotiated between two vendors who have never worked together. On budgeting, we do not publish a separate forensics rate card, deliberately; the reconciled responder rates and their sources are in How Much Does Incident Response Cost in 2026?.

How to decide this week

1. Write down your three highest-value log sources and look up their current retention. If retention is shorter than the dwell time you would consider plausible, that gap is your investigation timeline problem in advance.

2. Name the person who would have authority to approve imaging a production system at 2 a.m., and tell them.

3. Ask any firm you are considering for a committed date for preliminary findings, in writing, and a re-baselining mechanism for the report date. Refuse fixed report dates offered before anyone has seen your environment.

4. Map your shortest binding notification clock, including contractual ones, and confirm that your process can produce a decision at that deadline from interim findings.

5. Agree the report audience and format now, so nothing gets written twice.

The honest summary: preliminary answers are days away, defensible answers are weeks away, and the difference between those weeks and several months was decided by a retention setting nobody remembers choosing.

Frequently asked questions

How long does a data breach investigation take?

Expect preliminary findings within days, a working investigation measured in weeks, and the defensible written report after that, with the report stage frequently the longest because it includes counsel review and any content review of affected mailboxes or file shares. The spread is wide because it is driven by your environment rather than by the firm: log availability, the number of systems in scope, whether the evidence is cloud or on-premises, and how quickly your side makes decisions. A firm quoting a fixed end date before seeing your log inventory is guessing. Ask instead for a committed date for the preliminary briefing and a written mechanism for re-baselining the report date when scope changes.

Is the 247-day breach figure how long a forensic investigation takes?

No. IBM's 2026 Cost of a Data Breach report used that figure for the mean time to identify and contain a breach, which is mostly attacker dwell time before anyone noticed, plus the containment period afterward. The forensic engagement sits inside the tail of that window and commonly begins around the time containment does. Treating the 247-day figure as an engagement length leads companies to defer notification decisions they should be making within days, which is the more expensive of the two possible mistakes.

Do I have to wait for the forensic report before notifying regulators?

No, and in most regimes waiting would put you out of compliance. Notification clocks start on discovery, awareness, or a materiality determination depending on the regime, not on the delivery of a report, and several are shorter than any realistic investigation: GDPR runs 72 hours from awareness, HIPAA 60 days from discovery, and the SEC's requirement for public companies four business days from the materiality determination. Regulators generally expect notification based on what you reasonably know at the deadline, with supplemental information to follow. That works only if your investigation is producing interim findings your counsel can act on, which is why the preliminary briefing should be a contractual commitment.

Why do forensic investigations take longer than expected?

Three reasons, in the order they bite. Evidence volume: every additional system imaged carries acquisition, processing, examination, and storage time, so a scope that grows from four servers to forty endpoints does not grow the schedule proportionally, it grows it worse. Missing logs: when retention has expired, facts that a log line would settle in minutes have to be reconstructed from disk artifacts. And decision latency on the client side, waiting for admin access, for approval to image production systems, or for a single named decision-maker to exist. The first is a scoping discipline problem, the second was decided months earlier, and the third is the one you can fix this week.