ISO 27001 Annex A 8.8: Management of technical vulnerabilities

What Control 8.8 means in practice

Identify relevant vulnerabilities, determine exposure and make timely, risk-based remediation or acceptance decisions. Test the control through the organisation's actual scope, decisions, ownership and operating records rather than relying on a policy reference alone.

For management of technical vulnerabilities, proportional design depends on the affected services, information, people and dependencies. The evidence below should be adapted to that real boundary.

Implementation steps

1. Step 1. Maintain an accurate inventory of in-scope systems and owners.
2. Step 2. Use appropriate vulnerability sources and scanning coverage.
3. Step 3. Evaluate applicability, exposure and business impact before prioritizing remediation.
4. Step 4. Assign owners and target dates, control exceptions and verify closure.
5. Step 5. Review recurring weaknesses and unsupported technology.

What good implementation looks like

• closure verification rather than ticket status alone
• coverage reports identifying missing scanners or stale assets
• exceptions with current exposure assessment and expiry

Implementation evidence and effectiveness evidence

How an auditor may test Control 8.8

1. Select a representative in-scope service, asset or process.
2. Confirm the accountable owner and expected operation.
3. Trace a recent example: An internet-facing critical vulnerability is traced from advisory to scanning, owner assignment, patching and verification.
4. Inspect the operating record and corroborating technical evidence.
5. Compare the design with evidence that the control operated effectively.
6. Follow an exception or adverse result through decision and closure.
7. Review trends, metrics and improvement decisions.

Questions to prepare for

• How do you identify new vulnerabilities affecting the environment?
• How is applicability and exposure determined?
• Show a high-risk vulnerability from discovery through verified closure.
• How are overdue findings and exceptions approved?

Practical examples

Illustrative decision and evidence record

Reviewer note: Measure exposure, age, recurrence and accepted risk—not only the number of findings closed.

Useful performance and coverage measures

• critical exposure age
• scan coverage by asset class
• reopened or recurring vulnerabilities

Approach for smaller and mature organizations

Smaller organization

Use a clear owner, a proportionate working record, built-in platform capability and a scheduled review. Sample real activity instead of creating duplicate paperwork for management of technical vulnerabilities.

Mature or complex organization

Define service-level ownership, automated coverage reporting, integrated workflow, risk-based exceptions and independent assurance across business units and technology platforms.

Practical implementation checklist

• □ Maintain an accurate inventory of in-scope systems and owners.
• □ Use appropriate vulnerability sources and scanning coverage.
• □ Evaluate applicability, exposure and business impact before prioritizing remediation.
• □ Assign owners and target dates, control exceptions and verify closure.
• □ Review recurring weaknesses and unsupported technology.
• □ Sample evidence has been checked for operation and effectiveness.
• □ Exceptions have owners, rationale, review dates and closure evidence.

Common implementation mistakes

• scanner output treated as the whole process
• no linkage to asset ownership or business impact
• priorities based only on technical severity
• findings closed without verification
• unsupported systems remain outside tracking

Related controls, clauses and resources