ISO 27001 A.8.8: Turn vulnerability findings into verified action
Technical vulnerability management turns information about weaknesses into decisions that reduce exposure. ISO 27001 Annex A.8.8 addresses obtaining relevant vulnerability information, evaluating the organisation's exposure and taking appropriate measures. A report containing hundreds of findings is not evidence that those findings have been assessed or treated.
What A.8.8 requires in practice
A.8.8 deals with management of technical vulnerabilities, which are weaknesses in systems that could be exploited. The control has three connected parts: obtain information about vulnerabilities in the systems you actually use, evaluate how exposed the organisation is to each, and take appropriate measures.
Obtaining information means having a dependable way to learn about weaknesses, for example through supplier notices, advisories and the organisation's own checks. Evaluating means judging how a weakness affects your environment, not merely repeating a severity score. Appropriate measures can include updating, changing a setting, restricting access or accepting a risk through a recorded decision.
Outputs are an up-to-date view of what is in use, a flow of vulnerability information, evaluated exposure and treatment that is carried to completion. The control does not set a patching deadline or require a scanner. Verifying that a fix actually worked is a method Sterling's teams treat as essential practice, though the control does not spell it out.
Know which assets and components are affected
Relevant information depends on knowing the technology in use. Record enough about systems, software versions, ownership and deployment to determine whether an advisory applies. Include third-party components within applications and clarify provider responsibilities. A cloud provider's work does not automatically cover software, identities or configurations managed by the customer.
Use trustworthy information sources appropriate to the inventory. Supplier advisories, authorised scanning and reports from internal or external parties can each contribute. Establish a route for receiving and evaluating reports rather than assuming that every important issue will arrive through the same tool. Keep assessment activities within explicit authorisation and safe operational boundaries.
Prioritise exposure, not only a severity number
A technical score can inform a decision, but it does not describe the whole business situation. Consider whether the affected component is present, whether relevant access is possible, the information or service at risk and existing protective measures. Record the reasoning when a finding is prioritised differently from its initial label.
Assign an owner and a response expectation appropriate to the risk. A vague promise to fix an issue in the next maintenance window can conceal an unaccepted delay. If the normal change route cannot respond quickly enough, an authorised urgent process should still retain accountability, evidence and an appropriate check of the outcome.
Why vulnerability management matters to the business
Attackers often use weaknesses that were publicly known and had a fix available. The business harm comes from the delay between knowing and acting. A long list of unaddressed findings tells clients and regulators that the organisation sees problems but does not close them. Managing vulnerabilities well lowers the likelihood of breaches, reduces emergency work and makes it possible to show customers that exposure is under control. It also supports commercial trust: many contracts and questionnaires ask how weaknesses are found and fixed. Clear prioritisation helps the business spend effort where exposure is greatest, and recorded decisions for delayed fixes show that gaps are managed deliberately rather than ignored.
How to implement A.8.8
The goal is a steady route from information about a weakness to a verified decision. Prioritise by what is actually exposed and valuable in your environment, and keep the process light enough that people follow it.
- Keep a current view of the hardware, software, services and components in use, including those run by suppliers.
- Choose sources of vulnerability information that match what you run, and name who watches them.
- Evaluate each weakness against your environment, considering exposure, the information at stake and how easily it could be reached.
- Decide the treatment and the owner, and set a target that reflects the risk, using wording an operations team can plan around.
- Record any temporary measure or accepted delay with a reason and a point at which it will be reviewed.
- Verify, by a repeat check or a direct test, that each fix took effect and the weakness no longer exists, instead of closing the item when a change request is marked done.
- Look at repeated gaps to find process causes, such as systems nobody owns.
Evidence an auditor expects for A.8.8
Auditors look for a connected story from awareness to verified action. Useful evidence includes:
- records showing which sources of vulnerability information are monitored and by whom;
- results of scans or checks, with evaluations that go beyond raw severity;
- records of treatment decisions, including accepted delays and the reasoning behind them;
- observation of a sample of fixed items, confirming the weakness is no longer present;
- an interview with the system owner about how they learned of, assessed and handled a recent finding.
Evidence is strongest when one finding can be followed from discovery to confirmed closure. A report of findings alone shows detection, not management.
Illustrative software example: an unused component is still deployed
A fictional software team receives an advisory concerning a third-party library. Developers initially believe it is irrelevant because the affected function is not used in the current product. The technical owner checks the deployed build and configuration rather than closing the finding on that assumption.
The review establishes the actual exposure and selects an update with suitable testing. The closure evidence identifies the affected release, the treatment and confirmation of the deployed result. Where a finding proves inapplicable, the team keeps a reasoned record tied to the current configuration; it does not treat an old explanation as valid after a later feature enables the component.
Illustrative manufacturing example: a delayed supplier update
A hypothetical manufacturer identifies a weakness on a system supporting production scheduling. The supplier's update requires compatibility testing, and an immediate uncontrolled installation could disrupt operations. The operational owner and security team evaluate both the vulnerability and the proposed change.
They agree temporary restrictions appropriate to the exposure, a monitored review point and responsibility for completing the update assessment. After the approved change, they verify both the security treatment and the business function. This is a time-bounded risk decision with evidence, not a blanket exemption for manufacturing systems or a claim that patching is always harmless.
Make temporary treatment visible
An update may not yet exist or may be unsuitable for immediate deployment. Depending on the issue, restrictions on access, removal of an affected function or additional monitoring may reduce exposure. Evaluate whether the chosen measure actually addresses the relevant route and whether it introduces another operational risk.
Connect temporary treatment to configuration management and change management. State when it will be reviewed and what would trigger escalation. A workaround should not disappear from attention merely because the scanning dashboard changes colour or the original owner changes role.
Verify remediation and learn from repeated gaps
Useful evidence follows the finding through applicability assessment, priority, ownership, decision, action and verification. A ticket marked complete without checking the affected asset leaves the central question unanswered. Verification might involve an appropriate rescan, version and configuration checks or another safe method suited to the weakness.
Also test the process itself. Sample a relevant supplier advisory and trace whether it reached the right owner. Compare the scanning scope with the asset inventory. Review findings that repeatedly return after deployment, because these may reveal an uncontrolled baseline or build process rather than isolated patch failures.
Measures such as overdue high-risk actions, unexplained scope gaps and recurring findings can support performance evaluation. Count reductions cautiously: deleting assets from a tool or accepting findings without evaluation can improve a graph while leaving exposure unchanged. Coordinate significant evidence with incident response when circumstances suggest an active security event.
Frequently asked questions
Is a vulnerability scan sufficient for A.8.8?
No. It can identify potential weaknesses, but the organisation still needs applicability assessment, prioritisation, treatment and verification. Scanning scope and limitations also matter.
Does ISO 27001 set one patching deadline?
No universal deadline fits every weakness and environment. Establish justified response expectations using exposure, consequence and applicable commitments, then manage delays and residual risk explicitly.
Can a finding be closed without installing a patch?
Sometimes another treatment or a supported finding of non-applicability is appropriate. Record the rationale and verify the resulting protection; administrative closure alone does not demonstrate effective treatment.
Get a clear route from findings to action
Discuss an authorised vulnerability assessment with Sterling, scoped as agreed scanning and findings review within the ISO 27001 programme. Consulting, documentation, relevant learning and agreed Effivity ISO & GRC automation software can support accountable follow-through. Sterling continues the defined preparation work; certification remains an independent decision. Enrol in ISO/IEC 27002 Information Security Controls to place vulnerability treatment within the wider technological controls.