Control Definition
Organizations must stay informed about technical vulnerabilities in the systems they run, assess how exposed they actually are to each one, and act on that assessment — patching, mitigating, or formally accepting the risk.
Control Objective
To find and fix exploitable weaknesses in systems before attackers can use them.
What This Really Means
This control requires organizations to have a systematic process for identifying, evaluating, and patching security vulnerabilities in their IT systems. This includes software applications, operating systems, network devices, and cloud services.
The goal is to find and fix security holes before attackers can exploit them.
In practice, this means:
- •Running regular vulnerability scans
- •Subscribing to security bulletins from vendors
- •Prioritizing patches based on risk
- •Maintaining an inventory of all assets that need patching
Organizations must document their patch management process, define timelines for different severity levels, and track remediation progress.
Why It Matters
Technical vulnerabilities are one of the most common entry points for cyberattacks. Unpatched systems are responsible for major data breaches including Equifax (2017), WannaCry ransomware (2017), and countless others.
Without systematic vulnerability management, organizations face:
- •Data breaches – Attackers exploiting known vulnerabilities to steal sensitive data
- •Ransomware attacks – Encryption of critical systems through unpatched vulnerabilities
- •Compliance failures – Regulatory penalties for failing to maintain security controls
- •Reputational damage – Loss of customer trust and business opportunities
- •Operational disruption – System downtime and recovery costs
For ISO 27001 certification, this is a critical control that auditors scrutinize closely.
Failure to demonstrate a working vulnerability and patch management process can result in major nonconformities that block certification until corrected.
Implementation Guidance
Establish Vulnerability Sources
Subscribe to vendor security bulletins (Microsoft, Apple, Oracle, etc.), CVE/NVD feeds, CERT advisories, and security mailing lists. Configure automated alerts for new vulnerabilities affecting your technology stack.
Deploy Vulnerability Scanning
Implement automated vulnerability scanners (e.g., Nessus, Qualys, OpenVAS) to run weekly scans on all networked assets. Configure both authenticated and unauthenticated scans to identify missing patches, misconfigurations, and known vulnerabilities.
Define Risk-Based Prioritization
Create a vulnerability severity matrix based on CVSS scores, asset criticality, and exploitability. Define SLAs: Critical (7 days), High (30 days), Medium (90 days), Low (as scheduled). Document exceptions for systems that cannot be patched immediately.
Implement Patch Management Process
Establish a formal change management workflow for patches: Test patches in a staging environment → Approve via change control board → Deploy to production → Verify remediation → Document closure. Use patch management tools (WSUS, SCCM, Ansible) for automation.
Maintain Asset Inventory
Keep an up-to-date inventory of all assets (hardware, software, cloud services) including version numbers, OS, installed applications, and ownership. Link vulnerability scan results to the asset register to track patch status.
Document and Report
Generate monthly vulnerability management reports showing: Open vulnerabilities by severity, Mean Time to Remediate (MTTR), aging vulnerabilities >90 days, exception approvals. Present metrics to management review meetings.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.8:
Documentation
- Vulnerability Management Policy
- Patch Management Procedure
- Vulnerability scan reports (last 3-6 months)
- Patch deployment records
- Risk register for unpatched systems
- Asset inventory with patch levels
- Management review meeting minutes
Interviews
- IT security team: vulnerability scanning frequency and coverage
- System administrators: patch testing and deployment process
- Change control board: patch approval workflow
- CISO/InfoSec Manager: vulnerability metrics and KPIs
- Application owners: how they track vendor security advisories
Observations
- Review vulnerability scanner configuration
- Sample 5-10 recent critical vulnerabilities and verify remediation
- Check for aging vulnerabilities (>90 days old)
- Verify patch testing environment exists
- Inspect change management tickets for patch deployments
- Confirm automated patching tools are in use
Practitioner Insights
In our audits, we consistently see organizations fail A.8.8 due to aging vulnerabilities. Having a vulnerability scanner is not enough — you must demonstrate timely remediation. I recommend showing auditors your MTTR metrics and explaining how you handle exceptions for systems that cannot be patched immediately. Document why a system is unpatched and what compensating controls are in place.
One common mistake is not linking vulnerability scans to your asset inventory. Auditors will sample vulnerabilities and ask: What system is this? Who owns it? When was it patched? If you cannot answer, that is a finding. Use a centralized CMDB or asset management system to maintain this mapping.
Common Challenges & Solutions
Challenge
Legacy systems that cannot be patched without breaking functionality
Solution
Document technical debt in risk register. Implement compensating controls: network segmentation, enhanced monitoring, application whitelisting, restricted access. Obtain written risk acceptance from management with defined review dates.
Challenge
Large vulnerability backlog (500+ open findings) that seems impossible to remediate
Solution
Apply risk-based prioritization ruthlessly. Focus on internet-facing systems and critical assets first. Filter out low-severity items and false positives. Use automated patch deployment for operating systems. Present trending metrics (decreasing backlog) rather than absolute numbers to show progress.
Challenge
Third-party SaaS applications where you do not control patching
Solution
Require vendors to provide SOC 2 Type II or ISO 27001 certification as evidence of their patch management. Include SLA clauses for security updates in contracts. Document vendor patch management process in your third-party risk assessments.
Challenge
No dedicated vulnerability management tool or budget for commercial scanners
Solution
Use open-source scanners like OpenVAS or OWASP ZAP for web applications. For cloud environments, leverage built-in tools (AWS Inspector, Azure Security Center, GCP Security Command Center). Document manual vulnerability tracking in a spreadsheet if automated tools are unavailable — it is not ideal, but acceptable with evidence of regular reviews.
