ISO 27001 A.8.8: Management of Technical Vulnerabilities

ISO 27001 A.8.8 requires that an organization obtain information about the technical vulnerabilities in the systems it uses, assess its exposure to them, and take action: patch, apply a compensating control, or formally accept the risk. It is a Technological control (A.8), and teams most often get flagged on the remediation SLA: committing to a timeline the team cannot hold, then handing the auditor a trail of findings that missed it.

ISO 27001 A.8.8 maps fully to SOC 2 CC7.1, so a team already running vulnerability management for SOC 2 has most of the evidence an ISO 27001 auditor will ask for.

What is ISO 27001 A.8.8?

ISO 27001 A.8.8, titled Management of technical vulnerabilities, requires that information about the technical vulnerabilities of information systems in use be obtained, the organization's exposure to those vulnerabilities be evaluated, and appropriate measures be taken. The intent, as expressed in ISO/IEC 27001:2022, Annex A, is that a team knows what is vulnerable in its environment, understands how much that exposure matters, and acts on it deliberately rather than discovering the gap during an incident.

The control is deliberately technology-neutral. It does not name a scanner, a CVE feed, or a patch cadence. What it expects is a running process: a way to learn about new vulnerabilities, an asset inventory that defines what is in scope, a method for judging severity and exposure, and a documented response for each finding. A.8.8 operates alongside configuration management (A.8.9) and change management (A.8.32), but it owns a specific job: the loop from detecting a vulnerability to closing it or accepting it.

How do you implement A.8.8?

Run A.8.8 as a closed loop that detects vulnerabilities, decides what each one means, and closes it on a timeline the team can hold. The sequence below is the same regardless of where the infrastructure lives:

1. Maintain an asset inventory as the scan scope. Every in-scope system, server, container image, network appliance, and application has to be in an inventory, because a scan can only find vulnerabilities on assets it knows about. The asset inventory defines the scan scope, and a system missing from it is a system nobody is checking.
2. Obtain vulnerability information continuously. Run authenticated scans against in-scope assets on a defined cadence with a scanner such as Nessus or Qualys, and subscribe to vendor security advisories and CVE feeds for the software and hardware in the environment. Scanning finds what is vulnerable now; advisory monitoring catches newly published vulnerabilities affecting systems already deployed.
3. Triage by severity and exposure. Score each finding by severity (typically the CVSS rating) and by real exposure: an internet-facing production host outranks an isolated internal device running the same CVE. Triage is what turns a raw scan of hundreds of findings into a short, ranked remediation queue.
4. Set remediation SLAs per severity. Assign a fix-by timeline to each severity band and write it into the vulnerability management policy. A defensible starting point is critical and high within 48 hours on internet-facing assets, medium within 7 days, and low within 30 days. Set SLAs the team can meet: missing a 24-hour critical SLA repeatedly produces evidence of the team violating its own policy, which is a worse audit outcome than a slightly longer SLA the team consistently hits.
5. Patch or apply a compensating control. Remediate within the SLA by patching, or, when a system cannot be patched, apply a compensating control (network isolation on a restricted segment, tighter monitoring) and record a documented, time-bounded risk acceptance. Every finding ends in one of three states: fixed, mitigated, or formally accepted.
6. Verify with a rescan. Confirm the fix took effect by rescanning the asset and showing the finding cleared. The rescan after remediation is what closes the loop and proves the action worked rather than being assumed.

Steps 2 and 5, the scanning and the patching mechanics, implement differently in cloud and on-prem environments. The two subsections below cover each.

In cloud environments

Cloud environments implement A.8.8 largely through managed services, with findings collected in a console the team already operates:

• Managed vulnerability scanning from the cloud provider (the native vulnerability service) or a third-party scanner covers hosts and workloads without deploying a separate scanning appliance.
• Container and image scanning with a tool such as Trivy runs in the CI/CD pipeline and the registry, scanning every image on a schedule and on every merge to the main branch, and dependency scanning such as Dependabot or Snyk flags vulnerable packages, so a vulnerable dependency is caught before it reaches production.
• Cloud vulnerability findings from the provider's security hub or posture management tool aggregate misconfigurations and known CVEs across accounts into one triage queue.
• Auto-patching and managed base images apply operating system and dependency updates through managed instance groups or rebuilt golden images, shortening the remediation step for a large share of findings.
• Egress-limited, immutable infrastructure means many fixes go out as a redeployed image through the change pipeline rather than an in-place patch, so the change record doubles as the remediation evidence.

On-prem / self-hosted

On-prem environments reach the same outcomes through scanning appliances and patch tooling that produce their own evidence. The SOC 2 vulnerability scanning on-prem guide and the SOC 2 patch management on-prem guide cover the full implementation; the shape is:

• Agent-based and authenticated scanning where agents run on servers and the scanner connects to firewalls, switches, and appliances through their management interfaces, covering device classes that cannot run an agent.
• Patch tooling such as WSUS, SCCM, Red Hat Satellite, or a cross-platform RMM applies operating system and application updates on a scheduled cadence across the estate.
• Maintenance windows carry the patches that need downtime or testing, with the patch flowing through the change process and the window recorded on the change ticket.
• Firmware and appliance updates for BIOS, out-of-band management cards, switches, and the edge firewall come from vendor channels, tested in a lab instance first where the blast radius requires it.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.8?

Evidence for A.8.8 is a chain: detection showing what was found, remediation showing what was done and when, and verification showing the finding closed. Many teams wire the scanner and ticketing outputs into an automated evidence pipeline, the approach covered in GRC engineering, so the chain assembles as the loop operates.

How does A.8.8 map to SOC 2?

A.8.8 is a Full overlap with SOC 2 CC7.1. An organization with an existing SOC 2 vulnerability management program can reuse the same detection, remediation, and verification evidence for the ISO 27001 certification audit with no adaptation.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including how much of an existing SOC 2 program transfers.

Related controls

A.8.8 owns the detect-to-remediate loop, and the controls around it govern the systems that loop runs against. A.8.9 Configuration management defines the hardened baseline a vulnerability is measured against, and A.8.32 Change management is the path a patch travels through to reach production. A.8.19 Installation of software on operational systems constrains what gets installed in the first place, which shrinks the vulnerability surface, and A.8.25 Secure development life cycle pushes vulnerability detection left into the build. The ISO 27001 certification guide summarizes how the A.8 controls fit together.

Frequently Asked Questions

What is ISO 27001 A.8.8?

ISO 27001 A.8.8 Management of technical vulnerabilities is a Technological control in Annex A of ISO/IEC 27001:2022. It requires that an organization obtain information about the technical vulnerabilities of the systems it uses, evaluate its exposure to them, and take appropriate action: patch, apply a compensating control, or formally accept the risk. It covers the loop from detection through scanning and advisory monitoring to triage, remediation, and verification.

What evidence satisfies A.8.8?

A.8.8 evidence is a chain from detection to closure: vulnerability scan reports showing the scan schedule and findings, remediation tickets with SLA timestamps for critical and high findings, patch records and rescan results showing the finding cleared, and a risk-accepted exception register for anything not remediated. A vulnerability management policy defining the severity-to-SLA framework ties the artifacts together. The same records satisfy SOC 2 CC7.1.

What remediation SLAs should you set for A.8.8?

A.8.8 does not prescribe timelines, so the team sets SLAs by severity and holds to them. A defensible starting point is critical and high vulnerabilities within 48 hours on internet-facing assets, medium within 7 days, and low within 30 days. The rule that matters most is achievability: a 24-hour critical SLA that the team misses repeatedly produces evidence of policy violations, which auditors flag, while a slightly longer SLA the team consistently meets reads as a control that operates.

How do you implement A.8.8 in the cloud versus on-prem?

Cloud implementations use managed vulnerability scanning, container and image scanning in the CI/CD pipeline, aggregated findings in the provider's security hub, and auto-patching or rebuilt base images, with fixes often applied as a redeployed image. On-prem implementations reach the same outcomes with scanning appliances, agent-based and authenticated scanning, patch tooling such as WSUS or SCCM, and firmware updates through vendor channels during maintenance windows. The loop is identical; the scanning and patching mechanics differ.

Is A.8.8 a new control in ISO 27001:2022?

No. A.8.8 Management of technical vulnerabilities is not new to the 2022 revision. It carries forward the technical vulnerability management requirement from the 2013 version of the standard into the consolidated A.8 Technological controls theme, keeping the same underlying expectation to detect, assess, and remediate vulnerabilities in systems in use.

How does A.8.8 differ from A.8.9 configuration management and A.8.32 change management?

A.8.8 owns the vulnerability loop: finding what is vulnerable and closing it. A.8.9 configuration management defines the secure baseline configuration a system should hold, which is the reference a vulnerable system deviates from. A.8.32 change management governs how any change, including a patch, is requested, tested, approved, and recorded on its way to production. In practice a vulnerability is discovered under A.8.8, assessed against the baseline defined by A.8.9, and the patch travels through the process required by A.8.32.