The short answer. LexisNexis — a company whose business is selling identity verification and risk intelligence — has confirmed two separate data breaches in roughly fourteen months. The data brokers that aggregate your information do not need your consent to hold it, and the evidence is mounting that they cannot reliably secure it either. That combination is the strongest practical argument for removing yourself from the aggregation layer rather than trusting it.
On 3 March 2026, LexisNexis Legal & Professional confirmed a data breach after a threat actor published roughly two gigabytes of internal files. The company characterised the exposure as limited and largely legacy. Whatever the eventual scope, the more important fact is the pattern: this was the second confirmed LexisNexis breach in fourteen months.
For most companies, a breach is an incident. For a data broker, it is a structural question — because the people whose data is exposed never chose to be in the database in the first place.
Two breaches, two divisions, two root causes
The breaches were not a single event re-reported. They hit different parts of the business through different failures.
May 2025 — LexisNexis Risk Solutions. The company disclosed that data on 364,333 individuals had been taken via a third-party software-development platform (GitHub), where personal information was held alongside code. The exposed data reportedly included names, dates of birth, phone numbers, email addresses, Social Security numbers, and driver's licence numbers — the categories that drive identity fraud. Class-action investigations followed.
March 2026 — LexisNexis Legal & Professional. A separate intrusion, confirmed by the company, exploited an unpatched web-application vulnerability to reach cloud infrastructure. Reporting put the exposure at roughly 3.9 million database records and around 400,000 user profiles with names, emails, phone numbers, and job functions — including, per reporting, more than a hundred US government email addresses belonging to court and agency staff. LexisNexis described the data as predominantly legacy, pre-2020 information and stated that sensitive identifiers and active credentials were not included.
Two divisions. One via a third-party code platform, one via an unpatched front-end. The common thread is not a single mistake; it is an organisation that holds enormous quantities of other people's data and has now failed to contain it twice.
The part worth pausing on: what LexisNexis sells
The LexisNexis Risk Solutions division does not merely hold data. It sells identity verification, fraud analytics, and risk intelligence — including security and risk-assessment services — to banks, insurers, and government agencies. Its entire value proposition is that it can be trusted to evaluate and manage risk on behalf of others.
A company cannot sell risk intelligence and simultaneously treat the security of its own aggregated data as a solved problem. The 2026 intrusion turned on an unpatched application and over-broad internal access — the same failure modes the firm's own risk products are sold to help others avoid. This is not schadenfreude; it is the relevant data point. If the dominant risk-intelligence vendor operates this way, the assumption that any broker is a safe custodian needs to be retired.
If a company you never chose to do business with can hold — and lose — your identity data, the question is not whether you trust them. It is whether you can find and remove yourself. That is what an Eraser engagement is built to do.
Talk to an Analyst“Limited incident” is doing a lot of work
Expect a data broker's breach disclosure to be narrow by construction. The 2026 statement emphasised legacy data and the absence of Social Security numbers, driver's licences, financial data, and active passwords.
Read that carefully, because it can be entirely accurate and still understate the exposure. “No Social Security numbers were in the breached data” is a statement about what was copied, not about what the data broker holds or what the breached records reveal. A customer-account export with hundreds of thousands of named individuals, their employers, contact details, and the products their organisations license is not sensitive in the SSN sense — and is still a precise targeting map for fraud and social engineering against the exact people (court staff, agency employees, law-firm personnel) whose roles make them worth targeting.
The disclosure language and the real-world risk are measuring different things. Both can be true at once. The practitioner's job is to read the gap between them.
What the disclosure says vs what the data shows
| The disclosure emphasises | What a breach of this shape still reveals |
|---|---|
| “Largely legacy, pre-2020 data” | A contact roster does not expire — names, employers, roles and emails of identifiable people stay actionable for years |
| “No Social Security numbers or driver's licences” | The records still map who holds what data and who is permitted to access it — a targeting map, even without raw identifiers |
| “No active passwords or search queries” | Organisation-level licensing, product and contact data is enough to build convincing, role-aware social engineering |
| “A limited incident” | “Limited” describes what was copied — not what the broker holds, nor what the copied records expose |
You cannot opt out of the architecture
Here is the structural reason this matters more for a broker than for an ordinary company.
LexisNexis Risk Solutions products are built around permissioned access to sensitive identifiers. Under the US permissible-purpose framework (FCRA, GLBA), identifiers such as Social Security numbers are masked by default and unmasked only for users who assert an authorised reason. That design is not a secret; it is how the products are sold. The implication is the point: the full data is present in the system at all times — it is simply gated. Masking is an access-control decision, not a deletion. The records exist, complete, waiting for a permission flag.
You were never asked whether you wanted to be in that system. Data brokers assemble profiles from public records, commercial sources, and other brokers — without a direct relationship with the person described. So when the aggregation is breached, the ordinary advice (“change your password, watch your statements”) only partly applies. You cannot change a credential you never set with a company you never signed up with.
This is the same truth at the centre of every honest discussion of data brokers: knowing your data is held is not the same as being able to remove it. Two confirmed breaches in fourteen months simply raise the cost of leaving it there.
What this changes for an individual
It does not change the mechanics of removal — it changes the urgency. The exposure is not hypothetical and it is not one-off; it is a repeated failure at the most established broker in the market.
The defensible response is the one that was always available: find where you appear across the broker and people-search ecosystem, exercise the removal and deletion rights that apply to you, and treat it as maintenance rather than a one-time fix, because brokers re-acquire and re-list. The legal hook differs by jurisdiction — erasure and objection rights under the GDPR in Europe; the emerging deletion mechanisms and state laws in the US — but the principle is constant: the only data that cannot leak from a broker is the data the broker no longer holds.
It is worth being clear about where the consequences land. LexisNexis Risk Solutions operates, for parts of its business, as a consumer-reporting agency regulated under the US Fair Credit Reporting Act — it has settled FCRA class actions before (a $13.5 million settlement over its Accurint reports) — and the 2025 breach drew class-action investigations of its own. The legal machinery does engage. In Europe, the GDPR's penalty ceiling (up to 4% of global turnover) exists, though regulators reach it rarely and only where EU data subjects are affected. But notice what that machinery does and does not do: a fine or a settlement punishes the broker after the fact. It does not remove your record from the next export. The penalty regime is the company's problem to absorb; the exposure stays yours, whatever the outcome. That asymmetry — consequences for them, risk for you — is the whole case for not leaving your data in the pile.
The brokers will keep getting breached. The question each person actually controls is whether their record is still in the pile when it happens.