How MSPs Can Use Public Breach Disclosures to Find Clients

Here's part of a breach notice filed with the Ohio Attorney General last December, sent by a law firm on behalf of a company called 700Credit:

On or around October 25, 2025, 700Credit became aware of suspicious activity within its web application and immediately launched an investigation… The investigation determined that certain records in the web application relating to customers of its dealership clients were copied without authorization.

A few paragraphs later it gets to the number: 245,973 Ohio residents, with names, addresses, Social Security numbers, and dates of birth.

You probably didn't see that letter. Breach notices like this almost never make the news, so unless you went looking, there was no way you would have. (Most breaches are like this. More on that later.)

That letter is a good example of how breach disclosure actually works in the US, and why it matters if you sell security services. Most of it happens quietly, in state filings, weeks after the incident. If you know where to look, it's the most honest buying signal in this industry.

What one filing actually tells you

Strip out the legal boilerplate and the 700Credit letter gives you a timeline:

1. October 25, 2025: suspicious activity found in a web application
2. November 21, 2025: 700Credit starts notifying its dealership clients
3. December 15, 2025: the letter goes to the Ohio Attorney General
4. December 22, 2025: written notices start going out to 245,973 Ohioans

So it was 51 days from discovery to a regulator hearing about it, and nearly two months before the affected people did. That isn't unusual, and it isn't necessarily a scandal. Working out whose data was in which records takes time, and 700Credit was notifying on behalf of dealerships whose customers were affected, which adds a layer.

But look at who's actually in this story. 700Credit is the company that got breached. The records belonged to customers of car dealerships. I have no inside knowledge here, but I'd bet plenty of those dealerships spent December answering calls from customers asking why their Social Security number was in some other company's breach notice. They didn't get breached, and they still had to deal with it.

If you're an MSP with dealerships on your client list, that filing is a reason to pick up the phone. It isn't a sales opener for strangers, though. It's a reason to call people who already trust you.

Where breach disclosures actually come from

Ask most people where breaches get disclosed and they'll say the news, or maybe the SEC. So I took a one-year snapshot: every filing in RiversideIQ's database from the last 12 full months (September 2025 through August 2026), counted by where it came from:

Source	Filings	Share
State Attorney General notices	8,887	77%
Other compiled public breach records	1,158	10%
SEC 8-K filings	988	9%
HHS OCR breach portal	493	4%

Those 11,526 filings map to 7,193 distinct breach events. About a quarter of those events (1,721, or 24%) show up in more than one source, because a company with customers in several states files in several states.

The SEC number deserves a closer look. Of those 988 SEC filings, only 27 were filed under Item 1.05, the "material cybersecurity incident" item that's been required since December 2023. The rest were other 8-K items that matched cyber-incident keywords, a mix of voluntary disclosures and some noise. Plenty of public companies have chosen to disclose incidents without calling them material, which the SEC's own staff encouraged in May 2024 for incidents that aren't (or aren't yet) considered material.

So the source that gets the headlines is 9% of the volume. And it's the least useful one for an MSP, because it only covers public companies, which already have security teams, incident response retainers, and procurement departments that don't buy from you.

The organizations an MSP can actually help, like the regional credit union, the 40-person manufacturer, or the dental group with six offices, show up in state Attorney General filings. That's three-quarters of all disclosures.

The three places to look

SEC filings cover public companies only. Under Item 1.05, a company has four business days to file once it decides an incident is material. They're fast, public, and searchable, but mostly irrelevant to MSP sales, for the reasons above.

The HHS breach portal covers healthcare: providers, health plans, and the vendors that handle their data, whenever 500 or more people are affected. If you sell to clinics, dental groups, or healthcare billing companies, this is your list. Pay attention to the vendors too. A breach at a billing company or IT provider can mean dozens of practices dealing with the fallout.

State Attorney General notices cover almost everyone else, and this is where the variation gets interesting. Every state has a breach law, but they disagree on almost everything:

• Texas requires notice to the AG within 30 days once 250 or more Texans are affected, and publishes the list. (Texas breach law)
• California requires notice once more than 500 residents are affected, and keeps a searchable public database. (California breach law)
• Massachusetts requires a report to the AG for every breach, regardless of size, so small organizations show up there that wouldn't appear in most other states' records. (Massachusetts breach law)
• New York sends every notice to three agencies at once: the Attorney General, the Department of State, and the State Police. (New York breach law)

Put those side by side and you can see the problem. Some states post filings within days, in a searchable list. Others post a PDF once in a while. Every one uses its own format, its own thresholds, and its own idea of what counts as "the date of the breach." If you sell across state lines, which most MSPs do, there's no single place to look.

How to use this without being creepy

Here's where it's easy to get it wrong.

Don't open with the breach. Nobody wants a cold call that starts with "I saw you got hacked." It's accurate, it's public record, and it'll get you hung up on. The organization has spent two months with lawyers, forensics firms, and possibly its insurer. They don't need a stranger reminding them.

Do read the filing first. It tells you what data was involved, how many people were affected, when it happened, and often what the organization says it's doing about it ("implementing additional safeguards" is doing a lot of work in most of these letters). That's the difference between a generic pitch and a conversation about their actual situation.

Mind the timing. By the time a filing goes public, the incident is usually weeks old and the fire is out. What's left is the aftermath: regulator questions, an insurance renewal that's about to get expensive, and a board asking what changes. That's when assessments, managed detection, backup verification, and incident-response planning are easiest to justify. Showing up that week with a plan puts you ahead of everyone who shows up six months later.

Look past the breached company. The 700Credit letter is the pattern to remember: the breached company is often a vendor, and the pain lands on its clients. When a payroll provider, billing company, or software vendor shows up in a filing, the question for you is which of your clients or prospects use it.

Check more than one state. A quarter of breaches appear in multiple states' records, and the filings don't always agree on the details. One state's letter might give you the resident count; another might describe what was taken. Read both.

The short version

Breach disclosures aren't news. They're paperwork, filed in 50 different formats with 50 different Attorneys General, usually weeks after the fact. That's exactly why they're useful: most of your competitors aren't reading them.

Reading one state's list is easy. Reading all of them, every week, and working out which filings are the same breach showing up in five states, is the part nobody has time for. That's why we built RiversideIQ. Whichever way you do it, a public breach filing is a better lead than most of what's in your inbox.