If the boss can’t follow the security advice, the advice is the problem.
Security decisions get made by people who were never given a plain explanation. After 20 years in IT, I think the jargon is a risk in its own right. Here’s what it costs and how to cut through it.
Somewhere in your business there is probably a security report nobody finished reading. It mentions threat actors, attack surfaces and lateral movement. It recommends EDR, or possibly XDR, and a move towards zero trust. Everyone nodded, somebody approved the spend, and nobody around the table could have told you what was bought. I think cyber security jargon is a risk in its own right, and after more than 20 years in IT I’d put it on the risk register alongside the things it’s used to describe.
Decisions get made by people who didn’t follow
Security decisions in most businesses are made by an owner, a finance director or a board. Those are the right people. They hold the budget and they carry the consequences. They are also, usually, not technical, and they have no reason to be.
So the quality of the decision depends on the quality of the explanation. If the explanation arrives in a language the decision maker doesn’t speak, one of three things happens. They approve it because the person asking seems confident. They refuse it because it sounds expensive and vague. Or they put it off until next quarter, which is a refusal with better manners.
None of those is a decision about risk. The business has spent money, or declined to, without anyone weighing what it protects against. I have seen sensible, cheap fixes turned down and expensive tools waved through, and the only difference was how well each one was explained.
Jargon stops people asking
There’s a moment in most meetings about security where somebody has a question and doesn’t ask it. They don’t want to be the one person who doesn’t know what a “privileged endpoint” is. The meeting moves on. That silence is where a lot of risk lives.
The unasked questions are nearly always the good ones. “Does that cover the laptops people use at home?” “What happens to this if Sam leaves?” “Are the backups included in that?” People who work in the business know where the odd corners are. A room that feels safe for plain questions finds those corners. A room full of acronyms doesn’t.
It reaches your team too. If the guidance says “report suspected credential compromise to the service desk”, a fair number of people won’t recognise that it means “tell us straight away if you typed your password into something dodgy”. You’ve written a rule that the people it’s aimed at can’t act on.
If the person who signs it off couldn’t explain it to someone else, the business hasn’t made a decision. It has made a guess.
Ashley Adkins, fromIT
Who the jargon really serves
I’ll be blunt about my own industry here. Some jargon is honest shorthand between specialists, and that’s fine. Engineers talking to engineers need precise words. The trouble starts when that shorthand is pointed at customers.
A long list of acronyms makes a product sound more substantial than “it watches your computers for anything suspicious and tells someone”. It makes a quote hard to compare with another quote. It makes an awkward question, such as “so what did we get for the money last year?”, harder to ask. And when something goes wrong, a cloud of technical language is a very comfortable place for a supplier to stand.
I don’t think most people in security do this on purpose. It’s habit. We learn the vocabulary on the way up and forget we ever didn’t know it. But the effect on the customer is the same whether it’s deliberate or lazy.
The same words in plain English
Almost everything in security can be said simply without losing anything that matters to a business decision. A few I’d translate on sight:
| What you’ll hear | What it means |
|---|---|
| Threat actor | The criminal, or whoever is attacking you. |
| Attack surface | All the ways somebody could get in: accounts, devices, websites, suppliers. |
| MFA | A second check when you sign in, such as an app prompt or a passkey, so a stolen password isn’t enough. |
| EDR | Software on each computer that watches for suspicious behaviour and can cut that machine off. |
| Lateral movement | Getting into one computer or account and using it to reach the rest. |
| Zero trust | Check every sign-in and every device each time, wherever it’s coming from. |
| Patch management | Installing updates promptly, and knowing which devices haven’t had them. |
| Least privilege | People can only get at what they need for their job. |
The National Cyber Security Centre manages to write its guidance for businesses in language like the right-hand column, and it keeps a public glossary for the terms it can’t avoid. If the UK’s national technical authority can do it, the rest of us have no excuse.
When it matters most
The worst time to discover that nobody understands each other is during a cyber incident. Decisions come quickly. Do we switch that server off? Do we tell customers today? Can people keep working? The person making those calls needs short, true sentences. “The attacker can read the finance mailbox and we don’t yet know for how long” is something a director can act on. A paragraph about indicators of compromise is something they have to ask to have repeated, and every repeat costs minutes.
The same goes for what you tell customers and staff afterwards. People forgive a lot when they’re told plainly what happened and what to do. They forgive much less when the message reads as if it was written to avoid saying anything.
What I’d do about it
- Ask three questions of anything you’re asked to approve. What does this stop? What happens if we don’t do it? What does it cost, including someone’s time? If the answers aren’t clear, the proposal isn’t ready.
- Make “say that again in plain English” a normal thing to say. Say it yourself, out loud, in front of others. It gives everyone else permission.
- Ask suppliers for a one-page summary with no acronyms. What they do for you, what they don’t, and what you’d need to do in an emergency. A good supplier can write that in an afternoon.
- Read your own policies as a new starter would. If a rule can’t be understood by the person it applies to, rewrite the rule.
- Write your incident plan in the words you’d use on the phone. Names, numbers and plain instructions. No one reads a glossary in an emergency.
- Judge advisers on how they explain. Being able to make something simple is a sign someone understands it. I’d treat fog as a warning.
There’s a reason this business is called fromIT and the first thing on the website is “Hi, it’s Ashley from IT.” Security advice should sound like a person you could ring up and ask. I’d rather be thought a bit plain than leave someone nodding at a sentence they didn’t follow.
So here’s a small test for this week. Take the last security report, quote or renewal you received and ask whoever sent it to explain one paragraph of it in everyday words. If they can, good, you’ll learn something. If they can’t, you’ll have learned something more important.
More on this. See every guide and story on these topics, or follow Ashley on LinkedIn for a short post most days.