How to Talk to Non-Technical Clients About Data Breaches (Without Scaring Them)
Many MSPs and IT providers struggle with the same problem: you want clients to take breach risk seriously, but you don't want to terrify them or drown them in jargon. Here's a simple, calm framework you can reuse in QBRs, onboarding calls, and security reviews.
1Start with what a breach means in their world
Most non-technical clients don't care about hash types, APIs, or dark-web forums. They care about very human outcomes:
- "Will someone move money out of our accounts?"
- "Will our staff be tricked into paying fake invoices?"
- "Will our customers get suspicious emails from us?"
A simple intro line could be: "When we talk about breaches, we're talking about your staff's email addresses and passwords showing up in leaks tied to services you already use. That data can be used to trick your team or log in as them."
2Use one concrete example, not a wall of incidents
Instead of listing ten different breaches, pick one relevant example and walk through it slowly:
- What was leaked (emails, passwords, names)
- How that connects to the client's business
- What attackers could realistically do with it
The goal is understanding, not fear. One clear story beats a dozen headlines.
3Separate "signal" from "noise"
Breach data can feel noisy—especially when multiple staff emails show up in multiple leaks. Help clients see which items actually matter:
- Breaches involving accounts used for finance, approvals, or admin roles
- Breaches where passwords were exposed or likely exposed
- Recent breaches tied to services the business still actively uses
You can say something like: "Out of everything we saw, these three accounts are the ones we're most focused on, because of their role and access."
4Always pair risk with a short list of next steps
Non-technical decision-makers don't just want "bad news"—they want a clear, finite list of actions. For example:
- Enable MFA on these three key systems
- Move staff to a password manager by the end of the quarter
- Review and clean up old accounts (especially ex-employees)
This keeps the conversation grounded in solutions, not just problems.
5Avoid blame and shame language
Breaches often feel personal to staff: "Did I do something wrong?" Reassure them:
- Breaches usually happen to the service, not the individual
- Reusing passwords is common—but now we know better
- The goal is improving habits, not blaming anyone
A calm, non-judgmental tone makes staff more likely to cooperate with changes.
6Use plain language, not security shorthand
Swap jargon for everyday terms wherever possible:
- "Someone could log in as you" instead of "account takeover risk"
- "We want to make stolen passwords useless" instead of "MFA mitigation"
- "We'll give your team a simple checklist" instead of "awareness training program"
You can still be accurate without sounding like a security textbook.
7Make breach checks part of a regular rhythm
Finally, position breach checks as an ongoing hygiene step, not a one-time panic button. For example:
- Include breach snapshots in quarterly reviews
- Re-check key staff emails after major public breaches
- Use calm, visual reports instead of noisy dashboards
This turns breach data into a familiar part of your service, not an occasional scare.
The bottom line
Non-technical clients don't need every technical detail. They need:
- A clear sense of what's at stake in their world
- Confidence that someone (you) is watching the signal, not just the noise
- Short, realistic next steps they can say "yes" to
When you present breaches calmly, with clear actions, you build trust instead of fear—and make it easier to roll out the protections you know they need.
Want a clean, client-ready way to show breach findings in plain English?
Go to EmailBreachGuard →