ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 vulnerability management is one of the few Annex A controls where the gap between what auditors accept and what most organizations actually do is measurable. The control is A.8.8, Management of technical vulnerabilities, and it is three requirements in one sentence: obtain the information, evaluate your exposure, take appropriate measures. A scanner licence satisfies the first. Most ISO 27001 vulnerability management programs never genuinely satisfy the second, because they substitute a vendor severity score for an evaluation of their own environment — and in October 2026 the two public benchmarks that used to make that substitution look defensible have both moved against it.
This guide covers what A.8.8 states, the 2013 merge that quietly widened it, why a CVSS threshold is not an exposure evaluation, how CISA’s June 2026 directive reset the prioritization benchmark, and the evidence an auditor will actually ask to see.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Annex A control 8.8 reads: information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken. (Annex A states controls with “shall”; ISO/IEC 27002:2022, the guidance companion, states the same control with “should”. That is a difference between two documents, not an edition change — do not read anything into it.)
Three limbs, three separate failure modes, and ISO 27001 vulnerability management is only as strong as the weakest of them. Pull them apart before you buy anything:
| Limb of A.8.8 | What it asks | How it usually fails | Evidence that satisfies it |
|---|---|---|---|
| Obtain information | Vulnerability information about the systems in use — from vendor advisories, scanners, penetration tests, threat intelligence, third-party library monitoring | Coverage is narrower than the asset inventory, so the scan report is silent about systems nobody onboarded | Scanner coverage reconciled against the asset inventory, with the delta explained |
| Evaluate exposure | Your exposure — this environment, these compensating controls, this business impact | A vendor severity band is treated as the evaluation | A documented prioritization method that uses exposure and exploitation facts, not severity alone |
| Take appropriate measures | Action proportionate to the evaluation, routed through change management or incident response depending on urgency | Patching is the only response on the menu, so anything unpatchable becomes a permanent open ticket | Change records, mitigation records, and documented risk acceptance for what stays open |
ISO/IEC 27002’s guidance for 8.8 fills in the practical detail: an asset inventory carrying software version numbers, vendors, and deployment locations as the precondition; named roles for monitoring, assessment, patching, and asset tracking; scanning tools and documented penetration testing; monitoring of third-party code libraries; patches taken only from trusted sources and tested before they reach production; an audit trail of the activity; and periodic review of the process itself. It also tells you to agree how this works with cloud providers, whose patching schedule is not yours to set — a point that quietly limits how much of your ISO 27001 vulnerability management you control directly.
A.8.8 is not a renumbering. It is a two-into-one merge, and the second parent came from a different chapter of the 2013 standard entirely:
| ISO 27001:2013 control | 2013 chapter | ISO 27001:2022 control |
|---|---|---|
| A.12.6.1 Management of technical vulnerabilities | A.12 Operations security | A.8.8 Management of technical vulnerabilities |
| A.18.2.3 Technical compliance review | A.18 Compliance | A.8.8 Management of technical vulnerabilities |
| A.12.6.2 Restrictions on software installation | A.12 Operations security | A.8.19 Installation of software on operational systems |
The consequence is specific and almost nobody writes about it. A.18.2.3 was the control that required information systems to be reviewed regularly for compliance with your own security policies and standards — hardening baselines, build standards, configuration rules. That requirement did not disappear in the 2022 edition. It moved inside A.8.8. So a single Statement of Applicability row now has to answer two different questions: are we finding the vulnerabilities vendors tell us about, and are we technically checking that our systems match the standards we set ourselves. A clean scan report answers the first. It says nothing about the second. That is the forgotten half of ISO 27001 vulnerability management, and it is why so many programs produce a pile of CVE evidence and nothing at all on baseline drift.
If you already treat configuration compliance checking as purely an A.8.9 matter, read our guide to ISO 27001 configuration management alongside this one: 8.9 is where the baselines are defined and monitored, and 8.8 is where the technical verification of those baselines now reports.
The Statement of Applicability itself is mandatory under clause 6.1.3, so whatever you decide about A.8.8 has to be written down there with a justification. Excluding it is not a realistic option for any scope that runs software, so every certified organization has an ISO 27001 vulnerability management position on record whether it means to or not. For the full control set of ISO/IEC 27001:2022 — 93 controls in four themes, 37 organizational, 8 people, 14 physical, 34 technological — see our overview of the ISO 27001:2022 controls.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
The most common prioritization rule in the wild is some version of “critical in 15 days, high in 30, medium in 90,” keyed to the CVSS score on the scanner screen. It is clean, it is auditable, and as ISO 27001 vulnerability management it does not satisfy the evaluate limb of A.8.8. The body that publishes CVSS says so itself.
CVSS v4.0, released on 1 November 2023 by FIRST, has four metric groups: Base, Threat, Environmental, and Supplemental. The CVSS v4.0 user guide carries a section heading that could have been written for an ISO auditor: CVSS Base Score (CVSS-B) Measures Severity, not Risk. The specification is explicit that the Base score reflects only the intrinsic characteristics of a vulnerability, is independent of threat and of the environment where the vulnerable system sits, and assumes the reasonable worst-case impact across all deployments.
FIRST also publishes a nomenclature precisely so nobody mistakes one for the other:
| Notation | Metrics used | What it tells you |
|---|---|---|
| CVSS-B | Base only | Intrinsic severity, worst-case assumption — what your scanner shows |
| CVSS-BT | Base + Threat | Severity adjusted for exploit maturity and in-the-wild exploitation |
| CVSS-BE | Base + Environmental | Severity adjusted for your environment and asset criticality |
| CVSS-BTE | Base + Threat + Environmental | FIRST’s own guidance: the only combination that gets “much closer to risk” |
Read that bottom row against the words in A.8.8. The control asks you to evaluate the organization’s exposure. Environmental metrics are the part of CVSS that models exposure, and FIRST puts the responsibility for applying them squarely on the consumer — meaning you, not the scanner vendor. A policy built on CVSS-B alone is using the one score its own publisher says should not be used alone. That is not a technicality an experienced auditor will miss when they ask how your ISO 27001 vulnerability management thresholds were derived.
Two more v4.0 changes matter for ISO 27001 vulnerability management documentation written before 2024: Exploit Code Maturity was renamed Exploit Maturity and moved into the Threat group, and Remediation Level and Report Confidence were retired. If your procedure names the retired metrics, it is describing a scoring system that no longer exists.
The scale argument for prioritization is easy to make with live data rather than estimates. Both of these figures were read from the primary sources on 14 October 2026:
| Source | Count | What it means for prioritization |
|---|---|---|
| NIST National Vulnerability Database | 407,372 CVE records | The universe of published vulnerabilities, growing daily |
| CISA Known Exploited Vulnerabilities catalog (version 2026.10.13) | 1,741 entries | About 0.4% of all CVEs have confirmed real-world exploitation |
| KEV entries flagged as used in ransomware campaigns | 361 | Roughly one in five KEV entries has a known ransomware link |
| KEV entries flagged for forensic triage | 81 | The subset where CISA expects agencies to check for prior compromise, not just patch |
The catalog’s earliest entries are dated 3 November 2021, the day the KEV catalog was created. It is free, machine-readable, and it is the cheapest evidence of exploitation you can feed into an evaluation. Note the shape of the numbers: a severity-driven program spends its budget across tens of thousands of high-scoring findings, while the set with demonstrated exploitation is three orders of magnitude smaller. Exposure plus exploitation evidence is what turns a scan report into the evaluation that ISO 27001 vulnerability management asks for.
This is the change most ISO 27001 vulnerability management procedures have not caught up with, and it is the easiest one to fix. On 10 June 2026 CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, which supersedes both BOD 22-01 (3 November 2021, the directive that created the KEV remediation clock) and BOD 19-02 (29 April 2019, internet-accessible systems).
The old model was severity-and-catalog driven: KEV entries carried a due date, two weeks for recent CVEs and six months for pre-2021 ones. The new model is a risk-tiered matrix built on four variables, drawn from the Stakeholder-Specific Vulnerability Categorization (SSVC) methodology:
| Criterion | Question it asks | Where you get the answer |
|---|---|---|
| Asset exposure | Is the affected asset reachable from the internet? | Your asset inventory and external attack surface data |
| KEV status | Is the vulnerability in CISA’s catalog of exploited vulnerabilities? | The free KEV feed |
| Exploit automation | Can an adversary automate every step needed to exploit it? | CISA’s Vulnrichment data and threat intelligence |
| Technical impact | Does the attacker gain partial control or total control of the asset? | CISA’s Vulnrichment data, not the severity band alone |
Three of those four answers are published free. CISA states that it publishes answers to KEV status, exploit automation, and technical impact for every CVE ID through services such as its Vulnrichment program, and points agencies at its internet exposure reduction guidance for the fourth. For a small security team, that is a prioritization input you do not have to build or buy — which removes the usual excuse for falling back on severity bands.
The resulting timelines in the directive’s Table 1 are a sixteen-row truth table across those four variables. They run from three days plus forensic triage at the worst combination — publicly exposed, in the KEV catalog, automatable, total control — through fourteen-day and sixty-day tiers, down to “fix on system upgrade” for the two rows where the asset is not exposed, the vulnerability is not in KEV and exploitation is not automatable. The forensic triage requirement is the interesting part: at the top tier, patching is not considered sufficient, because an exposed and actively exploited asset may already be compromised. That is the same logic the KEV feed now carries as a per-entry field.
Two caveats before you copy the matrix into your procedure. BOD 26-04 binds United States federal civilian executive branch agencies, not private companies, and it is not an ISO 27001 requirement — no certification body will hold you to it. And CISA has moved away from requiring CVSS for prioritization, which is why the directive’s criteria read as exposure and exploitation facts rather than score bands. Its value to ISO 27001 vulnerability management is as a published, defensible reference point: when an auditor asks how your tiers were derived, “we modelled them on the current US federal directive, adjusted for our exposure” is a far stronger answer than “critical means 15 days.”
Search for remediation timeframes and you will be told that critical internet-facing systems must be scanned weekly, or monthly, or quarterly, and that criticals must be fixed in 15 days. Those are vendor conventions, not ISO 27001 vulnerability management requirements. ISO/IEC 27001:2022 states no scanning frequency and no remediation deadline anywhere — not in A.8.8, not in clause 9.1. What 27002’s guidance for 8.8 actually says is that you should define a timeline to react to notifications of potentially relevant technical vulnerabilities, and that the action should run through change management or through incident response depending on how urgent it is.
That is a requirement to make a decision and keep it, not a number to hit. The audit question is never “why 15 days?” — it is “where did your tiers come from, and do your records show you met them?” ISO 27001 vulnerability management that misses a self-declared 30-day target is in better shape than a program that quietly has no target, because the first produces measurable evidence and the second produces none. Our guide to vulnerability management metrics covers what to measure once the tiers exist.
The third limb of A.8.8 says “appropriate measures,” not “patch.” NIST’s current patching guidance — SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, published April 2022 and superseding Revision 3 from 2013 — names four:
| Risk response | What it looks like in practice | ISO 27001 evidence it generates |
|---|---|---|
| Accept | Rely on existing controls, or judge the impact low enough that no action is needed | A risk treatment decision with an owner and a review date |
| Mitigate | Patch, upgrade, disable the vulnerable feature, or isolate the asset behind segmentation | Change records, firewall or segmentation configuration, retest results |
| Transfer | Move to a managed or SaaS service where the provider patches, or insure the consequence | Supplier agreements and service descriptions under A.5.19 to A.5.21 |
| Avoid | Uninstall the software, decommission the asset, or switch off the capability | Decommissioning records and an updated asset inventory |
SP 800-40 Rev. 4 includes a sentence that belongs at the top of every ISO 27001 vulnerability management policy: by default, an organization accepts the risk posed by using its software. Acceptance is the condition you are already in; every other response is something you choose to do. Framed that way, ISO 27001 vulnerability management lines up exactly with clause 6.1.3 risk treatment, and the unpatched finding that has been open for eight months stops being a hole in the program and becomes either a documented acceptance or a nonconformity against your own rules. It cannot stay as neither.
NIST also separates the scenarios you need procedures for — routine patching, emergency patching, emergency mitigation where no patch exists yet, and genuinely unpatchable assets — and warns that neglected routine patching makes emergency patching slower, because new patches often depend on the ones you skipped.
Most organizations run an exceptions list: a spreadsheet of assets that cannot be patched on the standard schedule, each with an approval and an expiry date that gets extended. SP 800-40 Rev. 4 takes a different line, and it is the single most useful idea in the document for ISO 27001 vulnerability management. Rather than labelling assets as exceptions, assign every asset to a maintenance group — a set of assets with similar characteristics and the same maintenance needs per scenario, defined by what software they run, what outage they tolerate, what mitigations already surround them, and what the impact would be if they were compromised.
NIST’s reasoning is blunt: if an asset cannot or should not be patched, that removes one option for addressing its vulnerabilities, but it still has maintenance needs, so it still belongs to a group. In ISO 27001 vulnerability management terms, an exceptions register is a list of things you have decided not to manage. A maintenance group is a statement of how you manage them. The second survives an audit; the first invites the question of why the expiry date keeps moving.
There is a procurement angle here too, and it maps to the supplier controls rather than to A.8.8. SP 800-40 Rev. 4 offers a questionnaire for buyers: how many patches do you expect to release each year, for how many years are you committed to fixing vulnerabilities, do you have a disclosure program, and what do you recommend when a vulnerability is public but no patch exists? Ask those at selection and you reduce the unpatchable population before it ever reaches your ISO 27001 vulnerability management process.
Certification auditors sample. For ISO 27001 vulnerability management they sample in a predictable order, because each item tests a different limb:
| Evidence | What it proves | The question behind it |
|---|---|---|
| Scanner or tool coverage reconciled to the asset inventory | The “obtain” limb covers the real estate | What is in the inventory but not in the scanner? |
| Named roles for monitoring, assessment, remediation, and asset tracking | Accountability exists before an incident forces it | Who decides a finding is an emergency? |
| Documented prioritization method, with its inputs | The “evaluate” limb reflects your environment | Where did your tiers come from? |
| A sample of findings traced from detection to closure | The “act” limb works end to end | Show me this critical from scan to change record |
| Change records for patches, and incident records for emergencies | Action was routed through the right process | Which route did this take, and why? |
| Risk acceptances for findings left open, with owner and review date | Open items are decisions, not drift | Who accepted this, and when is it revisited? |
| Penetration test reports and remediation tracking | Independent detection supplements the tooling | What did the test find that scanning missed? |
| Technical compliance checks against your own baselines | The inherited A.18.2.3 requirement is met | How do you know builds still match the standard? |
| Management review input on vulnerability performance | Clause 9.3 sees the program, not just the tool | What did leadership do with these numbers? |
The last two are the ones that trip well-tooled organizations. Baseline verification gets delegated to the configuration team and never surfaces as A.8.8 evidence, and ISO 27001 vulnerability management performance gets reported to IT management but never reaches the management review pack.
No. A.8.8 does not require documented information, and an ISO 27001 vulnerability management policy is not among the mandatory documents of ISO/IEC 27001:2022 — see our list of the ISO 27001 mandatory documents. Several popular control guides describe a vulnerability management policy, rules of engagement document, and patch management policy as compliance requirements. They are not; they are good practice that most organizations adopt because the alternative is undocumented judgement.
What is genuinely mandatory is the Statement of Applicability entry under clause 6.1.3, the risk treatment decisions behind anything you leave open, and whatever records your own procedure says you will keep — clause 7.5.3 then governs how those records are controlled. Write the policy because it makes the three limbs of ISO 27001 vulnerability management auditable in one place, not because a blog said the standard demands it.
This distinction decides how an audit finding gets written, and it is worth understanding before the auditor arrives. An unpatched critical vulnerability is not, by itself, a nonconformity against ISO 27001, and treating every open finding as one wastes the ISO 27001 vulnerability management effort you have. The standard does not prohibit vulnerabilities; no estate is free of them. A nonconformity arises when your ISMS says one thing and reality says another: your procedure commits to a 14-day tier and the record shows 60 days with no acceptance, or the SoA says A.8.8 is applied and there is no evidence of evaluation, or an exception expired a year ago and nobody renewed it.
That is why a self-declared timeline you actually meet is stronger than an aggressive one you miss, and why documented acceptance is not an admission of weakness. For how findings get graded and closed, see our guide to ISO 27001 nonconformity.
ISO 27001 vulnerability management does not stand alone, and the SoA justification for A.8.8 should name its neighbours:
| Control | Relationship to A.8.8 |
|---|---|
| A.5.9 Inventory of information and other associated assets | The precondition — scanner coverage can never exceed what you know you own |
| A.5.7 Threat intelligence | Feeds the “obtain” limb with exploitation context the scanner lacks |
| A.8.9 Configuration management | Defines the baselines that A.8.8’s inherited technical compliance review verifies |
| A.8.19 Installation of software on operational systems | The other half of 2013’s A.12.6 — controls what gets installed in the first place |
| A.8.29 Security testing in development and acceptance | Finds vulnerabilities before release; A.8.8 handles systems in use |
| A.8.32 Change management | The route most remediation takes, and the record that proves it |
| A.5.19 to A.5.21 Supplier and ICT supply chain security | Where cloud and vendor patching responsibility is agreed |
| A.5.24 to A.5.26 Incident management | The route emergency remediation takes when urgency overtakes change control |
A.5.7 is the one worth deliberate attention: without exploitation context, the evaluate limb has nothing to work with except severity. Our guide to ISO 27001 threat intelligence covers what the control expects and how to run it without a subscription budget.
Two developments this year should prompt a review of any ISO 27001 vulnerability management procedure written before 2026, even though neither is an ISO requirement:
CISA BOD 26-04 (10 June 2026). The federal benchmark moved from severity-and-catalog to exposure, exploitability, automation, and technical impact, and dropped the CVSS requirement. If your prioritization narrative cites BOD 22-01 or its two-week KEV clock, it cites a revoked directive.
EU Cyber Resilience Act Article 14 (applies from 11 September 2026). Manufacturers of products with digital elements now report actively exploited vulnerabilities on a three-stage clock: early warning within 24 hours, vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For you as a buyer, that is a supply of information the “obtain” limb never used to have — and a question worth adding to supplier assessments, since under Article 69(3) the duty reaches products placed on the market years ago. See our breakdown of the CRA reporting deadline.
Neither changes A.8.8’s text. Both change what a defensible evaluation looks like, which is the part of ISO 27001 vulnerability management that auditors actually probe.
ISO 27001 vulnerability management does not specify a frequency. ISO/IEC 27001:2022 states no scanning interval and no remediation deadline; 27002’s guidance for 8.8 asks you to define a timeline for reacting to vulnerability notifications. Set tiers you can evidence — typically continuous or weekly for internet-facing systems and monthly for internal ones — and expect to be audited against your own numbers, not against a figure from the standard.
Not explicitly. Penetration testing is named in 27002’s guidance for 8.8 as one way to obtain vulnerability information, and in A.8.29 for development and acceptance testing. Neither makes an annual external test mandatory. It is, however, the most common way organizations demonstrate the “obtain” limb reaches beyond automated scanning, and most certified organizations do run one.
On its own, no. FIRST’s own user guide states that the CVSS Base score measures severity, not risk, and that it should be supplemented with threat and environmental factors. A.8.8 asks you to evaluate your organization’s exposure, which is exactly what the Base score excludes. Use CVSS as one input to ISO 27001 vulnerability management alongside exploitation evidence such as the KEV catalog and your own asset exposure data.
A.8.9 Configuration management is about defining, implementing, monitoring, and reviewing secure configurations. A.8.8 is about vulnerabilities in the software you run and, since it absorbed 2013’s A.18.2.3 technical compliance review, about technically verifying that systems still comply with the standards you set. In practice 8.9 writes the baseline and 8.8 checks it, which is why the two controls are usually audited together in any ISO 27001 vulnerability management review.
Realistically, no. Any scope that runs operating systems, applications, or cloud services has technical vulnerabilities to manage, and clause 6.1.3 requires a justification for every exclusion. An exclusion here would have to argue that you operate no software in scope, which is almost never true. Where responsibility sits with a provider, the honest treatment is to apply the control and document the shared responsibility under the supplier controls, not to exclude it.
Yes. ISO 27001 vulnerability management covers them: ISO/IEC 27002’s guidance for 8.8 explicitly includes monitoring third-party code libraries for vulnerabilities in underlying components. In a modern application estate that is where most of the findings live, and it is the part of the “obtain” limb that an infrastructure scanner alone will miss entirely.
If you are building this from nothing, the order that works is: reconcile the asset inventory first, because every other limb inherits its gaps; define maintenance groups rather than exceptions; write a prioritization method that names exposure and exploitation as inputs alongside severity; set tiers you can meet and record against them; and make sure baseline compliance checking and vulnerability performance both surface in management review. That sequence maps ISO 27001 vulnerability management to the three limbs of A.8.8 in the order an auditor will test them.
If you would rather start from a drafted set, the ISO 27001 Toolkit includes 165 templates covering the full standard — Statement of Applicability, risk treatment, and the operational procedures that A.8.8 reports into — for $149 as a one-time purchase, editable and aligned to the 2022 edition. It will not do the asset reconciliation for you, but it removes the blank-page problem from everything downstream of it.
October 14, 2026
October 13, 2026
October 12, 2026
October 12, 2026
October 12, 2026