ISO 27001 A.8.8 - Management of Technical Vulnerabilities

Requirement

“Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.”

Plain-language meaning

The organization should actively find out what vulnerabilities affect its systems, assess how exposed it is, and respond in a risk-based timeframe. Response can include patching, configuration change, compensating controls, isolation, monitoring, or formal risk acceptance.

Vulnerability management is broader than running a scanner. Scanning finds issues, but the control also expects roles, timelines, risk evaluation, testing, patch/change control, rollback, retesting, and effectiveness review.

Why this matters

Most technical attacks exploit known vulnerabilities. The time between disclosure and active exploitation can be short. If the organization is slow to detect, assess, patch, or mitigate vulnerabilities, attackers get a practical path into systems before the organization acts.

Critical systems may need manual penetration testing or deeper assessment because automated scans often find surface-level weaknesses but miss business logic, chained vulnerabilities, and contextual exposure.

Implementation guidance

1. Define vulnerability management ownership

Assign responsibilities for:

• vulnerability intelligence sources;
• asset/system ownership;
• scanning and testing;
• risk rating and prioritization;
• patch testing;
• implementation;
• rollback;
• retesting;
• exception approval;
• reporting to management.

2. Obtain vulnerability information

Sources may include vendor advisories, security bulletins, threat intelligence, vulnerability databases, managed service reports, cloud provider notices, scanner feeds, and penetration test findings.

3. Scan and test relevant systems

Automated vulnerability scanning should cover relevant systems, not only a convenient sample. Sensitive or critical systems may also need manual penetration testing or deeper technical review.

4. Evaluate exposure and risk

The organization should consider:

5. Treat vulnerabilities through change control

Patching should be tested where appropriate and linked to change control. Rollback should be available in case the patch causes failure. Smaller organizations may patch quickly with lighter testing, while larger or highly available environments may need staged testing. The approach should be risk-based.

6. Retest and monitor effectiveness

After remediation, retest to confirm the vulnerability is closed. Track overdue items, repeated findings, exceptions, and vulnerability management performance.

Audit guidance

Auditors should verify:

• documented vulnerability management procedure;
• vulnerability intelligence sources;
• asset scope for scanning/testing;
• scan configurations and coverage;
• penetration testing approach for sensitive systems;
• vulnerability risk rating and prioritization;
• patch/change records;
• testing and rollback plans;
• exception/risk acceptance records;
• remediation evidence and retest reports;
• metrics and management reporting.

Audit the full lifecycle, not only the scan report. A scan report with no risk decision, no owner, no action plan, and no retest is weak evidence.

Evidence examples

Strong evidence

• Scanning covers all relevant systems.
• Vulnerabilities are assigned owners and deadlines.
• Critical vulnerabilities are prioritized by exposure and exploitability.
• Patches are tested and implemented through change control where needed.
• Retests confirm closure.
• Exceptions have risk-based approval and review dates.

Weak evidence

• Vulnerability scans are run but not acted on.
• Only sample systems are scanned without rationale.
• No retesting after remediation.
• Patches are installed without rollback planning.
• Exceptions are informal or indefinite.
• Penetration test findings are treated as one-off project tasks.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.6 Capacity Management
• A.8.7 Protection Against Malware
• A.8.9 Configuration Management
• A.5.8 Information Security in Project Management
• A.5.24 Information Security Incident Management Planning and Preparation
• A.5.26 Response to Information Security Incidents
• Risk Assessment
• Statement of Applicability
• Vulnerability Management Procedure
• Vulnerability Register and Remediation Tracker
• Patch Testing and Rollback Checklist
• Vulnerability Exception and Risk Acceptance Record
• A.8.8 Audit Evidence Pack
• A.8.8 Audit Checklist

KB-ready summary

• Monitor reliable vulnerability information sources.
• Scan and test relevant systems.
• Risk-rate findings based on exposure and impact.
• Patch or mitigate through controlled change.
• Retest and report closure or accepted residual risk.

Templates and checklists

• Vulnerability Management Procedure
• Vulnerability Register and Remediation Tracker
• Patch Testing and Rollback Checklist
• Vulnerability Exception and Risk Acceptance Record
• A.8.8 Audit Checklist