There is a scene that plays out more often than the cyber security industry likes to admit. A finance officer at a mid-sized organisation, let us call her Emma, has been with the company for over a decade. One morning, she receives an email that appears to come from HR, referencing a sensitive personal matter. She clicks. A landing page tells her she has failed the test. By the end of the day, she is in tears at her desk. By the end of the week, she is asking about leaving.
The programme that sent her that email had been described, the previous year, as “human centred.” It had a friendly logo. The training videos were animated. The vendor’s brochure used the word “empathy” three times. And it had, in one morning, done real harm to a real person.
This is why we talk about trauma informed security awareness. Not because the phrase is fashionable, but because the gap between what programmes claim to be and what they actually do to the people sitting in front of them has become too wide to ignore.
What Trauma Informed Actually Means
Trauma informed practice did not start in cyber security. It started in healthcare, social work and education, where practitioners spent years working out how to design services that did not retraumatise the people they were meant to help. The principles that emerged are surprisingly portable. Safety. Trustworthiness. Choice. Collaboration. Awareness that any given person in front of you may be carrying experiences you know nothing about.
When you bring those principles into security awareness, the work changes shape. You stop designing programmes as if everyone in the audience is a healthy, well rested, neurotypical employee with no personal history that might intersect with what you are about to show them. You start designing programmes that assume people are human.
That single shift, taking the human reality of your audience seriously, changes almost every decision you make. It changes the scenarios you choose for phishing simulations. It changes the language on your landing pages. It changes how you respond to someone who clicked. It changes the way you measure success.
What It Looks Like When a Simulation Lands Badly
Most security teams know, at some level, that their phishing simulations sometimes land badly. They hear it through HR. They see it in the angry tickets. They feel it in the awkward silences in town halls. What is often missed is just how badly, and to whom.
We have spoken to people who clicked a simulated phish about a family bereavement and then had to spend the rest of the day at work trying to compose themselves after reliving their own recent loss. We have spoken to people who clicked a simulated phish dressed up as an HR investigation and spent the next week genuinely believing their job was at risk. We have spoken to neurodivergent colleagues who clicked a particularly aggressive simulation, were publicly named in a leaderboard, and never trusted their security team again.
In every one of those cases, the security team thought they were running a clever, realistic campaign. The vendor brochure told them realistic was good. The board liked the numbers. Nobody asked what the campaign was doing to the people inside it.
A trauma informed approach does not mean refusing to ever send a difficult simulation. It means asking, before you send anything, who in this population might be hurt by this, what we will do if they are, and whether the learning outcome is worth the cost.
Why the Language of Failure and Being Caught Needs to Go
The vocabulary of security awareness has been imported, almost without thinking, from a particular kind of military and adversarial culture. We talk about people being “caught” by phishing tests. We talk about “failure rates.” We tell staff they have been “tricked.” We design landing pages that congratulate the attacker and admonish the victim.
That language tells the person on the receiving end a very specific story. You were stupid. You let us down. You are the problem.
That language is unkind. It is also operationally counterproductive. People who feel shamed do not report future incidents. People who feel publicly tracked do not raise their hand when something looks off. People who believe security exists to catch them out start working around security, not with it.
The language that replaces it is not soft. It is precise. People did not fail a test; they encountered a simulation. They did not get caught; they responded the way a real attacker would have wanted. They did not fall for anything; they were targeted by something designed by professionals to be difficult to spot. Naming the asymmetry honestly is more respectful, and more accurate, than pretending the contest was fair.
How to Tell Whether a Programme Is Trauma Informed or Just Rebranded
A lot of vendors are now adding the word “empathy” to their slide decks. A few have added “trauma informed” to their websites. Most have changed nothing about the underlying product.
There are practical signals that tell you which is which:
A trauma informed programme has thought carefully about which scenarios it will not run. It does not send simulations that mimic bereavement notices, redundancy letters, immigration paperwork, medical results or safeguarding concerns, unless there is a very specific operational reason to do so and a clear support pathway behind it.
- A trauma informed programme treats the moment after the click as the most important part of the design. The landing page is calm in tone. It does not shout. It does not use red. It does not display the person’s name in a public report. It tells the user what just happened, why it mattered, what to do next and, importantly, that they are not in trouble.
- A trauma informed programme builds in a support route for the people who need one. If the simulation has touched a nerve, there is a named human being to talk to, not a generic inbox. The security team works with HR, occupational health and employee assistance providers before campaigns go out, not after the complaints arrive.
- A trauma informed programme measures what matters. It tracks reporting rates, time to report, repeat reporters and the health of the relationship between staff and the security function. It does not lead with click rate league tables, and it does not name and shame.
- A trauma informed programme listens to its neurodivergent colleagues, its colleagues with caring responsibilities, its colleagues who have been victims of crime, fraud or coercive control, its colleagues who have lost someone recently. It listens before it designs, not after it has caused harm.
- A trauma informed programme has a written policy on what happens when something does land badly. It does not improvise. It treats those moments as serious, learns from them and changes the design.
If a programme cannot point to any of those things, the word “empathy” on the brochure is decoration.
The Work Is Worth Doing
Building a trauma informed security awareness programme is more demanding than the alternative. It asks more of the security team. It asks more of the vendor. It asks more of leadership, who must be willing to give up the comfort of a simple click rate number.
What you get in return is a workforce that reports incidents instead of hiding them and that trusts the security function instead of avoiding it. You also get something harder to measure, which is the knowledge that your security programme is not adding to the load of people who are already carrying a great deal.
If you would like to talk about what trauma informed security awareness might look like inside your organisation, whether you are starting from scratch or rethinking a programme that is not working the way you hoped, we would be glad to hear from you. You can reach us at hello@unitysolutions.org.uk.
