The Control Obsession
Why more tools don't reduce risk.
There is a predictable response to security anxiety.
Add a tool.
When a breach makes headlines, boards ask what controls were missing. When an audit flags a gap, the answer is a new platform. When a team feels exposed, the instinct is to add coverage — another scanner, another SIEM rule, another dashboard, another vendor. The budget grows. The stack grows. The reports grow thicker and more detailed.
The exposure doesn’t shrink.
This is the control obsession: the belief that accumulating security tools is the same as reducing security risk. It is one of the most expensive and pervasive misunderstandings in the field, and it persists because it feels so reasonable at every individual step.
* * *
Controls are not wrong. They are necessary. The problem is not the controls themselves; it is what happens when controls become the primary model for thinking about risk.
Every control is designed to address something specific. A vulnerability scanner finds known CVEs. A firewall enforces defined rules. An EDR detects patterns that match known behaviors. A DLP tool flags certain data movements. Each one does what it was built to do, within the scope it was built to cover.
But exposure is not a specific thing. It is a condition; one that accumulates continuously across an entire environment, including the spaces between controls, the assets controls don’t know about, and the changes that happen faster than controls can be updated to reflect them.
Every new tool added to the stack creates something that was not there before: new configuration to maintain, new integrations to secure, new alerts to tune, new agents to deploy, new access credentials to manage. The control layer does not sit cleanly on top of the environment. It becomes part of the environment. And like everything else in a living environment, it drifts.
The tool meant to reduce exposure introduces its own.
Security teams know this, even when they don’t say it directly. They spend enormous amounts of time managing the stack — tuning thresholds, chasing false positives, maintaining integrations that break when something upstream changes. This is not wasted effort. But it is effort spent on the instrument rather than the territory the instrument is supposed to be measuring. The map grows more detailed. The territory grows faster.
* * *
Here is what controls actually do: they redistribute attention.
When a new tool is deployed, it creates a new stream of findings. Those findings require review. Some are false positives. Some are real. Some are real but low priority. Some are high priority but not actionable given current resources. The team processes the stream and moves on.
What the tool does not do — cannot do — is tell you what it isn’t seeing.
Every control has a detection surface: the things it is positioned to observe. Outside that surface, the environment continues to change without notice. New assets appear. Old assets accumulate dependencies. Access persists past its intended window. Services respond to requests they were never meant to receive. None of this generates a finding, because none of it falls within the scope of any deployed control.
The team sees what their tools show them. They assume that what is not shown is not a problem. This assumption is understandable. It is also the source of most of what eventually becomes a serious incident.
Mature security programs understand something that tool-heavy programs often miss: the absence of alerts is not the same as the absence of risk. It is the presence of blind spots. And blind spots are not fixed by adding more tools within the same coverage model; they are fixed by questioning what the coverage model is missing entirely.
* * *
The question security programs should be asking is not: how many controls do we have?
The question is: what is actually exposed right now that none of our controls can see?
Those are different questions. The first measures investment. The second measures the condition. A program that can answer the first but not the second is measuring its own effort — not its actual risk surface.
Controls answer yesterday’s question. They are built from known threat patterns, defined rules, and bounded scopes. They are inherently retrospective — optimized for the things that were understood well enough to design detection for. Exposure, by contrast, is a present condition. It exists independent of whether any control is positioned to observe it.
An organization can have a mature, well-resourced control stack and still carry significant exposure — not because their controls are failing, but because exposure accumulates in the gaps that no control was ever positioned to cover. The subdomain that outlived its purpose. The cloud resource deployed outside the normal provisioning process. The service that became reachable when a configuration changed and no one noticed.
None of these generate alerts. All of them exist.
The control obsession is seductive because it makes risk feel manageable. More controls means more coverage means more safety. But this logic only holds if controls and exposure are the same thing — if knowing what your tools can see is equivalent to knowing what is actually exposed. They are not the same thing.
What reduces exposure is not more controls. It is better awareness of what exists, what is reachable, how long it has been visible, and whether anyone is positioned to act on it before time removes that option.
A security program built on controls is asking: are our instruments working?
A security program built on exposure awareness is asking: what is the actual condition of our environment right now?
The second question is harder. It requires a different model, different tooling, and a different definition of what the security function is actually for.
But it is the only question that leads to shorter windows.
Richard La Bella
Richard is the founder of WatchGate (watchgate.io), an external attack surface visibility platform built for regulated small businesses.