BrowseToolsGuidesComparePricingStacksPlaybooksBlogSearch
ComplianceReadiness checkISO 27001ISO 42001SOC 2PCI DSSPolicy templatesControl mapCompliance softwareFramework compare
A.8.8A.8 Technological controls

Management of technical vulnerabilities

A.5EVIDENCEA.6EVIDENCEA.7EVIDENCEA.8EVIDENCECONTROL MAPA.8.8 Evidence MapPOLICY / CONTROL / EVIDENCE / REVIEW

Purpose

Prevent exploitation by identifying technical vulnerabilities, assessing exposure and taking timely action.

How to meet this control

In short: Obtain vulnerability information and take action to address exposure.

  1. Step 01Maintain an asset inventory listing operating systems, software, versions and owners so vulnerability advisories can be matched to exposure
  2. Step 02Run authenticated vulnerability scans with a tool such as Qualys, Tenable or Rapid7 on a regular cadence across servers, endpoints and external surface
  3. Step 03Integrate software composition analysis (Dependabot, Snyk, Mend) to catch vulnerable third-party and open-source libraries in the codebase
  4. Step 04Triage findings by severity and exploitability, then raise remediation tickets with risk-based SLAs (for example critical within days, high within weeks)
  5. Step 05Operate a patch management process that tests and deploys vendor updates, prioritising internet-facing and high-value systems
  6. Step 06Commission periodic penetration tests and feed the findings into the same remediation workflow

Tip: Run regular scans and patch on a risk-based SLA; keep the records.

What ISO 27002 says to cover

Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.

  • ›Keep an accurate asset inventory recording vendor, product, version and a named owner for all software, so new advisories can be matched to what is actually deployed
  • ›Assign clear roles for vulnerability monitoring, risk assessment and remediation, and subscribe to reliable advisory sources for your technology stack
  • ›Require suppliers to report, handle and disclose vulnerabilities in what they provide, and back this up in contracts; for cloud services, agree in the service agreement which vulnerability responsibilities sit with the provider and which stay with you
  • ›Run vulnerability scans suited to the technologies in use, confirm that applied patches actually took effect, and commission penetration tests by competent and authorised testers
  • ›Track third party libraries and open source components used in your own code, and give internal staff and outside researchers a way to report vulnerabilities in the products and services you offer, such as a public contact point and a disclosure policy
  • ›Assess each confirmed finding for risk, set response timelines based on urgency, and handle fixes through change management or, when urgent, incident response
  • ›Install updates only from legitimate sources, test them before rollout, remediate the highest risk systems first, and verify the fix worked
  • ›When no patch is available, apply workarounds such as turning off the affected service, tightening firewall rules, traffic filtering or extra monitoring, and keep an audit log of every step in the process

Audit evidence to keep

  • - Vulnerability scan reports with severity ratings and trend over time
  • - Remediation tickets linked to findings showing SLA and closure dates
  • - Patch management policy stating risk-based timelines
  • - Software composition analysis output for application dependencies
  • - Most recent penetration test report with remediation tracking

Common mistakes

  • - Writing a policy but not operating the process
  • - Keeping evidence in personal folders where auditors cannot trace it
  • - Letting exceptions stay open with no owner or expiry date

Owner, cadence, and proof

Assign one accountable owner for A.8.8. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.

Policy templates for this control

Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.

Vulnerability and patch management policyUse for ISO 27001 A.8.8, A.8.19, A.8.32, SOC 2 Security, and PCI DSS requirements 6 and 11.Asset management policyUse for ISO 27001 A.5.9, A.5.10, A.5.11, A.7.9 to A.7.14, SOC 2 Security, and PCI DSS asset inventory expectations.Supplier security policyUse for ISO 27001 A.5.19 to A.5.23, SOC 2 vendor management, cloud services, and AI supplier reviews.Acceptable use policyUse for ISO 27001 A.5.10, A.6.3, A.6.4, endpoint controls, remote work, and SOC 2 Security awareness.
Open the control-to-policy map
← A.8.7 Protection against malwareA.8.9 Configuration management →
Back to all technological controls or see the requirements (clauses 4 to 10). To run this control with automation, read how AI manages controls.