Ask someone to picture a security breach and they will usually picture the same thing: a skilled attacker, somewhere far away, working through your defences with clever tools until they break in. It is a vivid image, and it is why so much security spending goes on better walls. The trouble is that it is not how most breaches actually begin. The real ones are duller and closer to home. They start with an account that should have been switched off months ago, a system nobody was quite responsible for, a password shared in a hurry, a rule that got bent once for convenience and never straightened again. When the attacker finally does arrive, they rarely break in. They walk through a door your own operation left open.
This is the uncomfortable reframing that matters. For most organisations, the biggest security risk is not a hacker. It is a process. The gaps that incidents exploit are operational: they are about who has access, who owns what, and what happens when things change. And because they are operational, you cannot buy your way out of them. No tool closes a door that nobody knew was open.
The breach you picture, and the one you get
The breach you picture is external, sophisticated, and technical. The breach you get is usually internal, mundane, and procedural. A former contractor's login still works because offboarding never reached the third system they were given access to. A shared drive holding sensitive files was opened up to the whole company years ago for one project and never closed. An administrator account uses a password that half the team knows because it was easier that way. None of these is an attack. Each is just the ordinary residue of a busy operation that grants access far more readily than it removes it. The attack, if it comes, is almost an afterthought. The vulnerability was manufactured in-house, quietly, over months.
The risks that never show up in a tool
Walk through where these gaps actually live and a pattern appears. Access outlives need: people join, change roles, and leave, and every one of those events is supposed to change what they can reach, but only the joining reliably does. Ownership goes missing: ask who is responsible for a given system or dataset and too often the honest answer is that nobody is, which means nobody is watching it. Credentials get shared: the informal password passed around a team, the service account whose login sits in a spreadsheet, the vendor given a standing key to save time. Shadow tools appear: departments adopt their own SaaS products, sensible in themselves, that security has never seen and cannot protect. And exceptions harden: a control gets switched off for one urgent case, and the switch is never flipped back. Not one of these is a hacking problem, and not one is something a firewall or a scanner will hand you on a report.
Why the gaps survive
These openings persist for the same reason operational problems always do: each one is individually small, nobody clearly owns it, and it stays invisible right up until the moment it is exploited. Removing a stale account or reviewing who can reach a system is deliberate, effortful work with no visible reward, competing against everything that feels more urgent. Keeping the gap costs nothing on any ordinary day. The person who could close it often does not know it exists, and the person who created it has moved on. So the risk sits in a blind spot, accumulating, exactly like a workaround that never got removed, except that the bill for this one arrives all at once and with your customers' data attached.
Security is an ownership question before it is a technical one
The way to close these gaps is not another product on top of the ones you have. It is to treat security as part of how the operation is run, which means answering ownership and process questions that no tool can answer for you. What systems and data do we actually have, and who owns each one. What happens to a person's access the day they change role or leave, across every system and not just the obvious ones. Who can reach our most sensitive data right now, and is that still the list it should be. When we grant a vendor access, what ends it. When we make a security exception, who owns it and when does it expire. Tools matter, and you should have the sensible ones, but they enforce decisions; they do not make them. A well-run operation with modest tools is safer than a poorly-run one with expensive tools, because the openings incidents use are made by process, and only process closes them.
A worked example
A company came to us after a scare, convinced they needed to spend heavily on new security tooling. Before they did, we looked at how access actually worked. The picture was familiar. Their joining process was crisp, so new staff got exactly the right access on day one. Nothing anywhere near as clean happened when people left or changed roles, so accounts and permissions had been piling up for years. We found active logins belonging to people who had left, a former vendor whose access from a finished project was still live, and a sensitive shared folder open to the entire company because of a need that had ended long ago. None of it involved an attacker. All of it was a way in. We did not start with a purchase. We built an honest inventory of systems and data, put a named owner against each, defined what had to happen to access when someone joined, moved, or left, and set a recurring access review so drift could be caught on a schedule rather than after an incident. The exposure fell sharply, and it fell before any new tool was bought, because the real problem had never been a shortage of tools. It had been a shortage of ownership.
Buy the discipline, not just the tool
Good security tools are worth having, and this is not an argument against them. It is an argument against believing they are the whole answer, because the risks that actually cause most incidents are not the ones tools are built to stop. They are operational gaps: access that outlived its purpose, systems without an owner, credentials shared for convenience, tools nobody sanctioned, exceptions that quietly became permanent. Close those, and you have removed the openings real attacks depend on. Leave them open behind an expensive tool, and you have bought a stronger lock for a door that was standing ajar. The most valuable security question you can ask this quarter is not what should we buy. It is who has access to what, who owns it, and what happens when that changes.
Treating security as an operational discipline, with clear ownership of every system, access that changes when people and vendors do, and regular reviews that catch drift before an incident does, is exactly what our cybersecurity and compliance work is built around: closing the process gaps that real breaches actually use, not just adding another tool on top. Book a discovery call and we will help you find the doors your operation has left open.
Frequently asked questions
What is the biggest cybersecurity risk for most businesses?
For most organisations the biggest risk is not a sophisticated external attacker but their own operational gaps: access that was granted and never revoked, systems and data that nobody clearly owns, credentials shared informally, tools bought and used without anyone in security knowing, and security rules that were quietly bent for convenience and never straightened again. These gaps are how the majority of real incidents actually begin, and none of them is a hacking problem. They are process and ownership problems. The attacker, when one arrives, simply walks through the door that an operational gap left open.
Why don't security tools stop these problems?
Because tools enforce rules; they do not decide what the rules should be or notice when reality has drifted away from them. A tool can require multi-factor authentication, but it cannot know that a contractor who left a year ago still has an active account, that an admin password lives in a shared spreadsheet, or that a whole department is using a SaaS product security has never heard of. Those are gaps in who owns what and what happens when things change, and no purchase closes them. Buying more tools on top of unmanaged access and unclear ownership adds cost and a false sense of safety without removing the openings that incidents actually use.
What is an access review and why does it matter?
An access review is a periodic, deliberate check of who and what can reach each system and whether they should still be able to. It matters because access only ever accumulates on its own. People join, change roles, and leave; vendors are given entry for a project; exceptions are granted in a hurry. Almost every one of those grants adds access, and almost nothing removes it unless someone deliberately looks. Over time that leaves a large, invisible population of accounts and permissions that no longer match reality, and every one of them is a way in. A regular review is how you find and close them before an incident does.
How do you make security part of operations?
By treating it as an ownership and process discipline rather than a product you install. That means keeping an honest inventory of your systems and data, naming an owner for each one, and defining what happens to access at the moments that matter: when someone joins, changes role, or leaves, and when a vendor's work ends. It means reviewing access on a schedule instead of only after something goes wrong, and treating any security exception as a deliberate, time-limited decision with an owner rather than a quiet permanent change. Done this way, security stops being a separate event and becomes part of how the operation is run, which is the only place most real risk actually lives.