ISO 27001 controls
A vulnerability programme starts with knowing what you own
Annex A control 8.8, management of technical vulnerabilities, expects you to learn about weaknesses in your systems, judge how much they matter, and act in time. The scanner is the easy part. The hard parts are coverage, ranking and showing an auditor that findings were closed, or knowingly accepted.
Back to ISO 27001 services01 · Inventory first
Scan what is on the list, and fix the list
A scan only covers what it knows about.
Control 8.8 leans on the asset inventory of control 5.9. If a server, container image or laptop is missing from the inventory, it is probably missing from the scan too, and nobody will notice until an attacker does. The first test an auditor runs is simple: pick assets from the inventory and look for them in the scan results, then pick hosts from the scan and look for them in the inventory.
- Infrastructure: servers, network devices and cloud resources, scanned from inside and outside.
- Endpoints: laptops and mobile devices, usually through the device management or endpoint tool.
- Applications and code: dependency scanning in the build pipeline, plus scanning of container images.
- Cloud configuration: misconfiguration findings from a posture tool, which overlap with configuration management.
- Vendor advisories: a named person watching the advisories for products you run, which ties into threat intelligence (control 5.7).
02 · Ranking
Severity is a starting point, not a decision
Rank by exploitability and exposure, then by score.
A scanner reports a severity score, usually based on the Common Vulnerability Scoring System (CVSS). That score describes the flaw in general. It does not know whether your vulnerable host faces the internet, holds customer data or is already behind a compensating control. Two more questions change the order of work: is the flaw being exploited in the wild, and can an attacker reach it on your network?
| Signal | Question it answers | Where to find it |
|---|---|---|
| Severity score | How bad is the flaw in the abstract? | The scanner, the vendor advisory, CVSS |
| Known exploitation | Is anyone using it right now? | The CISA Known Exploited Vulnerabilities catalog, vendor advisories, threat feeds |
| Exposure | Can an attacker reach the affected component? | Your network map, cloud security groups, the asset inventory |
| Asset value | What is on the box if it falls? | Classification of the data it holds (control 5.12) |
| Existing protection | Is something already blocking the path? | Firewall rules, web application firewall, disabled feature |
Illustrative: two findings, one afternoon
A scan returns a critical-rated flaw in a library on an internal reporting server reachable only from the office network, and a high-rated flaw in the VPN appliance that sits on the internet and appears in a public exploited-vulnerabilities list. The team patches the VPN first, the same day, and schedules the library fix into the next release with a ticket and a date. The lower score went first because exposure and active exploitation outweighed the label.
03 · Timelines
Fix windows are your policy, so write them down
The standard asks for timely action and leaves the clock to you.
Annex A does not set patch deadlines. You decide them in a vulnerability management procedure, by risk tier, and then measure yourself against them. Customer contracts, regulators or a SOC 2 commitment may already fix some numbers for you; check those first so the procedure does not promise less than a contract does.
A small SaaS team
- One cloud posture tool and a dependency scanner in the pipeline
- Weekly triage by the lead engineer, findings tracked as tickets
- Managed services patched by the provider; your own images rebuilt on a schedule
- A one-page procedure with three risk tiers and their fix windows
A large enterprise
- Authenticated scanning across data centres and cloud accounts, with agent coverage on endpoints
- A vulnerability team that triages and routes findings to system owners
- Patch rings: test, early adopters, then the estate
- Dashboards of open findings against the timeline, reported to management review
When a patch is not available or would break something, mitigate: turn off the vulnerable feature, restrict access, add a detection rule. Record the mitigation on the ticket so it can be shown later.
04 · Exceptions
Exceptions and accepted risk
An exception is a decision with an owner and an end date.
- Why it cannot be fixed now. A legacy system, a vendor with no patch, a release freeze.
- What reduces the risk meanwhile. The mitigation, in concrete terms.
- Who accepted it. The risk owner named in your risk process, not the engineer who found it.
- When it expires. A review date, after which the exception lapses unless renewed.
- Where it is recorded. In the risk register or an exceptions log the auditor can sample.
05 · Evidence and pen tests
What an auditor samples, and where pen testing fits
Scans find known flaws; a test shows how they chain.
- The procedure. Scope, tools, frequency, risk tiers and fix windows.
- Scan history. Reports across the audit period, not one run the week before.
- Sampled findings. A handful of findings traced from detection to fix or exception, with dates.
- Coverage check. Inventory against scan targets, both directions.
- Trend reporting. Open findings and overdue items, seen by management.
A penetration test is not named as a requirement in Annex A, but many organisations use one as evidence that scanning and patching work in practice. Its findings should flow into the same ticket and exception process as scanner output. The pages below cover what the standard and auditors expect from a test, and the Annex A list as a whole.
- Penetration testing and ISO 27001What the standard expects, and what auditors accept.
- ISO 27001 Annex A controlsAll 93 controls in four themes, with what each one asks.
- Unauthenticated scans only. They see the outside of a host and miss most missing patches.
- Findings with no owner. A report emailed to a shared inbox is not a process.
- Permanent exceptions. An accepted risk with no review date is just an ignored one.
- Ignoring the pipeline. Container images and libraries carry most new flaws in a cloud product.
Sources: ISO/IEC 27001:2022 Annex A controls 5.7, 5.9, 5.12 and 8.8 (cited by number and name only); NIST SP 800-40 Rev. 4 on enterprise patch management planning; NIST SP 800-53 Rev. 5 controls RA-5 and SI-2; FIRST's Common Vulnerability Scoring System; the CISA Known Exploited Vulnerabilities catalog. The prioritisation example is illustrative.
Questions about vulnerability management
How often should we scan for ISO 27001?
The standard does not say. Your procedure does.
Pick a frequency that matches how fast your estate changes. Continuous or weekly scanning is common for cloud products; monthly is common for stable internal networks. The auditor checks you followed your own frequency.
Do we have to fix every critical finding within a fixed number of days?
Only if your policy or a contract says so.
Annex A asks for timely action, judged against risk. Set fix windows per tier, then either meet them or record a reasoned exception with an owner and an end date.
Does a cloud provider's patching count?
For the layers they manage, yes; the rest is yours.
On managed services the provider patches the platform. Your images, code, dependencies and configuration remain yours. Write the split down so the auditor can see which evidence comes from whom.
Is a yearly penetration test enough for control 8.8?
No. A test is a snapshot; 8.8 is a running process.
A test is useful evidence and finds things scanners miss, but control 8.8 expects ongoing discovery and remediation between tests.
Find out what your scans are missing.
An ISO 27001 gap analysis compares your inventory, scanning and remediation records against control 8.8, and a penetration test shows what an attacker could chain together.