Teaching Cybersecurity to People Who Will Never Write Code
Earlier in this series
Here is an unpopular opinion from someone with a cybersecurity engineering degree: the security field does not primarily have a shortage of engineers. It has a shortage of understanding among everyone else.
The people who approve budgets, write laws, sign contracts, and click links are almost never engineers. Yet nearly all security education is aimed at the small group who already speak the language. We keep training the translators and ignoring the audience.
This piece is my manifesto for the other direction. It is also a description of my method, so you can steal it.
Why literacy beats another certification
Think about the decisions that actually determine whether an organisation or a country is secure:
- A minister decides which sectors count as critical infrastructure.
- A CEO decides whether the security budget survives a bad quarter.
- A procurement officer decides which vendor's promises to believe.
- A finance clerk decides whether an urgent invoice email is real.
Not one of these people will ever write code. Every one of them is making a security decision. If they cannot reason about risk, no number of certified engineers downstream can fully compensate, because the engineers inherit decisions already made badly.
I did not learn this at university. I learned it in three-plus years of B2B sales before I ever touched a firewall professionally. In sales you discover quickly that the buyer's understanding, not your product, is the bottleneck. Later, as an ICT sysadmin in Kuala Lumpur for five years, I ran end-user training and support. Then I led security at a startup I co-founded, where I had to convince my own developers and my own co-founders. Then I worked in a telecom security operations centre, explaining live incidents to people who needed decisions in minutes. The audience kept changing. The problem never did.
The method
Over those years I converged on a small set of rules. None of them is clever. All of them are disciplines, which means the hard part is not knowing them but refusing to break them.
Rule 1: One concept per block
A paragraph, a slide, a table — each carries exactly one idea. When I explain phishing, I do not also explain malware. The single biggest failure mode in technical teaching is bundling: three ideas in one sentence, each half-explained. Unbundle. It feels slow. It is faster.
Rule 2: Concrete before abstract
Never open with a definition. Open with a situation the listener already understands — a forged invoice, a stolen key, a fire drill — and only then attach the technical word to it. Definitions are labels for understanding, not sources of it. I keep a working set of these labels in Cybersecurity in Plain Language: A Policymaker's Glossary.
Rule 3: Use analogies honestly
Analogies are load-bearing in my teaching, but every analogy lies a little. So I state where it breaks, every time. "A vulnerability is an unlocked window — except a burglar can try a million windows per second, from another country, for free." The correction is not a footnote. It is often the actual lesson, because the breaking point of the analogy is usually exactly where digital risk differs from physical intuition.
Rule 4: Tables and checklists over prose
Prose is where nuance lives; tables are where decisions live. A non-technical reader can act on a checklist immediately. They cannot act on three paragraphs of caveats. When I want someone to understand, I write sentences. When I want someone to do, I write a checklist.
Rule 5: Respect the reader
My readers are not stupid; they are experts in something else. A minister understands incentives and institutions better than I do. A doctor understands triage better than most SOC analysts. Condescension is not just rude, it is wasteful — it throws away the listener's existing mental models instead of building on them.
What this looks like in practice
Here is the difference between engineer-speak and what I actually say:
| What the engineer says | What I say instead |
|---|---|
| "We detected anomalous authentication activity." | "Someone tried to log in as you, from a place you have never been." |
| "This CVE has a CVSS of 9.8." | "This flaw is as bad as it gets, and the fix exists. The only question is how fast we apply it." |
| "Users are the weakest link." | "We built doors that are hard to tell apart from traps, then blamed people for opening them." |
| "We need budget for detection and response." | "We have smoke detectors for the building. We have none for the network. This buys the detectors and the people who answer them." |
Notice what the right column does. It names an actor, a consequence, and usually a decision. That is what non-technical readers need: not less information, but information shaped like the decisions they own.
A checklist for anyone teaching this material
If you ever have to explain security to a board, a classroom, or a parliament committee, here is my pre-flight list:
- ☐ Can I state the one decision my audience owns in this topic?
- ☐ Does every block carry exactly one concept?
- ☐ Does every technical term get defined at first use?
- ☐ Does every analogy come with its breaking point?
- ☐ Is there at least one table or checklist the audience can act on tomorrow?
- ☐ Have I removed every sentence whose real purpose was to sound smart?
That last item is the hardest. Jargon is comfortable. It signals membership. Giving it up feels like giving up status. But every time I have traded status for clarity — with a buyer, an end user, a developer, an analyst on shift, a policy student — the room got measurably safer, because people finally understood what they were deciding.
Where this series goes
Everything I publish under this pillar follows the rules above. Next I want to apply them to a question I keep hearing from policy people: what does a national incident response team actually do all day, and why should a government pay for one? Then phishing, zero trust, encryption — each one concept at a time, each with the analogy and its breaking point.
If you will never write code, this series is for you. That is not a consolation prize. You are the audience that decides whether any of this works.