When something happens in an organization, the story goes around anyway, and that is a fact. Someone shares the little they know in a chat group, someone else adds what they imagine, and within days the story going around no longer resembles what happened. Meanwhile, the version that explains step by step how the scam worked turns up nowhere. And it is the only one that would keep it from happening again. Why does it stay locked away? Because telling it in full seems to force us to name who it happened to, and the story stalls right there. That is a shame, because your own incident is the strongest awareness material an organization has, and it is already paid for.
Why does your own incident teach more than a textbook example?
Because a textbook example describes a scam that worked somewhere else, and your own incident describes one that worked here. For the person listening, those are two very different things. With the outside example we have to fill in the rest ourselves, because we have to imagine what that email would look like in our own role, with our systems and with the people who write to us every day. When the account comes from inside there is nothing to imagine, because it carries the names of the tools we use, the kind of request that circulates here and the moment when a request like that does not stand out.
There is something more that no purchased content can provide. Your own incident proves that it happens here. While risk is explained with other people’s cases, we tend to listen the way we listen to the news, with interest and with the sense that it happens to someone else. A case of our own closes that distance better than any statistic.
That said, that same strength is what makes it delicate. The account that teaches the most is also the one that most easily leaves a person exposed, so before telling it we have to decide how it gets told.
What to strip from the account before telling it
The name is the first thing to go and it is the easy part. The hard part comes next, because a detailed account carries plenty of details that rebuild the person without naming them: the department when it is small, the day and the hour, the client that appeared in the email, the amount, the system version only one team uses. With those details side by side, the people who work with that person know who we are talking about.
Here a simple criterion comes into play, and it is the full mechanism and the minimum context. Nothing comes out of the mechanism, since that is where the learning sits. And how much context is the minimum? Whatever it takes to understand the scam, and not one detail more. Suppose the draft is ready and the team of the person involved reads it. If from there they can point at them, we still have work to do.
What stays in the account describes the attack, and none of it points at a person:
- The request and the channel it arrived through. What the message asked for, with what urgency and how it came in, so we can recognize the same attempt next time.
- The signal that was in plain sight. The detail that did not add up, told without irony, because it looks obvious once we know the ending.
- How it was detected and what stopped it. The alert, the verification call or the control that fired, which is the part that shows the system did its job.
And one more thing, which is not about the text. The person involved is told beforehand, even if the account goes out with none of their details in it. Finding out from an internal bulletin that your own story is being used as training material makes the next story stay unspoken.
When is it told?
Having no written decision about this is the norm. The UK Government’s Cyber Security Breaches Survey 2025/2026 measured that 57% of medium businesses and 76% of large businesses have a formal incident response plan, which leaves one in four large organizations without one at all. And what the survey counts as a plan is who to notify, who does what and when to report externally. Telling the incident internally, so that the organization learns something, is not on that list.
It does not get told while containment is under way. In those hours the account competes with the work of resolving it, and what happened is not yet clear, so whatever goes out will be the first version, the one that usually gets corrected a few days later. Nor is it told so late that the organization has filed it away, because an account that lands once the subject has cooled reads like paperwork.
The window that works best is once the incident is closed and we still remember that something happened. At that point there is a curiosity that later fades, and that curiosity is attention we did not have to manufacture, the same attention that costs so much to get the rest of the year. Letting it pass is expensive, because the same story told months later needs an enormous effort for anyone to read it.
The account has a second life, though. When new people join, the incident that is old news to us becomes useful information again. For them it is not old news, and it explains better than any policy why we ask for what we ask for.
The tone decides whether anyone speaks up next time
This is the expensive part to get wrong. An account that ends in a moral reads like a warning, and we quickly work out what is in store if it ever happens to us. What breaks there is the reporting channel. The next person it happens to will take a few more hours to speak up, or will try to fix it alone first, and the time between the mistake and the alert is what decides the size of the incident. A single badly written message can cost a programme much of the trust it took years to build.
There is a rule that is simple to apply once we keep it in mind, and it is that the subject of the sentences in the account is the scam and the system. The email asked for this, it arrived from an address close to the supplier’s and it looked plausible because requests of that kind arrive that way here. All of that describes the attack precisely and leaves one person’s decision out of the account. There is no need to add that nobody was to blame either, since naming blame installs it.
And there is a part of the account that weighs more than it seems, which is the ending. If the story ends in how it was detected, with the name of the control or the channel that stopped it, what stays with us is the reflex of speaking up, and that is exactly the behaviour we want next time.
What to do when the incident cannot be told
Sometimes it cannot, and the reasons are good ones. There is a client involved, an open investigation, a notification duty with its own deadlines or a contract that sets out what can be said. When that happens, waiting until it can be told usually amounts to never telling it. Is the lesson lost then? Not all of it, because we still have the displaced version, which tells the mechanism without the case.
Instead of “this happened to us”, the message warns that a request of this kind is circulating, with these characteristics, and explains how to verify it before replying. It loses the proof that it happens here, which was the most valuable part, and it gains something that makes up for a good deal of that, because it can go out while the mechanism is still active.
The other way out lasts longer, because rather than communicating it turns the mechanism into something we can use again.
From one-off anecdote to material that lasts
A story told once reaches as far as it reached that day. In time there are new people, people who were on leave and people who skimmed it, so for the incident to keep teaching we have to take it out of bulletin format and move it into the programme.
The most direct way is to carry the mechanism into a simulation of our own. In phishing simulations from SMARTFENSE you can edit the predefined content or create new content from scratch, so the same kind of request, with the same style of sender and the same excuse, goes back into circulation weeks later with nobody exposed. For whoever performs the risky action, a Teachable Moment explains right then what happened and how to recognize the scam next time, with a validation question that confirms the content was read.
There is a limit worth respecting here, and it is stricter than the one for the bulletin. The simulation replicates the mechanism and leaves the case out. If it reproduces the incident with its recognizable details it exposes the person who lived through it all over again, this time in front of the whole organization and with the programme’s stamp on it.
The rest of the uses are calmer and call for no difficult decision. The mechanism goes into the material for people who are joining, comes back once a year as a reminder and gives the internal policy the example it was missing.
Which version do you want going around?
Back to the versions from the start. The story is going to circulate either way. The only thing the organization decides is which version has the details, explains the mechanism and reaches everyone, and that decision is taken in the days after the incident or lost.
All in all, the version that works has a fairly recognizable shape. It tells precisely how the scam worked, it lets nobody be singled out, it ends in how it was detected and it leaves us with a clear idea of what to do if something similar arrives tomorrow.
If something has already happened in your organization and nobody has told it yet, this may be a good moment to write that version. Because we have already paid for the incident, and what remains to be decided is whether it also teaches us something.
Leave a Reply