Clustered 2 filings across 2 jurisdictions · filing window Aug 6, 2025 → Aug 7, 2025. View entity profile → Other incidents for this victim →
incident inc_edf3dc1314f04ea9 · merge_method human · confidence 100%
Discovered → first regulatory filing
Range of discovered_at dates across filings
OR TX
Time between earliest and latest filing
Not recorded for this incident
Leak precedence · Materiality delta · SEC filing delay — no leak-site claim in this cluster; no SEC 8-K in this cluster.
all State AG
Earliest sighting first · deep chronology in Litigation Timeline
Aug 16, 2023
When the intrusion reportedly occurred, per the linked filings
Mar 21, 2024
Reported by OREGON AG filing
Dec 30, 2024
Reported by TEXAS AG filing
Sirva, Inc. filing on its own and on behalf of the impacted data owners (Sirva, Inc. clients). reported a data breach to the Oregon Attorney General. The breach was reported on 2025-08-06. The breach occurred during 8/16/2023. The breach was discovered on 3/21/2024. 1,418 individuals were affected. Notice was sent on 8/6/2025.
Affected (this filing): 1,418
Sirva, Inc. filing on its own and on behalf of the impacted data owners (Sirva, Inc. clients). based in Oakbrook Terrace, Illinois, a other entity reported a data breach to the Texas Attorney General. The breach was discovered on 2024-12-30 and reported on 2025-08-07. 63 Texas residents were affected. 1,418 individuals affected in total. Types of information involved: Name of individual;Address;Social Security Number Information;Financial Information (e.g. account number, credit or debit card number). Consumers were notified via U.S. Mail;Email.
Affected (this filing): 63
About this clustering
DisclosureLens links filings into incidents through layered matchers: deterministic rules (same source document, multistate filings of one breach, tight-window same-victim pairs), a weighted-similarity scorer for cross-source candidates, and an operator review queue for everything uncertain. Each link records its own method and confidence — shown per filing in the timeline below. The system defaults to NOT merging when uncertain, because a false merge (collapsing two unrelated breaches) is more harmful than a false split (showing related filings separately); uncertain pairs route to human review instead of auto-merging. Filing summaries shown in the timeline are AI-generated extracts — verify each against its linked source.