In the world of information security, vulnerability management is a crucial part of protecting systems and data. It is a continuous process that helps organizations identify, assess, and manage technical weaknesses in their IT landscape. ISO 27001 explicitly mentions this in control measure A.8.8: Management of technical vulnerabilities.
However, in practice, it turns out that vulnerability management often gets stuck at incidental patching or a loose scan. This misses the core: structural, preventive, and demonstrable management.
This article explains what vulnerability management entails, why it is essential, and how to implement it in accordance with ISO standards.
What is vulnerability management?
Vulnerability management is the structured and ongoing process by which an organization identifies, analyzes, prioritizes, and remedies technical vulnerabilities. It is explicitly not just about fixing individual leaks, but about managing the risk that vulnerabilities are exploited.
ISO 27001 approaches vulnerabilities as the link between a threat and actual damage. A vulnerability in itself is not an incident, but it is an open door for abuse if a threat is active.
A mature vulnerability management process consists of the following interrelated steps:
Detection: actively searching for vulnerabilities in systems, software, and infrastructure
Analysis: determining impact, exposure, and likelihood
Treatment: applying technical or organizational measures
Monitoring: checking whether measures are working and whether new vulnerabilities arise
This process is cyclical and continuous.
More than just software patches
A common misconception is that vulnerability management is equivalent to patch management. Patching is important, but it is only one component.
Vulnerabilities can arise from:
Outdated or unsupported software
Unsafe configurations
Errors in self-developed code
Vulnerable open-source components
External dependencies in the supply chain
IoT devices with limited security
Especially with end-of-life software, a structural risk arises: no security updates are made available, while systems often remain in production. ISO 27001 expects organizations to explicitly recognize and manage this risk.
Methods to identify vulnerabilities
Vulnerability scanning
Automated vulnerability scans form the basis for many organizations. These tools compare systems with known vulnerabilities and configuration errors. They are efficient but require good configuration to limit noise and false positives.
Pentration testing
While scans are generally broad, penetration testing goes deeper. This actively attempts to exploit vulnerabilities, similar to the behavior of an attacker.
There are different approaches:
White (or crystal) box: full technical knowledge available
Black box: testing without prior knowledge
Grey box: limited access rights and information
In practice, these forms are often combined, depending on the purpose of the test.
Red teaming and attack simulations
In more mature organizations, you also see red team exercises or breach and attack simulations. Here, not just one vulnerability is tested, but the total detection and response capability of the organization.
Vulnerabilities in modern IT environments
Web applications and APIs
APIs are an essential part of modern architectures but also introduce new risks. Think of insufficient authorization, injections, or abuse of endpoints. Regular assessment is necessary, especially for publicly accessible interfaces. Consider also having pentests conducted here.
IoT and operational technology
IoT devices are often continuously connected to the network and have management interfaces that are insufficiently secured. Updates are not always applied or are even unavailable. This makes them an attractive entry point for attackers. Some organizations set up standalone IoT networks without internet access with device isolation to mitigate this. However, this is not always feasible for all IoT.
Suppliers and supply chain
Vulnerabilities are not limited to the organization itself. Software vendors, cloud providers, and IT service providers can inadvertently form an entry point. ISO 27001 therefore expects that vulnerabilities in the chain are included in the risk assessment and contractual agreements.
Roles, responsibilities, and governance
An effective vulnerability management process requires clear responsibilities:
Who owns the process?
Who assesses risks?
Who decides on acceptance, mitigation, or phasing out?
How is progress monitored and reported?
ISO 27001 expects that this does not happen ad-hoc, but is documented in policies, procedures, and planning. Even when tasks are outsourced, the organization remains ultimately responsible.
From detection to control
An important audit criterion is the difference between reactive recovery and demonstrable control. This means, among other things:
Structural monitoring of known vulnerabilities
Here, paying close attention to the entire information supply chain: Servers, OS's, firmware on routers/switches/storage appliances, installed software, self-developed software, but also office automation: workstations and the software on them.
Timely application of updates and security patches
Documented prioritization criteria
Insight into outstanding vulnerabilities
Periodic evaluation of effectiveness
The goal is not to achieve "zero vulnerabilities," but to demonstrably have control over the risks they cause.
Vulnerability management and compliance
For many organizations, vulnerability management is also necessary from a legal and regulatory perspective. Think of ISO 27001, NEN 7510, NIS2, and sector-specific requirements. All these frameworks expect organizations to actively, structurally, and demonstrably manage technical vulnerabilities.
Good documentation, insightful reports, and consistent follow-up make the difference between "we are doing something" and "we have it under control."
Interrelationship of control measure A.8.8 with other ISO 27001 measures
Control measure A.8.8 – Management of technical vulnerabilities does not stand alone. On the contrary: this measure forms a hub between risk management, operational management, software development, and incident response. ISO 27001 explicitly expects that vulnerabilities are not treated in isolation, but in conjunction with other control measures.
Consider, for example:
A.5.7 Information and analyses on threats
By collecting information about information security threats and applying it to the own environment, you can nicely support vulnerability management.
A.5.9 Inventory of information and other related business assets
Without an up-to-date overview of systems, software versions, and components, vulnerability management is not effective. Control measure A.5.9 requires organizations to map all information and other related business assets.
A.5.21 Managing information security in the ICT Chain
Supply chain attacks make vulnerability management relevant across the chain. Recently, for example: NPM Supply chain (link to external site)
A.8.32 Change management
The application of patches and updates is a change that must be controlled.
A.8.9 Configuration management
Many vulnerabilities arise from unsafe or deviating configurations.
A.8.25 Securing during the development cycle
Vulnerabilities often arise during the design and development of proprietary software. Think of the implementation of (open source) libraries. Organizations need to be sharp on this. Identify libraries that are vulnerable and actively update them. There are many methods for this, such as static code analyses that automatically recognize used libraries and version numbers and search vulnerability databases.
How do I create good policy?
Good policy on vulnerability management is entirely dependent on the business. Therefore, we cannot provide a 'one size fits all' solution. The starting point is that good policy takes into account the entire infrastructure.
Often, a prioritization is applied. You can do this, for example, by looking at the most important business processes and then mapping which assets (A.5.9 Inventory of information and other related business assets) are essential for those business processes to function. These are the components on which the greatest focus can be placed.
Examine per asset what a good way is to inventory vulnerabilities: vulnerability scans, pentests, keeping track of vendor websites, etc.
Describe per component, as needed, a patch guide (A5.37 Documented operating procedures) Then create a patch schedule. Identify what a suitable patch moment is per asset (taking into account, for example, SLAs).
Also consider zero-day vulnerabilities and emergency patches.
Evidence during an audit
An auditor can assess in many ways whether vulnerability management is well organized. The auditor will take samples and will want to see evidence.
The basis of the evidence consists of documented agreements, such as:
Policy or guidelines for vulnerability and patch management
Description of roles and responsibilities
Established prioritization criteria (for example, based on risk or impact)
These documents demonstrate that vulnerability management is consciously organized.
Many auditors will then want to see the following:
An up-to-date inventory of systems, applications, and components
Overview of software versions and vendors
Link between assets and responsible parties
This supports the demonstrability that vulnerabilities are systematically assessed within the appropriate scope.
Additionally, keep evidence of detection:
Results of vulnerability scans
Reports of penetration tests
Notifications from vendors or CERTs
Findings from monitoring or log analysis
During the audit process, it is important that you can demonstrate that the results from such reports are actually used to take action. You can demonstrate this, for example, with:
Registration of applied patches or configuration changes in change or ticket registrations
In the case of pentests: conducting retests or self-verification after remediation
No hard requirements, but it would be excellent if your organization can provide insight into the process itself:
Overviews of outstanding vulnerabilities
Turnaround times between detection and resolution
Trend analyses (for example, recurring vulnerabilities)
Reports to management or security meetings
In short, as a compliance or security officer, you can really dive into this control measure! We wish everyone good luck and a successful audit!