# ISO 27001 A.8.8: Management of Technical Vulnerabilities

Source: https://truvocyber.com/blog/iso-27001-a-8-8-technical-vulnerabilities
Published: 2026-08-03
Topic cluster: ISO 27001

> ISO 27001 A.8.8 technical vulnerabilities: how to scan, triage by severity, set remediation SLAs, patch and rescan, the evidence auditors expect, and the SOC 2 CC7.1 map.

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](https://truvocyber.com/blog/soc-2-vulnerability-risk-acceptance). 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.

At a glance

- **Theme:** Technological (A.8)

- **Source:** ISO/IEC 27001:2022, Annex A

- **New in 2022:** No

- **SOC 2 mapping:** [CC7.1](/blog/soc-2-cc7-1-vulnerability-management) (Full)

- **Part of:** the [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies)

## 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.

Key insight

**The rescan is what turns A.8.8 remediation into evidence**

A patch record shows a fix was attempted. A rescan showing the finding cleared shows it worked. For A.8.8, the closed loop is detection, remediation within the SLA, then re-verification, and the rescan is the artifact that proves the loop closed rather than stopping at intent.

A passive [external exposure scan](https://truvocyber.com/tools/domain-security-check) is a useful complement to the authenticated scans: it shows the mail, DNS, TLS and subdomain findings visible from outside without touching the systems themselves.

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](/blog/soc2-vulnerability-scanning-on-prem) and the [SOC 2 patch management on-prem guide](/blog/soc2-patch-management-on-prem) 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

Implementation theme
Cloud
On-prem / self-hosted

Scanning
Managed vulnerability service, agent-based host scanning
Scanning appliances, agent-based plus authenticated scanning

Container / image scanning
Registry and CI/CD image scanning on merge and schedule
Image scanning in the self-hosted registry and pipeline

Advisory and CVE monitoring
Provider security hub aggregates known CVEs and misconfigurations
Vendor advisory subscriptions per hardware and software class

Patching
Auto-patching, rebuilt managed base images
WSUS, SCCM, Red Hat Satellite, RMM, scheduled maintenance windows

Firmware
Inherited from the provider under shared responsibility
Vendor firmware channels, lab-tested for high blast-radius devices

Verification
Rescan in the console or next pipeline scan after redeploy
Scheduled rescan after the patch cycle clears the finding

## 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](/blog/grc-engineering), so the chain assembles as the loop operates.

Artifact
What it demonstrates
Cadence

Scan reports with schedule and findings
Vulnerabilities are detected across in-scope assets on a defined cadence
Weekly to quarterly by asset tier

Remediation tickets with SLA timestamps
Findings are triaged and fixed within the committed timeline
Per critical and high finding

Patch records and rescan results
Remediation was applied and the finding cleared on re-verification
Per patch cycle

Risk-accepted exception register
Unremediated findings are formally accepted with compensating controls and a review date
Per exception, reviewed quarterly

Vulnerability management policy with severity SLAs
The severity-to-SLA framework is defined and matches operations
Reviewed annually

Watch out

**A common A.8.8 gap: an SLA the team cannot meet**

A common gap that comes up during readiness work is a remediation SLA the team committed to but cannot meet. In one engagement, a SaaS team modeled its policy on enterprise standards and set a 24-hour SLA for critical vulnerabilities, with same-day expectations for high findings. The team quickly realized it could not reliably patch within a day, especially for changes that needed a testing window, and every scan cycle risked producing evidence of a policy violation.

The resolution was to adjust the critical and high SLA to 48 hours for internet-facing assets, medium to 7 days, and low to 30 days, and to require remediation tickets only for critical and high findings rather than every vulnerability. The adjusted timelines were defensible to the auditor and achievable for a small team, which turned the SLA from an audit liability into evidence that the loop runs.

### Vulnerability management that survives the audit

Truvo designs the detect-triage-remediate loop as part of an effective security program that holds up under ISO 27001 and SOC 2.

[Book Your Strategy Call](/contact-us)

Free download · Excel

ISO 27001 Evidence Checklist

The evidence list an internal auditor works from: 138 items across clauses 4 to 10 and all 93 Annex A controls, with owner, status and location columns ready for your team. Enter your email to download it.

(function initLmChecklist(){ if (window.hbspt && window.hbspt.forms) { window.hbspt.forms.create({ region: "na3", portalId: "341945322", formId: "e9f8aeed-ff99-4c1b-860f-5eafb34bc993", target: "#lm-iso-evidence-list-form", css: "" }); } else { setTimeout(initLmChecklist, 200); } })();

## How does A.8.8 map to SOC 2?

A.8.8 is a Full overlap with SOC 2 [CC7.1](/blog/soc-2-cc7-1-vulnerability-management). 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.

SOC 2 criteria
Overlap type
Evidence reusable in both directions

[CC7.1](/blog/soc-2-cc7-1-vulnerability-management) (detects and monitors security vulnerabilities)
Full
Internal and external vulnerability scan reports, penetration test results, vulnerability tracking records with remediation status, threat detection alerts

The [SOC 2 to ISO 27001 control mapping](/blog/iso-27001-soc-2-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](/blog/iso-27001-a-8-9-configuration-management) defines the hardened baseline a vulnerability is measured against, and [A.8.32 Change management](/blog/iso-27001-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](/blog/iso-27001-a-8-25-secure-development-lifecycle) pushes vulnerability detection left into the build. The [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies) summarizes how the A.8 controls fit together.

*Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the [ISO 27001 certification guide](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies) for the full picture. If you are building vulnerability management as part of an effective security program and want a second set of eyes on the design, Truvo runs [scoping calls](/contact-us).*

 

## 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](https://truvocyber.com/blog/soc-2-automatic-patching-change-management), 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.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is ISO 27001 A.8.8?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What evidence satisfies A.8.8?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "What remediation SLAs should you set for A.8.8?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How do you implement A.8.8 in the cloud versus on-prem?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Is A.8.8 a new control in ISO 27001:2022?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "How does A.8.8 differ from A.8.9 configuration management and A.8.32 change management?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    }
  ]
}