Confidence Is Not a Security Control: What Happened When Noel Left Us Unsupervised
Hello, Mauven here.
Noel left us two bottles of Prosecco, a microphone, and a topic. He was absent for this episode, which means you got three women with government, intelligence, and investigative journalism backgrounds talking about security culture without anyone to interrupt us. I expect he will have opinions about this. That is fine.
What we talked about matters. So let me give you the written version.
The topic was ego. Not the pop psychology kind. The expensive kind.
The kind that sounds reasonable. The kind that sits in a planning meeting and says “we’ll revisit that next quarter” while an attacker is already doing reconnaissance. The kind that buys twelve security tools, stares at a calm dashboard, and calls it done.
This is a problem for small businesses in particular. And I say that not to be unkind, but because the pattern is everywhere in the data, and it is costing UK businesses money and reputation that they cannot afford to lose.
The Entry Point Is Rarely What You Think
Corrine Jefferson, who spent years in intelligence before moving to the private sector, made the point cleanly: the exploitation phase of a breach may look sophisticated after the fact. The entry point usually is not.
Unpatched infrastructure. Excessive account permissions that nobody has cleaned up because it was tedious. Credentials reused across systems. A collection of medium-severity findings, each individually dismissed as theoretical, chained together by a patient attacker who was not working to your timeline.
This is not hypothetical. It is a pattern that appears repeatedly in post-incident reviews. The British Library attack in 2023. The Advanced Computer Software Group breach that resulted in a £3.07 million ICO fine in 2025. Multiple NHS supplier incidents. In each case, there were known weaknesses. In each case, there was a period during which someone in the business decided that the risk was manageable, the finding was theoretical, or the fix could wait.
The NCSC has been saying this for years. From a threat actor’s point of view, a business’s uniqueness is largely irrelevant. They are not trying to admire your architecture. They are looking for a workable path.
The Sentences That Precede Expensive Afternoons
On the podcast, we ran through what I called the greatest hits: the confident-sounding phrases that organisations use to explain why a known risk is not being addressed.
“We’ve already got a tool for that.”
Tools create capability. They do not guarantee execution. Buying MFA is not the same as rolling it out to every account. Having endpoint protection is not the same as checking what it is alerting on. Security maturity is measured less by what was purchased than by what you can verify is actually happening. These are not the same thing, and in many SMBs they are very far apart.
“Our setup is unique.”
Every business believes this. Some environments are unusual. But attackers do not require your environment to be generic in order to exploit exposed credentials, an unpatched internet-facing service, or accounts with excessive privileges. Uniqueness protects nothing.
“That finding is only theoretical.”
This one is particularly dangerous. It is frequently shorthand for “we do not wish to spend resource on this right now.” The practical problem is that multiple medium-severity findings, each individually tolerated, can be chained together following initial access. This is documented behaviour. It is not theoretical.
“The dashboard looks calm.”
Bought confidence. Twelve products. Lovely charts. Nobody quite clear on who is responsible for what. Buying confidence is easier than building resilience. They are not the same thing.
The Shadow Tools Problem
Lucy Harper raised something that often gets missed in the security conversation: staff who use unsanctioned tools are not usually trying to be reckless. They are trying to do their jobs faster, because speed is what gets rewarded.
Someone signs up for a project management tool on a company card because the approved one is too slow. Someone installs a browser extension that improves their workflow. Someone pastes client meeting notes into an AI assistant because it helps them write the follow-up email.
No policy. No governance. No decision about where the data has gone.
The responsibility for this sits with leadership, not with the individual staff member. Leadership created incentives for convenience and then appeared surprised when convenience was chosen. If your team is regularly using tools you have not approved, the question is not what is wrong with your team. The question is what gap in your approved tooling they are trying to fill, and what you are going to do about it.
What Psychological Safety Has to Do With Security
This is the part I want business owners to sit with.
In too many organisations, the people closest to the systems have an accurate picture of the risk. The junior engineer knows about the unpatched server. The IT contractor has flagged the excessive permissions twice. The office manager has noticed that a random third-party app has access to customer files and cannot get anyone to take it seriously.
The problem is not that these people do not exist. The problem is that when they speak up, they get pushback, eye-rolling, or the classic: “We’ll revisit that next quarter.” They learn, quickly, that being the person who raises awkward things does not advance your career in this organisation. So they stop.
And then organisations enter the post-incident review wondering why no one raised the alarm sooner.
Psychological safety, stripped of the corporate workshop language, means this: people can raise a concern before it becomes an incident, without fearing the consequences of doing so. That is a security control. It costs nothing to implement. It requires only that you respond to bad news with curiosity rather than defensiveness.
Organisations that survive incidents are not the ones that never make mistakes. They are the ones that surface mistakes faster, contain them sooner, and do not spend the post-incident review identifying the most junior person to blame.
Four Questions to Ask This Week
On the podcast, we proposed a practical audit. Not a tool purchase. Not a consultant engagement. Four questions to put to your team in the next five working days.
1. What have we delayed because it is inconvenient?
Not because the risk was assessed as acceptable. Because patching it would cause downtime. Because fixing the permissions would require a conversation nobody wanted to have. Because the vendor said not to worry. Make a list.
2. Who has more access than they need?
Admin rights granted three years ago for convenience and never reviewed. Service accounts with excessive scope. Shared logins that everyone uses because individual accounts were too much trouble to set up. List them.
3. What tools or AI applications are staff using that nobody has formally approved?
This one requires honesty. Ask the team directly and listen without judgment. You will hear things.
4. Where do people currently raise concerns, and what actually happens when they do?
If the answer is “they mention it in a meeting and hope someone follows up,” that is not a process. That is a hope. It is also a control failure.
How to Turn This Into a Competitive Advantage
Most of your competitors are not asking these questions. They are buying tools and calling it done.
If you can demonstrate to clients, partners, and suppliers that your organisation has a functioning security culture: that your team raises concerns through a real process, that known risks are being addressed rather than deferred, that you govern your use of AI and SaaS tools, you are ahead of most SMBs in the UK market.
This is increasingly valuable. The Cyber Security and Resilience Bill is progressing through Parliament and is expected to become law later in 2026. Customer and supplier security requirements are tightening. Cyber Essentials v3.3 goes live in April. The organisations that have already built the culture will have a much easier time meeting the requirements.
How to Sell This to Your Board
The board needs a business case, not a security lecture. Here is one.
The DSIT Cyber Security Breaches Survey 2025 found that 43% of UK businesses experienced a cyber incident in the past twelve months. The average cost of a significant attack is now £195,000. That is before legal fees, ICO investigation, reputational impact, or customer churn.
The four questions above cost nothing to ask. Addressing what you find costs a fraction of what a breach will cost. And the evidence is clear: the incidents that cause the most damage are overwhelmingly the ones where someone in the organisation already knew about the weakness and was not in a position to get it fixed.
The board’s job is to ensure the organisation is not in that position. This is a governance question, not a technology question.
What This Means for Your Business
-
Ask the four questions this week. Not next quarter. This week. Write down the answers.
-
Create one route for people to raise security concerns. A standing ten-minute slot in the weekly operations meeting is sufficient. It needs to be real, consistent, and visibly acted on.
-
Make a stop-doing list. Identify one convenience-led risk and either shut it down or formalise it. Shared logins. An unsanctioned SaaS tool. Customer data going into an AI application with no governance. Pick one.
-
Review delayed decisions. List the security fixes that have been deferred for convenience or meeting politics rather than evidence. Schedule the first one.
Listen to the Full Episode
The full podcast is available now on all major platforms. This episode features Corrine Jefferson and Lucy Harper joining me in Noel’s absence, which, as Noel will probably tell you himself on Saturday, he is quietly furious about.
Sources
Related Posts: