Vulnerability management is the continuous cycle of finding weaknesses across your systems, working out which ones an attacker could actually use against you, and closing them before that happens. It only works as an ongoing programme, not as an annual scan report.
- Scanning finds vulnerabilities. Penetration testing proves which ones are exploitable and how far an attacker can go once inside.
- CVSS score alone is a weak prioritisation signal. Exposure, exploit availability and asset criticality matter more.
- Most GCC vulnerability management programmes fail at remediation ownership and verification, not at detection.
- Assessors want a documented cycle with tracked SLAs and evidence of closure, not a clean scan report.
The cycle, and where it actually breaks
Vulnerability management runs in five steps: discover the asset, scan it, work out whether the finding matters, fix it, and confirm the fix worked. Every vendor pitch makes this sound simple. In practice the first step fails first, because most organisations do not have an accurate inventory of what they run. Cloud accounts get spun up outside procurement, subsidiaries keep their own subdomains, a marketing team stands up a WordPress instance nobody in security ever sees, and an OT engineer adds a sensor to what security still believes is an isolated network. You cannot scan an asset you do not know exists, and an attacker doing reconnaissance from the outside will usually find it before an internal audit does.
Scanning itself splits into two different exercises: unauthenticated scans that see the network the way an outsider would, and authenticated, credentialed scans that log into the host and read the real patch level, installed software and configuration. An unauthenticated scan against a well-segmented internal network comes back mostly clean and mostly wrong. Authenticated scanning is what surfaces the real backlog, and it is also the scan most organisations skip, because it means granting scanning service accounts local admin rights across the estate. Security teams do not always want to ask for that, and IT operations do not always want to grant it.
Tooling choice matters less than the vendors selling it want you to believe. Nessus, Qualys VMDR and Rapid7 InsightVM all do the same core job: agent or agentless scanning against a plugin or signature feed, with a dashboard that ranks findings. What actually differs between them is agent footprint, cloud and container coverage, and how well the platform ties into your ticketing system, because remediation tracking is what usually decides whether a programme works, not the scanner.
Vulnerability assessment and penetration testing answer different questions
A vulnerability assessment tells you what is exposed. A penetration test tells you what an attacker can actually do with it. Assessment is breadth: run the scanner across the estate and get back a list of findings ranked by severity. Penetration testing is depth: a tester picks a target, chains two or three findings that individually look moderate, and demonstrates domain compromise or data exfiltration from what the scan report labelled a handful of medium issues. Organisations that only ever scan tend to over trust the numbers, because a clean-looking report says nothing about how those findings combine once someone is actually trying to get in. Manual testing that maps to how an attacker moves through a network, rather than a scripted checklist, is what closes that gap.
Prioritisation is the actual skill
CVSS base score measures theoretical severity in a vacuum. It says nothing about whether the vulnerable service is reachable from the internet, whether a working exploit exists for it, or whether the host already sits behind a compensating control. A 9.8 on an isolated management VLAN behind a jump host is a lower real risk than a 7.5 on an internet facing application with no web application firewall in front of it. Effective prioritisation blends four inputs: exploit availability (a probability score like EPSS is a better signal here than CVSS alone), exposure (internet facing beats internal, internal beats air gapped), asset criticality (a finding on a domain controller is not the same finding on a print server), and the compensating controls already in place. Programmes that prioritise on CVSS alone burn remediation effort on findings that were never going to be exploited, while the genuinely dangerous ones sit in the backlog under a medium label.
What GCC assessors actually look for
Regulators across the region, including frameworks like NESA in the UAE, generally do not mandate a specific scanning tool or a fixed patch cadence in the text of the regulation itself. What assessors ask for in practice is evidence of a documented, repeatable process: an asset inventory that is kept current, a scanning cadence matched to asset criticality, severity based remediation SLAs that are tracked against real close dates, and a formal exception or risk acceptance process for findings that cannot be closed on schedule. A programme that has all of that but occasionally turns up a critical finding will pass review more easily than one with a spotless scan history and no evidence anyone reviewed it. A zero-finding report is more often a sign of a badly scoped or badly configured scan than a secure network, and experienced assessors know it.
Where programmes actually break down
Three failure patterns show up repeatedly across the region. First, remediation SLAs exist on paper and nowhere else: security sets a window for critical findings, IT operations owns the actual patching, and there is no shared ticket or escalation path connecting the two, so the SLA is aspirational rather than tracked. Second, OT and legacy systems get quietly excluded from the cycle because they cannot be patched without a maintenance window operations will not approve, and nobody documents the compensating control that is supposed to cover the gap in the meantime. Third, there is no verification step: a ticket gets closed because a patch was deployed, but nobody rescans to confirm it actually applied, which on a large estate fails often enough to matter.
Scanning cadence that matches the risk
Internet facing assets warrant continuous or at minimum weekly scanning, because opportunistic scanning against newly published CVEs will find them first. Internal infrastructure can run on a monthly cycle for most estates, tightened for anything handling regulated data. Any change to production, a new host, a firewall rule change, an application deployment, should trigger an ad hoc scan rather than waiting for the next scheduled run. A quarterly-only cadence, still common across the region, leaves a gap measured in weeks between a new CVE being published and the organisation even knowing it applies to them.
A working checklist before your next audit
- Confirm the asset inventory reconciles against cloud billing and DNS records, not just the CMDB.
- Check that scans run authenticated, not only network based.
- Verify remediation SLAs are tracked against real close dates in a ticketing system, not a spreadsheet.
- Pull a sample of tickets marked closed last quarter and confirm the fix was actually rescanned.
- Ask whether OT or legacy exclusions have a documented compensating control on file, not just an exclusion.
- Run a penetration test against the estate at least once a year to check what the scan data says against what an attacker can actually reach.
