ISO 27001 A.8.8 — Management of technical vulnerabilities

What ISO 27001 A.8.8 requires

Management of technical vulnerabilities is one of 34 Technological Controls in ISO/IEC 27001:2022 Annex A. Obtain information about technical vulnerabilities of systems in use, evaluate exposure, and take measures to address the associated risk. Technological controls are tested against system state, not policy text: expect the auditor to ask for configuration exports, tickets, or console screenshots showing the control is enforced in the live environment.

Audit evidence assessors look for

When preparing your Statement of Applicability (SoA) for A.8.8, gather artefacts such as:

Vulnerability scanning reports (internal and external, authenticated and unauthenticated)
Vulnerability remediation tracking records with SLA compliance
Patch management policy with defined timelines by severity
Risk acceptance records for deferred or unpatched vulnerabilities

How to implement A.8.8

Scan authenticated, not just from the outsideUnauthenticated external scanning finds a fraction of what is there. Authenticated scanning against the full estate — including containers, images and cloud workloads — is what the control expects, and the difference in findings volume is usually an order of magnitude.
Set remediation SLAs by severity and stick to themDefine the timelines (for example critical within 7 days, high within 30) in policy, then report against them. The control is not "we scan"; it is obtaining information, evaluating exposure, and taking measures. The SLA report is what evidences the third part.
Prioritise by exploitability, not just CVSSA CVSS 9.8 on an internal system with no path to it matters less than a CVSS 7.5 being actively exploited on an internet-facing service. Feed threat intelligence from A.5.7 into prioritisation and record the reasoning — this is exactly the "evaluate exposure" language in the control.
Formalise risk acceptance for what you will not fixSome vulnerabilities cannot be remediated in the SLA — legacy systems, vendor dependencies, breaking changes. That is acceptable if it is a documented, time-bound, authorised decision with compensating controls. Undocumented, it is simply an overdue vulnerability.
Reconcile scan coverage against the asset inventoryThe vulnerability you never find is on the host the scanner never saw. Compare scanner coverage to the asset inventory periodically; the delta is the real finding.

Common audit findings for A.8.8

What actually gets raised against A.8.8, in rough order of how often it comes up:

Scan coverage materially below the asset inventory, with no reconciliation performed.
Remediation SLAs defined in policy but never reported against, so compliance is unknown.
Long-standing critical findings with no risk acceptance record and no compensating control.
External scanning only, with the internal estate and container images unassessed.

Scoping A.8.8

A.8.8 is applicable to any organisation running technology, which is all of them. It is one of the most heavily sampled controls in a Stage 2 audit because the evidence is quantitative and easy to test. It maps closely to SOC 2 CC7.1 — evidence built for one will substantially serve the other.

How A.8.8 maps to SOC 2 and NIST CSF

If you run more than one framework, the same evidence usually satisfies all of them. A.8.8 aligns with:

SOC 2: CC7.1 Vulnerability and configuration monitoring

NIST CSF 2.0: ID.RA-01 Vulnerability identification, ID.RA-08 Vulnerability disclosure handling, PR.PS-02 Software maintenance and patching

ISO 27001:2013 mapping

A.8.8 consolidates the following ISO 27001:2013 control(s): A.12.6.1, A.12.6.2. If you are transitioning an existing ISMS, map your prior evidence for these to A.8.8 in your updated SoA.

Map A.8.8 to NIST CSF & SOC 2 →

Crosswalk this control in the Control Mapper & Gap Assessment.

Document the risk →

Record treatment for gaps against A.8.8 in the Risk Register.

Related Annex A controls

A.5.7 Threat intelligence A.8.9 Configuration management A.8.19 Installation of software on operational systems

See all 34 Technological Controls →

Frequently asked questions

Is ISO 27001 A.8.8 mandatory?

Annex A controls are not mandatory in the abstract. Clause 6.1.3 requires you to compare your risk treatment plan against Annex A and justify, in the Statement of Applicability, any control you exclude. If your risk assessment surfaces a risk that A.8.8 addresses, excluding it needs a documented, risk-based rationale that an auditor will test.

How do auditors test ISO 27001 A.8.8?

In two passes. First design: does a documented control exist, is it owned, and does it address the risk? Then operating effectiveness: the auditor samples records from across the audit period to confirm the control actually ran. A Stage 2 audit will typically pull several samples, so evidence that only exists for the month before the audit is a common finding.

How often should A.8.8 be reviewed?

ISO 27001 sets no fixed interval — it requires review at "planned intervals" and after significant change. Annual review is the norm most certification bodies expect, with an out-of-cycle review triggered by incidents, major system changes, restructures, or new regulatory obligations. Record the review date and outcome either way; an undated control is treated as unreviewed.

What does ISO 27001 A.8.8 map to in SOC 2 and NIST CSF?

A.8.8 aligns with SOC 2 CC7.1 and NIST CSF ID.RA-01, ID.RA-08, PR.PS-02. Evidence gathered for one framework will usually satisfy the others, which is the basis for a test-once, satisfy-many control library.

What was A.8.8 in ISO 27001:2013?

A.8.8 consolidates 2 control(s) from the 2013 edition: A.12.6.1, A.12.6.2. When transitioning, re-point the existing evidence rather than rebuilding it — the underlying requirement has not changed materially.

What are the most common audit findings for A.8.8?

Scan coverage materially below the asset inventory, with no reconciliation performed. Remediation SLAs defined in policy but never reported against, so compliance is unknown.