How to Read a Breach Report and Apply It to Your Business

A Louisiana hospital system gets ransomware. A Texas oilfield services company has customer data stolen. A national restaurant chain's POS systems get compromised.

You see these headlines. You think: "glad that's not us." But if you're using software, services, or vendors that those companies also use, you might be next in line—or already affected without knowing it.

Breach reports exist to document what happened, how attackers got in, and what organizations should do differently. Learning to read them means you can spot the same problems in your business before someone exploits them.

Why breach reports matter for SMBs

Large breach reports get published because the organizations involved were large enough to generate public interest and regulatory scrutiny. But the techniques attackers used? Those apply everywhere.

When Okta got breached in 2022, the attackers used a vendor's access to compromise Okta's systems. That vendor access model exists in thousands of smaller vendor relationships. When MOVEit got exploited in 2023, the vulnerability had been used against hundreds of organizations that used the file transfer software.

The patterns repeat. Your business isn't immune because you're small—you're potentially more vulnerable because you might be using the same vulnerable software without the security team a large company has.

What to actually look for

The initial access vector: How did attackers get in? Was it a phishing email? An unpatched VPN? A compromised vendor? This tells you what to secure first.

What got stolen: Customer data? Credentials? Financial records? This tells you what you need to protect and what notification requirements you'd face if it happened to you.

The timeline: When did the breach start? When was it discovered? How long were attackers in before anyone noticed? This reveals how important detection speed is.

What the attackers did after initial access: Did they move laterally? Did they escalate privileges? Did they exfiltrate data over weeks or months? This shows you what a determined attacker can do even after the initial entry point.

What controls failed: MFA wasn't enforced. Patches weren't applied. The vendor had too much access. These are the specific failures you can check in your own environment.

What can go wrong if you ignore breach reports

You repeat the same mistakes: If companies keep getting hit by the same attack techniques, and you don't know what those techniques are, you're likely vulnerable to them too.

You miss vendor risk: If your vendor gets hit by the same exploit used in a public breach, you need to know if you're affected and what to do.

You can't prioritize: Without understanding what attacks are happening and how, you can't make good decisions about where to spend your limited security budget.

You don't know what "good enough" looks like: Breach reports often include what the victim organization did wrong. That list is a checklist of minimum security controls.

What it costs

• Breach analysis time: Reading and understanding major breach reports takes a few hours per incident. This is time well spent.
• Implementing controls: If a breach report reveals you need a specific control (like patching a specific software), that might cost nothing if it's just configuration, or a few hundred to a few thousand dollars if it requires new tools.
• Incident response if you're hit by the same technique: $5,000 to $100,000+ depending on scope.

Vendor questions (copy/paste)

"We use [specific software mentioned in a breach report]. Are we affected? What should we do?"

"What do you know about the [specific vulnerability or attack technique] from that breach? Are we protected?"

"How quickly do you apply security patches for known vulnerabilities? What's your patching process for critical vulnerabilities?"

"Do you monitor for the attack techniques mentioned in that breach report? What would trigger an alert?"

"We need to assess our exposure to [specific vendor or software mentioned in breach]. Can you help us understand our risk?"

Minimum viable implementation

1. Pick one breach report per month to read in detail. Set a recurring calendar reminder. Look for the initial access vector, what controls failed, and what the timeline looked like. Focus on breaches in industries similar to yours or involving software you use.

2. After each breach report, ask yourself three questions: (1) Do we use this software or vendor? (2) Do we have this control in place? (3) If not, what's the cost and effort of adding it?

3. Sign up for breach notification services. CISA's CISA Alerts, your state's attorney general breach notifications, and vendor security mailing lists. When something relevant to your business gets hit, you want to know immediately.

4. Check the CISA Known Exploited Vulnerabilities (KEV) catalog when you see a breach report. If the breach exploited a known vulnerability that's in the KEV, prioritize patching that vulnerability on your systems.

5. Talk to your IT vendor about the specific attacks you read about. Ask: "If this attack happened to us, would you detect it? How would you respond?"

6. Maintain a simple "lessons learned" list. Every breach report you read, note one action you can take this week to reduce similar risk. Review the list quarterly.

7. Apply patches for actively exploited vulnerabilities within days, not weeks. Many breach reports show attackers exploited known vulnerabilities that had patches available. Your patch process matters.

When to hire help

Call someone today if:

• A breach report mentions software you use and you can't determine if you're affected
• You want someone to analyze a specific breach report and apply it to your specific environment

Call someone this week if:

• You want help establishing a process for reading and acting on breach reports
• You need help assessing your exposure to specific vulnerabilities mentioned in a recent breach
• You want someone to monitor threat intelligence for you and alert you to relevant incidents

You can probably handle it yourself if:

• You can read a breach report, identify the initial access vector, and check if you use the affected software
• You have IT support who can help you assess and patch affected systems
• You're willing to spend an hour or two each month reading and applying breach report lessons

The goal isn't to read every breach report. It's to understand the patterns so you can recognize them in your own environment. Most breaches succeed because basic controls weren't in place. That's good news—it means basic controls actually work.