ISO 27001 Vulnerability Management: A.8.8 Evidence and Priorities

Implement ISO 27001 A.8.8 with asset-aware intelligence, risk-based prioritization, remediation, exceptions, verification and auditable evidence.

Direct answer: ISO 27001 vulnerability management should identify relevant technical weaknesses, determine which assets are affected, prioritize action by real exposure and impact, implement treatment, verify the result and manage exceptions. Auditors need evidence of the full decision cycle, not only a scanner report or patch percentage.

ISO/IEC 27001:2022 Annex A control 8.8 addresses management of technical vulnerabilities. Patching is an important treatment, but the control system also needs asset context, intelligence, risk decisions, alternative treatments, verification and learning.

This article provides AuditPrepared guidance and does not reproduce standard text. The organisation’s risk method, technology, obligations and Statement of Applicability determine the process.

Build the asset foundation

Vulnerability information is actionable only when it can be connected to assets and owners. Maintain enough detail to identify:

hardware, operating system, application and component versions;
cloud services, images, containers and serverless dependencies;
internet exposure and network location;
service owner and technical custodian;
information classification and business criticality;
supplier or support responsibility;
lifecycle and support status; and
approved maintenance constraints.

Perfect discovery may be unrealistic, but unexplained blind spots should be treated as risk. Reconcile inventories from endpoint, cloud, network, code and procurement sources. The asset inventory and ownership guide explains the governance needed to make ownership usable.

Use multiple information sources

Relevant intelligence may come from:

vendor security advisories;
vulnerability databases and national authorities;
software-composition and dependency tools;
infrastructure and application scanning;
penetration tests and code review;
threat intelligence and incident findings;
supplier notifications; and
security researchers or coordinated disclosure.

Define who monitors each source, how often and how urgent notifications enter the workflow. A mailbox that no one reviews is not an effective intelligence source.

The U.S. Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities Catalog as an authoritative source of weaknesses known to be exploited in the wild. It can inform prioritization, but it does not replace the organisation’s own asset and risk context.

Confirm applicability before prioritizing

A listed vulnerability may not affect the deployed version, configuration or feature. Conversely, a scanner may miss an affected component hidden in an appliance or build artifact.

For each material item, determine:

whether the component and version are present;
whether the vulnerable function is enabled or reachable;
which services and information depend on it;
whether exploitation is observed or credible;
which safeguards reduce likelihood or impact; and
whether a supplier must act.

Record the basis for “not affected” decisions. Unsupported assumptions can become silent exceptions.

Prioritize beyond severity scores

A technical score describes characteristics of a vulnerability, not the complete organisational risk. Prioritization should consider:

active exploitation and threat relevance;
internet or partner exposure;
required privileges and attack path;
service criticality and information sensitivity;
reachability of the vulnerable component;
exploit reliability and available proof;
compensating prevention and detection;
recovery capability; and
consequence of the remediation itself.

Define urgency levels and target times through the approved risk method. These are organisational decisions; ISO 27001 does not prescribe one universal deadline table.

Use the risk score calculator to structure likelihood and impact discussion while retaining accountable professional judgement.

Choose treatment based on the service

Treatment may include:

applying a vendor patch or upgraded release;
changing configuration or disabling a vulnerable feature;
isolating the asset or restricting access;
adding filtering, detection or rate limits;
replacing unsupported technology;
removing the component or service;
applying a supplier workaround; or
accepting residual risk through authorized governance.

Test material changes before broad deployment when feasible. Consider backup, rollback, availability, interoperability and security side effects. An urgent patch that disables a critical safeguard or recovery function may create another unacceptable risk.

Govern exceptions and deferrals

When treatment cannot meet the target, require an exception containing:

affected assets and services;
risk and business impact;
reason for delay;
interim safeguards and monitoring;
accountable owner and approver;
action plan and target date; and
expiry and review frequency.

Exceptions should not disappear into a change backlog. Escalate overdue and repeatedly renewed items. Unsupported products usually need a funded replacement or isolation strategy, not an indefinite patch exception.

Verify the result

Installation status alone may be misleading. Verify treatment through suitable methods:

rescan or version confirmation;
configuration inspection;
targeted security test;
deployment and restart evidence;
validation that the vulnerable service is no longer reachable;
monitoring for failed deployment; and
confirmation that business and security functions still operate.

For a compensating measure, test the measure itself. A firewall request does not prove the rule is deployed correctly on every relevant path.

Connect changes to the ISO 27001 change-management guide so risk, testing, approval and rollback remain traceable.

Include suppliers and cloud responsibility

For managed services, determine which party identifies, assesses, patches and verifies each layer. Obtain notification and status evidence appropriate to the service. Supplier statements such as “fully managed” are too vague for accountable risk decisions.

Track vulnerabilities in customer-controlled configuration, identities, code and dependencies separately from provider infrastructure. Confirm contract terms for notification, emergency change and end-of-support.

Measure outcomes without rewarding noise

Useful measures may include:

coverage of in-scope assets by discovery and assessment;
time from publication to applicability decision;
time from decision to verified treatment by priority;
overdue exposure weighted by asset criticality;
exception age and renewal count;
unsupported technology exposure;
recurrence of previously corrected weaknesses; and
proportion of urgent changes that cause failure or rollback.

A high raw finding count may reflect better discovery rather than worse security. Present context and trends so management can decide where process or investment must change.

Preserve design and operating evidence

Design evidence

scope and asset sources;
intelligence responsibilities and frequency;
applicability and prioritization criteria;
remediation targets and approval authority;
testing and deployment rules;
exception and escalation process;
supplier responsibilities; and
metrics and reporting.

Operating evidence

advisories and scan results;
asset applicability decisions;
prioritized treatment records;
approved changes and deployment logs;
verification or rescans;
exceptions and interim safeguards;
supplier notifications; and
management review and corrective actions.

The NIST SP 800-40 Rev. 4 publication describes enterprise patch management as preventive maintenance and provides a useful governance reference.

Trace a worked example

A critical vulnerability affects a remote-access product. The asset inventory identifies two gateways: one internet-facing production gateway and one isolated training appliance. Threat intelligence reports active exploitation.

The production gateway receives urgent priority. The vendor update is tested against authentication and failover, approved through emergency change and deployed. A version check and targeted scan confirm treatment. Monitoring is reviewed for earlier exploitation attempts.

The training appliance cannot be patched immediately because its licence has expired. It is disconnected, an exception is approved for 14 days and replacement is assigned. The records show why the assets received different actions and how each risk was controlled.

Audit the full lifecycle

Sample vulnerabilities with different priorities, sources, asset types and outcomes. Include one not-applicable decision, one supplier-managed issue and one exception.

For each sample:

trace the intelligence source and receipt time;
identify all affected assets and owners;
inspect applicability and risk reasoning;
compare action timing with approved criteria;
examine change testing and authorization;
verify treatment effectiveness;
inspect any exception and interim control; and
confirm closure and management visibility.

Use the Annex A control lookup to explore related controls, then verify applicability against licensed standards.

Result	Example
Pass	Relevant vulnerabilities are linked to owned assets, risk-prioritized, treated or accepted and independently verified.
Partial	Scanning and patching operate, but supplier assets, applicability decisions or exception evidence are incomplete.
Fail	Critical exposure remains unidentified, severity is ignored without approval or closure relies only on ticket status.

Common questions

Does A.8.8 require every patch to be installed immediately?

No universal deadline applies to every patch. The organisation needs timely, risk-based decisions that account for exposure, impact, safeguards and the risk of change.

Is a vulnerability scanner mandatory?

The standard focuses on the control outcome, not one product. Scanning is often valuable, but sources and methods should fit the asset types and risks.

Can accepted vulnerabilities remain open forever?

Risk acceptance should have accountable approval and review triggers. Changes in exploitation, exposure, business impact or available treatment can invalidate the decision.

Make the decision cycle visible

Effective vulnerability management connects intelligence to assets, assets to risk and risk to verified action. When assumptions, exceptions and outcomes are traceable, management can prioritize real exposure and auditors can test more than patch statistics.