Vulnerability management and patching under ISO 27001 (A.8.8)
Vulnerability management is the fixed process for finding, assessing and fixing weak spots in your software and systems, usually by installing updates. In ISO/IEC 27001:2022 , this is control A.8.8 “Management of technical vulnerabilities” in Annex A. Patching, which means installing security updates, is the most important part.
The NCSC (Dutch National Cyber Security Centre) counts timely updating among the basic principles of digital resilience. It publishes security advisories about current vulnerabilities every day. For ISO 27001, you turn that into agreements on deadlines, responsibilities and evidence. It starts with your asset register: you can only patch what you know about.
Short answer: for ISO 27001 A.8.8 you need an overview of your systems, a way to hear about new vulnerabilities, fixed patch deadlines per severity and a record of what you have done. The standard does not set deadlines. A common choice is critical flaws within a few days, high-severity within two weeks and others within a month.
What does A.8.8 require for vulnerability management?
ISO 27002:2022 elaborates on the control. In summary, A.8.8 asks you to collect information about technical vulnerabilities, assess how exposed you are, and take appropriate measures. That involves three activities:
| Step | Question | Example |
|---|---|---|
| Detect | Which vulnerabilities affect us? | Supplier notifications, NCSC advisories, automated scans |
| Assess | How serious is it for us? | An internet-facing VPN with an actively exploited flaw: critical |
| Resolve | What do we do, and when? | Install the update, or temporarily switch off the feature |
A.8.8 works together with other controls. Configuration management (A.8.9) makes sure systems are securely set up. Protection against malware (A.8.7) catches what still gets in. Change management (A.8.32) makes sure an update goes into production in a controlled way.
Setting patch deadlines per severity
ISO 27001 leaves the deadlines to you. Base them on your risk analysis. Many organisations use the CVSS score as a starting point. The Common Vulnerability Scoring System gives each vulnerability a score from 0 to 10. Also look at your own situation: is the system reachable from the internet, and is the flaw already being actively exploited?
This is an example of a deadline table. These are choices, not requirements of the standard.
| Severity | When | Deadline | Example |
|---|---|---|---|
| Critical | CVSS 9.0 or higher, or actively exploited on an internet-facing system | Within 72 hours, or an immediate temporary measure | Flaw in the VPN gateway |
| High | CVSS 7.0 to 8.9 | Within 14 days | Flaw in the browser on all laptops |
| Medium | CVSS 4.0 to 6.9 | Within 30 days | Flaw in an internal application |
| Low | Below 4.0 | With the next regular update | Flaw that can only be exploited locally |
Can you not patch in time, for example because the supplier has no update yet? Then take a temporary measure, such as shielding the system from the internet. Record it as a deliberate exception with an end date.
Patching process in five steps
Keep track of your systems
Use your asset register and your device management as the source. Every system has an owner who is responsible for its updates.
Follow new vulnerabilities
Subscribe to security notices from your main suppliers and to the NCSC advisories. Have a vulnerability scanner check your internet-facing systems regularly.
Assess and plan
For each notice, determine the severity for your situation and the deadline from the table. Schedule the update.
Install and check
Turn on automatic updates where possible, such as on laptops and browsers. After installation, check that the update was really installed, with a report or a new scan.
Record and report
Record what you did and when. Report monthly how many vulnerabilities were resolved within the deadline.
Example vulnerability register
You do not need to register automatic updates on laptops one by one. A compliance report from your management system then serves as the evidence. For manual or high-risk patches, keep a register. This fictional example belongs to a web shop with its own servers.
| No. | Reported | System | Vulnerability | Source | Severity | Deadline | Action | Completed |
|---|---|---|---|---|---|---|---|---|
| KW-26-031 | 6 May 2026 | Firewall | Vulnerability in VPN component, actively exploited | NCSC advisory and supplier | Critical | 8 May 2026 | Firmware updated, logs checked for misuse | 7 May 2026 |
| KW-26-032 | 12 May 2026 | Web shop platform | Vulnerability in payment plug-in | Supplier | High | 26 May 2026 | Plug-in updated after testing in the acceptance environment | 19 May 2026 |
| KW-26-033 | 14 May 2026 | Old stock server | Operating system no longer receives updates | Scan | High | 28 May 2026 | Exception until 30 September 2026: server removed from the internet, replacement planned | Open |
The third row shows how you record an exception. The auditor accepts an open item, provided the risk has been assessed, there is a temporary measure and a date is set.
What does the auditor ask for as evidence for A.8.8?
During the ISO 27001 audit, you can expect these requests:
- The procedure or policy with patch deadlines per severity.
- A report from your management system: what share of the devices is fully updated?
- The vulnerability register or the tickets from recent months.
- A recent, well-known vulnerability: “How did you handle this?”
- The results of the latest vulnerability scan or penetration test, with follow-up.
Systems for which the supplier no longer provides updates, such as an old Windows server or an outdated NAS, are a constant source of findings. Make an inventory of them before the audit and record a decision for each system: replace it, shield it, or accept the risk with the signature of management.
Common mistakes in vulnerability management
Patching only laptops. Firewalls, printers, NAS devices and web plug-ins are often forgotten, even though they are reachable from the internet.
Updates switched on, but not checked. An update that fails on 10% of laptops only shows up in a report.
No deadlines. “As soon as possible” cannot be tested. Record concrete deadlines.
Not asking the SaaS supplier. For cloud services, the supplier patches. Record in your supplier management how they do this and how they inform you.
Not checking whether you were already hit after patching. For vulnerabilities that are actively exploited, the update is not enough. Check your logging for signs of earlier misuse.
Vulnerability management in government
Government organisations that follow the BIO2 (Dutch government information security baseline) have a strict deadline. If a vulnerability warning carries both a high chance of misuse and high expected damage, they take appropriate measures within one week at the latest. Internet-facing systems must also be tested for vulnerabilities at least once a year.
More information
- Asset register: the overview of systems you need to keep up to date
- Logging and monitoring: finding out whether a vulnerability has already been exploited
- Back-up policy: your safety net if things go wrong anyway
- Remote working and BYOD policy: updates on personal devices
- Annex A: all 93 controls, including A.8.7 to A.8.9
- NCSC security advisories : current vulnerabilities and their severity