The Overconfidence Tax: UK Security Failures 2026 | The Small Business Cybersecurity Guy

Let me give you a statistic that should bother you more than it probably does.

Fifty-eight per cent of UK business leaders rank cyber breaches as their number one business risk for 2026. Three quarters of those same leaders doubt their organisation’s ability to manage a breach when it happens.

They know. They just haven’t done anything about it.

That gap, between knowing the risk and actually fixing the underlying problems, is what I’ve been calling the overconfidence tax. It’s the premium businesses pay, measured in incident response costs, ICO fines, customer churn, and reputational damage, for the privilege of feeling reasonably secure without actually being so.

The DSIT Cyber Security Breaches Survey puts the average cost of a significant cyber attack on a UK business at £195,000. That’s before legal fees, regulatory investigation, or the longer-term consequences of losing customer trust. For a business with thirty employees and margins that don’t leave much room for disasters, that’s an existential number.

And most of the time, it was preventable.

The Confidence Gap Is Not About Ignorance

Here’s what frustrates me about the way this gets discussed in the industry. The standard framing is that businesses don’t know enough. They need more education, more awareness campaigns, more Cyber Essentials posters in the break room.

That is not the problem.

The businesses I have spent decades watching get breached are not, in the main, ignorant. They have security tools. Many of them have certifications. They have heard the warnings. They believe the warnings. They just have a set of confident-sounding narratives that explain why the specific things on their risk backlog are not as urgent as they appear.

“We’ve already got a tool for that.” “Our environment is quite unusual.” “That finding was rated medium, not critical.” “We went through this last year.”

Each of those sentences can be true. None of them mean what the person saying them thinks they mean.

The Four Myths I Keep Hearing

Myth one: we’ve got a tool for that.

Security tools are not security outcomes. They are the capability to achieve security outcomes, if configured correctly, monitored actively, and acted on when they produce alerts.

A significant proportion of UK businesses have endpoint protection software that is generating alerts nobody is reading. They have MFA purchased but not enforced on all accounts. They have firewall rules that haven’t been reviewed since the system was set up by someone who no longer works there.

The tool exists. The security does not.

The ICCSO put it well in a recent analysis: cybersecurity in 2026 is not suffering from a lack of tools, frameworks, or awareness. It is suffering from misplaced confidence. Organisations believe they are reasonably mature because they have invested in the right products. The investment and the outcome are being conflated.

Myth two: our setup is unique.

This is a peculiarly persistent belief, and I understand why it exists. Every business has its own processes, its own legacy systems, its own particular combination of applications cobbled together over fifteen years. It feels unique because it is yours.

Threat actors do not share this perspective. They are not interested in the particulars of your environment. They are looking for one of a small number of well-understood weaknesses: an internet-facing service with known vulnerabilities, credentials that have been exposed, accounts with more access than they need, users who can be manipulated.

Your bespoke accounting integration with the 2019 middleware layer does not make you harder to breach. If anything, bespoke setups tend to have more unreviewed corners, more exceptions to standard security controls, more “we’ll deal with that eventually” items on a list that never gets shorter.

Myth three: that finding was only theoretical.

This is the one that bothers me most, because it is so clearly a resource allocation decision dressed up as a risk assessment.

When a penetration test or vulnerability scan returns a medium-severity finding, the correct response is to assess whether the risk is acceptable given your specific context. The response I see most often is to file it under “theoretical” and move on, because fixing it would cost time and money and the auditor said medium, not critical.

Here is the problem. Attackers do not respect your severity ratings. A patient attacker with initial access to a low-value account, combined with excessive permissions that should have been cleaned up eighteen months ago, combined with an unpatched internal system that was rated medium because it’s not internet-facing, can cause catastrophic damage. This is not a hypothetical. It appears in post-incident reports with enough regularity that the NCSC has written guidance about it.

Multiple medium findings, each individually tolerated, chain together into one very bad day. Corrine Jefferson made this point on Monday’s podcast more crisply than I’m managing here: the exploitation phase may look sophisticated. The entry point usually is not.

Myth four: the dashboard looks calm, so we’re fine.

I have seen this one end careers. Twelve security products. Beautifully formatted management reports. Nobody quite sure who is responsible for actually acting on what any of them are telling them.

Complexity, without clarity about ownership and response, is not a security posture. It is a liability. And the dashboard looks calm right up until the moment someone checks whether the alerts have been configured correctly, which in a depressing number of cases they haven’t been.

The Shadow SaaS Problem Is Getting Worse

Here’s a specific version of the overconfidence problem that I want to address directly, because it is accelerating.

Your staff are using tools you haven’t approved. Not because they are trying to cause problems. Because they are trying to do their jobs, and the officially approved route is slower or clunkier than the alternative they found.

Someone on your team has signed up for an AI-assisted meeting notetaker using a company email address. Someone has connected a third-party automation tool to your customer records. Someone is regularly pasting client information into a large language model to help draft emails.

In each case, data is leaving your control and going somewhere you haven’t assessed, under terms you haven’t read, in ways that may or may not be compliant with your GDPR obligations or your client contracts.

The confident-sounding response to this is: “We have a policy that prohibits unauthorised tools.” The useful response is: “We have a policy, and we also know exactly which tools our staff are actually using, and we have either approved them or replaced them with something better.”

Those are very different situations.

The Ponemon Institute estimates that insider incidents, including accidental data exposure through shadow IT, account for over a quarter of data breaches. This is not about malicious insiders. This is about well-intentioned people using convenient tools in a policy vacuum, because leadership never got around to creating a workable alternative.

The Permission Creep Nobody Wants to Fix

While I’m on the subject of things that everyone knows about and nobody wants to deal with: excessive account permissions.

It’s boring. Cleaning up access rights is administrative, unglamorous, and time-consuming. It also happens to be one of the most effective things a small business can do to reduce the blast radius of any breach that does occur.

Every account in your organisation should have the minimum access required to do the job it’s there to do. In practice, most businesses have accounts that started with standard access three years ago and have gradually accumulated additional permissions every time someone needed something in a hurry. Nobody revoked anything because revoking things causes friction.

The result is that when an account is compromised, whether through credential theft, phishing, or social engineering, the attacker has far more access than the compromised account should ever have had.

This is not a sophisticated attack vector. It is a structural weakness that costs almost nothing to address, requires no new tools, and dramatically limits the damage from any number of threat scenarios.

What Resilient Businesses Look Like

I want to be clear that I’m not describing an impossible standard. The businesses that navigate security incidents with limited damage are not the ones that have the most tools or the highest compliance ratings.

They are the ones that know what’s actually running in their environment. They patch the obvious things when they should be patched, rather than when it becomes convenient. They have cleaned up their account permissions, not because an auditor told them to, but because someone took the time to do it. They have a process for raising concerns that produces action, not eye-rolls.

And critically: someone in the business knows what “normal” looks like well enough to notice when something isn’t.

That last one is harder to buy than it sounds. It requires attention, institutional knowledge, and a culture where the people closest to the systems feel empowered to raise problems without worrying about the reception.

How to Turn This Into a Competitive Advantage

The overconfidence gap is not just your problem. It is your sector’s problem. Which means if you close it, you are ahead of most of your competitors.

Suppliers and clients are increasingly asking security questions before they sign contracts. Cyber Essentials v3.3, going live in April 2026, tightens the requirements around MFA, cloud services, and device management. The Cyber Security and Resilience Bill, expected to pass into law later this year, will expand regulatory scope significantly.

Businesses that have already done the unglamorous work: cleaned permissions, addressed the backlog, created a real process for concern-raising, governed their SaaS estate, will find certification and compliance considerably easier than those that haven’t.

More importantly, they will have fewer £195,000 afternoons.

How to Sell This to Your Board

Four arguments, none of which require a technology discussion:

1. This is a financial risk, not a technology risk. The average significant incident costs £195,000. That is not an IT problem. That is a balance sheet problem.

2. The liability is personal. The NCSC’s Cyber Governance Code of Practice establishes that cyber security is a board-level responsibility. Directors have statutory duties under the Companies Act 2006 to protect company assets. Digital assets are company assets.

3. The regulatory environment is tightening. The Cyber Security and Resilience Bill is progressing through Parliament. ICO enforcement is increasing: the average fine in 2025 was £933,000. Ignorance of a known risk is not a mitigating factor.

4. The fixes are not expensive. Cleaning permissions costs staff time, not budget. Addressing the patch backlog costs some planned downtime. Creating a process for concern-raising costs a weekly meeting slot. The cost of not doing these things, on the other hand, is well-documented.

What This Means for Your Business

Audit your tool estate. For every security product you are paying for, identify: who is responsible for it, what alerts it is generating, and when those alerts were last reviewed. If you cannot answer all three, you have a tool. You do not have security.
Run a shadow SaaS audit. Ask your team, without judgment, what tools they are actually using. You will hear about AI applications, third-party integrations, and browser extensions that you did not know existed. Assess each one and either approve it with appropriate governance, replace it, or discontinue it.
Review your permission structure. Start with accounts that have admin or elevated access. For each one, ask: is this level of access genuinely required? If the answer is “probably not, but it was easier to leave it,” that is your answer.
Revisit your medium findings. Pull up the last vulnerability scan or penetration test report. Look at every medium finding that was not remediated. For each one, document why. If the reason is “inconvenient,” schedule it.

Sources

Source	Article
DSIT / UK Government	Cyber Security Breaches Survey 2025
NCSC	Cyber Security: Board Toolkit
NCSC	10 Steps to Cyber Security
Infosecurity Magazine	Cyber Breaches, Compliance and Reputation Top UK Corporate Concerns
ICCSO	The Cyber Threat Landscape in 2026: What Organisations Are Still Underestimating
Ponemon Institute	Cost of a Data Breach Report 2025
Marsh	Cyber Risk Predictions for 2026
UK Parliament	Cyber Security and Resilience Bill — Progress

Related Posts: