A breach review and a litigation review sit on the same stack — a secure platform, vetted reviewers, a project manager keeping the protocol straight. From a distance they look like the same engagement run at different speeds. They aren’t, and staffing the second one the way you’d staff the first is how breach matters miss their deadline.
The difference starts with what each review is for.
What a breach review actually produces
A litigation review produces a production set: documents coded for relevance and privilege, defensible against a request and a court. A breach review produces a notification list — a deduplicated, validated set of the individuals whose personally identifiable information (PII) or protected health information (PHI) sat in the compromised data, and which jurisdiction each one is in. The client takes that list and discharges a statutory duty with it.
That single fact reorganizes everything downstream. The reviewer isn’t building a narrative; they’re extracting entities and the sensitive data points attached to them, often out of partially OCR’d scans, multilingual records, and HR forms that no extraction tool reads cleanly. The output isn’t coded documents. It’s a list of people.
Where the two diverge
| Dimension | Data breach review | Litigation review |
|---|---|---|
| Primary output | Notification list of affected individuals | Production set responsive to discovery requests |
| Coding decision | PII / PHI extraction + entity resolution | Relevance, privilege, confidentiality |
| Pace | Compressed, fixed by statute | Phased over weeks or months, negotiated under Rule 26(f) |
| QC focus | Recall — a missed person is legal exposure | Precision — overproduction is the risk |
| Tooling | Redaction, OCR, entity recognition, dedup | TAR / CAL, threading, privilege logging |
| Reviewer profile | Fast, exact, fluent in PII patterns and entity resolution | Bar-admitted attorneys for the privilege calls |
The QC line is the one buyers underestimate. A litigation review guards against overproduction — coding something responsive that should have been held back. A breach review guards against the opposite: a person who was in the data and never made it onto the list. One is a precision problem. The other is a recall problem, and recall failures don’t surface until a regulator or a plaintiff finds the name you missed.
The clock is the binding constraint
Most breach reviews don’t fail on the substance. They fail on the calendar.
If a 60-day clock starts on discovery and scoping takes two weeks, the review itself has a few days to three weeks — for a corpus that can run to millions of documents. That math is why breach staffing has to be elastic: zero to a full team inside a week, run hot, then stand down. A bench that takes three days to confirm availability has already spent a tenth of the window.
Staffing a breach review
The work rewards reviewers who have run a breach protocol before. Entity resolution — recognizing that the same person appears in twelve emails under three spellings and resolves to one notification — is a learned skill, not an instruction you give on day one. So is knowing which near-miss documents to escalate rather than guess on. Reviewers carrying that experience move materially faster on the same protocol than first-timers, and the gap shows up in the recall numbers, not just the speed.
This is also where the AI question lands, and it lands differently than buyers expect. Extraction tools and pattern matching are genuinely good at surfacing PII candidates — that part of the work is increasingly software. What doesn’t reduce to software is the judgment around it: whether a flagged record is actually reportable, whether two near-identical entries are one person or two, whether a handwritten form holds a data point the OCR dropped. The tooling raises the candidates; an attorney resolves them. The documents that still reach a human in a breach review are the ones the model couldn’t settle, which means the human work is getting harder, not lighter.
Quality control, built for recall
Breach QC is layered because the cost of a miss is asymmetric. A workable model runs a full first pass, a sample-based QC pass against a target accuracy, and a focused audit on the documents most likely to hide a name — foreign-language records, handwriting, low-quality OCR. On matters under active regulator scrutiny, a privacy attorney signs off on the final list before it leaves. Each layer is there to catch the one thing the layer above it would let through.
What to ask before you sign
Four questions separate a managed capability from a body shop:
- How many breach reviews have you run, and what’s your typical ramp time? Vague answers mean the bench hasn’t done this work.
- What was your QC accuracy on the last several engagements, and how do you measure recall specifically?
- How do you handle entity resolution across documents? If they can’t describe the mechanism, they don’t have one.
- What’s your coverage across time zones and languages? Multinationals breach multinationally, and the clock doesn’t pause for a single shift.
If those come back crisp, you’re talking to an operation that has done this before. If they come back soft, keep looking — the deadline won’t wait for you to find out which.
Bring us your breach matter and we’ll walk the protocol, the clock, and the staffing model with you before you commit to anything.