A critical vulnerability is announced. The supplier publishes a security update. A few days later, exploit code appears that allows attackers to practically abuse the leak. Then it becomes clear how well the patch management of an organisation really works. This requires more than automatic updates.
What is patch management?
Patch management is the process by which an organisation manages software and security updates throughout the entire life cycle of its IT environment.
A workable process begins with insight. You need to know which systems, applications and versions are used before you can determine which security warnings are relevant. After that, review, prioritisation, installation and control will follow.
An updated version is only controlled when you can determine that the vulnerability has actually been corrected.
- 1. Relevant security warnings received.
- 2. Detecting which systems are being hit.
- 3. Risk and urgency assessment.
- 4. Test the update or determine the impact.
- 5. Install the patch.
- 6. Checking for installation has been successful.
- 7. To define derogations and exceptions.
- 8. Report regularly on backlogs and risks.
Good patch management is organized speed: know what you're using, recognize serious vulnerabilities, act with focus and then verify that the risk has actually been solved.
Not every vulnerability has the same urgency
Software providers constantly publish patches. Installing everything immediately is practically impossible in many environments and can cause continuity risks. Prioritization is therefore important.
In case of a new vulnerability, look at the accessibility of the system, the severity of the leak, available exploit code, perceived active abuse, the value of the affected system and the possible consequences for the organisation.
A serious vulnerability in an internet-accessible mail server requires a response other than a vulnerability in an internal test system without sensitive data.
Mitigation measures also count. A system can be temporarily shielded, vulnerable functionality can be disabled or access can be restricted until the patch can be checked. Record the decision and the remaining risks when an update is postponed.
The Exchange leak of August 2026 shows why speed counts
Microsoft released security updates for various vulnerabilities in Exchange Server in August 2026. For CVE-2026-62911 later published public proof-of-concept code. The NCSC then increased the scaling to High/High.
This changed the situation for organisations that had not yet installed the patch. The vulnerability was the same, while the practical risk of abuse had increased significantly.
A good patch process responds to such changes. A monthly patch round can be too slow in case of acute threat. Organisations therefore also need a route for urgent security updates.
Who is responsible if IT is outsourced?
Many organisations spend technical management on an MSP, cloud supplier or other IT service provider. This means that the technical implementation lies with an external party. The organisation remains dependent on the quality, speed and demonstrability of that process.
Ask how critical vulnerabilities are detected, what response times apply per emergency level and how the supplier controls successful installation.
Regular reporting gives boards and executive management and IT managers more insight than the general agreement that the supplier provides patch management.
- which systems are outside automatic patching
- how many critical and high vulnerabilities are currently available
- which patches have been deliberately postponed and why
- how successful installation is checked
- how delays, exceptions and residual risks are reported
Patch management and ISO 27001
ISO 27001 explicitly deals with the management of technical vulnerabilities. Annex A measure 8.8 focuses on obtaining information on technical vulnerabilities, assessing exposure and taking appropriate measures. Patch management is an important part of that.
For demonstrable control, you want to be able to show which vulnerabilities have been assessed, which deadlines have been chosen, which updates have been executed and how exceptions are followed.
- a current overview of systems and software
- vulnerability scans and supplier warnings
- patch reports with established priorities and deadlines
- registrations of exceptions and temporary measures
- proof completed updates
- periodic checks on overdue patches
Patch management under NIS2 and Dutch Cybersecurity Act
Within NIS2 and the Dutch Cybersecurity Act, the management of technical vulnerabilities is part of the broader approach to digital risks.
the board and executive management do not have to assess individual security updates themselves. They should be able to identify the organisation as having a working process that will identify and resolve serious vulnerabilities in a timely manner.
A practical question of management is: How do we know that a critical vulnerability in an important system is found, assessed and resolved within an appropriate time frame? Without a concrete answer, it is difficult to determine whether patch management is sufficiently secure.
Also check if patches are working
A patch report can indicate that an update has been rolled out. This does not yet establish that every system has been successfully updated. Installations can fail, devices can be offline and old systems can be out of central management.
Verification is therefore part of the process. Vulnerability scanning can, for example, show whether known vulnerabilities are still present after a patch round. This gives more certainty than an overview of sent updates.
Practical control for your own organisation
You quickly gain insight into the maturity of patch management by answering five questions. An unclear answer usually points directly to a concrete improvement point.
- 1. Do we know which systems and software versions we use?
- 2. Do we receive and assess alerts on critical vulnerabilities active?
- 3. Do we have an emergency procedure for vulnerabilities that can be directly abused?
- 4. Can we show that patches have been successfully installed?
- 5. Are delays and exceptions visible to those responsible for the risk?
Good patch management is organized speed
The technical operation of installing an update is often the simple part. The quality is in the process around it: know what you have, recognize relevant warnings, determine urgency, act quickly and then check that the risk has actually been resolved.
Just when exploitation code suddenly becomes available, that preparation makes the difference.
Continue reading
The practice shows why patching, logging, incident response and independent research should be assessed in conjunction.
Do you want to know if vulnerabilities, patching and technical management are in a demonstrable state of order? An independent Cyber Security Audit will show the operation, exceptions and key points of improvement.
Sources and deepening
Based on official frameworks and practical implementation
The source pages provide the formal background. Kynexis Information Security translates this information into an executable approach for your organisation, sector and risk profile.
