Most UK CISOs we speak to can produce a vulnerability scan report within minutes. Far fewer can tell us, with confidence, which of the 14,000 findings in that report actually matter, who owns remediation for each, and whether the patch SLA was met. That gap — between detection and demonstrable action — is where audits fail, breaches happen, and boards lose patience.
The NCSC's Vulnerability Management guidance and ISO/IEC 27001:2022 control 8.8 both expect a documented, risk-based vulnerability management programme. Cyber Essentials (administered by IASME on behalf of NCSC) requires high and critical vulnerabilities to be patched within 14 days of vendor release. PCI DSS v4.0.1, mandatory since 31 March 2025, tightens scoping and prioritisation requirements further. Yet our consultants routinely walk into engagements where the "programme" is a Tenable licence and a SharePoint folder.
This post sets out the five failures our team sees most often during pre-audit reviews, and exactly how to fix them before an assessor — or an attacker — finds them first.
Failure 1: Treating the Scanner Output as the Programme
A vulnerability scanner is a sensor. It is not a programme. We have lost count of the UK organisations where vulnerability management consists of running Qualys, Rapid7, or Tenable on a schedule and emailing the PDF to IT operations. There is no policy, no defined risk appetite, no remediation SLA tied to severity, and no governance forum that reviews trends.
An auditor for ISO 27001 Annex A 8.8 or SOC 2 CC7.1 will ask three questions in the first ten minutes: where is your vulnerability management policy, what is your remediation SLA by severity, and show me the evidence that last month's criticals were closed within that SLA. If any of those answers involves opening a scanner console, you have already failed the control.
Fix this by writing a one-page policy that names the scanning tools, scan frequency (we recommend authenticated scans weekly for servers, daily for internet-facing assets), the CVSS thresholds that map to your severity tiers, the patch management SLA per tier, and the named role accountable for the programme. Get it signed by the CISO or, in smaller firms, the Managing Director. That single page transforms an activity into a programme.
Failure 2: CVSS Base Score Used in Isolation
CVSS v3.1 base scores describe the theoretical worst case. They do not describe your environment. A CVSS 9.8 on a vendor management console behind two firewalls, with no internet exposure and patched within the vendor's supported window, is a different problem from a CVSS 7.5 on your customer-facing API gateway. Treating both as "criticals" wastes remediation capacity and, worse, erodes engineering teams' faith in the security function.
Effective CVSS prioritisation layers three signals on top of the base score:
- Exploitability — is the CVE listed in CISA's Known Exploited Vulnerabilities catalogue, or does it have a published EPSS score above 0.5? Both are free, authoritative sources.
- Asset criticality — derived from your asset register and data classification. A vulnerability on a PCI cardholder data environment system is not equivalent to one on a developer's test VM.
- Exposure — internet-facing, internal, or air-gapped. Shodan and your own ASM tooling answer this.
Our consultants typically rebuild client prioritisation logic around these three multipliers, then map the resulting risk score to the patch management SLA. The volume of "fix immediately" tickets usually drops by an order of magnitude, and remediation actually happens.
Failure 3: Patch Management SLAs That Nobody Owns
A patch management SLA written in a policy that no engineering team has agreed to is decorative. We have seen 7-day critical SLAs in policies where the platform team has a two-week change freeze every quarter end. Predictably, the SLA breaches and nobody escalates because nobody owns it.
Tie the SLA to a named team, a named ticketing queue, and an exception process. Our recommended baseline for UK organisations aligning to Cyber Essentials and ISO 27001:
- Critical (internet-facing or KEV-listed): 14 days from vendor release, with emergency change for active exploitation
- High: 30 days
- Medium: 90 days
- Low: next scheduled maintenance window or accepted in writing
Crucially, build the exception path. Engineering teams will sometimes legitimately miss SLAs — vendor patch dependencies, compensating controls in place, or business-critical change freezes. A risk acceptance form, signed by the system owner and reviewed by the CISO, is the auditor-acceptable answer. A breached SLA with no paperwork is not.
Failure 4: Cloud and SaaS Treated as Someone Else's Problem
The vulnerability management programme that worked in 2018 — quarterly Nessus scans of the on-prem estate — misses the majority of modern risk. Misconfigured S3 buckets, over-privileged Entra ID roles, exposed Kubernetes API servers, and out-of-date container images do not appear in traditional vulnerability scanners. Yet they are exactly where breaches originate.
The shared responsibility model means AWS, Azure, and Google patch the hypervisor. Everything above it — the OS, the IAM policy, the security group, the container — is yours. Cloud Security Posture Management (CSPM) and container image scanning belong inside the vulnerability management programme, not as a separate workstream that reports to a different forum.
This is precisely the gap our CloudAuditX platform was built to close. It maps cloud misconfigurations against CIS Benchmarks, NCSC Cloud Security Principles, and ISO 27001 controls in a single view, so the CISO sees one risk-ranked queue rather than four disconnected dashboards.
Failure 5: No Evidence Trail When the Auditor Arrives
The final failure is the one that sinks audits even when the underlying programme is sound. Engineering closed the ticket, the patch went in, the scanner re-ran clean — but nobody screenshotted the before/after, nobody attached the change record, and the ticket was deleted after 90 days by a Jira retention policy.
Build evidence into the workflow, not as an afterthought:
- Ticket lifecycle from detection to closure must be retained for at least 12 months — three years for regulated firms under FCA Operational Resilience expectations
- Each closure ticket should link to the change record and a follow-up scan result
- Monthly KPI pack to the security governance forum: open vulnerabilities by severity, SLA compliance percentage, top 10 systems by risk, accepted risks register
When the ISO 27001 auditor samples ten remediations from the last quarter, you want to produce ten complete evidence chains in under an hour. Anything else signals weak control operation, regardless of how good your scanning is.
A 30-Day Fix Plan
If you recognise your organisation in any of the failures above, here is the sequence our team uses on pre-audit engagements:
- Week 1: Draft and sign the one-page vulnerability management policy. Confirm asset register completeness and data classification tags.
- Week 2: Rebuild prioritisation logic using CVSS base + CISA KEV + EPSS + asset criticality. Re-rank the existing backlog.
- Week 3: Agree patch management SLAs with engineering leadership in writing. Stand up the risk acceptance workflow.
- Week 4: Add CSPM and container scanning into the programme. Define the monthly KPI pack and book the first governance review.
How Pyralink Helps
Our consultants at Pyralink Innovation Ltd, led by Founder & Managing Director Michael Adedeji (CISM, CISA, CC, MSc Data Science), have built vulnerability management programmes for UK organisations from Series A fintechs to listed healthcare providers. We are not a tooling reseller — we work with whatever scanner you have and make the programme around it operational and audit-ready.
Where clients need ongoing senior oversight without a full-time hire, our fractional vCISO service provides the governance layer — chairing the monthly review, signing risk acceptances, and presenting to the board. For clients pursuing ISO 27001 certification, vulnerability management is one of the Annex A controls we evidence end-to-end. Pyralink carries £5M professional indemnity insurance, and you can browse more practical guidance in our insights library or test your cloud posture in minutes with the free compliance scanner.
Two next steps if this resonates: