ISO 27001 Vulnerability Management: How to Satisfy Annex A 8.8 and Prove It

Co-author expert - Valentin Kel, Software Developer at Cloudaware

ISO 27001 vulnerability management often breaks in the gap between “we fixed it” and “prove it.” The scanner logged the finding, and the remediation ticket closed. Neither record explains who evaluated the exposure, which SLA applied, or whether an approved exception remained valid.

ISO 27001 vulnerability management is addressed primarily through ISO/IEC 27001:2022 Annex A control 8.8, Management of technical vulnerabilities. The control requires organizations to obtain timely vulnerability information, evaluate their exposure, and take appropriate action. ISO/IEC 27002:2022 provides implementation guidance; Annex A 8.8 does not mandate a named scanner or universal scan frequency.

For an auditor, the practical test is narrower: can one sampled finding be traced from an in-scope asset through evaluation, treatment, or approved exception and verified closure? This guide is built for vulnerability managers, ISMS owners, and compliance leads who need to make that chain repeatable. It shows how to:

• Map Annex A 8.8 to sample-ready evidence;
• Adapt a policy template to actual owners, deadlines, and exception rules;
• Reconcile the in-scope asset population with current assessment results; and
• Connect scanner, CMDB, ticket, approval, and closure records without treating the scanner as the complete control.

Use one test throughout: can you answer, “Show me this critical finding, why you prioritized it, and whether you closed it on time,” without starting a fire drill?

How this guide was prepared: The control interpretation is based on ISO/IEC 27001:2022, FIRST’s CVSS and EPSS guidance, CISA’s KEV catalog, NIST patch-management guidance, and certification-stage guidance from TÜV Rheinland.

Quick answer: What does ISO 27001 require for vulnerability management?

ISO/IEC 27001:2022 addresses technical vulnerability management through Annex A control 8.8. Organizations must obtain timely vulnerability information, evaluate their exposure, and take appropriate action. The standard does not prescribe a specific scanner, universal assessment frequency, or fixed remediation deadline. Those choices must reflect the organization’s scope, risk criteria, and operating environment.

A defensible implementation should:

• Reconcile assessment coverage against all active, in-scope CIs, not only assets returned by a scanner.
• Prioritize findings using exposure, business impact, CISA KEV status, EPSS probability, observed exploitation, and existing controls alongside CVSS.
• Record the accountable owner, clock start, SLA, escalation path, exception authority, and expiry date.
• Accept closure only when a rescan, version check, configuration snapshot, or control test verifies the treatment.
• Use the Statement of Applicability to describe the control and an evidence pack to prove that it operated.

The practical test: select one open finding and one clean in-scope asset. If you cannot trace scope, evaluation, ownership, treatment, and verification from the underlying records, Annex A 8.8 is not sample-ready.

Four checks for defensible Annex A 8.8 evidence

Use these four checks before you call the control audit-ready:

• Define coverage against the in-scope asset denominator, not only the scan population.
• Prioritize with exposure, exploit activity, business impact, and existing controls beside CVSS.
• Require verification evidence before a remediation ticket counts as closed.
• Make the policy executable by naming the owner, clock, deadline, exception authority, expiry rule, and closure test.

What ISO 27001 requires for vulnerability management

Annex A 8.8 is outcome-based: obtain timely information about technical vulnerabilities, evaluate the organization’s exposure, and take appropriate action. An auditor needs evidence for those duties tied to the same asset or finding. The scanner supplies the observation; scope reconciliation, risk decisions, accountable treatment, and verification complete the control.

Collect vulnerability information across the full scope

Start with the expected asset population, not the assets that happened to appear in the latest scan. For every in-scope asset class, document the relevant inputs: authenticated scanner results, cloud-native findings, supplier advisories, threat-intelligence feeds, and records from sources such as the National Vulnerability Database. Retain the source owner, collection cadence, last successful ingestion, and handling rule when a feed fails.

An illustrative coverage check makes the hidden gap visible. Suppose discovery returns 1,200 assets. After 120 retired or unsupported records are excluded under documented rules, 1,080 remain in scope. Current findings or valid clean results exist for 1,055 assets, so effective coverage is 97.7%. The actionable output is the list of 25 gaps, with an owner and reason code for each one.

Verification test: Sample newly created assets and failed collectors as well as successful scans. A report containing 1,055 assets proves collection occurred. Only the denominator shows whether the process covered the estate it was supposed to assess.

Evaluate risk in context, not from CVSS alone

A scanner rating is an input to the decision, not the decision itself. FIRST’s CVSS v4.0 guidance states that the Base score measures severity and should not be used alone to assess risk. Add threat evidence from the CISA Known Exploited Vulnerabilities catalog, the Exploit Prediction Scoring System, and your own telemetry, then weigh it against exposure, business impact, and existing controls. KEV identifies vulnerabilities with evidence of active exploitation; EPSS estimates the probability that a published CVE will be exploited in the wild during the next 30 days. Neither approach replaces the need for environmental context or a documented decision.

Consider two illustrative findings with a CVSS-B score of 9.8. One affects an internet-facing production service that processes regulated data and has evidence of active exploitation. The other sits on an isolated development host scheduled for retirement, with no route from an untrusted network. Assigning both the same treatment deadline would be easy to automate and difficult to defend.

For each finding, preserve the asset ID, service and data criticality, exposure path, exploit status, existing controls, accountable owner, decision rationale, and review timestamp. The record should explain why the team escalated, deferred, or accepted the finding. If a reviewer cannot reconstruct the priority from stored fields, the evaluation exists only in someone’s memory.

Treat the finding, then verify the result

Appropriate action does not always mean applying a patch immediately. Depending on exposure and operating constraints, treatment may involve a patch, configuration change, compensating control, isolation, service replacement, or approved risk acceptance. The record must identify who selected the treatment, which deadline applied, and whether the work finished before it.

NIST authors Murugiah Souppaya and Karen Scarfone describe the full operating scope in SP 800-40 Rev. 4:

“Enterprise patch management is the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization.”

The final verb matters. A closed ticket records a workflow state. It does not show that the vulnerable version disappeared, the configuration changed, or a compensating control remained active. Attach a rescan result, version check, configuration snapshot, or control test to the closure record.

At minimum, retain the finding and asset IDs, assigned and completed timestamps, treatment, owner, applicable SLA, verification result, and evidence link. For an exception, add the approver, rationale, compensating controls, expiry date, and review history. A temporary exception without an expiry date is an unresolved finding with better paperwork.

These records should remain usable beyond certification preparation. Stage 1, Stage 2, and surveillance audits examine documentation, implementation, and continued operation at different points. Keep control-specific evidence here. Use the broader ISO 27001 risk assessment to define organizational risk criteria, ownership, acceptance, and treatment under clause 6.1.2.

How to customize an ISO 27001 vulnerability management policy template

Most teams do not write this policy from scratch. They start with a company, consultant, or vendor template, then ask the ISMS owner, vulnerability manager, service owners, and risk approvers to make it operational. That approach is sensible. Annex A 8.8 needs a repeatable process and traceable evidence, not original prose.

Before approval, customize these seven areas:

Validated critical findings affecting internet-facing production assets must be assigned within one business day and treated within 15 calendar days. The clock begins when the finding is validated against an in-scope asset. Closure requires a successful rescan, version check, or documented control test. Any exception requires risk-owner approval, compensating controls, and an expiry date.

The deadlines are illustrative; ISO 27001 does not prescribe them. Before approval, compare the proposed SLA with recent backlog data. If the target fails because ownership or routing is broken, repair the workflow instead of lengthening the deadline to improve the report.

Test the policy against two live records

Before approval, test the draft against two live records: one open finding and one asset reported as clean. For the finding, the policy must return the scope status, clock start, accountable owner, SLA or exception path, and accepted closure evidence. For the clean asset, confirm that a current scan or approved alternative assessment exists within the stated cadence. If either record cannot be resolved from the systems named in the policy, revise the fields or workflow before approving the wording.

• Template includes: scope, authoritative inventory, and approved exclusions.
• Roles and handoffs: validation, remediation, risk approval, closure verification, and escalation.
• SLA logic: risk tiers, clock start, pause conditions, and escalation points.
• Exception control: separate approver, rationale, compensating controls, review date, and expiry.
• Evidence rules: closure proof, metrics, review cadence, and version approval.

LEAD FORM HERE 

Run Annex A 8.8 as a repeatable control cycle

Annex A 8.8 becomes defensible when work moves through a defined clock instead of waiting for the next audit. The cycle starts with the in-scope asset population and ends only after closure has been verified.

1. Reconcile scope. Compare active in-scope CIs with current scanner results or approved alternative assessments. Output: a coverage-gap queue plus approved exclusions.
2. Validate and start the clock. Map each finding to a live CI, remove duplicates, record detection and validation times, and assign the applicable SLA tier.
3. Prioritize in context. Store exposure, exploit evidence, service and data criticality, existing controls, and the rationale for the chosen treatment path.
4. Assign treatment or approve a time-bound exception. Route the record to the service owner; keep requester and approver separate for accepted risk.
5. Verify closure, then review control health. Require a rescan, version check, configuration snapshot, or control test; monitor gaps, overdue findings, expiring exceptions, and unverified closures.

Use those five outputs as the audit trail. If a handoff still depends on chat or memory, add the missing field, owner, or system step before the next review.

What belongs in a sample-ready Annex A 8.8 evidence pack?

The Statement of Applicability explains why Annex A 8.8 applies and how the organization implements it. The control register records ownership and review status. Neither proves operation. For each audit period, provide a compact evidence index that lets an auditor trace one selected CI or CVE to the underlying source records without rebuilding the history in a spreadsheet.

• Prove that the full population was assessed. For the audit period, preserve the in-scope CI population, approved exclusions, current results, stale or unmatched records, and collection failures. An exclusion is defensible only when its rule, approver, date, and reason remain attached; otherwise coverage can rise because scope disappeared.
• Preserve the reasoning behind the priority. For a sampled finding, the index should point to the source, affected CI and service, detection and validation times, risk context, owner, decision rationale, and SLA. If identical 9.8 scores follow different treatment paths, those fields must explain why.
• Connect treatment to verified closure. Link the decision to its ticket, treatment, timestamps, and verification. For accepted risk, retain the separate approver, rationale, compensating controls, review history, and expiry. Do not treat the ticket state as final proof. The pack must point to the rescan, version check, configuration snapshot, or control test.

Audit dry-run: sample one assessed asset with zero findings, one open critical finding, one past-SLA item, one active exception, and one recently closed item. Each record should be traceable in five minutes without changing the source data.

Metrics that show whether the control still works

Finding counts alone reward large estates and noisy scanners. Review measures that expose missing coverage, stalled treatment, unmanaged exceptions, and weak closure evidence.

• Effective assessment coverage: CIs with a current scanner result or approved alternative assessment divided by all active in-scope CIs.
• Stale or unmatched CIs: Count and age the records that lack current assessment data or cannot be related to the authoritative inventory.
• Past-SLA rate by risk tier: Divide findings beyond their treatment deadline by all open findings in that tier.
• Verified closure rate: Divide closures with accepted verification evidence by tickets marked closed during the period.
• Exception exposure: Track active exceptions nearing expiry and any that have already expired, with the accountable approver.
• Median finding age by treatment path: Separate remediation, compensating control, and accepted-risk cohorts so one workflow does not hide another.

Use the same scope and reporting window across the measures. A dashboard that improves when a collector fails is not reporting control health; it is hiding the denominator.

Trace one Annex A 8.8 finding from detection to verified closure

At audit time, the problem is no longer defining the evidence chain. It is querying the same population across scanner results, CIs, owners, SLAs, exceptions, tickets, and verification records. When configured scanner findings are related to those records in Cloudaware, a vulnerability manager can trace one Annex A 8.8 sample without rebuilding the history in a spreadsheet. The scanner remains the finding source; Cloudaware provides the CMDB relationships, queries, dashboards, and workflow context.

Open the dashboard with the audit population, not the critical-finding count. Separate CIs with current assessment data, approved alternative assessments, and stale or unmatched records. Only then rank the open backlog.

Use the visible gaps to decide what happens next. Assign stale or unmatched CIs to the source owner, escalate past-SLA findings to the service owner, review exceptions approaching expiry, and return closed items without verification evidence to the workflow. The dashboard organizes the audit population; the linked records must still support the sample.

Cloudaware features that keep the evidence chain queryable

• Finding-to-CI context: Review scanner severity beside application, environment, exposure, ownership, and lifecycle data.
• Coverage reconciliation: Compare in-scope CIs with current assessment data while keeping stale and unmatched records visible.
• Risk filters: Isolate findings by severity, exposure, application, owner, age, SLA, and remediation status.
• Ticket routing: Create or synchronize Jira and ServiceNow work with the affected CI and finding context when configured.
• Compliance history and exceptions: Cloudaware IT Compliance retains policy results, evidence, lifecycle status, and time-bound exception context.

Cloudaware does not replace the scanner, perform ISO certification, or prove that unknown vulnerabilities do not exist. The view is bounded by configured sources, relationships, permissions, refresh schedules, and retention.