ISO 27001 A.8.8 evidence checklist

ISO 27001 A.8.8 covers the management of technical vulnerabilities. A useful evidence trail shows which vulnerabilities affected your scope, how the team assessed them, what decision it made, and how it verified the outcome.

This checklist is a practical way to organize that trail. It doesn't reproduce the control text, prescribe one tool, or guarantee certification.

Start with the current edition

ISO/IEC 27001:2022 is the current published edition of the information security management systems standard. Annex A control A.8.8 is titled management of technical vulnerabilities.

Amendment 1:2024 added climate action changes to ISO/IEC 27001:2022. It didn't change A.8.8. Record the edition and amendments your information security management system uses so a reviewer can understand the basis for your evidence.

The evidence below isn't a list of mandatory documents. Your evidence should fit your scope, risk treatment process, tools, and statement of applicability.

Evidence checklist

1. Define the asset and component scope

A vulnerability record needs a clear connection to something your organization owns or operates. Keep enough detail to identify the affected system without reconstructing it during the review.

• Repository, service, host, container image, device, or cloud resource
• Package or component and affected version
• Business owner and technical owner
• Environment and internet exposure
• Link to the relevant asset or software inventory record

Scope evidence also helps explain why an alert was handled by your team, transferred to another owner, or considered outside the information security management system.

2. Keep the monitored source and original finding

Record where the vulnerability information came from and when the team first saw it. Sources can include supplier notices, a dependency scanner, an infrastructure scanner, a penetration test, a CSIRT notice, or a researcher report.

Retain a stable reference to the original result. For a dependency alert, that might be an alert ID, advisory, CVE, affected version range, and detection timestamp. For a scan, keep the scan identifier and enough context to find the result again.

3. Assess exposure and risk

Scanner severity is one input. The record should show how the affected system, reachable attack path, existing controls, and business impact changed the team's view.

Useful evidence includes:

• Whether the vulnerable component is deployed and reachable
• Whether the affected code path or feature is used
• The confidentiality, integrity, and availability impact
• Existing controls that reduce likelihood or impact
• The resulting risk rating and assessment date

Write the assessment so another reviewer can follow the reasoning. A label such as “medium” won't explain why the team accepted a finding that a scanner called critical.

4. Prioritize with business context

Keep the original technical severity, then record the priority the team assigned after considering exposure and impact. If policy sets a remediation target, link the target to the finding.

This makes exceptions visible. A low-severity issue on a sensitive public service may move forward, while a higher-severity issue in unused test code may follow a different path.

5. Assign an owner and due date

Every open finding needs a named owner or accountable team and a time-bound next step. Record the assignment date, due date, and any policy or risk decision behind the deadline.

If the date changes, keep the earlier date and the reason for the change in the history. Replacing it loses the evidence that the team reviewed the delay.

6. Record the decision and approval

Use a small, consistent decision set such as remediate, defer, accept, or false positive. The label alone isn't enough. Keep the rationale, approver when required, decision date, and review or expiry date.

For a false positive, show the technical check that disproved the finding. For accepted or deferred risk, link the decision to your risk process and name any compensating control.

7. Link the work that carried out the decision

Connect the finding to the actual change or control. Depending on the decision, evidence might include:

• A patch, pull request, deployment, or change ticket
• A package upgrade and updated lockfile
• A configuration or infrastructure change
• A compensating control with its owner and operating evidence
• A supplier case or approved mitigation plan

The link should make the implementation reviewable. A status of “fixed” without the change record leaves the most important part of the trail missing.

8. Verify the outcome before closure

Closure evidence should show that the vulnerable condition is gone or that the approved treatment is operating. Record the verification method, result, date, and reviewer.

Verification can be a clean rescan, a dependency check against the deployed version, a focused test, or a review of the compensating control. Keep failed verification attempts in the history because they explain why the finding stayed open.

9. Review aging and recurring patterns

Individual records show how one vulnerability was handled. Periodic review shows whether the process keeps working over time.

Useful views include open findings by age, overdue work by owner, accepted risks nearing review, recurring affected components, and the time from detection to verified closure. Keep the review date, participants, decisions, and follow-up actions.

What a complete record looks like

A reviewer should be able to move through one finding without changing systems several times:

1. Identify the affected asset and component.
2. Open the original finding and see when it arrived.
3. Follow the exposure and risk assessment.
4. See the owner, decision, rationale, approval, and due date.
5. Open the remediation or exception evidence.
6. Confirm how and when the outcome was verified.

The record can link to other systems. It should still act as the index that connects the evidence and preserves the decision history.

Keep the checklist grounded

Review a sample of records against your risk treatment method, vulnerability policy, statement of applicability, and audit scope. Remove fields nobody uses. Add a field only when it helps someone make or verify a decision.

Teams working under EU cybersecurity rules may also need to connect this trail to legal and national requirements. The NIS2 vulnerability management requirements guide explains how the Directive and the 2024 implementing regulation differ.

Start with a working register

The free vulnerability management template gives you one place to record findings, affected assets, decisions, owners, due dates, remediation evidence, and verified closure. Download the Excel workbook and adapt it to your scope and risk process.

Practical guidance only. This isn't legal or certification advice.