Spoliation tends to get lumped in with failed preservation efforts, and while this is technically true, the real culprit is usually improper or incomplete identification. Here are a few examples we have seen a lot of recently:
In each of these scenarios, more rigorous or robust identification would yield more defensible results. While we as practitioners cannot force clients to comply, better identification would lead to better outcomes in most cases.
I have also observed that up-front identification is often a rushed process with the least supporting information (compared to downstream phases).
But this is where risk is introduced. If identification is flawed or incomplete:
Traditional identification relies on a deeply flawed assumption:
"A custodian is a person, frozen in time."
In modern organizations, this simply is no longer true. Modern organizations do not work that way.
People do the following:
When custodians are identified based on current titles or current org charts, the historical reality that really matters is lost.
Consider Jane, a product manager who works remotely from her home office in New Jersey. Jane is asked to collaborate on product positioning briefs by a product marketing manager, Jim. Jane and Jim begin sharing documents back and forth on Teams via hyperlinks. Those documents are stored in each of their OneDrive repositories, on the Marketing SharePoint, and in the Marketing team’s Notion dashboard.
If we were asked to preserve all custodians who worked on the new messaging project in M365 Purview, we might miss documents stored in Jane’s OneDrive that are referenced in the Teams messages and emails of our custodians (unless Jane is explicitly added as a custodian).
What is missing in this scenario is the context that Jane worked cross-functionally on an ad hoc team for the project in question.
I would want to interview Jane, Jim, and the other custodians to determine if:
Discovery requests are drafted with the relevant timeframe in mind, not today’s org charts or roles.
Another common pitfall is repository-based scoping.
We may assume:
In practice, however:
A repository’s relevance is defined by how it was used, by whom, and when – not by its label or permissions hierarchy. This is behavioral context, and without it, scoping is guesswork.
Over-collection is often considered the safe bet. “Just get everything, and we will sort it out in processing or review.” Sound familiar? Later, that over-collection is framed as a cost problem, when it is really a confidence problem.
If you cannot trust the context available during scoping, the duty to preserve and thus, avoiding spoliation, requires over-collection. In some cases, proportionality concerns have not even been raised or discussed because the impact to downstream review and hosting cost is not yet known. And even if those concerns were raised, you may not have had enough information to support the claim.
When identification is grounded in context:
Context-Aware eDiscovery™ treats identification as a reconstruction exercise, not a checklist.
It asks:
Identification becomes an act of defensible reasoning, supported by evidence, not assumptions.
Everything in eDiscovery flows downstream from identification. It is the moment where defensibility is won or lost.
When identification improves:
Context-Aware eDiscovery™ starts where risk begins. It brings together identity, behavior, and document context in a reconstruction-grade record that reflects what actually happened, not merely what content exists today.
This article is part of Cloudficient’s Context-Aware eDiscovery™ series leading up to Legalweek.