Risk-based patch management in enterprise environments in the context of NIS2

Article written by Bogdan Agiu, O365 L2 Engineer

A company applies updates every month. Yet when an auditor or security owner asks which patch was installed, on which assets, on what date, with what result, and whether the servers were restarted, it takes days to provide an answer.

The patches were deployed. The evidence that they worked is missing.

 

This is where NIS2 changes the perspective. Risk-based patch management is a repeatable process, not a one-off monthly installation exercise. In practical terms, it means identifying vulnerabilities, prioritising them according to actual risk, testing, deploying and verifying remediation. This article focuses on hybrid infrastructure, critical systems and assets managed by third-party providers. It is not intended as a general overview of all NIS2 obligations.

 

One point is worth clarifying from the start. A patch that has been pushed is not necessarily installed. An installed patch is not automatically active. And an active patch does not prove that the vulnerability has been successfully remediated.

The difference between these states is exactly where real security programmes succeed or fail.

 

Representation of an enterprise IT asset inventory and attack-surface mapping in a hybrid infrastructure

 

What NIS2 requires for vulnerability and patch management

The NIS2 Directive does not tell organisations to install every patch immediately. It requires them to demonstrate a coherent process for managing vulnerabilities in proportion to risk. The wording is deliberately flexible because organisations with very different sizes, exposure levels and operational criticality cannot be managed in the same way.

 

The link to Article 21

Article 21 of the Directive requires appropriate and proportionate technical, operational and organisational measures based on risks, exposure, the size of the entity and the potential impact of an incident.

Patch management falls directly under the requirement covering the security of network and information systems acquisition, development and maintenance, which explicitly includes vulnerability handling and disclosure. The full text is available on EUR-Lex.

 

What Implementing Regulation 2024/2690 adds

For certain categories of organisations, the general requirements of the Directive become more specific.

Commission Implementing Regulation (EU) 2024/2690 sets out technical and methodological requirements for entities including DNS service providers, TLD registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers.

The sections covering acquisition and maintenance security require patch-management procedures to be:

• aligned with change, vulnerability and risk management;
• applied within an appropriate timeframe based on relevant risks;
• tested before deployment into production where appropriate;
• obtained from trusted sources and subject to appropriate integrity controls;
• supplemented by mitigating measures where a patch cannot be applied;
• documented where an organisation decides not to apply an available patch.

ENISA’s technical implementation guidance further provides practical recommendations, examples of evidence and implementation considerations for the entities covered by the Implementing Regulation.

 

National implementation and governance across the EU

NIS2 establishes a common European cybersecurity framework, but implementation, supervision and enforcement take place at national level.

Each EU Member State transposes the Directive into its national legal framework and designates one or more competent authorities responsible for supervision, enforcement and incident-reporting requirements.

For organisations operating across several EU countries, this creates an important distinction.

The underlying cybersecurity risk-management principles are broadly aligned at EU level, while specific registration processes, competent authorities, supervisory procedures and enforcement mechanisms may differ between jurisdictions.

Patch-management policies should therefore be designed around the common NIS2 risk-management principles, while national implementation requirements should be verified in each country where the organisation falls within scope.

For organisations operating across the wider EMEA region, NIS2 should therefore be assessed in relation to their EU entities and services rather than treated as a general EMEA-wide regulation.

 

Who is responsible for what

A patching programme does not have a single owner.

It only works when responsibilities are clearly distributed across the vulnerability-management team, infrastructure administrators, application and service owners, cloud and DevOps teams, owners of critical systems and the change advisory board responsible for approving changes.

Management approves and oversees accepted residual risk.

That does not mean every technical exception needs to be approved personally by the CISO. It means that material decisions remain traceable to someone who is accountable for them.

 

Asset inventory and attack-surface mapping

You cannot patch a server you do not know exists. It sounds obvious, but this is where many programmes fail. An incomplete inventory turns any prioritisation strategy into an assumption. Complete asset visibility is the foundation of any risk-based patch-management programme.

 

The principle of complete visibility

The attack surface of a medium-sized or large organisation extends far beyond employee laptops.

A serious inventory includes physical and virtual servers, hypervisors, endpoints, applications and middleware, network and security devices, firmware, containers and images, IaaS, PaaS and SaaS services, as well as OT, ICS and industrial IoT systems.

Third-party-managed assets must also be included, because these often disappear from internal visibility altogether. The real problem is forgotten assets.

Shadow IT that appeared overnight. Legacy on-premises systems nobody touches anymore. Assets without a clearly assigned owner. End-of-support systems that no longer receive patches. And assets excluded from vulnerability scans or patch-management platforms, making them invisible exactly where visibility matters most.

 

Continuous discovery, not once a year

An inventory created a week before an audit starts ageing immediately.

A mature approach therefore combines several discovery sources, each with different strengths:

• agent-based inventory, accurate but dependent on agent deployment;
• agentless scanning, useful for assets where an agent cannot run;
• passive network monitoring, which can identify unregistered devices;
• correlated data from CMDBs, EDR platforms, vulnerability scanners and cloud platforms.

No single source covers everything. Together, they bring the asset inventory closer to reality.

 

Minimum data required in an asset register

A useful asset register contains more than hostnames.

For each asset, it is worth maintaining:

• a unique identifier;
• a technical owner and business owner;
• operating system;
• applications;
• firmware and software versions;
• environment, such as production, test, development or backup;
• internet exposure;
• supported business service;
• operational criticality;
• type of data processed;
• dependencies;
• maintenance window;
• update mechanism;
• support status;
• date of the most recent technical verification.

Without these fields, later prioritisation lacks the context needed for meaningful decisions.

 

Cloud, on-premises and SBOM

Cloud inventory needs to be correlated with local infrastructure.

Data from Entra ID and Intune should align with Active Directory, physical servers and the rest of the on-premises environment. Otherwise, the organisation ends up with two parallel versions of the truth.

A Software Bill of Materials, or SBOM, extends the inventory into applications, where conventional scanners may have limited visibility.

It can reveal open-source libraries, components used in internally developed applications, microservice dependencies and software supplied by third parties.

Consistent tagging should then be applied across internet-facing, internal, segmented, air-gapped, IT, OT, IoT, critical and redundant assets.

Those tags become an important input into later prioritisation decisions.

 

Asset visibility in practice

A technical posture-monitoring platform such as Security OptiApp can help inventory assets across environments including Entra ID, Microsoft 365, Active Directory and servers, highlighting discrepancies between what the organisation believes it manages and what is actually visible in its systems.

The objective is to work from a single source of truth rather than a collection of disconnected dashboards.

 

Risk-based prioritisation beyond severity scores

If every critical vulnerability is treated in exactly the same way, resources will be spent on some vulnerabilities that may never be exploited while remediation of more relevant issues is delayed.

Risk-based prioritisation means deciding what to fix first based on context rather than relying on a single number.

 

Actual risk combines technical severity, likelihood of exploitation and internal context.

 

Why CVSS is not enough on its own

A high CVSS score tells you how severe exploitation could be. It does not tell you how likely exploitation is in your environment.

A critical vulnerability on an isolated server with no internet exposure and no sensitive data does not necessarily have the same urgency as a medium-severity vulnerability on an internet-facing asset supporting a critical service.

CVSS v4.0 reinforces the idea that CVSS should not be reduced to the Base score alone. It includes Base, Threat and Environmental metric combinations that allow vulnerability severity to be considered alongside additional context.

 

Three sources of context

A robust prioritisation model does not rely on one score.

It combines technical severity, likelihood of exploitation, evidence of active exploitation and what the organisation knows about its own infrastructure.

Source	What it measures	How to use it
CVSS v4.0	Technical severity and potential impact	Starting point
EPSS	Estimated probability of exploitation in the next 30 days	Predictive layer
CISA KEV	Vulnerabilities with confirmed exploitation in the wild	Urgency signal
Internal context	Exposure, criticality, data, dependencies and existing controls	Final decision

EPSS is a data-driven model maintained through FIRST that estimates the probability that a published CVE will be exploited in the wild within the next 30 days. It is useful precisely because exploitation likelihood and technical severity are different questions.

The CISA Known Exploited Vulnerabilities Catalog lists vulnerabilities for which there is evidence of exploitation in the wild, making it a useful operational signal when prioritising remediation.

Neither EPSS nor KEV replaces asset context. A vulnerability still needs to be assessed against the technologies, exposure and compensating controls present in the organisation.

 

The factors that determine priority

In practice, the decision combines several factors. Technical severity. Likelihood of exploitation. The presence of a public exploit or proof of concept.

Weaponisation status, meaning whether exploitation has already been turned into a working attack capability. Asset exposure. Criticality of the supported service. Impact on availability, integrity and confidentiality. Compensating controls that are already active. Dependencies and the risk of disruption caused by applying the patch. And finally, whether a patch exists and whether a viable rollback path is available.

 

An indicative prioritisation matrix

Priority	Context	Proposed internal treatment
P0	Zero-day or CISA KEV vulnerability, exposed asset, critical service	Remediation or mitigation within 24–72 hours
P1	Critical vulnerability, high EPSS or public exploit	Remediation within 7–14 days
P2	Important vulnerability with no confirmed exploitation	Next patching cycle
P3	Low risk, non-critical asset or limited exposure	Normal cycle, typically within 30 days

These timeframes are examples of internal policy and need to be calibrated by each organisation. NIS2 does not impose universal fixed patching deadlines. It requires organisations to apply risk-management measures that are appropriate and proportionate to the risks involved. A matrix such as this gives teams a practical way to document why remediation decisions were made.

 

Testing before production and preventing downtime

A patch that fixes a vulnerability but takes down a critical application is not a successful outcome. It is a self-inflicted incident. Testing is not an administrative formality. It is the step that separates controlled patching from a three-in-the-morning emergency.

 

A controlled testing and promotion workflow reduces the risk of regression in production.

 

Test environments and pilot groups

A staging environment is valuable only when it resembles production. That means replicating critical configurations rather than creating an approximation.

For endpoints, pilot groups and deployment rings work well: the patch is deployed to a limited group first and expanded only if no issues appear.

Legacy applications deserve particular attention because incompatibilities are more common there.

Functional tests, performance tests and validation of authentication and integrations can expose problems before they reach end users.

 

Microservices and containers

In containerised environments, the logic changes. You generally do not patch a running container. You rebuild it.

That means updating base images, scanning images before deployment and redeploying rather than modifying the container manually.

Immutable infrastructure, blue-green deployment and canary deployment provide finer control over exposure, while rolling back to a previous version becomes a routine operational procedure rather than an emergency measure.

 

Promotion and rollback criteria

Before deployment, define clearly what success looks like and what triggers a rollback. Without predefined criteria, teams improvise under pressure.

A minimum set should include:

• measurable success criteria for promotion;
• error thresholds that stop deployment;
• specific indicators that trigger rollback;
• the person authorised to approve rollback;
• maximum acceptable downtime;
• the verification procedure after rollback.

Backups and snapshots should not be assumed to work. They should be tested. A snapshot that nobody has ever restored is a hope, not a recovery plan.

 

Deployment windows, automation and critical systems

When a patch is installed can matter almost as much as the patch itself. A poorly chosen maintenance window can turn a routine update into a customer-visible service disruption.

 

Maintenance windows

Most organisations operate on weekly or monthly cycles aligned with vendor release schedules, including Patch Tuesday where the ecosystem makes this relevant.

In addition to planned windows, organisations need:

• emergency windows for P0 vulnerabilities;
• different windows for different asset classes;
• advance communication of planned downtime;
• coordination with third parties managing part of the infrastructure.

 

Automation and orchestration

Not every asset should be handled in the same way. Workstations and endpoints can often support highly automated patching. Servers require orchestrated patching with controlled steps. Databases need additional approvals because mistakes can have significant consequences.

Production environments benefit from controlled deployment, with automated stopping conditions when the error rate exceeds an agreed threshold. The difference between automation and chaos is often exactly that threshold.

 

Cloud-native and on-premises environments

Patch mechanisms differ substantially between environments. On-premises infrastructure commonly relies on traditional patching agents.

In cloud environments, organisations may update AMIs and golden images, redeploy virtual machines, replace instances or upgrade clusters. The boundary of responsibility also changes across IaaS, PaaS and SaaS. The shared-responsibility model is not merely a contractual detail. It determines who applies which updates and who is accountable when they are not applied.

 

High-availability systems

Where services cannot tolerate complete downtime, patching should not require full service interruption. Clustering, redundancy and failover make rolling updates possible.

Nodes are updated one by one, each node is validated before moving to the next, and deployment is expanded only when stability is confirmed. It is slower. It also avoids unnecessary outages.

 

OT, ICS and critical infrastructure

Industrial environments follow different rules, and naïve patching can be dangerous. PLCs and SCADA systems may have very limited maintenance windows, while frequent shutdowns may be operationally impossible.

Many updates require OEM approval. Otherwise, support or warranty conditions may be affected. Testing should take place in a laboratory or representative environment rather than directly on the production line.

Separation between IT and OT, strict change-management procedures and alignment with business continuity and IT BCP plans become especially important. Where patching is delayed, which is often the case, compensating controls need to cover the gap.

 

Exceptions, accepted risk and compensating controls

Sometimes a patch cannot be applied. That is not necessarily a failure of the programme. It is an operational reality. The real question is whether exceptions are managed transparently or hidden until the next incident.

 

When an exception is legitimate

There are situations where delaying or not applying a patch can be justified:

• demonstrated incompatibility with a critical application;
• absence of an available vendor patch;
• a critical system with no available maintenance window;
• disproportionate risk of downtime;
• a fragile legacy component;
• an unsupported system;
• a patch that has been withdrawn or reported as unstable by the vendor.

The key word is demonstrated. An exception without analysis behind it is simply a delay with a different label.

 

The exception register

Every exception needs an audit trail capable of surviving scrutiny.

A proper register should record:

• the asset and vulnerability;
• the reason the patch is not being applied;
• impact analysis;
• decision owner;
• relevant approval;
• duration;
• expiry date;
• remediation plan;
• accepted residual risk;
• compensating controls applied in the meantime.

An exception with no expiry date has a tendency to become permanent. A permanent exception is often simply a risk that nobody has reassessed.

 

Compensating controls

Where direct remediation is not possible, exposure can be reduced through other measures:

• virtual patching through WAF, IPS, IDS or firewall controls;
• microsegmentation and access restrictions;
• disabling the vulnerable service where it is not essential;
• jump servers and additional monitoring;
• dedicated SIEM and EDR or XDR rules;
• asset isolation and more frequent scanning.

These controls buy time. They do not permanently replace the patch, and the exception should be reviewed periodically rather than forgotten in a file.

 

Verifying deployment and closing the remediation loop

Installing the patch does not complete the job. The process is complete when the organisation confirms that the vulnerability has actually disappeared. This is where a programme that looks good on paper separates from one that can withstand real scrutiny.Verifying deployment and closing the remediation loop

Installing the patch does not complete the job. The process is complete when the organisation confirms that the vulnerability has actually disappeared. This is where a programme that looks good on paper separates from one that can withstand real scrutiny.

 

A closed loop turns patch deployment into verifiable evidence of remediation.

 

The closed-loop workflow

patch available → asset identified → priority established → testing → approval → deployment → restart, where required → version verification → rescanning → functional testing → ticket closure

Every arrow is a point where something can fail. A mature programme does not assume that the step succeeded. It verifies it.

 

Why a deployment report is not enough

A dashboard showing “95% compliant” looks reassuring and can still hide significant problems. Discrepancies often appear where nobody is looking:

A patch is installed but the system has not been restarted, so the update is not active. An asset is reported as updated but is running the wrong version. An asset was omitted from the deployment group entirely. The vulnerability reappeared after the update. A patch was applied to one system but not to dependent components. A service failed after deployment and nobody noticed until the first user complaint.

The deployment report tells you what the platform attempted to deliver. It does not necessarily tell you what actually happened on the asset.

 

Post-deployment verification

Real confirmation combines several checks:

• installed version;
• service status;
• relevant logs;
• vulnerability rescanning;
• testing of critical functionality;
• regression detection;
• confirmation that the asset remains included in the applicable policy.

If the rescan shows that the vulnerability is still open, the result returns to the remediation cycle. The ticket should not be closed solely because the installation platform reported success.

 

Operational evidence

Evidence should not be assembled in a rush immediately before an audit. It should be produced by the process itself.

Useful evidence includes:

• exports from the patch-management platform;
• pre- and post-remediation rescan results;
• change tickets;
• approvals;
• installation logs;
• test results;
• rollback records;
• exception registers;
• documented acceptance of residual risk.

When these pieces already exist, an external review becomes a presentation exercise rather than several nights of emergency evidence gathering.

 

Technical evidence, organised

 

At the verification stage, a technical posture-monitoring platform such as Security OptiApp can help track configuration changes and organise evidence in a reusable format, allowing the question “what can we demonstrate right now?” to be answered quickly. Its role is to support the team, not to replace the underlying process, formal assessment or control.

 

Progress indicators, reporting and the operational checklist

Without measurement, you do not know whether the programme is improving or simply generating activity. The right indicators show where time is being lost and where exposure remains. Good reporting translates technical information into business decisions.

 

Performance indicators (KPIs)

• Mean Time to Patch: average time from publication to remediation;
• Patch Compliance Rate: percentage of compliant assets;
• percentage of assets meeting the internal SLA;
• time from patch publication to assessment;
• time from approval to installation;
• failed installation rate;
• Patch Rollback Rate;
• percentage of patches verified after installation.

 

Risk indicators (KRIs)

• exploited vulnerabilities that remain open;
• critical assets that are still exposed;
• vulnerabilities that have exceeded the SLA;
• expired and unresolved exceptions;
• assets without an owner or without vendor support;
• systems not covered by vulnerability scanning;
• recurring vulnerabilities.

Board reporting should not be written in purely technical language. It should answer business questions:

Which critical services remain exposed? What residual risk has been accepted? Which exceptions have exceeded their deadline? Where do we depend on third parties for remediation? What resources are missing to close the remaining gaps?

A CIO can act on those questions. A dashboard full of CVEs is harder to translate into a business decision.

 

Operational checklist

• the inventory covers on-premises, cloud, containers, OT and third-party-managed assets;
• every asset has an owner and a criticality level;
• prioritisation combines CVSS, EPSS, KEV and internal context;
• patches are tested before production deployment;
• standard and emergency maintenance windows are defined;
• critical systems have rollback capabilities and redundancy;
• exceptions are documented and time-limited;
• compensating controls are applied where patching is delayed;
• installation is verified through rescanning and functional testing;
• KPIs and KRIs reach management;
• evidence is retained in a reusable format.

 

Is CVSS enough for prioritisation?

No.

CVSS provides technical severity, but it does not tell you the likelihood of exploitation or the context of your own environment.

For better decisions, combine it with EPSS, CISA KEV and the real exposure of the affected asset.

 

What should we do when a critical system cannot be updated?

Document the exception with an impact assessment and expiry date, apply compensating controls ranging from segmentation to virtual patching, and reassess it periodically. The exception should remain temporary by design.

 

How do we demonstrate that the patch is active?

By verifying the installed version, confirming the restart where one was required, and rescanning the vulnerability. A deployment report shows the intention to install. It does not necessarily prove the final result.

 

What is the difference between an installed patch and a remediated vulnerability?

A patch may be installed without the required restart, deployed on the wrong version, or applied to one system while dependent components remain exposed.

The vulnerability is only considered remediated when verification and rescanning confirm that it is closed. A risk-based patch-management programme should not be judged by how many patches have been deployed.

It should be judged by how quickly the organisation can demonstrate what has been remediated, what has been deliberately deferred, and why.

If an auditor, customer, partner or your own management asks tomorrow for the current status of critical vulnerabilities, the answer should come from the process itself rather than from a last-minute evidence-gathering exercise.

The useful question is not simply whether you apply patches. It is whether you can prove that they worked.

 

About the Optimizor Team

Article prepared by the Optimizor team, specialising in managed IT services, cybersecurity and compliance for medium-sized and large organisations across Europe and international environments, with expertise across the Microsoft ecosystem, identity governance and vulnerability management in hybrid infrastructures. Optimizor is a managed IT services provider and the developer of Security OptiApp, a platform for monitoring technical security posture. The analysis is based on primary legislative and official technical sources together with established cybersecurity standards and operational guidance.

 

NIS2 establishes an EU-wide framework, but national implementation, supervisory procedures and enforcement mechanisms may differ between Member States. Organisations should verify the requirements applicable in each jurisdiction in which their entities or services fall within scope.

 

Sources

1. Directive (EU) 2022/2555 (NIS2). European Parliament and Council of the European Union, 2022.
   EUR-Lex – Directive (EU) 2022/2555
2. Commission Implementing Regulation (EU) 2024/2690. European Commission, 2024.
   EUR-Lex – Implementing Regulation (EU) 2024/2690
3. NIS2 Technical Implementation Guidance. ENISA, 2025.
   ENISA – NIS2 Technical Implementation Guidance
4. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, NIST SP 800-40 Rev. 4. NIST, 2022.
   NIST – SP 800-40 Rev. 4
5. Common Vulnerability Scoring System v4.0. FIRST.
   FIRST – CVSS v4.0
6. Exploit Prediction Scoring System (EPSS). FIRST.
   FIRST – EPSS
7. Known Exploited Vulnerabilities Catalog. Cybersecurity and Infrastructure Security Agency (CISA).
   CISA – Known Exploited Vulnerabilities Catalog