How we think about it.

You can't manage what you haven't found.

The first job on every engagement we run is finding the assets the CMDB has lost. There are always more than the client expects.

The unknown estate isn't malice. It's history. A subsidiary the parent acquired four years ago. A lab network nobody decommissioned. Personal devices that wandered onto the wireless. Test environments that grew up; build pipelines that spun up VMs and never deleted them.

None of these things are visible to a vulnerability scan if the scan doesn't know they exist. So we discover first, catalogue second, automate third. In that order, every time.

Automation is the only way out.

2025 logged more than 48,000 unique vulnerabilities (NVD): a record, and a step-change on every prior year. With each new generation of LLM, we expect that figure to double or triple. No human team triages fifty thousand findings, never mind a hundred. With sufficient discipline, a team can triage a few hundred, provided they do nothing else.

So the bulk of the work has to be automated. Asset discovery: automated. OS and third-party patching: automated, every cycle, with health-check and rollback in the pipeline. Configuration baselines: automated. Verification: automated. Reporting: automated.

What remains for humans is the small set of judgement calls: the regulated change, the maintenance window for the system that genuinely cannot tolerate a reboot, the exception that needs a signature. Automation isn't deskilling. It frees up senior attention for the judgement calls that need it.

Patching belongs to IT. VM steers it.

Patching is owned by IT operations. Always. The team that owns the toolchain, the maintenance windows, the rollback plan and the change SLA is doing real engineering, and that ownership belongs with the people who keep the estate running.

What vulnerability management owns is the direction. VM sets priorities: which vulnerabilities matter, which CVEs to pull forward, which exposures justify a special cycle. VM tells patching what to automate next, what's worth a manual exception, and what isn't. Patching executes; VM steers.

The one well-judged exception we've seen work is a zero-day killswitch where VM holds the keys to a pre-agreed action (block, isolate, force-update) that fires inside an hour rather than waiting for a change window. It is rare, and it works only when the rules of engagement are written down in advance and the IT team is genuinely on board. Without that, it's just shadow ops.

Where the model breaks down is when the two functions don't share a metric. Fix that (a single number both teams own) and most of the friction goes away.

Vulnerability management is a funnel, not a list.

Most teams treat vulnerability management as a backlog. The board asks how many criticals are open; the team reports the number; the number doesn't move; the team is asked to do more with less. None of this changes the underlying flow.

The pipeline above has direction. Findings enter at discovery, and most of them should leave through automated patching long before they reach a human queue. The ones that arrive at VM are exceptions: what automation didn't handle this cycle. A growing VM backlog is rarely a VM problem; it's a flow problem upstream. Inventory missing a class of asset, automated patching skipping a third-party package, manual patching that isn't being completed on a regular cadence: each leaks work into the next stage and surfaces at VM as a pile of CVEs.

So we don't ask "how many critical findings do you have?" We ask: how many entered the pipeline this week, how many left through automation, and at which stage the rest got stuck.

The right tools, deeply known.

We invest seriously in our software partners. Tanium for endpoint truth at scale. Wiz for cloud workload. CyberArk for privileged access. Microsoft, ServiceNow, Axonius, Forescout: each chosen for a problem we know they're good at. We've worked alongside their engineering teams, sat in their roadmap reviews, and built our practice on their platforms because they earn it.

That said: the tool isn't the strategy. What clients actually buy is the operating model around the tool: who runs it, who reports on it, how exceptions are governed, how patches make it from discovery to verification without a meeting. We bring the operating model. The tool serves it.

We are deliberately small on the partner roster: seven platforms, hand-picked. A consultancy that supports thirty supports none of them well.

Cyber and IT need shared KPIs.

Most of the dysfunction we see in vulnerability management is not a tooling failure. It's a communication failure between two teams with different incentives.

Security counts findings. IT counts uptime. The metric a CISO chooses for the board is not the metric a head of operations chooses for the COO. The patch that closes a CVSS 9.8 also risks taking a system offline, closing the CISO's metric and damaging the head of operations'. So the patch doesn't get applied. Eventually that shows up as a breach.

Fix the incentives and the rest follows. A shared KPI (days-to-patch on critical findings, with both teams jointly accountable) collapses an entire genre of organisational pain. We help write that KPI, instrument it, and in our managed services we report against it weekly.