Patching has always been operational hygiene. Under NIS2 and DORA, it is also a legal obligation with teeth. Directive (EU) 2022/2555, which repealed its predecessor on 18 October 2024, requires essential and important entities to implement documented vulnerability handling and disclosure processes, and Implementing Regulation (EU) 2024/2690 goes further, specifying in Annex 6.6 that patches must be prioritised, tested, applied promptly, and recorded in a traceable way. If a patch does not exist yet, the workaround must be documented too. Installing updates “at some point” is no longer a defence.
DORA (Regulation EU 2022/2554), fully applicable since 17 January 2025, adds a second layer for the roughly 22,000 financial entities it covers. ICT risk management under DORA is not a checkbox; it is one of five structural pillars, and regulators now have direct supervisory reach over the cloud providers those entities depend on. Nineteen ICT service providers, including the three largest US hyperscalers, were designated as critical under that framework in November 2025.
The practical implication is straightforward: a patch management process that cannot be audited, reported on, and tied to risk decisions is not compliant, regardless of how fast your team actually moves. What follows is how we think about this problem for the infrastructure we operate, and how the same logic applies to any European enterprise building or migrating workloads in 2026.
What the regulations actually require
NIS2 Article 21(2) lists ten minimum cybersecurity risk management measures. Vulnerability handling and disclosure sits explicitly inside “security in network and information systems acquisition, development and maintenance.” The directive is deliberately technology-neutral and outcomes-based: it tells you what to achieve, not which tools to use. Proportionality matters too. Article 21(1) ties the depth of controls to the entity’s risk exposure, size, and the societal impact of a potential incident.
What Implementing Regulation (EU) 2024/2690 adds is specificity for the sectors it covers, including cloud computing and managed services. Annex 6.6 names the operational requirements: patches from trustworthy sources, testing before production deployment, prompt application, and documented handling of cases where no patch is available. The word “verifiably” matters here. Regulators are not asking whether you patched; they are asking whether you can prove it, when, and why you prioritised the way you did.
DORA’s incident reporting timeline reinforces this. NIS2 Article 23 requires a 24-hour early warning, a 72-hour incident notification, and a final report within one month for significant incidents. A vulnerability that sits unpatched and then becomes the root cause of an incident will be visible in that paper trail. Management bodies can be held personally liable under NIS2 for failures in Article 21 compliance, and penalties reach up to €10 million or 2% of global annual turnover.
A patch management process that cannot be audited is not a process. It is a hope, and hope is not an Article 21 control.
Linux patching best practices for cloud workloads
Most European enterprise cloud infrastructure runs on Linux, and Linux patching has its own operational rhythm that does not always map cleanly onto compliance timelines. The starting point is a complete and current inventory: you cannot patch what you cannot see. In cloud environments this means treating your asset inventory as a live data product, not a spreadsheet updated quarterly.
Vulnerability remediation in cloud follows a risk-tiered model. Critical CVEs, particularly those with known active exploitation, warrant the shortest remediation windows and should be tracked against a defined SLA from the moment they appear in your scanner output. High-severity vulnerabilities follow on a longer but still bounded timeline. Medium and low findings feed into scheduled maintenance windows. The specific windows your organisation adopts should reflect your risk exposure and sector obligations; NIS2 does not prescribe numbers, but your competent authority and any sector-specific guidance may.
Automated patch deployment is the only realistic path to scale. Tools like unattended-upgrades on Debian and Ubuntu, dnf-automatic on RHEL and its derivatives, and orchestration layers built on Ansible or similar frameworks let you define policy once and enforce it consistently across a fleet. The key discipline is separating security patches from feature updates in your pipeline. Security patches move on their own cadence; feature updates go through your standard change management process.
Building an auditable patch pipeline
Compliance under NIS2 and DORA is not just about patching speed; it is about evidence. Every step in your patch pipeline should produce a record: when a vulnerability was detected, how it was scored and prioritised, when a patch was tested, when it was deployed to production, and, if it was not deployed, what compensating control was put in place and why.
A practical pipeline looks like this:
- Continuous scanning: integrate vulnerability scanning into your CI/CD pipeline and run scheduled scans against production. Feed results into a central tracking system with timestamps.
- Risk scoring and prioritisation: use CVSS scores as a starting point, but layer in context: is this service internet-facing, does it process regulated data, is there a known exploit in the wild? CVSS alone is not a prioritisation strategy.
- Staged rollout: patch a canary or staging environment first. Automated patch deployment should never go directly to production without a validation gate, however short.
- Production deployment with change records: every production patch deployment should generate a change record with the vulnerability reference, patch version, deployment timestamp, and the operator or automation identity that applied it.
- Exception handling: when a patch cannot be applied, document the reason, the compensating control (network segmentation, WAF rule, temporary service isolation), and the review date. This is explicitly required under Annex 6.6 of Implementing Regulation (EU) 2024/2690.
How sovereign infrastructure changes the equation
One operational reality that gets underweighted in patch management discussions is where your infrastructure actually lives and who controls the update chain. When you run workloads on a US hyperscaler, the patch pipeline for the underlying platform sits outside your jurisdiction and outside European law. That matters for Schrems II and it matters for NIS2 supply chain security obligations, which are also listed under Article 21(2).
We run managed infrastructure across our four European datacenters: MAD1 in Madrid, MUC1 in Munich, HEL1 in Helsinki, and AMS1 in Amsterdam. When a customer’s managed workload needs a patch applied, the entire chain, from the vulnerability scanner to the change record to the deployment automation, stays within European jurisdiction. We operate under ISO 27001 and a contractual 99.9% uptime SLA, and our managed services are designed to produce the audit trail that Article 21 and Annex 6.6 actually require. For finance customers under DORA, that chain of custody is not a nice-to-have; it is part of the third-party risk management documentation their regulators will ask for.
What to have in place before your next audit
If you are an essential or important entity under NIS2, or a financial entity under DORA, the following should exist and be demonstrable today, not in progress:
- A complete, timestamped asset inventory covering all network and information systems in scope.
- A documented vulnerability management policy that defines severity tiers, remediation timelines, and exception handling.
- Automated scanning with output feeding into a tracked, reportable backlog.
- A staged patch deployment process with validation gates and change records.
- Evidence that management has approved and oversees the process, as Article 21 requires of management bodies.
- A documented procedure for the 24-hour and 72-hour incident notification requirements under Article 23, in case an unpatched vulnerability becomes an incident.
The January 2026 Commission proposal to amend NIS2 signals that the regulatory direction is toward simplification for smaller entities, not relaxation of the core risk management obligations. For medium and large enterprises, the baseline is not moving. The question is whether your patch management process is built to meet it or built to explain why it did not.
