Security Without Blame: The Culture That Reports in Minutes
Tuesday, 09:02, at Dunmore Textiles. Sana in sales clicks a link in an e-mail about a delivery and sees a sign-in page that looks nearly right. She types her password and realises as she presses enter that the delivery was not expected. At 09:04 she rings the desk and says "I think I have just done something stupid". By 09:30 her password is changed and her sessions are signed out everywhere. By then, the message has been pulled from the other forty mailboxes it reached. By then, the security contractor has a note with the times in it. Total cost: about an hour of the desk's time, and Sana's morning.
Eight months earlier, Rob in dispatch clicked a very similar link at lunchtime and said nothing for four days. He was not careless and he was not stupid. He had watched what happened to the last person who admitted a click. That person had been named in an all-staff e-mail "as a reminder to us all". And Rob had drawn the obvious conclusion. By the time Rob's account was noticed sending invoices to the mill's customers, the clean-up was a week's work and a round of apologetic phone calls. Same mill, same kind of link, same desk. The difference between two minutes and four days was not the two people. It was what each of them expected to happen next.
Security without blame means that a person who reports a mistake, including their own, is never worse off for having reported it. It also means everybody knows that in advance. It is not the same as no consequences for anything, and this article is careful about the difference. It is part of our The Helpdesk's Role in Security Culture series. This article is about the one condition under which the early-warning signals of the previous article arrive at all. People have to be willing to send them.
It covers why blame hides the thing you need to see, the two clicks side by side, and what no-blame means and what it does not. Next come the thank-you, every time, the manager's role, and why there is never a per-person list. Writing the statement and putting it where people see it, and keeping the rule when it is tested follow. A short war story and the no-blame statement to copy come last, in that order.
Why Blame Hides the Thing You Need to See
A click is not the incident. The hidden click is. The link Sana clicked was going to be clicked by somebody in a building of two hundred people, because the e-mail was good and people are busy. No training programme changes that arithmetic much. What the organisation controls is what happens in the minutes after the click. Reported at once, a click is a reset and a note. Hidden, it is an account that somebody else is using, for as long as nobody says anything. Every day it stays hidden the cost roughly doubles.
Blame teaches exactly one lesson, and it is "say nothing". People do not learn security from the policy. They learn it from what happened to the last person. If the last person was thanked and helped, the next one rings in two minutes. If the last person was named, lectured or made the subject of a meeting, the next one waits and hopes. That person tells the desk only when the account has already been noticed doing something. By then, the desk is the last to know rather than the first. Rob's four days were not a character flaw. They were a rational response to the evidence available to him.
This is why the desk has a stake in it. The previous article in this series, Spotting Incidents Early From the Queue, depends entirely on people bringing their odd mornings to the desk. They will only do that in a culture where the odd morning is safe to report. Every signal on that sheet is a person choosing to speak. Blame is the tax on speaking, and at a high enough rate nobody pays it.
The Two Clicks, Side by Side
The table below puts Sana's click beside Rob's, with the cost in hours, as a worked example from one fictional mill. The ranges are what the Dunmore desk reckoned afterwards, not a benchmark for anyone else's desk. And the point is the shape rather than the figures. The two-minute click is cheap in every column and the four-day click is expensive in all of them, including the one that does not show up on any timesheet.
| The click reported in two minutes | The click hidden for four days | |
|---|---|---|
| What the desk could do | Reset, sign out every session, remove the message from other mailboxes, tell the security contact; all before the account was used | Nothing until the account was noticed sending mail; by then the desk was reacting to what the account had already done |
| Desk time | Roughly one to two hours, including the note and the thank-you | Roughly twenty to forty hours across a week, including tracing what was sent and to whom |
| Other people's time | The security contractor's note: under an hour | Contractor days; the sales team ringing customers; the managing director's apology letter |
| What the person learned | Reporting fast is the right thing and is welcomed | Reporting is dangerous; next time, wait longer |
| What the desk learned | The early-warning signals work | Nothing it could use, because the signal never arrived |
| What everyone else learned | Sana was thanked; the e-mail was real; ring the desk | Whatever they inferred from the silence, which is usually worse |
The last row is the one that compounds. Sana's colleagues heard that she rang, that the desk thanked her and that it was sorted by half past nine. The next person who clicks at Dunmore will ring. The people who heard about Rob, and about the all-staff e-mail before him, learned to wait. A culture is nothing more than the sum of these stories, and the desk writes most of them.
What No-Blame Means, and What It Does Not
No-blame means one thing precisely: the act of reporting never makes a person's position worse. Not in the moment, not in their next review, not in an e-mail they are copied on. Somebody who rings to say "I clicked" is treated as a person who has just done the single most useful thing available to them, because they have. The mistake is handled as a technical event with a runbook. The person is thanked, helped and left with their dignity.
It does not mean that nothing ever has a consequence. A person who clicks every month is not in trouble for reporting, but somebody should notice that the training is not reaching them. And that is a conversation the security function or the manager has, privately, as training rather than discipline. Deliberate misuse is a different thing entirely. Take the person who copies the customer list to a personal account on their last day. That belongs to the security function and to HR. The desk's position is simple and it never moves: the desk does not adjudicate any of it. It thanks, it contains, it records the facts, and it hands the rest to the people whose job it is.
The line to say when somebody asks is "the person who reports is never worse off for reporting". It survives every edge case because it is about the reporting, not the mistake. Somebody who clicked five times and reported five times has been a model citizen five times. Whether five clicks says something about the training is a question for somebody other than the technician who did the resets.
The Thank-You, Every Time
The first words the desk says to a person who has just clicked decide whether they will ring next time. The words are "thank you for telling us straight away. That is the thing that matters most". Then the facts, the reset and the rest of the runbook in When Someone Clicked: The First Hour, which this article does not repeat. The thank-you goes first, before the questions, because the person is braced for something else. The moment they hear it their shoulders drop and they start giving you accurate answers.
Thank the reporters who were wrong just as warmly, the ones who forwarded a legitimate invoice or a real message from the chief executive. The whole machinery of thanking, the outcome message that says what the report caught, the monthly note and the careful handling of anything that looks like a leaderboard, is in Rewarding the Reporters. What this article adds is the reason it matters beyond phishing. A person who is thanked for a false alarm has learned that the desk would rather hear from them. That lesson transfers to the USB stick, the odd sign-in and the day they click.
The thank-you has to be real, which means the technician has to believe it. That means the desk lead has to say it to the technicians first. A desk that privately rolls its eyes at the fourth report of the same e-mail will leak that in its tone. Tone is the only part of the message the reporter remembers. If the desk is tired of reports, the fix is a rota for triage, not a cooler thank-you.
The Manager's Role
Blame mostly comes from managers, and so does its absence, so the desk needs managers on side and most of them will be if asked. The manager who says "thanks for telling IT so fast" in front of the team has done more for security culture in six words than the module did in forty minutes. The manager who says "which one of you was it?" in the same meeting has undone a year. Neither manager is a villain. The second one simply has never been told what their words do.
Tell them, in one paragraph, before an incident rather than during one. The paragraph says three things. When somebody on your team reports a security mistake, thank them for reporting it fast. Do not ask the desk or the team who it was unless you need to know for the work. And never forward the details on. The desk tells the manager what happened to the account and what the team needs to do, which is usually nothing. It does not deliver a verdict on the person, because it does not have one. Managers who have been briefed this way almost always comply, and several will thank you for the script.
When a manager wants more than the facts, the desk's line is "we report what happened to the account. Who was behind the keyboard is in the ticket, and the security function decides who needs to know". Said politely and consistently, it holds. The statement at the end of this article is signed by somebody senior. That is precisely so that the technician saying that line to a department head is quoting the organisation rather than arguing with it.
Never a Per-Person List
There is no list of who clicked, and the desk does not keep one, even privately, even for its own curiosity. The counts that matter are reports per month, time to report, and clicks per campaign if the organisation runs simulated phishing. They are all kept as totals and by department at most. The counting rules are in Measuring Reports and Clicks Without Shaming Anyone. A per-person list has one property that overrides all its uses: it leaks. It ends up in a manager's folder, then in a review, then in a corridor, and from the day it leaks the reporting stops.
The desk will know names anyway, because the desk did the resets. The names stay in the tickets, where they are facts about what happened to an account, and they go no further. A technician asked "who was it?" by anyone other than the security contact says "it is in the ticket, and the security team decides who needs that". That answer is not secrecy. It is the only arrangement under which the next person rings in two minutes.
If the organisation runs simulated phishing, the results by name are the most dangerous document it produces. The desk should have nothing to do with those results. The security function may use them for targeted training, quietly and one to one. The moment a list of names from a simulation is shown in a meeting, the simulation has taught the organisation the same lesson as the all-staff e-mail. It has taught it on purpose. A leaderboard of clickers has never once reduced clicking. It has reliably reduced reporting.
Remember: the person who reports is never worse off for reporting, and everybody knows it in advance. The desk thanks first, contains by the runbook, records the facts, and hands anything that needs a decision about a person to the security function. There is no list of names, anywhere.
Writing the Statement and Putting It Where People See It
The statement is a paragraph, not a policy. Policies are eleven pages and are read by the person who wrote them and the auditor. A paragraph says, in plain words, that reporting a security mistake will never count against you. It is signed by somebody whose name people recognise. Such a paragraph is read in twenty seconds and remembered. The template at the end of this article is one. Rewrite it in your organisation's voice and keep it under a hundred words. If it needs a second paragraph, the first one is not clear enough.
Put it in four places. In the new starter's first week, have it said aloud by whoever does the welcome and included in the day-one material that The Day-One Checklist describes. People decide what is safe here in the first month. Put it in the acknowledgement the desk sends to anyone who reports anything, as one line. That way, it is seen at the exact moment it is relevant. Put it on a page everybody can read without asking. If you run QuerySolv, a knowledge base article visible to everyone, not only to agents, is where the statement lives, beside how to reach the desk. And put it on the wall by the desk, where visitors and technicians both see it.
Say it in the moment, too. A person may ring with "I think I have just done something stupid". The technician can say "nobody here thinks that, and you will not be in any trouble for ringing. That is a promise the organisation has made in writing". Being able to point at the writing is what turns a kind technician into an organisation that means it.
Keeping the Rule When It Is Tested
The statement is easy to keep in a quiet month and is only worth anything in a bad one. The test comes the week after the worst incident the organisation has had. A director wants a name, the insurer wants a report, and somebody suggests that "this time" an exception is warranted. The rule either survives that week or it was never a rule, and everyone in the building will know which by Friday. A desk lead who has the statement in writing, signed, has something to stand behind. One who has only a good intention has a conversation they will lose.
The person who clicks for the third time is the second test. The desk thanks them for the third report exactly as it did the first, contains, and records. It tells the security contact that the same account has been reset three times this quarter. What happens next is the security function's and the manager's. It might be additional training, a different mail setup for a high-risk role, or a quiet word, and it is framed as help. The desk's tone with the person does not change. The moment it does, that person's fourth click will be a hidden one.
The audit is the third. Auditors ask for lists. The honest answer is that the organisation keeps counts and not names, on purpose, and here is the statement that says why. Most auditors accept that readily, since a culture that reports in minutes is the control they were hoping to find. The ones who insist are a conversation for the security function and the leadership, not for the desk. The desk's job in that conversation is to keep thanking people in the meantime.
A Short War Story: The All-Staff E-mail at Stonebridge Insurance
Helen, the operations director at Stonebridge Insurance, meant well when she sent the all-staff e-mail. A claims handler had clicked a link and reported it within the hour. The desk had contained it cleanly. Helen, wanting everyone to learn from it, described the incident in detail and named the handler "so we can all be more careful". The desk's security reports fell from about a dozen a month to two over the following quarter, and the two were from the technicians. The next real click, in underwriting, was hidden for nine days, until the account was noticed sending renewal reminders with the wrong bank details. The clean-up cost a weekend of two contractors and around forty hours of desk time. It also cost a month of the desk visiting every team to rebuild a reporting habit it had taken two years to grow. Helen withdrew the e-mail's approach in a second all-staff message, this time signed with the no-blame statement, and reports recovered by the spring. The lesson Stonebridge wrote down was that the e-mail had cost more than the click it was about. The lesson also said that the click had cost almost nothing.
The No-Blame Statement
The statement below is the one Stonebridge's second e-mail carried. It is short on purpose. Fill the signature with somebody senior whose name people know, because the statement's power is that a technician can quote it to a department head. The notes beneath it say where it lives and what managers are asked to do. They are for the desk and the managers, not for the statement itself, which stays a single paragraph in the organisation's own voice.
THE NO-BLAME STATEMENT — ONE PARAGRAPH, SIGNED If you think you have clicked something you should not have, given a password to the wrong page, plugged in a device you were unsure of, or noticed anything odd about your account, tell the help desk straight away. You will be thanked, and you will never be worse off for having told us. The sooner we know, the smaller the problem, and the people who report fast are the ones keeping this organisation safe. Nobody here will be named, listed or lectured for reporting. Signed: ______________________ Role: ______________________ WHERE IT LIVES [ ] Said aloud in the first week, and in the new starter's day-one material [ ] One line in the desk's acknowledgement to every security report [ ] On a page everyone can read, beside how to reach the desk [ ] On the wall by the desk WHAT MANAGERS ARE ASKED TO DO (the one-paragraph briefing) Thank anyone on your team who reports a security mistake, in front of the team if you can. Do not ask who it was unless you need to know for the work. Never forward the details. The desk will tell you what happened to the account and what, if anything, your team needs to do. WHAT THE DESK SAYS WHEN ASKED FOR A NAME "We report what happened to the account. Who was at the keyboard is in the ticket, and the security function decides who needs to know." WHAT NO-BLAME DOES NOT COVER Repeated clicks: a training matter for the security function and the manager, in private. Deliberate misuse: the security function and HR. The desk adjudicates neither.
Sana rang in two minutes because she had read a paragraph like this one in her first week and because the person before her had been thanked. That is the whole mechanism, and it costs nothing but consistency. The desk cannot stop people clicking. It can make sure that the next person who does has every reason to pick up the phone.
Frequently Asked Questions
Doesn't no-blame mean people stop being careful?
What about the person who clicks every month?
A director demands the name of the person who clicked. What does the desk say?
Should the statement be part of the security policy?
Do we tell the person's manager?
How do we know the culture is actually blameless, rather than just saying so?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.