ISO 27001 control 8.8: Management of technical vulnerabilities

Most organizations don’t get breached by novel zero-day exploits. They get breached because a known vulnerability sat unpatched on an internet-facing system long enough for an attacker to find it. The management of technical vulnerabilities isn’t a theoretical exercise; it’s the operational discipline that determines whether your organization fixes what’s broken before someone else exploits it. Exploitation of vulnerabilities as an initial access vector grew 34% year-over-year and accounted for 20% of breaches in 2024, according to the Verizon 2025 Data Breach Investigations Report (DBIR). ISO 27001 control 8.8 exists to close that gap.

What 8.8 requires

ISO 27001 Annex A control 8.8 requires organizations to build and maintain a continuous process for identifying, evaluating, and responding to technical vulnerabilities across their environment. The official objective states that organizations must “establish a process to obtain timely information about technical vulnerabilities, evaluate the organization’s exposure, and implement appropriate measures to mitigate the associated risks.”

In practice, this means four things.

First, you need a reliable way to learn about new vulnerabilities as they’re disclosed. That means subscribing to vendor security advisories, monitoring sources like the Common Vulnerabilities and Exposures (CVE) database through the National Vulnerability Database (NVD) and national Computer Emergency Response Team (CERT) feeds, and integrating threat intelligence into your vulnerability management workflow.

Second, you need to evaluate whether each disclosed vulnerability actually affects your environment. Not every CVE is relevant to your technology stack, and not every relevant vulnerability carries the same risk. This evaluation requires an accurate, current asset inventory and enough context to assess exposure. A vulnerability in a library your organization doesn’t use requires no action. A vulnerability in a component that’s deployed but not internet-facing has a different risk profile than the same vulnerability on a public-facing system.

Third, you need to act on what you find. That action could be patching, applying a compensating control, isolating an affected system, or accepting the risk with documented justification and appropriate approval. The key is that every vulnerability gets a deliberate disposition, not silence.

Fourth, and most critically, this is not a one-time scan or annual penetration test. Control 8.8 demands a continuous operational capability. Point-in-time assessments create blind spots between assessment cycles, and those blind spots are exactly where attackers operate. The difference between a compliant program and an effective one often comes down to whether vulnerability management runs as a living process or a periodic checkbox.

Why 8.8 matters

An organization that runs vulnerability scans on a quarterly cycle discovers a batch of findings in January and remediates them by February. In March, a critical CVE affecting their VPN concentrator is disclosed. By the time the next scheduled scan runs in April, an attacker has already exploited the vulnerability, established persistence, and begun lateral movement. The quarterly scan finds the vulnerability, but the breach happened weeks ago.

This scenario plays out repeatedly because the window between disclosure and exploitation keeps shrinking. The average time-to-exploit for newly disclosed vulnerabilities dropped to five days in 2024, according to Mandiant and Google Cloud research. Five days is not enough time for a quarterly scan to catch it, a change advisory board to approve a patch, and an operations team to deploy it. Organizations that treat vulnerability management as a periodic activity rather than a continuous one are structurally exposed to this timing gap.

Unpatched known vulnerabilities remain the dominant initial access vector across threat landscapes globally. The problem isn’t that organizations lack scanning tools. It’s that the process connecting discovery to remediation has too many gaps, too little urgency, and too few connections to the asset and change management functions that make timely response possible.

The regulatory consequences compound the operational ones. An ISO 27001 compliance auditor reviewing control 8.8 won’t accept a quarterly scan schedule as evidence of “timely information” about vulnerabilities. They’ll look for a process that responds to the actual pace of vulnerability disclosure, which in 2024 meant over 35,000 new CVEs published across the year. Organizations that can’t demonstrate continuous vulnerability awareness and risk-based response face nonconformities that can delay or block certification.

What attackers exploit

• Unpatched internet-facing systems: VPNs, web servers, and email gateways that sit exposed to the external attack surface with known vulnerabilities
• Delayed patching due to undefined Service Level Agreements (SLAs) or ownership: Vulnerabilities that linger because no one is accountable for fixing them within a defined timeframe
• Incomplete asset inventories: Shadow IT and forgotten infrastructure that never gets scanned in the first place
• Over-reliance on Common Vulnerability Scoring System (CVSS) scores: Prioritizing by severity alone without factoring in exploitability, threat intelligence, or business context
• Missing vendor alert subscriptions: Critical infrastructure components whose vendors publish advisories that no one in the organization monitors
• No process for zero-day or emergency response: When a critical vulnerability drops outside the normal patch cycle, there’s no escalation path or pre-approved emergency change process to accelerate remediation

How to implement 8.8

For your organization (first-party)

Effective implementation of control 8.8 follows a structured lifecycle that connects asset visibility, threat intelligence, scanning, prioritization, remediation, and verification into a repeatable process. Most organizations already have some of these elements in place. The challenge is connecting them into a cohesive workflow with clear ownership, defined timelines, and feedback loops that improve over time.

1. Maintain a current asset inventory. You can’t patch what you don’t know about. Control 5.9 (Inventory of information and other associated assets) is a prerequisite here. Every piece of hardware, software, and cloud infrastructure needs an owner and a criticality rating. The Configuration Management Database (CMDB) or equivalent asset register should feed directly into your scanning tools.
2. Subscribe to vendor security advisories and threat intelligence feeds. For every critical technology in your stack, ensure someone receives and triages vendor-issued security bulletins. Supplement with feeds from CERT organizations, the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog, and commercial threat intelligence providers.
3. Deploy vulnerability scanning tools on a risk-based schedule. Tools like Nessus, Qualys, or Tenable should run authenticated scans against your full asset inventory. Internet-facing assets warrant higher scan frequency than internal systems, and combining attack surface management and vulnerability scanning provides more comprehensive coverage than either approach alone. Credentialed scanning catches significantly more findings than unauthenticated scans.
4. Conduct periodic penetration testing. Scanning identifies known vulnerabilities; penetration testing validates exploitability and identifies attack chains that automated tools miss. Most organizations align this with annual audit cycles, but critical environments benefit from more frequent testing following the Penetration Testing Execution Standard (PTES) methodology.
5. Establish a risk-based prioritization framework. CVSS scores alone aren’t sufficient. Combine CVSS with Exploit Prediction Scoring System (EPSS) data, CISA KEV status, asset criticality, and network exposure to prioritize what gets fixed first. A medium-severity vulnerability on an internet-facing system with a known exploit is more urgent than a critical-severity finding on an isolated internal test server.
6. Define remediation SLAs by severity. Without defined timelines, vulnerabilities age indefinitely. A common framework looks like this: Critical within 24-72 hours, High within 7-30 days, Medium within 30-90 days, and Low in the next maintenance cycle. Organizations take an average of 252 days to remediate a known vulnerability, according to the Veracode State of Software Security report (2024), which underscores why enforceable SLAs matter.
7. Document risk acceptance decisions. Not every vulnerability gets patched. When remediation isn’t feasible due to system dependencies, operational risk, or compensating controls, document the rationale, the approver, the review date, and any mitigating measures in a formal risk acceptance register.
8. Integrate with change management. Patches are changes, and they should flow through your change management process (control 8.32). This ensures testing, rollback planning, and approval while preventing patches from introducing new issues.
9. Track to closure and verify. Every identified vulnerability should be tracked through to confirmed remediation. Re-scan after patching to verify the fix was applied correctly and the vulnerability is resolved. Many organizations use their IT Service Management (ITSM) platform to create remediation tickets automatically from scan findings, linking the vulnerability ID to the change request and the verification scan result. This audit trail is exactly what ISO 27001 auditors look for when evaluating control 8.8 effectiveness.

Common mistakes:

• Incomplete asset coverage: Running scans without a complete asset inventory guarantees blind spots
• CVSS-only prioritization: Treating CVSS score as the sole prioritization input without exploitability or business context
• Untested patches: Patching production systems without testing in a staging environment first
• Missing risk acceptance documentation: No documented risk acceptance for deferred remediation, which creates audit gaps
• Siloed vulnerability management: Vulnerability management disconnected from change management, leading to untracked changes

For your vendors (third-party assessment)

Your organization’s vulnerability management program is only as strong as the weakest link in your supply chain. When assessing vendors against control 8.8, you need to verify that they maintain the same operational rigor you apply internally.

Questionnaire questions to include:

• “Describe your vulnerability management process, including scanning cadence and tools used.”
• “What are your remediation SLAs by severity level?”
• “How do you handle zero-day vulnerabilities or emergency patches?”
• “Do you conduct regular penetration testing? If so, at what frequency and by whom?”

Evidence to request:

• Recent vulnerability scan reports (redacted to protect specifics, but showing scope and cadence)
• Patch management policy documentation
• Remediation SLA definitions and compliance metrics
• Penetration test executive summary with remediation status

Red flags during assessment:

• No defined remediation timelines or SLAs
• Vulnerability scanning only performed annually
• No penetration testing program
• Inability to produce scan reports or remediation evidence
• Claims that “we don’t have vulnerabilities”

Self-attestation alone isn’t sufficient for critical vendors. Request evidence of actual scan cadence and remediation metrics. Use external attack surface scanning to independently verify whether a vendor has public-facing vulnerabilities. Review SOC 2 Type II reports or ISO 27001 certificates to confirm third-party validation of their vulnerability management practices. For a deeper walkthrough, see UpGuard’s guide on ISO 27001 third-party risk requirements.

The depth of your vendor assessment should scale with vendor criticality. A Tier 1 vendor processing sensitive data warrants direct evidence review, while a lower-risk vendor might be adequately assessed through a standardized security questionnaire and external scanning. Establish a vendor tiering model that maps assessment rigor to the risk each vendor introduces, and reassess at defined intervals or when the vendor’s risk profile changes.

Audit evidence for 8.8

When preparing for an ISO 27001 audit of control 8.8, auditors will look for documented evidence that your vulnerability management process is defined, operational, and producing measurable results. Effective audit preparation means having these artifacts current and accessible before the auditor asks for them, not scrambling to assemble evidence during the audit window. The following artifacts map to the key elements of the control.

Cross-framework mapping

Control 8.8 doesn’t exist in isolation. If your organization maps to multiple compliance frameworks, the vulnerability management requirements overlap significantly. This means that work done to satisfy 8.8 can serve as evidence across multiple audits, reducing the total compliance burden. The following table shows how 8.8 aligns with equivalent controls across common frameworks, helping you identify where a single vulnerability management program can satisfy multiple regulatory requirements simultaneously.

Related ISO 27001 controls

Control 8.8 connects to several other Annex A controls that either provide inputs to vulnerability management or depend on its outputs. Understanding these relationships helps ensure your implementation doesn’t operate in a silo and that supporting processes are mature enough to make 8.8 effective.

Frequently asked questions

What is ISO 27001 8.8?

ISO 27001 Annex A control 8.8 requires organizations to establish a continuous process for identifying technical vulnerabilities, evaluating their exposure, and taking appropriate action to mitigate the associated risks. It covers the full lifecycle from vulnerability discovery through remediation or documented risk acceptance.

What happens if 8.8 is not implemented?

Without a functioning vulnerability management process, known vulnerabilities accumulate across your environment, giving attackers a growing menu of exploitable entry points. Auditors will flag the absence of documented scanning, remediation tracking, and risk acceptance as a nonconformity, potentially blocking ISO 27001 certification.

How do you audit 8.8?

Auditors verify that a vulnerability management policy exists, that scanning runs on a defined schedule, and that vulnerabilities are tracked from discovery through remediation. They request scan reports, remediation logs, risk acceptance records, and evidence of threat intelligence subscriptions to confirm the process operates as documented.

How UpGuard helps

Control 8.8 requires continuous visibility into vulnerabilities across your environment and your supply chain. The UpGuard platform delivers both, giving security teams the external attack surface awareness and vendor risk intelligence that auditors expect to see.

• Breach Risk: Continuously scans your external attack surface to identify vulnerabilities, misconfigurations, and exposures across internet-facing assets, prioritizing findings using EPSS and KEV data rather than CVSS scores alone
• Vendor Risk: Assesses and monitors your vendors’ security posture, including their vulnerability management practices, with automated questionnaires and continuous risk rating updates

Start a free trial to see how UpGuard strengthens your vulnerability management program.