Annex A 8.8 is the control auditors spend the most time on during an ISO 27001 surveillance or certification audit, because it is the one control where “we have a policy” is never sufficient evidence on its own. The auditor wants to see a working loop: vulnerabilities get discovered, someone decides what to do about them, action happens inside a defined window, and someone else confirms the action actually closed the gap. This article walks through what the control text asks for, what it assumes you already have in place, and exactly what a sampled audit trail needs to contain.
Control text of Annex A 8.8 and how it differs from A.12.6.1
In the ISO/IEC 27001:2022 restructuring, technical vulnerability management moved into the Technological controls group as Annex A 8.8, replacing what was A.12.6.1 in the 2013 edition. The underlying intent has not changed: an organization must obtain timely information about technical vulnerabilities in the systems it uses, evaluate its exposure to those vulnerabilities, and take appropriate measures to address the risk. What changed is emphasis, not substance.
The 2022 guidance text is more explicit about three things that auditors now check directly rather than inferring from a policy document: a documented process with named roles and decision authority, defined timeframes for action that are tied to risk rather than left open-ended, and a rule set for how software gets installed and patched, which links 8.8 to the change management and secure configuration controls elsewhere in the annex. In practice this means a one-page “we scan quarterly” statement that satisfied some 2013-era auditors will not satisfy a 2022 audit. The control now expects a procedure document that reads like an SOP: who pulls vulnerability data, who triages it, who approves exceptions, and how long each severity tier has before it becomes overdue.
Information sources the control assumes
Annex A 8.8 does not tell you which scanner to buy, but it assumes three categories of input exist and are current.
Asset inventory
You cannot evaluate exposure to a CVE if you do not know which hosts run the affected software version. The inventory needs to carry enough detail to match against vulnerability data, ideally CPE (Common Platform Enumeration) strings or equivalent version fields, not just hostnames. An inventory that tracks “Apache” without a version number cannot support the exposure evaluation the control requires; the auditor will ask how you determined a given CVE did or did not apply to a specific asset, and “we assumed” is not an answer that survives a sample check.
Vendor advisories
Subscribe directly to PSIRT feeds for anything business-critical: Microsoft’s monthly Patch Tuesday bulletins, Cisco’s PSIRT RSS feed, Oracle’s quarterly Critical Patch Update, and equivalent feeds for any framework or library your applications depend on. Relying solely on a scanner’s plugin update cycle introduces lag, sometimes measured in weeks, between public disclosure and detection.
Public vulnerability feeds
The NVD (National Vulnerability Database) is the baseline source for CVSS scoring and CPE matching. Layer the CISA Known Exploited Vulnerabilities (KEV) catalog on top of it. KEV entries are vulnerabilities with confirmed real-world exploitation, and treating a KEV-listed medium-severity CVE with the same urgency as an unexploited critical is a defensible, auditable decision rule, whereas ignoring KEV status entirely is a gap an auditor will flag once they know the list exists.
Defining roles, decision authority and remediation timeframes
This is where most procedures fail the audit, not because the timeframes are wrong but because they are missing or vague. A defensible procedure names, at minimum: who owns the vulnerability management process end to end, who has authority to approve a risk acceptance or exception, who executes the remediation (patch, config change, compensating control), and who independently confirms closure. These do not need to be four different people in a small team, but the roles must be distinct on paper even if one person holds two of them, because the audit checks for separation between “did the work” and “verified the work.”
Timeframes should be risk-tiered rather than uniform. A defensible model that maps cleanly to CVSS and exploit status looks like this:
| Severity tier | Criteria | Remediation SLA |
|---|---|---|
| Critical | CVSS 9.0 to 10.0, or any severity listed in CISA KEV | 7 calendar days |
| High | CVSS 7.0 to 8.9 | 30 calendar days |
| Medium | CVSS 4.0 to 6.9 | 90 calendar days |
| Low | CVSS below 4.0 | Next scheduled maintenance window |
Whatever thresholds you choose, write them into the procedure document with the exact CVSS ranges and the exact day counts, and apply them consistently. An auditor who finds a critical finding open for 45 days with no exception record on file, against a documented 7-day SLA, has an easy nonconformity to write. An auditor who finds the same 45-day gap covered by a signed, dated, time-bound exception has evidence the control is working as designed, even though the underlying vulnerability is still unpatched.
Evidence an ISO auditor samples
Auditors do not read your whole vulnerability backlog. They pull a sample, usually a handful of critical and high findings from the audit period, and trace each one through four pieces of evidence:
- Scan schedule records showing the scan that surfaced the finding actually ran on the cadence the procedure specifies, covering the asset scope the procedure claims (authenticated versus unauthenticated, internal versus external, which subnets or asset groups were in or out of scope).
- Ticket trail from detection timestamp through triage decision, assignment, and remediation action, with enough timestamps to calculate whether the SLA was met.
- Exception or risk acceptance records for anything that ran past its SLA, each one carrying an approver name, a documented business justification, and an expiry date. An exception without an expiry date reads as a permanent waiver and gets challenged.
- Retest proof confirming the specific finding was verified closed, not merely that a patch was deployed. A change ticket marked “complete” is not the same evidence as a rescan showing the CVE no longer detects on that asset. This distinction between remediation activity and remediation-team platforms, such as SITEY, that log discovery, patch, and retest as three separate timestamped phases give an auditor exactly this chain without reconstructing it from separate systems. If your scanning, ticketing, and patch management tools are not linked, plan to export and cross-reference them manually before the audit window, because doing it live in front of an auditor is where gaps surface.
Findings that escalate from observation to nonconformity
Not every gap becomes a formal nonconformity. Auditors generally distinguish between an observation or opportunity for improvement, something worth fixing but not a control failure, and a nonconformity, where the control is not operating as designed. The line auditors typically apply:
An isolated late remediation with a documented, approved exception is an observation at most; the control caught it and the process handled it. A pattern of overdue criticals with no exceptions on file, a vulnerability management procedure that exists but names no one responsible for approving exceptions, or a scan scope that silently excludes a class of assets (unmanaged endpoints, cloud workloads spun up outside IT’s inventory process) tends to escalate to a minor nonconformity. It becomes a major nonconformity when the gap is systemic rather than isolated: no documented procedure at all, no evidence of retest across the entire sample, or an inventory so incomplete that the organization cannot demonstrate it knows its own exposure. Major nonconformities block certification until corrected and re-verified; minor ones typically carry a defined correction deadline before the next surveillance audit.
How Clause 9 monitoring and management review close the loop
Annex A 8.8 does not operate in isolation from the main clauses. Clause 9.1 (Monitoring, measurement, analysis and evaluation) is where you define the metrics that prove the control is functioning over time, not just on the day of the audit: mean time to remediate by severity tier, percentage of the asset inventory covered by the last scan cycle, and count of open exceptions past their stated expiry. These numbers should exist as a standing report, not something assembled the week before the audit.
Clause 9.2 internal audits should independently test 8.8 before the external auditor does, sampling the same kind of evidence: pick five findings, trace each one, confirm SLAs and retest proof exist. Clause 9.3 management review is where trends from 9.1 get discussed at a level that can actually change resourcing, for example when MTTR for high-severity findings has been drifting upward for two consecutive quarters because the patching team is understaffed relative to finding volume. If review consistently surfaces a gap without triggering a corrective action under Clause 10, that pattern itself becomes something an auditor will question, since a management review that never changes anything is functionally the same as no review.
Because 8.8 sits at the intersection of asset management, patch operations, and risk acceptance, most of the audit friction comes from evidence living in three or four disconnected systems. Whether you assemble that evidence manually across a scanner, a ticketing tool, and a spreadsheet of exceptions, or through a platform that keeps the phases linked automatically, the standard is indifferent to tooling. It only asks that the loop from discovery to verified closure can be demonstrated, on demand, for whichever finding the auditor happens to pick.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.