Patch Management for NIS2 and DORA: What the Texts Require

Short answer: neither NIS2 nor DORA sets a fixed number of days to install a patch. NIS2 requires vulnerability handling as part of cybersecurity risk-management measures. DORA requires financial entities to have documented policies for patches and updates, and controlled change management. In both cases, you must be able to show that your process works.

This guide quotes what the two EU texts actually say about patching. It then explains how a server patch process can produce the evidence supervisors ask for.

Which law applies to you

NIS2 is Directive (EU) 2022/2555. It covers essential and important entities across many sectors, including energy, transport, health and digital infrastructure. Member States had to adopt national measures by 17 October 2024 and apply them from 18 October 2024.

DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It applies to financial entities from 17 January 2025. NIS2 treats DORA as a sector-specific act. For financial entities covered by DORA, its ICT risk-management rules apply instead of NIS2’s.

What NIS2 says about patching

Article 21(1) requires appropriate and proportionate technical, operational and organizational measures to manage risks to network and information systems. Article 21(2) lists minimum measures. Three relate directly to patching:

• Point (e): security in network and information systems acquisition, development and maintenance, “including vulnerability handling and disclosure.”
• Point (f): policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
• Point (g): basic cyber hygiene practices and cybersecurity training.

The recitals name software and hardware updates as part of a common cyber hygiene baseline. Article 20 adds governance. Management bodies must approve the Article 21 measures, oversee their implementation and can be held liable for infringements.

NIS2 also sets incident reporting deadlines. Entities send an early warning within 24 hours of becoming aware of a significant incident. A notification follows within 72 hours, and a final report within one month.

What DORA says about patching

DORA is more specific. Article 9(4) lists what financial entities must do within their ICT risk management framework. Two points matter most for servers:

• Point (e): documented ICT change management, so that all changes are “recorded, tested, assessed, approved, implemented and verified in a controlled manner.”
• Point (f): appropriate and comprehensive documented policies for patches and updates.

Article 8 covers identification. Financial entities must identify, classify and document their ICT assets and dependencies, and review that at least yearly. They must also continuously identify ICT risk and assess vulnerabilities in those assets.

In short, NIS2 sets the principle and DORA adds detail for financial entities. Both expect a documented process that runs as written. Both also expect you to check that it works.

From legal text to patch evidence

How JetPatch helps produce that evidence

JetPatch runs on your own infrastructure and patches Windows Server, Linux, AIX and Solaris from one console. It is installed software with no telemetry, so patch data stays in your environment.

• Inventory. Discovery from vCenter, AWS, Azure, Active Directory and WSUS keeps the asset list current.
• Controlled change. Deployment can wait for ServiceNow or Jira approval. Sequence Patching moves updates from QA to staging to production.
• Testing before change. Predictive Patching simulates the cycle and flags blockers before the window.
• Exceptions on record. Patch Compliance Rules block specific patches on specific servers, while overall targets are still tracked.
• Reports. Compliance reports by OS, environment and plan export to CSV and PDF.

For Windows, JetPatch works with your existing WSUS or replaces it with the JetPatch repository. For isolated sites, Offline Windows Patching records who approved what, what was installed where, and when. See Offline Windows Patching and the patch management overview.

Steps to build a defensible patch process

1. Write the policy. Define scope, risk tiers, timeframes and an exception process. Have management approve it.
2. Keep inventory current. Tie every server to an owner, a criticality rating and a maintenance window.
3. Link scanning to patching. Feed vulnerability scanner results into patch priorities.
4. Control each change. Test, approve, deploy in stages and verify the result.
5. Measure and report. Track compliance and SLA adherence, and share trends with management.
6. Cover isolated systems. Apply the same process to air-gapped servers, with the same records.

Supervisors will compare your written policy with what actually happened. A tool that records each step makes that comparison easy.

Frequently asked questions

Does NIS2 set a deadline for installing patches?

The directive itself does not set a number of days. It requires vulnerability handling within proportionate risk-management measures. National laws and guidance may add detail, so check your Member State’s rules.

Does DORA require a patch management policy?

Yes. Article 9(4)(f) requires appropriate and comprehensive documented policies for patches and updates, as part of the ICT risk management framework.

If we are covered by DORA, does NIS2 also apply?

NIS2 treats DORA as a sector-specific act for financial entities. For those entities, DORA’s ICT risk-management and reporting rules apply instead of NIS2’s.

Do isolated servers need the same evidence?

Neither text exempts isolated systems. Air-gapped servers still need a defined patch process and records that prove it ran.

Need patch evidence your supervisor can review? Request an evaluation and see JetPatch reports from your own servers.