Scope Is Not a Phase
Before joining Lansweeper as Director of Product Strategy, I spent years in offensive cybersecurity, focusing on penetration testing, red teaming, and vulnerability management. You get to test a lot of organisations with mature vulnerability programmes from that position: regular scanning, remediation tracking, the works. And you learn, pretty quickly, where they actually break.
More often than not, it’s literally not where they’re looking.
The Equifax breach is the most documented version of what this looks like at scale. They ran vulnerability scans. When the Apache Struts advisory came out in 2017, they couldn’t identify all the systems that needed patching because they didn’t have a reliable asset inventory to direct those scans. TransUnion and Experian received the same advisory and patched promptly. They knew what they had. Equifax didn’t. 147 million records. 78 days before anyone noticed.
The vulnerability management programme itself wasn’t the problem. The scope was.
The False Ceiling
This is what incomplete scope actually does to a vulnerability programme. It doesn’t just mean you’re slightly less covered than you think. It means the programme is generating a false picture of your security posture.
You’re patching faster. You’re tracking CVEs. Remediation velocity is improving. The dashboards look healthy. But all of that reflects the portion of the environment that made it into scope, not the environment you’re running. Leadership sees a security posture. What they’re actually seeing is a security posture only for the things the programme was built to find.
In most enterprises, the gap is bigger than people are comfortable admitting. Orphaned domains from old projects. Cloud workloads spun up by teams who didn’t go through IT. Infrastructure from acquisitions that someone inventoried once and never came back to. Some organisations work from whatever the scanner finds. Others rely on a CMDB that everyone knows is stale, but nobody has fixed. A few did a proper asset inventory two or three years ago and consider the job done.
Attackers don’t work from your scope document.
Where Discovery Ends and Prioritisation Breaks Down
When I raise the scope question with security teams, the response is usually some version of: “We do discovery. We know what we have.”
Discovery tells you an asset exists. It doesn’t tell you enough to make a security decision about it. You need to know what’s running on it, who owns it, when it was last patched, whether it’s internet-facing, whether it’s managed or something a team stood up without going through IT. Discovery answers “is it there?” Knowing enough to act on it is a different question, and most organisations are significantly better at the first than the second.
That fidelity gap doesn’t stay contained to scope. It flows directly into prioritisation. According to Verizon’s 2026 Data Breach Investigations Report, vulnerability exploitation is now the leading initial access vector, responsible for 31% of breaches and overtaking credential theft for the first time. CVE volumes keep climbing. The median time to fully remediate a vulnerability increased from 32 days to 43 days in 2025, according to the same Verizon report, while exploitation windows are moving in the opposite direction. The gap between how fast attackers move and how fast organisations patch is getting wider, not narrower. Security teams are triaging thousands of findings and trying to work out which ones actually matter in their specific environment.
Prioritisation tools can only work with what you give them. If your asset data is thin, if you don’t know which systems are internet-facing or who owns them or what compensating controls are already in place, the output reflects that. You end up working through noise. The things that matter get buried in it. And the vulnerability that leads to a breach often isn’t the highest CVSS score in the queue. It’s the one in the part of the environment your programme couldn’t see.
Where CTEM Gets This Wrong
Most exposure management frameworks, CTEM included, treat Scope as a phase. Something you do at the beginning of the process, check off, and move past on the way to the more interesting work: discovery, prioritisation, validation, remediation.
Scope isn’t a phase. It’s a discipline.
If you treat it as a one-time activity, the programme starts decaying the moment you finish it. Assets change. Teams spin up new services without going through IT. Acquisitions bring in environments that nobody has properly mapped. Shadow IT happens continuously. The network you scoped last quarter already looks different from the one you’re running today.
The organisations that handle this well treat asset intelligence as infrastructure rather than a project. They feed it continuously from multiple sources and make it someone’s clear responsibility to keep records accurate and current.
But data quality is more specific than it sounds. It comes down to three things.
- Are your records complete, covering not just what the scanner can reach but cloud workloads, OT, remote endpoints, shadow IT?
- Are they current? Stale data produces the same false confidence as incomplete data.
- And do they give you enough context to act? Owner, patch state, business criticality, whether the asset is internet-facing.
Knowing an asset exists is step one. Knowing enough to drive remediation is a different bar entirely.
Most organisations score reasonably on completeness for their core estate. Freshness tends to be lower than they’d like. Depth is where the real gap is, and it creates the most friction in practice. You can find the right vulnerability on the right asset and still be unable to move because nobody knows who owns it.
That matters more than the tooling. I’ve seen teams with impressive technology and completely unclear ownership of their underlying data, and I’ve seen teams with much simpler setups maintaining genuinely reliable asset records simply because someone cared enough to keep them that way. The second group handles incidents better, every time.
Three Things Worth Doing
None of these require a new tool or a budget conversation.
- Audit your scope inputs
Where does your asset data come from? List the sources: scanner results, CMDB, cloud console exports, agent inventories, spreadsheets someone maintains manually. For each one, ask how complete it is, how fresh, and what it misses by design. You don’t need to fix anything yet. Just map the inputs. In most organisations, this exercise alone surfaces gaps that weren’t visible because nobody had looked at all the sources end to end.
- Measure data quality, not just asset count
Most programmes track how many assets they have. Fewer track what percentage of those assets have an owner assigned, have been updated in the last 30 days, or have a known patch state. Asset count is a number that gives you confidence. Data quality metrics tell you whether that confidence is warranted. A quick test: pick 50 asset records at random and ask three questions about each. Is this still accurate? Do I know who owns it? Is there enough context here for a security team to make a decision?
- Make scope a recurring conversation, not a one-off
Scope isn’t something you solve in a project and move on from. Environments change constantly. Cloud assets spin up and down. Acquisitions bring in new infrastructure. Remote work has extended the perimeter in ways that a lot of asset programmes haven’t caught up with. Scope needs to be a standing agenda item. Who’s responsible for keeping asset data current? How often does it refresh? Where do new assets get missed? If nobody owns scope, nobody’s maintaining it.
Attackers need reachability and time. You need ownership, evidence, and action. That asymmetry only works in your favour if you’re starting from a complete picture.
Most programmes aren’t. And the confidence they generate can make that harder to see.
