Vulnerability Assessment as Audit Evidence

Not every scan output qualifies as audit evidence. A credible scan report must carry four properties: authentication, scope definition, currency, and integrity. Authentication means the report identifies the tool, version, scan date, authenticated credentials used (unauthenticated scans miss a large class of vulnerabilities), and the operator responsible. Scope definition means the report specifies which IP ranges, hosts, or applications were included and, critically, which were excluded. Currency means the scan was performed within the audit period or within an agreed recency window, typically 90 days for internal scans under PCI-DSS.

Integrity means the report was delivered directly from the scanning system or from an evidence repository with access controls, not via an email attachment from the IT team. An auditor who accepts a PDF of a scan report with no provenance controls cannot assert that the results have not been altered. In practice, the auditor requests the raw export from the scanning platform or a read-only portal session in the tool itself.

The auditor also checks whether the scan scope matches the asset inventory. A scan that covers 80 of 120 documented servers is not evidence for the uncovered 40. The gap is either a scope exception that management has formally accepted, a coverage failure in the scanning programme, or a sign that the asset inventory is incomplete. Each of those conditions is itself an audit finding.

The Common Vulnerability Scoring System version 3.1 is the current standard for expressing vulnerability severity. Every vulnerability in the National Vulnerability Database (NVD) carries a CVSS v3.1 base score. The base score is composed of six metrics: Attack Vector (network, adjacent, local, physical), Attack Complexity (low or high), Privileges Required, User Interaction, Scope (whether the vulnerable component affects components beyond its security authority), and the CIA impact ratings (none, low, high for each of confidentiality, integrity, and availability). The score ranges from 0.0 to 10.0, with bands defined as none (0.0), low (0.1 to 3.9), medium (4.0 to 6.9), high (7.0 to 8.9), and critical (9.0 to 10.0).

The base score alone does not capture every relevant dimension. CVSS also defines a temporal score, which adjusts the base score for exploit code maturity and remediation availability, and an environmental score, which the organisation customises to reflect asset criticality and existing controls. Auditors should ask whether the organisation uses only base scores or has implemented environmental scoring to reflect actual exposure. An organisation that remediates all critical base scores without considering whether those systems are internet-facing versus air-gapped may be both over- and under-prioritising.

Security auditors and vulnerability assessors have different mandates. The assessor runs tools, interprets technical output, and produces a finding list. The auditor evaluates whether that process was carried out competently, whether its outputs were acted upon within policy timelines, and whether the remaining exposure is consistent with the organisation's documented risk appetite. Attempting to replicate the scan confuses the two roles and creates a false impression that a second technical result validates the first.

The auditor's questions are procedural and evidentiary: Is there a written vulnerability management policy that specifies scanning frequency, scope, and remediation timelines? Are scans performed on that frequency, and is there a log to prove it? Do findings map to a tracked remediation backlog? Are exceptions documented with a risk owner and an expiry date? Does the organisation receive threat intelligence that could adjust prioritisation when a vulnerability is being actively exploited in the wild?

Cross-referencing the scan output with the asset register is one of the most important interpretive steps. If the asset register contains 300 endpoints and the scan covers 210, the auditor notes the gap. If the missing 90 are development systems explicitly excluded by policy, that policy must be documented and signed off. If the gap is unexplained, the auditor cannot form a conclusion about the vulnerability posture of the missing assets. See Risk Identification and Asset Classification for the relationship between asset inventory quality and audit coverage.

Remediation prioritisation is the process by which an organisation decides which vulnerabilities to fix first, given that resources are limited and not all findings carry equal risk. A mature programme combines CVSS scores with asset criticality ratings, threat intelligence feeds such as CISA's Known Exploited Vulnerabilities (KEV) catalogue, and compensating control status. Auditors evaluate whether this process is documented, applied consistently, and producing defensible decisions.

The audit finding schedule for vulnerability management typically contains three categories. Open findings within SLA are not exceptions: the organisation is working to schedule. Open findings outside SLA without documented risk acceptance are audit exceptions: the control has failed. Open findings outside SLA with documented risk acceptance may or may not be exceptions, depending on whether the risk acceptance was properly authorised, whether the compensating controls described are real and verifiable, and whether the acceptance expiry has passed.

Auditors in jurisdictions with data protection obligations should note that an unmitigated critical vulnerability on a system holding personal data may constitute a reportable failure of technical security measures. Under the EU General Data Protection Regulation (GDPR) Article 32, controllers must implement appropriate technical measures to protect personal data. The UK ICO, India's Digital Personal Data Protection Act 2023 (Section 8), and equivalent laws in the United States (sector-by-sector under HIPAA, GLBA, and state breach-notification statutes) all carry similar requirements. An audit finding of unmitigated critical vulnerabilities on personal data systems carries legal exposure beyond the audit report itself.

Each major compliance framework prescribes vulnerability scanning in different terms, but all treat it as a mandatory verifiable control rather than a recommended practice. Understanding the specific requirement for the applicable framework determines what evidence the auditor must collect.

CIS Controls v8 Implementation Group 1 includes Control 7 (Continuous Vulnerability Management) as a basic hygiene requirement. IG1 specifies at minimum monthly automated scanning of all enterprise assets. Auditors benchmarking against CIS Controls, as referenced in CIS Controls and Implementation Groups, should request the scanning cadence log alongside the finding reports.

The audit report should not reproduce a raw vulnerability scan. Presenting 400 scanner findings in an audit report transfers the assessor's work product into the wrong document and makes the report unreadable for senior management. The auditor's job is to synthesise: to assess the programme as a whole and to surface the findings that represent a control failure, a policy gap, or a risk beyond the organisation's stated appetite.

A well-structured vulnerability management finding in an audit report contains: the condition (what the auditor observed, for example, 12 critical vulnerabilities on production web servers open beyond the 30-day remediation SLA), the criterion (the policy or standard that was not met, for example, the organisation's own vulnerability management policy requires critical findings to be resolved within 30 days), the cause (why the gap exists, as far as the auditor can determine), the effect (the risk consequence, such as exposure of cardholder data), and the recommendation (a specific, actionable correction with a realistic timeframe).

When the vulnerability assessment programme is functioning well, the auditor's conclusion is also evidence-backed: the programme covers 100% of in-scope assets, scans at the required frequency, remediates within SLA for critical and high findings, and documents formal risk acceptance for all exceptions. That positive conclusion, supported by a sample of scan reports and remediation tickets reviewed during fieldwork, is exactly the kind of objective, reproducible assurance that an audit is designed to provide. For the relationship between programme maturity and risk treatment decisions, see Risk Treatment and the Risk Register.