Security updates (patches) are no longer an annoying IT ritual — they are mandatory at the very latest with the German implementation of the NIS2 Directive. The Cybersecurity Act was passed in November 2025 and has been in force since 06.12.25. Conscientious technical implementation thus becomes a central component of legal cybersecurity compliance.
But what does this mean for companies in practice? How can you ensure that patches are not only installed quickly, but also verifiably and compliantly? This article shows why patch management is so crucial in NIS2 — and which requirements must be implemented in practice.
The most important things in brief
- Patch management is mandatory under NIS2 and part of the required vulnerability management. Security updates must be implemented risk-based and promptly.
- The specific requirements arise primarily from the EU implementing regulation (Annex 6.6), not just from German law.
- Tests are required, however, the scope of documentation is risk-based — proof of exceptions or delays is particularly important.
- Third-party applications are often the biggest gap: Automation helps, but it doesn't replace complete transparency across all applications.
1 Why patch management is so important as part of NIS2
Any vulnerability that remains unpatched opens a door — or rather a barn door — for attacks. And this is until the patch is completely rolled out. The NIS2 Directive recognizes exactly this and therefore places the issue at the center of the European cybersecurity strategy.
NIS2 requires companies to install security patches within a reasonable period of time — and verifiably. That means: It is no longer enough, patches sometime to install. They must be prioritized, tested, documented and rolled out in a traceable manner.
The following excerpt is from the Commission Implementing Regulation. The various documents relevant to patch management and their classification are explained in more detail in Section 2.
Patch management has always been one of the most important cyber hygiene measures, but is now given additional legal responsibility. Anyone who acts inconsistently here not only endangers their systems, but also risks sanctions and liability issues — and in both cases, the existence of the organization in an emergency.
Our experience shows: For many companies, patching 3rd party applications regularly and quickly is a challenge. patch management catalogs, such as Patch My PC, are essential, but you can't rest on your laurels: Applications, drivers, etc. outside the catalog should never be neglected!
This assessment is also supported by current figures. This study by Juriba and application management legend Bob Kelly shows that 80% of companies are unable to keep more than half of their applications up to date over a period of 3 months. A significant security risk resulting from increasingly frequent vulnerabilities and ever leaner IT departments. This is exactly why patch management under NIS2 can no longer be regarded as a side task, but must be understood as a continuous, structured and partially automated process.
2 Important documents about patch management in the context of NIS2
Anyone who deals with NIS2 and patch management for the first time will quickly come across a variety of regulations, laws and guidelines at EU and national level. At first glance, the interplay of these documents seems confusing, as the requirements cannot be read in full in one place.
In principle, the NIS2 Directive sets the legal framework, while the German Cybersecurity Act transforms this framework into national law. However, the actual technical specification, in particular for patch management, is carried out at EU level through an implementing regulation and is also explained by ENISA guidelines. These documents build on each other, complement each other and have different legal binding effects.
The following table lists the most important regulations and shows what role they each play in patch management and where specific requirements can be found.
3 The NIS2 patch management requirements in detail
The specific requirements for patch management are derived from Annex 6.6 “Security Patch Management” of the EU Implementing Regulation (EU) 2024/2690, which clarifies the content of NIS2 and German legislation. Among other things, prompt application, tests before production, trustworthy sources and how to deal with missing patches are named.
The ENISA Technical Implementation Guidance deepens these points and provides practical advice on risk-based deadlines, documentation and auditability.
- Timely application of security patches: Security-relevant updates must be installed within a defined period of time — depending on the criticality of the vulnerability.
- Pre-implementation testing: Patches must not be rolled out uncontrollably. Companies must ensure that they have no side effects on production systems.
- Using trusted sources: Only updates from verified, verified sources may be used. Integrity checks are mandatory.
- Documentation & verifiability: Every step — from patch testing to rollout — must be comprehensibly documented. These logs serve as evidence in the event of audits or incidents.
- Dealing with missing patches: If a patch is not yet available for a vulnerability, alternative protective measures (e.g. workarounds, segmentation) must be documented.
The NIS2 requirements for patch management make it clear: Companies must interlink technical implementation, process quality and verification — a challenge that only requires consistency, clearly defined responsibilities, the right Tools and automation must be mastered.
4 Common challenges with NIS2-compliant patch management
In theory, patch management sounds simple: Identify, test, distribute updates — that's it.
In practice, however, many companies are reaching their limits here. NIS2 further aggravates this situation because not only technical implementation but also documentation, traceability and governance are required.
- Time and resource bottleneck: Regular checks for security patches, software packaging, testing, rollout, documentation and monitoring take up a lot of time, but must be carried out constantly and regularly. A lack of resources causes tasks to build up. Many IT teams are constantly lagging behind and are therefore at risk — for damage caused by cyber attacks and failure to comply with regulatory requirements. Even cyber insurance often does not work if no effective process for patch management has been established.
- Heterogeneous system landscapes: Many organizations operate a mix of Windows, Linux, macOS, and IoT devices — often spread across multiple locations or clouds. This makes uniform patch processes and consistent reporting difficult.
- Lack of central control: Without a central Unified endpoint management solution and corresponding reporting options, there is no transparency as to which systems are currently patched and which are not. However, it is precisely this overview that is the basis for NIS2 audits.
- Test effort and operational risks: Updates can have side effects — particularly for business-critical applications. However, NIS2 requires a timely installation. There is an organizational conflict of goals between speed and stability.
- Prioritize vulnerabilities: Not every patch is equally critical. Many companies do not have clear rules as to which gaps are closed immediately and which are closed later. NIS2 requires a risk-based approach here.
- documentation requirements: Many IT teams underestimate the effort associated with the obligation to provide evidence. Logs, test reports and approvals must be maintained in such a way that they remain auditable — often an additional administrative effort.
- Sense of false security: Many companies feel well positioned because operating systems are patched automatically, for example via Windows Autopatch. It often goes unnoticed that a large part of the attack surface lies in third-party applications. Although patch catalogs such as Patch My PC are used wisely, applications outside of these catalogs are easy to lose sight of. This creates deceptive security in which supposedly closed gaps actually remain open.
These challenges show that anyone who takes NIS2 seriously not only needs tools, but also clear processes, responsibilities and automation.
5 This is how practical implementation works — patch management according to NIS2
This makes it possible to set up NIS2-compliant patch management. The biggest challenge is and remains the IT department's capacity:
- Manage all endpoints: The basic requirement for patches to be rolled out to many devices at the same time. At SOFTTAILOR, we usually focus on classic devices, such as servers and clients of various operating systems. As a rule, we try to combine this with a uniform Unified endpoint management from Microsoft or Baramundi to manage. However, this is not always possible and network components and IoT devices must also be considered.
- Clarify responsibilities: Patching requires clear ownership. For each device group, it is necessary to specify who implements and who provides the proof. Network components are typically the responsibility of the network team, clients and servers by the endpoint team. If not all devices can be controlled via one system, responsibilities are distributed across the platforms used. IoT and OT often involve joint responsibility between IT and specialist areas.
- Patch Reporting & Inventory: The first step is transparency — the patch status of all applications and devices should ideally be recorded in central reporting. Patch My PC is therefore very strong in Advanced Insights for Intune and for SCCM invests.
- automation: Automated processes are the key to delivering patches reliably, quickly and with consistent quality. Tools make this step significantly easier as applications are automatically packaged, tested, and integrated with Intune or MECM. This significantly reduces manual effort, while at the same time ensuring that third-party software is also updated regularly and consistently.
- Robust process for patches that aren't automated: Not all applications can be updated automatically, e.g. via Patch My PC. Such cases require a clearly defined continuous process. This includes regular checking for (security) updates and, as a result, timely software packaging, testing and rollout of the application.
- Assessment of security vulnerabilities: Not every patch is critical. A risk assessment process (e.g. based on CVSS scores, or Microsoft Defender-reviews) helps determine urgency. Critical gaps must be closed within clearly defined deadlines. But even less critical security gaps should not be neglected.
- Test in isolated environments: Before rollout, updates should be tested in a test environment. This is less about the range of functions and more about stability and compatibility — a key point for avoiding operational failures.
- Phased rollout: A phased rollout reduces risks and ensures operational stability. Updates should first be distributed in a small group of pilots and only then gradually rolled out to all systems. This approach makes it possible to identify unexpected effects early on and counteract them before they have major effects. Even though solutions can largely automate this process, continuous monitoring remains crucial — in particular to be able to intervene quickly in the event of errors or incompatibilities.
- Documentation & audit trail: Patch management must be comprehensible, not over-documented. It is crucial that it remains clear which patches have been rolled out and where there are deviations. If a patch is delayed or not installed, the reasons and planned replacement measures must be recorded. In practice, logs from management systems, change entries and approvals are sufficient for this. The scope and level of detail of documentation should be based on risk, not on formal reporting requirements. Features like Advanced Insights from Patch My PC support this by making patch status, deviations and trends centrally evaluable.
6 Conclusion — Patch Management as the Key to NIS2 Compliance
NIS2-compliant patch management must consider various aspects and must therefore be well thought out. However, with a little effort, the right tools and sufficient capacity, a robust, repeatable and partially automated process can be built that meets the requirements and at the same time significantly increases IT security. Companies that regularly and comprehensibly update their systems not only meet regulatory requirements, but also actively strengthen their cyber resilience.
Since many IT departments work with limited resources, external support can be useful. SoftTailors Patch Management as a Service automates processes where possible, monitors them, proactively takes care of non-automatable patches, complies with defined SLAs and provides audit-proof evidence for audits.
Since 2011, Thore has focused exclusively on endpoint management and endpoint security topics. Initially focused on software packaging and software distribution with Microsoft MECM/SCCM and Ivanti DSM, he is now a sought-after interlocutor when it comes to unified endpoint management, system hardening, patch management and endpoint protection. The focus is in particular on the Microsoft technologies Intune, Configuration Manager, Entra and Defender. Thore is co-founder of the “Endpoint Management” expert group at IAMCP e.V.
Jahre Erfarung
Verwaltete Endgeräte
