Run vulnerability assessment across Azure

Unlike many configuration controls, vulnerability assessment is not free: scanning is delivered through the Defender for Cloud plans, Defender for Servers for virtual machines, Defender for SQL for databases, and Defender for Containers for registry images, each of which carries a per-resource or per-vCore charge. That cost is the price of seeing what you are running. The remediation itself, patching a machine, rebuilding an image on a current base, fixing a SQL configuration, is engineering time rather than Azure spend, with the occasional exception of an upgrade that moves a resource to a larger or newer SKU.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A public-facing virtual machine with a critical unpatched CVE carries a far higher expected loss than an isolated internal box with a low-severity finding, yet both can surface inside the same red recommendation. Map the findings to the resources and the severities behind them and prioritise by exploitable exposure, not by the raw count of open items.

The arithmetic is the familiar security one but with a real plan cost on one side. The spend is the Defender plan fees plus engineering time to patch. The downside of leaving it is the documented cost of a breach that started with a known, fixable CVE: the great majority of successful intrusions exploit a vulnerability for which a patch already existed. Paying for scanning and acting on what it finds is the cheapest insurance against the most common attack.

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with a mix of vulnerability findings: a dozen machines with no scanner attached, two SQL databases with open findings, and a registry full of images carrying CVEs. The instinct is not to wave through a blanket remediation budget; it is to separate the two costs. Turning scanning on is a real, recurring Defender plan charge, Defender for Servers per machine, Defender for SQL per database, Defender for Containers per vCore, and that is the line that actually moves the bill. The remediation itself, patching machines and rebuilding images, is engineering time, with only the odd SKU upgrade adding incremental spend.

Sam asks the team to map each gap to the resource behind it. Three of the unscanned machines are internet-facing production, the rest are quiet internal boxes; one SQL database holds customer records, the other is a test instance; the registry images feed production workloads. The list is reframed on the risk register: enabling Defender for Servers across the production machines is a budgeted, recurring line that buys visibility into the highest-exposure resources first; the customer-data SQL findings are high expected-loss items to resolve immediately; the test instance and quiet boxes are lower priority. The finance pack reads: 'The scanning plans are a recurring cost we should size to risk, switch them on for the exposed production resources first; the remediation is engineering time; and the thing we are buying down is the single most common breach cause, an unpatched known CVE.'

The cost model here is unusual for this lesson series because the control genuinely costs money: the Defender for Cloud plans that deliver scanning are a recurring per-resource charge, not a free setting. But the comparison is still one-sided. The plan fees and the engineering time to patch are bounded and predictable; the downside they buy down is the documented and unbounded cost of a breach that started with a known, fixable CVE.

The right framing is to treat scanning coverage as an insurance premium sized to exposure. Enable the plans first where the expected loss is highest, internet-facing production machines, customer-data databases, images feeding production, and let the spend follow the risk rather than blanketing everything at once if budget is tight. Then attach severity-weighted expected loss to the open findings so remediation effort goes to exploitable criticals before low-severity internal noise. The finance role is to make sure the plan spend is justified by the exposure it covers, and that the remediation backlog is worked by risk rather than by raw count.

Vulnerability assessment is the difference between knowing your weaknesses and discovering them when someone else exploits them. The overwhelming majority of breaches begin with a known vulnerability for which a fix already existed, so the leadership question is blunt: is everything we run being scanned, and are we closing what the scans find?

The report shows this as a scatter of separate findings, a coverage gap on some machines, unresolved findings on a database, vulnerable images in a registry, but the underlying posture is a single number: the percentage of the estate under continuous scanning, and the trend in open critical findings. The defensible end state is full scanning coverage across virtual machines, container registries and databases, with a process that drives critical findings down on a schedule rather than letting them accumulate.

This one does have a cost: the Defender for Cloud plans are not free. But that cost buys visibility into the single most common breach root cause, and the question for leadership is whether that visibility, and the discipline to act on it, is in place by design or left to chance.

After a peer company was breached through an unpatched server that everyone later agreed should have been updated months earlier, the CEO asked the obvious question at the next review: are we scanning everything, and are we fixing what we find? The honest answer at the time was uncomfortable. Some machines were scanned and some were not, nobody could state the coverage percentage, and the SQL and container findings had been noted once and then left to drift.

The team's response was to stop treating vulnerability assessment as an occasional clean-up and start treating it as a standing process. They enabled Defender for Cloud scanning across every virtual machine, SQL database and container registry so coverage reached one hundred per cent, established a baseline so accepted findings stopped generating noise, and set a service-level target: critical findings resolved within a fixed window, tracked on the security review every month. The next time the CEO asked the question, the answer had changed from 'mostly, we think' to 'everything is scanned, here is the coverage number, and here is the trend in open critical findings, which is going down.' That shift, from a one-off audit to a measured, shrinking backlog, is the confidence signal this capability delivers, and unlike most controls it has a real and justifiable cost: the scanning plans that make the visibility possible.

Nearly every major breach that reached the news began the same way: a known vulnerability, a patch that already existed, and a resource that was never scanned or never updated. Vulnerability assessment is the capability that turns that root cause from an invisible certainty into a measured, shrinking number. It is the one control most directly aligned with how organisations are actually attacked.

Unlike most security configuration work, this one has a real cost: the scanning plans are a recurring charge. But the trade is straightforward. The spend buys visibility into the single most common breach mechanism, and the discipline to act on it bounds the exposure. The question leadership should ask is not whether to pay for scanning but whether the coverage is complete and the critical findings are trending down, because that pair of numbers is the honest measure of whether this risk is under control.