By Michael Barr
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
Breach cases have an unusual problem. In most technical litigation the evidence sits still and waits for you. In a breach, the evidence is a set of logs that were designed for operational troubleshooting rather than for proof, that were retained for as long as somebody's storage budget allowed, and that describe an event which the defendant was actively trying to stop while the record was being written.
That shapes everything a technical expert can honestly say, and it is why the most valuable thing an expert brings to a breach matter is often a clear statement of what the evidence cannot establish.
The four questions, and how differently they behave
Nearly every breach dispute reduces to four technical questions. They are usually treated as one investigation. They are not: they differ enormously in how provable they are.
What happened. The intrusion path, what the attacker touched, how long they were present. Well-instrumented environments answer this reasonably well.
What data was affected. Whether particular records were accessed or removed. This is dramatically harder than clients expect, and the gap between "the attacker had access to this system" and "the attacker took this data" is where most breach expert opinions are won or lost.
Whether the defendant's security was reasonable. A comparative judgment against practice at the time, not against hindsight.
Whether better security would have prevented it. Counterfactual, and the hardest of the four to state responsibly.
An expert who treats these as one continuous narrative will overreach on at least one. Keeping them separate, and being explicit about the confidence attached to each, is both more honest and more persuasive.
Access is not exfiltration
This is the single most important technical distinction in data-breach litigation, and it cuts both ways.
Demonstrating that an attacker obtained credentials to a database, or ran on a host holding sensitive records, establishes access and opportunity. It does not by itself establish that specific records left the environment. Proving exfiltration ordinarily requires something more direct: network flow records showing volume leaving to attacker infrastructure, staged archives left behind on disk, artifacts of the tooling used to package data, or the data itself surfacing somewhere it should not be.
Where those artifacts exist, the analysis can be strong. Where they do not, an expert has two honest options: describe access and stop, or describe what would have been required to determine exfiltration and note that the evidence to do so was not retained. What an expert should not do is let "could have" drift into "did" across the course of a report.
Defendants overreach here too, in the mirror image. Absence of exfiltration evidence is not proof that nothing left, particularly where logging was thin or retention short. "We found no evidence of exfiltration" and "no data was exfiltrated" are different statements, and an expert who conflates them will be asked about it.
Logs decide what is knowable
The scope of a defensible opinion is set almost entirely by what was logged and how long it was kept, and both are usually decided years before the incident by people optimizing for cost.
Useful sources include authentication records, endpoint telemetry, network flow data, cloud provider control-plane and access logs, database query and audit logs, and email gateway records. Each has a characteristic retention window and characteristic blind spots. Endpoint telemetry may be rich but short-lived. Flow records may be long-lived but lack content. Database audit logging is frequently disabled entirely because of its performance cost, which is precisely why the question "which records were accessed" so often has no clean answer.
Two practical consequences for counsel. First, the retention question should be asked immediately, because in a dispute that surfaces months later some of the decisive evidence may already have aged out, and knowing that early changes strategy. Second, whether logging was adequate is itself a merits question in many cases: an environment instrumented so poorly that the scope of a breach cannot be determined is a fact about the defendant's security posture, not merely an inconvenience.
Reasonableness, without hindsight
Where a case turns on whether security was reasonable, the expert is making a comparative judgment, and the discipline that makes it credible is anchoring it in time.
That means assessing what was known and available when the decisions were made: which vulnerabilities were public, what patches existed and how long they had been out, what the relevant frameworks and sector guidance called for then, and what the organization's own policies committed it to. An opinion that measures a decision made two years ago against today's consensus is straightforward to dismantle.
The most durable findings tend to be internal rather than comparative. An organization that documented a risk, assigned it, and then did nothing has produced the strongest evidence against itself, and it lives in its own ticketing system, risk register and audit findings rather than in any external standard. Conversely, a defendant who can show a considered, documented decision to accept a risk, made with the information available at the time, is in a far better position than one whose files are silent.
The counterfactual, handled carefully
Causation questions ask whether a specific control would have prevented the incident. This is the area where technical experts most often say more than they can support, because the question invites a confident answer and the honest answer is usually conditional.
The defensible version is narrow and mechanical: it walks the actual attack path step by step and identifies where a specific control would have interrupted it, given what the attacker actually did. The indefensible version asserts that better security generally would have produced a different outcome, which is unfalsifiable and reads as advocacy.
Sophisticated attackers adapt. A blocked path is often not the end of an intrusion but a detour. An expert willing to say that, while still identifying the specific point at which a specific control would have mattered, is far more credible than one who claims a single missing patch was the whole story.
Choosing the expert
Breach matters need a person who has done incident response, not only someone who has studied security. The instincts that matter, which log to reach for, what an artifact implies, what its absence implies, come from having worked real intrusions under time pressure.
They also frequently need more than one discipline. The intrusion analysis, the data-scoping analysis, and any assessment of the underlying software may call for different people: an incident responder, a forensics specialist, and, where the entry point was a flaw in the defendant's own application, someone who can read that code. The general framework for interrogating a review team, who testifies, who does the work, and how findings are documented, is set out in our guide to vetting a source code review team, and it applies here with the addition that you should ask specifically which of these disciplines each named person actually practices.
One more consideration particular to this field: much breach work is performed under privilege in the immediate aftermath, by responders retained for remediation rather than for litigation. Whether and how that work becomes available, and whether the testifying expert is relying on it or re-deriving conclusions independently, is worth settling early rather than at deposition.
What we do at Barr Group
Our electronics and software expert witnesses include practitioners in security and incident analysis alongside the software and embedded engineers who can read the code an intrusion exploited, which matters because breach cases regularly turn on a defect in the defendant's own software. We separate the four questions rather than blending them, we are explicit about the difference between access and exfiltration, and we anchor reasonableness opinions to what was known at the time. Where the underlying dispute reaches product liability or trade secrets, the same technical record has to serve both, and we keep it consistent through expert reports and testimony.
The takeaway
In breach litigation the evidence was not built for you, and the honest boundary of what it can show is usually the most valuable thing an expert can draw. Keep the four questions apart. Never let access quietly become exfiltration, in either direction. Ask what was logged and how long it was kept before you commit to a theory. Judge the defendant's decisions by what was knowable when they were made. And treat the counterfactual as the narrow, mechanical question it is, rather than an invitation to say that better security would have saved everyone.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.