Greenberg Traurig Breach: Why BigLaw Scale Can't Buy Security

Greenberg Traurig has 2,750 attorneys, 49 offices, and — by any reasonable estimate — one of the larger cybersecurity budgets in the legal industry. None of it stopped an unauthorized party from walking off with documents belonging to more than 256,000 individuals, or kept those files off the dark web, or compressed the firm's notification window to something less than two weeks. Two proposed federal class actions filed in the Southern District of New York this September — Addison v. GT (No. 1:26-cv-07793) and Hancock v. GT (No. 1:26-cv-08182) — now argue that scale and spend were never the point. Architecture was.

That argument should worry every managing partner who has quietly assumed that firm size is a proxy for data security. It isn't. And the plaintiffs' bar has figured that out faster than most general counsel offices have.

The Breach Anatomy: What Actually Happened

According to Greenberg Traurig's own disclosure, the firm's core systems were not compromised. Instead, an unauthorized party accessed and exfiltrated a limited set of documents — a phrase doing a lot of work in the firm's public statement, since "limited" documents still contained personal data on a quarter-million people. The stolen files later appeared on the dark web, which is typically how firms and their clients learn the incident wasn't contained, remediated, or even fully understood at the time of initial notification.

The two-week gap between discovery and client notification is the detail plaintiffs' counsel keeps returning to. In breach litigation, notification timing isn't a footnote — it's often the centerpiece of the negligence claim, because it's the one fact pattern that doesn't require expert testimony to explain to a jury. Clients whose Social Security numbers, financial data, or privileged case materials sat exposed for two additional weeks have a straightforward story: the firm knew, and people found out later than they should have.

What makes this breach instructive rather than merely unfortunate is the phrase "core systems were not breached." That's the language firms use when the exposure came through an adjacent system — a file-sharing platform, a vendor portal, a cloud storage integration, a third-party e-discovery tool. The perimeter that mattered wasn't the one the firm spent years hardening. It was the one nobody was watching as closely.

This Isn't an Outlier — It's a Pattern

Greenberg Traurig is not an isolated case study. It's the latest entry in a growing list of AmLaw-caliber firms that have disclosed cyber incidents in the recent cycle:

The common thread isn't sophistication of the attackers or negligence of any one IT department. It's that every firm on this list operates the same basic architecture: large, valuable document repositories, distributed across a mix of internal systems, cloud storage, and third-party SaaS tools, accessed by hundreds or thousands of people across dozens of offices. That architecture is, by design, a large and porous attack surface — and it is now standard across BigLaw, not a Greenberg Traurig-specific flaw.

When six top-tier firms disclose incidents within roughly the same cycle, the story stops being "a firm got breached" and becomes "this is what the current architecture produces at scale." Law firms hold some of the most concentrated, sensitive, and monetizable data in the economy — M&A terms, litigation strategy, IP filings, personal data from thousands of matters — without the security-engineering culture of a bank or a cloud provider. That mismatch is exactly what plaintiffs' firms are now pricing into their complaints.

The Legal Theory Plaintiffs Are Building — And Why It Works

The negligence claims in Addison and Hancock don't hinge on proving Greenberg Traurig was cheap or careless in the way a small firm might be. They hinge on a simpler, more damaging argument: adequate security is a function of architecture, not budget. A firm can spend millions on perimeter tools, SOC monitoring, and vendor questionnaires and still be one misconfigured third-party integration away from a quarter-million exposed records — because the actual point of failure was never inside the systems the security budget was built to protect.

This is a meaningful shift in exposure for law firms specifically, for three reasons:

• Vendor trust is not a legal shield. Firms have historically treated third-party risk as something offloaded through contractual indemnification. Plaintiffs are now arguing that outsourcing data handling doesn't outsource the duty of care — the firm chose the vendor, integrated the vendor, and controls what data flows to it.
• Detection speed is now a liability factor, not an IT metric. Industry benchmarks (IBM's Cost of a Data Breach research) have long shown average breach identification and containment cycles running into months. A two-week notification gap looks fast by that standard — and plaintiffs are using it anyway, because "industry average" isn't a legal defense to an individual client's damages claim.
• Class certification is easier when the exposed population is large and homogenous. 256,000 records from a single incident is exactly the kind of scale that supports a viable class, which is why these suits get filed within weeks of disclosure rather than fading quietly.

For a general counsel or managing partner, the practical takeaway is blunt: your outside counsel can no longer tell you that "we followed industry-standard security practices" is a complete answer. Plaintiffs aren't arguing you were behind the industry. They're arguing the industry's standard architecture is itself inadequate.

The Architectural Root Cause: Shared Infrastructure, Delayed Detection, Third-Party Handling

Strip away the specifics of any single breach and you find the same three structural weaknesses recurring across BigLaw incidents:

1. Shared, multi-tenant infrastructure. Most law firm data — including data processed by AI tools — lives in cloud environments shared across many customers, secured by a vendor whose incentives (uptime, feature velocity, cost efficiency) don't always align perfectly with a single client's risk tolerance. A misconfiguration, an over-permissioned integration, or a compromised vendor credential can expose data that never should have left the firm's four walls in the first place.

2. Delayed breach detection. The gap between compromise and discovery — and then discovery and notification — is where damages compound. Two weeks of undisclosed exposure is two weeks in which affected individuals can't freeze credit, monitor accounts, or take protective action. In a legal-privilege context, it's also two weeks during which litigation strategy or deal terms sitting in the exposed documents could be acted on by a counterparty.

3. Third-party data handling with limited firm visibility. When a firm's own systems weren't breached but a connected tool was, the firm often can't say precisely what was taken, when, or how, because the logging and access controls live on the vendor's side. That opacity is exactly what plaintiffs' experts probe first in discovery.

Each of these is an architecture decision, not a spending decision. And each is directly relevant to how firms deploy AI today, since the same shared-cloud, third-party-handling pattern that produced the Greenberg Traurig breach is the default architecture behind most per-seat legal AI SaaS products.

What Changes With a Private AI Architecture

This is where the AI conversation and the breach conversation converge. Most legal AI tools — regardless of vendor — route client documents through a cloud service the firm doesn't operate, store embeddings and indexes in the vendor's infrastructure, and manage permissions inside the vendor's platform. That's a reasonable trade-off for many use cases. But it's the same architectural pattern implicated in this cycle's breaches: shared infrastructure, dependency on a third party's detection capability, and data handling the firm can't fully audit in real time.

A private AI deployment inverts the default. The full client corpus, the vector store, the retrieval layer, the permissioning logic, and the audit trail all stay on infrastructure the firm controls — on-premise or in a private cloud environment the firm owns and monitors directly. The only thing that leaves the firm's environment is the minimal, task-specific text needed to generate a given answer, sent to the selected LLM provider under terms the firm has negotiated.

That last row is the honest distinction, and it's worth stating plainly: RAGbase Legal also sends data to LLM providers to generate answers — there's no version of generative AI that doesn't involve a model somewhere. The difference isn't "we never send anything out." It's that the firm controls exactly what leaves, in what form, and under what contractual terms, because the retrieval and reasoning layer that decides what's relevant never leaves the firm's environment. A full document repository sitting in a shared cloud is a fundamentally larger attack surface than a retrieval system that hands a model three relevant paragraphs and discards the rest.

The Minimized-Chunk Model, in Practice

When an attorney runs a query through a properly architected retrieval system — the kind underlying tools like RAGbase Legal's case search — the workflow looks like this: the query hits the firm's own vector index, the system retrieves the specific passages relevant to the question, and only those passages, not the surrounding case file, deal documents, or client correspondence, are sent to the model for synthesis. The 256,000 records exposed in the Greenberg Traurig incident were, by definition, sitting somewhere in bulk — a document set large enough to expose that many individuals doesn't get generated by minimized, per-query retrieval. Bulk exposure requires bulk storage in a system an attacker can reach and exfiltrate wholesale.

That's the practical argument for firms handling sovereignty-critical matters — M&A due diligence, regulatory investigations, high-net-worth private client work, anything with PII at scale: the retrieval architecture itself limits blast radius. If a downstream LLM provider's account or logs were ever compromised, the exposure is bounded to whatever chunks were queried in a given session, not the firm's entire document estate.

What CIOs and Managing Partners Should Do Now

The Greenberg Traurig litigation is a preview of a broader change: data security is becoming a diligence item clients ask about before signing an engagement letter, not just a topic for the annual security questionnaire. Three actions matter more than a bigger security budget:

• Map where client data physically and logically lives, including every AI tool, e-discovery platform, and file-sharing integration — not just the systems IT considers "core."
• Separate architecture decisions from vendor trust. A vendor's SOC 2 report describes their controls, not the firm's liability exposure when those controls fail.
• Treat AI deployment as a security decision, not just a productivity decision. Firms evaluating tools should ask directly: does the full document corpus leave our environment, or only minimized, task-specific text? That single question predicts most of the downstream breach exposure.

Firms building an AI strategy from scratch, or auditing an existing one against this new litigation risk, will find a useful starting framework in RAGbase Legal's AI for law firms guide, which walks through the architecture questions worth asking before — not after — a deployment decision.

Looking Ahead

Expect the Addison and Hancock complaints to become templates. Plaintiffs' firms now have a working playbook: identify the notification delay, allege inadequate security regardless of firm size or spend, and push for class certification on the strength of a large, identifiable affected population. Every AmLaw 200 firm holding client PII at scale should assume it's a plausible future defendant, not a spectator.

The firms that come out ahead of this cycle won't be the ones with the largest security line item. They'll be the ones that can say, credibly and specifically, which systems hold client data, what leaves those systems, and why. That's an architecture answer, not a budget answer — and it's increasingly the only answer plaintiffs' counsel, regulators, and clients are willing to accept.

If your firm is evaluating AI tools against this new litigation backdrop, the questions worth asking aren't about vendor reputation or feature lists — they're about where the corpus lives, what leaves your environment per query, and who controls the audit trail when something goes wrong.