Explain a Breach to Non-Technical

The forensic work is done, the vulnerability is patched, the attackers are out, and now you have to walk into a room full of people who do not know what a firewall is, and explain that their personal information may have been stolen.

This is the part nobody trains for, because security teams spend years learning how to detect, contain, and remediate incidents, yet almost none of them learn how to talk about it to the people who are scared, angry, and waiting for answers.

Getting this wrong has real consequences, because confused staff become angry staff, angry staff leak to the press, and leaked details become a bigger story than the breach itself.

Here is how to do it well.

Important Disclaimer

This article is intended for educational and defensive purposes only, and the guidance shared here is meant to help security and communications professionals handle incident communication responsibly.

The author assumes no liability for any damages, legal consequences, or other outcomes resulting from the use or misuse of this information, so always work with your legal counsel and communications team before issuing any formal breach communication, and stay legal, stay ethical, stay responsible.

Why This Is Harder Than It Sounds

Technical people explain things by building up from details, while non-technical people understand things by starting with meaning.

When a security engineer says an attacker exploited a SQL injection vulnerability to exfiltrate records from the customer database, they are doing what comes naturally, and they are being precise, but the person listening hears none of that, because they hear database and records and customer, and they immediately think about whether their salary is in there, whether their address is in there, and whether their family is in danger.

The gap is not intelligence, it is context, because your staff do not have the mental model that makes your explanation make sense, and no amount of technical detail will build that model in a fifteen-minute meeting.

So the first rule is this, start with what it means for them, not with what happened.

The Five Questions Every Employee Is Asking

Before you write a single word of your briefing, understand what people actually want to know, because every non-technical employee facing a breach is asking some version of five questions.

1. Am I affected? This is the first thing on everyone's mind, not the company, not the customers, not the regulators, but them.
2. What information was taken? They need specifics, because "some data" is not an answer, so was it their name, their address, their bank details, their health records, or their National Insurance number.
3. What does this mean for me right now? Do they need to do something today, do they need to change a password, watch their bank account, or check their credit.
4. Was it my fault? This is the question nobody says out loud, but almost everyone thinks, because if the breach involved a phishing email, half the room will quietly wonder if they were the one who clicked.
5. What is the company doing about it? They need to know that someone competent is handling it, and that it will not happen again tomorrow.

Answer these five questions clearly, and you have done ninety percent of the job.

What to Say in the First Meeting

Here is a structure that works, and while it is not the only structure, it is reliable.

1. Open With the Bottom Line

Do not build up to the news, lead with it.

"We discovered on Tuesday that an attacker accessed some of our systems, some employee information may have been exposed, and I am going to tell you exactly what we know, what we do not know yet, and what we are doing about it."

That takes fifteen seconds, and it answers the biggest question before anyone has to ask it, so everything after that is detail.

2. Say What You Know

Give the facts in plain language, not the technical facts, but the relevant facts.

"We know the attacker got in through a vendor account that had more access than it should have, we know they were in our systems for about four days, and we know they accessed files that contain names, addresses, and National Insurance numbers for around two hundred employees."

Notice what is missing, because there is no mention of the specific vulnerability, the attack technique, or the tools involved, since none of that helps your audience, and all of it creates confusion.

3. Say What You Do Not Know

This is the part most teams skip, and it is the part that builds the most trust.

"We do not yet know whether salary information was accessed, we do not know if the attacker shared the data with anyone else, and we expect to have answers on both of those within a week."

Admitting uncertainty is uncomfortable, but it is also the single most effective way to sound credible, because people trust someone who says "I do not know yet" far more than someone who claims to have everything under control.

4. Say What It Means for Them

Now, and only now, get specific about impact.

"If you are in the affected group, you will receive a separate email today with your specific details, and that email will tell you exactly what information was involved and what steps we recommend, but if you do not receive that email, your information was not in the files we know about."

Specificity here prevents the worst outcome, which is two hundred people all assuming they are affected, and all calling the same help desk at the same time.

5. Say What Happens Next

Give people a timeline and a contact.

"Here is what happens next, today you will receive your individual notification, tomorrow we will hold drop-in sessions with our security team so you can ask questions, and next week we will publish a full summary of what happened and what we changed, so if you have urgent concerns, here is the email address and here is the phone number."

A clear timeline turns panic into patience.

6. Say It Was Not Their Fault

If there is any chance people are blaming themselves, address it directly.

"Nobody in this room did anything wrong, because the access came from a third party account that we did not properly restrict, and that is on us to fix, and we have already fixed it."

This sentence costs nothing, and it prevents weeks of quiet anxiety.

What Not to Say

Just as important as what you say is what you avoid.

• Do not use jargon. No lateral movement, no exfiltration, no threat actor, because every technical term you use creates distance between you and your audience, so speak like a human.
• Do not blame the attacker. Saying we were targeted by sophisticated criminals may be true, but it sounds like an excuse, because your staff do not care who did it, they care whether it can happen again.
• Do not over-promise. Do not say your data is completely safe now unless you can prove it, because if something else comes out later, you will have destroyed your credibility permanently.
• Do not minimize. Phrases like "a minor incident" or "no cause for concern" make people furious when they later discover their bank details were exposed, so let the facts speak for themselves.
• Do not go silent. The worst thing you can do is hold one meeting, and then say nothing for three weeks, because silence fills with rumor.

Real Scenarios

Scenario 1: The Phishing Breach

The Situation

An employee clicked a phishing link, entered their credentials, and the attacker used those credentials to access a shared drive containing HR files.

The Challenge

Half the room will assume they were the one who clicked, and the other half will be quietly furious at whoever did.

How to Handle It

Do not identify the individual, and do not speculate, but say directly that this was not a case of someone being careless, because the email was extremely convincing, and it would have fooled most experienced people, including you.

Then focus on what changes, because you have added phishing-resistant authentication, so that even if someone enters their credentials on a fake page, it will not work.

That reframe moves the room from blame to solution.

Scenario 2: The Vendor Breach

The Situation

A third-party provider that handles payroll was breached, and your employee data was in their systems.

The Challenge

You are being asked to explain something that happened at a company your staff have never heard of, and you have limited information about what occurred.

How to Handle It

Be honest about the limits of your visibility, because the breach happened at a company we use to process payroll, we do not control their systems, and we are still learning the details, but what we do know is that our contract requires them to notify us within twenty-four hours, and they did.

Then focus on the action, because we have asked them for a full report, and we are reviewing whether to continue using them, so in the meantime, here is what you should do.

Owning the vendor relationship, rather than deflecting to it, keeps trust intact.

Scenario 3: The Insider Incident

The Situation

A departing employee copied files before leaving, and some of those files contained customer and employee information.

The Challenge

This is not a technical story at all, it is a human one, and it makes people look at their colleagues differently.

How to Handle It

Avoid details about the individual, and avoid any language that turns the room into a courtroom, but say what matters, which is that a former employee accessed files they should not have taken, we identified it, we have involved the authorities, and we have changed how we control access to those files.

Then address the human side, because I know this is uncomfortable, the person responsible is no longer with the company, and we are focused on protecting everyone affected.

Stay factual, stay calm, and do not let the meeting become a gossip session.

Scenario 4: The Ransomware Incident

The Situation

Ransomware encrypted systems, and the attackers claim to have stolen data before encrypting.

The Challenge

Operations are disrupted, people cannot work, and there is real uncertainty about whether data was taken.

How to Handle It

Separate the operational disruption from the data question, because they require different answers.

"Here is what we know about operations, email is down, the file share is down, and we expect to have both restored by Thursday, so here is the plan for the next two days while we are working on that."

Then address data, because separately, the attackers claim to have taken files before encrypting, we are investigating that claim, and we will tell you what we find, even if the answer is uncomfortable.

When the operational news is bad, be extra clear about the data question, because uncertainty multiplies anxiety.

Scenario 5: The Breach With Regulatory Involvement

The Situation

The breach triggers notification obligations, and regulators are involved, so staff will read about it in the news.

The Challenge

You need to tell staff before they hear it from a journalist.

How to Handle It

Get ahead of the story, even if your information is incomplete.

"You may see this in the news tomorrow, so here is what is happening, here is what we have told the regulator, and here is what it means for you."

Then be clear about what they should do if they are contacted by media, because if a journalist contacts you, please do not comment, forward it to the communications team, and we will handle it.

Preparing people for external attention prevents a lot of accidental damage.

Practical Templates

The All-Staff Email

Subject: Important update about a security incident

Team,

I want to let you know about a security incident that we discovered on [date], because an unauthorized party accessed some of our systems, and some employee information may have been involved.

Here is what we know so far:

• [Fact one, plain language]
• [Fact two, plain language]
• [Fact three, plain language]

Here is what we do not know yet:

• [Open question one]
• [Open question two]

If your information was involved, you will receive a separate email today with the specific details and recommended steps, but if you do not receive that email, your information was not in the files we have identified.

Here is what happens next:

• Today: Individual notifications sent
• [Date]: Drop-in sessions with the security team
• [Date]: Full incident summary published

If you have urgent questions, contact [email] or [phone].

Nobody did anything wrong here, this is on us to fix, and we are fixing it.

[Name]

The Manager Briefing

Managers will get questions before anyone else does, so give them a one-page briefing with the same structure, plus a short list of answers to the questions they are most likely to receive.

• What happened, in one sentence
• What is affected, in plain terms
• What is not affected, in plain terms
• What staff should do
• What staff should not do
• Where to send questions they cannot answer

The FAQ Sheet

Prepare a short FAQ with the ten questions you know are coming, and update it as you learn more, then circulate it to managers and publish it on the intranet.

Quick Reference: Breach Communication Checklist

The Bottom Line

Explaining a breach to non-technical staff is not a technical task, it is a trust task.

Your staff will forgive a breach, but what they will not forgive is being talked down to, being kept in the dark, or finding out later that you knew more than you said.

So lead with the bottom line, speak in plain language, admit what you do not know, tell people exactly what it means for them, and follow up until the story is finished.

The breach is a technical failure, but the communication is a leadership one, so get the communication right, and you can come out of an incident with more trust than you had going in.

FAQ Section

Should I tell staff before the investigation is complete?

Yes, if the breach affects them or is likely to become public, because waiting for complete information means they hear it from somewhere else, which damages trust more than uncertainty does.

How much technical detail should I include?

Very little, so explain what happened in plain terms, focus on what it means for the audience, and save the technical detail for the security team and regulators.

What if I do not know who was affected yet?

Say that clearly, and give a timeline for when you will know, because "we do not know yet, and we expect to know by Thursday" is a complete and acceptable answer.

Should I apologize?

Yes, if the breach resulted from your own failure, because a direct, unqualified apology lands better than a defensive one, so say that this happened because we did not restrict access properly, and that it is on us.

How do I stop people blaming a colleague who clicked a phishing link?

Address it before anyone asks, say directly that the lure was convincing, that most people would have clicked, and that the fix is technical rather than personal.

What if the breach becomes public before I finish communicating internally?

Get ahead of it immediately, send a short message confirming what is happening, tell staff what to do if media contacts them, and follow up with detail as it becomes available.