The Processing Exceptions Your Vendor Isn't Showing You

In every collection we process at Relevant Discovery - across matters ranging from 10,000 to more than 4 million files - between 3% and 8% of ingested files fail to process. On a 200,000-document matter, that is between 6,000 and 16,000 files that never enter the review platform. Of those, we recover approximately 60 to 75% through systematic remediation - which means the remaining 25 to 40% stay unreviewed unless someone documents specifically why they could not be processed.

The assumption that the review set is complete is one of the most quietly dangerous assumptions in discovery practice. It feels reasonable: you collected, you processed, you reviewed, you produced. But the processing stage is precisely where that assumption can break. Files fail without notice. No alert fires in the review platform. No one calls. The review database simply does not contain them, and no one looking only at the review database will ever know.

What Are Processing Exceptions, and Why Do They Create Legal Risk?

A processing exception is a file that the e-discovery processing engine attempted to ingest and failed.

The file exists - it was collected, it has a file path, it has a custodian, it has a date - but the processing software could not render it into a searchable, reviewable format. It does not enter the review platform. It does not receive a Bates number. It is simply absent, present in every way that matters for legal exposure and invisible in every way that matters for review, as of July 2026.

Processing exceptions are not rare edge cases. They are a routine artifact of every collection. The more complex the custodian's file environment - corporate laptops with encrypted drives, cloud-synchronized folders, shared mailboxes with legacy PST containers, employees who password-protect documents and then leave the company - the higher the exception rate tends to run. In my experience processing collections for litigation across financial services, healthcare, and technology sectors, the exception rate on any given collection falls between 3% and 8% of all ingested files. On larger matters, that arithmetic produces alarming numbers.

The Major Categories of Processing Exceptions

Understanding why a file failed is the first step toward recovering it. Processing exceptions fall into several distinct categories, and each has its own remediation pathway:

The distribution above comes from our own processing history across hundreds of matters. Password-protected Office documents - Word files, Excel spreadsheets, PowerPoint presentations locked by a user who set a password and then left the organization - account for the largest single category. The password is, in many cases, obtainable. The problem is that no one asked for it, because no one looked at the exception report to know it was needed.

Why the Legal Risk Is Not Theoretical

The legal exposure from unreviewed exception files depends entirely on what those files contain. The honest answer is: no one knows, because no one reviewed them. The statistical expectation is that if the rest of the collection is 15% responsive, a random sample of the exception files will also be approximately 15% responsive. On a 200,000-file collection with 10,000 exceptions, that suggests roughly 1,500 responsive documents sitting outside the review set - not produced, not logged as privileged, not withheld with explanation. Simply absent.

Those documents do not appear on privilege logs. They are not produced. If opposing counsel later obtains them through a subpoena to the custodian's employer, because a witness references them in deposition, or because forensic inspection surfaces them from a backup system, the production certification becomes a liability. Courts have not been generous with arguments that amount to "we did not know" when the documents were collected, nominally processed, and simply never surfaced for review. At Relevant Discovery, our defensible chain-of-custody workflow - with immutable originals, content hashing, and append-only audit trails - is designed precisely so that when exceptions occur, the record shows exactly what happened and why.

In summary: processing exceptions occur at rates that produce meaningful document volumes on any real matter, they contain responsive material in proportion to the rest of the collection, and the legal risk of leaving them unaddressed is substantial rather than theoretical.

What Does an Exception Report Tell You - and Why Doesn't Your Vendor Send It?

Every major e-discovery processing platform generates an exception report as a standard output. Nuix produces one.

Relativity Processing produces one. CloudNine, Everlaw, Milyli, IPRO - all of them generate logs of every file that failed to process, with the failure reason attached. The exception report is not a special deliverable requiring additional engineering effort. It already exists, waiting in a directory alongside your load files, the moment processing completes.

The question worth sitting with is why so many attorneys have never seen one from their vendor.

What an Exception Report Contains

A properly formatted exception report will provide, for each failed file:

• File name and original path - where the file lived in the custodian's environment before collection
• Custodian association - whose data source the file came from, linked to your matter's custodian list
• Exception type - the category of failure: password-protected, corrupted, unsupported format, DRM, oversized
• Error message - the specific technical error returned by the processing engine
• File extension and native size - context for evaluating whether the file is likely to be significant
• Collection date and last modified date - temporal context for situating the file in the matter timeline
• Remediation status - whether recovery was attempted, and with what outcome

Some platforms export this as CSV or Excel. Others generate it as a structured report within the processing console. Regardless of format, the content is consistent: a complete ledger of what was collected, what failed to process, and why. It is a document that defines the boundary between what your review team can see and what it cannot. At Relevant Discovery, every answer traces back to its source document - and the exception report is the document that reveals which sources never made it through.

Three Reasons Vendors Often Don't Share It

I have watched this pattern across years of processing work, and the reasons exception reports are withheld tend to cluster into three categories - none of which involve any technical inability to produce the report.

First, sharing the exception report surfaces a gap that reflects on the processing deliverable. Every exception file is, in a narrow sense, a file that did not make it into the review platform. Vendors who deliver processing jobs and move quickly to the next matter do not particularly want to open a conversation about what did not arrive. That conversation often leads to a remediation workflow - additional work that may not be in scope, that the vendor did not budget for, and that requires custodian coordination the client relationship was not designed to facilitate.

Second, most processing contracts do not require it. Standard e-discovery vendor agreements define deliverables as load files, rendered images, extracted text, and metadata. Exception reporting is rarely called out as a named deliverable with a required delivery date and format. If the contract does not require it, and the client does not ask for it, it does not get sent. This is not, in most cases, deliberate deception - it is a gap that no one thought to build an obligation around.

Third, attorneys historically have not known to ask. Processing exceptions are a technical artifact of a technical process, and most attorneys engage with e-discovery at the review stage, not the processing stage. The working assumption - often correct, sometimes catastrophically not - is that the vendor handled whatever needed handling. The exception report is the document that either confirms or refutes that assumption.

What to Put in Every Vendor Agreement

The remedy is contractual. Every engagement letter or vendor service agreement covering e-discovery processing should include language requiring:

1. Delivery of the complete exception report within a defined number of days after processing completes
2. Categorization of exceptions by type: password-protected, corrupted, unsupported format, DRM, and other
3. A remediation recommendation for each recoverable exception category
4. Documentation of any remediation attempts and their outcomes
5. Written attestation that the exception log has been delivered and is complete

Inserting this language into a vendor agreement costs nothing and takes minutes. Discovering an exception problem during a production review - or after a sanctions motion has been filed - costs considerably more time and considerably more than money. In summary: the exception report already exists on your vendor's server; the only question is whether your agreement creates a contractual obligation to deliver it.

How Do You Remediate Processing Exceptions Before They Become a Production Problem?

Remediation begins the moment processing completes - not after review is finished, not in the week before production, but immediately.

The exception report is the input. A structured workflow is the process. The output is either a recovered file that enters the review platform or a documented explanation of why it could not be recovered. Both outcomes are acceptable. The unacceptable outcome is silence: files in the exception report that no one examined, no one attempted to recover, and no one documented as unrecoverable.

The Five-Step Remediation Workflow

I apply this workflow on every matter where exceptions appear, which is every matter:

1. Request and review the exception report within 24 to 48 hours of processing completion. Sort by exception type to identify the largest categories. A matter where 80% of exceptions are password-protected Office documents has a very different remediation path than one where 60% are corrupted PST containers. Knowing the distribution early shapes every decision that follows.
2. Categorize and triage. Separate exceptions into recoverable, potentially recoverable, and likely unrecoverable. Password-protected files from identifiable, reachable custodians are generally recoverable. Severely corrupted files with no backup copy and no accessible source system are generally not. This triage step prevents spending a week pursuing unrecoverable files while the recoverable ones sit untouched.
3. Contact custodians for passwords and decryption keys. For password-protected files, the most effective remediation step is asking the person who set the password. This requires a process: compiling a request list organized by custodian, routing it through appropriate channels (direct, through HR, or through the client's IT department), and tracking responses in a log. In our work, approximately 65 to 75% of password-protected files can be unlocked through direct custodian contact when the request is made promptly and the custodian is still reachable.
4. Attempt technical remediation for remaining files. For files where the custodian cannot be reached or cannot recall the password, explore alternatives: re-exporting the file from its source system, recovering from backup media, using password recovery tools where the engagement permits, or obtaining an alternative format of the same document from a different source. For unsupported file formats, conversion tools resolve the large majority of cases. For corrupted files, recovery is less predictable but worth attempting on files that appear, from their names and custodian context, to be potentially significant.
5. Document all unrecoverable files in a structured log. Every file that cannot be recovered despite remediation efforts must be logged with: file name, custodian, collection date, exception type, remediation steps attempted, and outcome. This log becomes part of the discovery record. At Relevant Discovery, our append-only audit trail ensures this documentation is immutable - if an unrecoverable file surfaces later, the record of what was attempted and why remediation failed is preserved exactly as it was written, not subject to revision. That documentation is the protection against a spoliation allegation.

Recovery Rates by Exception Type

Across the remediation work we manage at Relevant Discovery, recovery rates by exception type follow a consistent pattern:

The overall recovery rate across all exception types, weighted by their typical frequency distribution, is approximately 60 to 75%. That is, by most standards, a successful outcome - particularly for attorneys who ask themselves why they are spending time and money on documents that were already collected. But it also means that 25 to 40% of exception files are not recovered, and without a documented remediation effort, no one can distinguish "we tried and could not recover it" from "we did not know it existed."

Build Exception Handling Into Matter Intake

The most efficient time to design the exception-handling workflow is before processing begins, not after the exception report arrives. At matter intake, the discovery team should establish: Who holds passwords for encrypted files? Which custodians used encrypted email or encrypted local drives? Is there an IT contact who can assist with enterprise container decryption? Does the organization use enterprise encryption with key escrow that the client's IT can access?

These questions, asked at the beginning, compress the remediation timeline from two weeks to two or three days. Asked after processing - when the exception report is in hand and the production deadline is three weeks away - they produce the same answers but under conditions where the time cost is exponentially higher and the margin for error is much smaller. In summary: systematic remediation recovers the majority of processing exceptions, but only when the workflow begins immediately after processing completes, and the groundwork for custodian outreach was laid at matter intake.

What Will Matter Most in Exception Handling Over the Next 12 to 24 Months?

The exception problem is not going away. It is getting more complex, driven by two forces converging at once: the proliferation of cloud-native collaboration tools generating file types and export formats that most processing platforms were not designed for, and the steady expansion of corporate encryption policies that turn more of every custodian's file system into a potential exception. Both trends are already underway. Both will intensify.

Cloud-Native File Complexity Will Define the Next Exception Category

Slack, Microsoft Teams, Box, Notion, Google Workspace - the tools that modern organizations use to do their work generate data that is not a document in any traditional sense. A Teams conversation is not an email. A Slack channel export is not a PST container. A Notion workspace is not a folder of Word files. When these sources are collected, the exception rates from extraction failures, unsupported format errors, and malformed or incomplete metadata tend to run considerably higher than rates from traditional custodian laptop or corporate mailbox collections.

In the next 12 to 24 months, as cases involving primarily cloud-native custodians become the norm rather than the exception within a collection, discovery teams that have not developed specific workflows for cloud-source exceptions will find themselves significantly exposed. The processing platforms are catching up to these export formats, but they are not there yet, and the complexity of these sources tends to compound in collections that involve multiple cloud tools from a single custodian.

Encryption Prevalence Will Make Password Exceptions the Default

Zero-trust security frameworks are driving corporate IT toward encrypting everything: drives, file systems, email containers, backup archives, collaboration tool exports. For discovery purposes, this means that the percentage of any collection that arrives encrypted is increasing, and will continue to increase for the foreseeable future. The organizations that put key-recovery infrastructure in place now - identified IT contacts, documented escrow policies, custodian password management practices - will process future collections with far fewer unrecoverable exceptions than those that do not.

The cost of this preparation is low. The cost of encountering a 2,000-file exception set that is 80% enterprise-encrypted containers, with no key-recovery contact and a production deadline in ten days, is not.

Court Expectations Around Exception Disclosure Are Hardening

Courts and magistrate judges who handle discovery disputes have grown more sophisticated about the technical realities of e-discovery processing. The "we did not know" defense for unreviewed exception files has never been strong. It is becoming weaker. Recent sanctions decisions and discovery-dispute rulings have addressed the obligation to identify and remediate - or formally document the failure to remediate - files that fail to process. Attorneys who cannot produce exception reports and documented remediation logs when completeness is challenged will find themselves in an increasingly difficult position.

The question of how to reduce the cost of document review in litigation - a question I hear often from attorneys managing large matters - is directly connected to the exception problem. Unreviewed exceptions that surface post-production create re-review costs, supplemental productions, and potential sanctions exposure that dwarf the cost of a systematic remediation workflow run at the right time.

In summary: the drivers of processing exceptions - cloud file complexity, expanding encryption, new collaboration-tool export formats - are all trending upward, while court expectations for disclosure and remediation are also rising. Teams that treat exception handling as a standard matter deliverable today will require only minor adjustments for the environment that is already arriving.

Every collection produces exception files. That is not a failure of the vendor or the processing platform - it is an artifact of the complexity of modern data environments, where employees encrypt documents, leave organizations without sharing passwords, use collaboration tools that export in non-standard formats, and store critical files in containers that degrade over time. The failure is not in the exceptions. The failure is in not looking at them.

The attorney who certifies a production as complete without reviewing the exception report is certifying something they cannot actually know. The documents they are unaware of are the ones most likely to surface at the worst moment - in a deposition, in a sanctions motion, in an argument about completeness they did not expect to have. The exception report is the document that draws the line between what was reviewed and what was not. It belongs in your hands, in your file, reviewed and acted upon, before any production is certified as complete.

At Relevant Discovery, exception reporting and remediation are built into every processing engagement as standard deliverables - not optional add-ons, not documents you have to think to request. If you want to understand how exception handling fits into a complete, defensible e-discovery processing workflow, I'd recommend starting with our article on reducing attorney review hours with hybrid search, or reaching out to discuss how we structure processing engagements from intake through production certification.