A vulnerability management programme at a financial services company

The company was not starting from zero: there were scans, there were reports and there was goodwill. What there was not was a process. Scans ran on an irregular basis, results arrived as lists of hundreds of findings sorted by technical severity — with no distinction between an internet-facing server and an isolated test machine — and remediation depended on some internal team finding a gap between its own priorities. The outcome was the familiar one: critical vulnerabilities sitting open for months, and nobody able to say how many, since when, or whose they were.

In a financial business that is not merely a technical problem: it is a risk that regulators, auditors and institutional clients ask about in writing. The company needed to move from scanning occasionally to managing continuously — with deadlines, owners and metrics it could put on the table.

1. Inventory and baseline — before scanning better, know what is being scanned: an inventory of infrastructure and applications, identification of internet-facing assets and of those underpinning critical business processes, and a first complete picture of the real state of play. That baseline set the severity-based remediation SLAs that have governed the programme ever since.
2. Recurring scanning of infrastructure and applications — monthly cycles across the whole estate, with a tighter cadence on the exposed perimeter and additional runs after significant changes. No annual snapshots: the estate changes every week and vulnerabilities are published every day.
3. Prioritisation by real risk, not by raw CVSS — every finding is weighed through three lenses: technical severity, exposure (is it reachable from the internet, and from where?) and business context (which process does the asset underpin?). A critical on an isolated machine can wait; a medium on the business perimeter cannot. That short, ordered list is what gets worked — not a several-hundred-line dump nobody reads.
4. Remediation coordinated with internal teams and suppliers — every prioritised vulnerability leaves with an owner, an SLA-based deadline and the technical detail whoever patches needs. We coordinate: chasing overdue items, escalating blockers, documenting compensating mitigations where a patch is not viable, and verifying every closure in the next cycle.
5. A monthly committee with metrics management understands — every month, a follow-up committee with the figures that matter: exposure time by severity, SLA compliance, backlog age and accepted risks pending review. In business language, with decisions on the table — not a technical annex nobody opens.
6. Continuous improvement of the programme itself — SLAs are reviewed against each year's data, false positives feed back into scan tuning, and each cycle's lessons — which supplier is slow, which platform concentrates findings — become preventive actions. The third-year programme detects better and interrupts less than the first-year one.

The most visible change sits in the metric that actually protects: exposure time. Critical vulnerabilities that used to sit open for months are now resolved within SLA, and the ones that do exceed 30 days can be counted on one hand — each with its compensating mitigation documented and its review date set. When an auditor or an institutional client asks, the answer is no longer improvised: it is printed.

The less visible change is cultural. Three years and twelve annual committees later, vulnerability management has stopped being a project with a beginning and an end and become part of how the company is governed: management knows its figures, teams know their deadlines, and the programme survives holidays, workload peaks and staff changes — which is exactly what a process is supposed to do.