Patch management process NIS-2 compliant: SLA, roles, evidence

Art. 21(2)(e) NIS-2 requires essential and important facilities to have a vulnerability and patch management process as part of cybersecurity measures. The directive became applicable in the member states on October 17, 2024, and the German NIS2 Implementation and Cybersecurity Strengthening Act specifies the obligation for around 29,500 affected companies. Patch management is no longer a technical IT discipline, but a governance task that requires documentation, the effectiveness of which is checked by the BSI in the audit and failure to do so leads to fines of up to 10 million euros or 2 percent of global group sales.

This guide shows how you can set up a patch management process that meets NIS-2 and ISO/IEC 27001:2022 Annex A 8.8 at the same time. You receive concrete SLA windows, a role matrix from the information security officer to the asset owner, a sample escalation path for critical vulnerabilities with a CVSS score of 9.0 and higher, and an evidence structure that is equally viable in the BSI audit, the ISO surveillance audit and the management reporting line. The post concludes with a 30-60-90 day plan to move an existing patching process to NIS-2. At the same time, we show where a workspace with versioning and audit mode replaces manual maintenance and how the reporting line to management can be implemented as a repeatable quarterly report.

Art. 21 NIS-2 lists ten minimum cybersecurity risk management measures. Lit. e explicitly mentions measures for vulnerability management and disclosure. Letter f requires measures to assess effectiveness. Lit. h calls for basic cyber hygiene and training. Patch management addresses at least three of these points simultaneously because an effective process includes both the detection, assessment and remediation of vulnerabilities, with management oversight. Management liability is expressly anchored in Art. 20 NIS-2 and affects the board and management personally.

The BSI has clearly formulated in its sector-specific details that a documented process, an asset inventory and defined SLA windows are minimum components. An Excel list with patch status and a ticket system without role documentation are not enough. What is required is a written patch policy, a risk classification per asset, a documented vulnerability assessment procedure according to CVSS and a reporting line to the information security officer and management. The fine framework distinguishes between essential institutions with up to 10 million euros or 2 percent of group turnover and important institutions with up to 7 million euros or 1.4 percent of group turnover. In addition, the BSI has the authority to issue orders and prohibitions, which in the event of a recurrence can also have a serious impact on operational business if patches are systematically missing. To clarify, NIS-2 covers 18 sectors, from energy and transport to financial markets and health to digital infrastructure, ICT services and food production. The threshold values ​​for medium-sized companies with 50 employees or more and a turnover of 10 million euros apply regardless of the previous KRITIS classification, so that many companies fall into the regulated area for the first time without historically maintaining a BSI relationship, which makes the development of a documented patching practice particularly urgent.

ISO/IEC 27001:2022 was published on October 25, 2022 and completely replaces the 2013 edition as of October 31, 2025. Annex A 8.8 is entitled Management of technical vulnerabilities and requires a documented process for the timely identification, assessment and treatment of technical vulnerabilities. The control owner is typically the ISB or an IT security function with a reporting line to the ISB. The standard not only requires the existence of a process, but also its measurable effectiveness, i.e. documented SLAs, measurement of success and corrective measures in the event of deviations.

The bridge between NIS-2 and ISO 27001 is particularly close here. A company that operates ISO 27001 with documented implementation of A.8.8 automatically meets the operational core of the NIS-2 requirements from Article 21 Paragraph 2 Letter e. What is missing is the organisational anchoring: the appointment of the ISB with a reporting line to management, the integration with the NIS-2 24-hour reporting path and the management reporting line. CIVAC automatically maps the 93 controls from ISO/IEC 27001:2022 Annex A to the NIS-2 requirements, so that A.8.8 has a double effect in the platform: once for the ISO surveillance audit, once for the BSI. The appointment certificate, signed, filed, verifiable. The ISB sees the vulnerability status, the open measures and the SLA hits in one view, and the management review receives the same report without any preparation effort. A significant advantage of this double effect: The evaluation of effectiveness in accordance with Article 21 Paragraph 2 Letter f of NIS-2 is possible without additional audit effort because the hit rate per SLA level is kept as a running key figure in the workspace and can be accessed immediately in the surveillance audit. Anyone who sets up a new patch policy today benefits from addressing both sets of rules in parallel, because experience shows that a later separation causes duplication of work and creates inconsistencies that are recorded as findings in the audit.

A reliable patch SLA is based on the CVSS score (Common Vulnerability Scoring System) and the criticality of the asset. A four-stage model has proven successful. Stage 1: Assessment of any new vulnerability within 24 hours of becoming known through the CSIRT or a relevant manufacturer bulletin. Level 2: Emergency patch within 72 hours for CVSS 9.0 or higher (critical) and active exploitation in the open field (zero-day or known active exploitation). Level 3: Patch within 7 days for CVSS 7.0 to 8.9 (high) on critical assets. Level 4: Patch within 30 days for high and 90 days for medium on non-critical assets.

These windows are not a legal requirement, but rather an industry standard based on the BSI situation report recommendations and on the recommendations of the CISA Known Exploited Vulnerabilities Catalog. The crucial point is the documented definition in the company, which is agreed between ISB, asset owner and management. Deadline begins as soon as we become aware of it. Anyone who does not have a documented SLA will be asked in the audit when the last Apache Log4j vulnerability from December 9, 2021 was completely closed and which reporting method applies. A plausible answer can only be found with documented windows, a patch backlog with an escalation workflow and a reporting line to management. The NIS-2 implementation in Germany makes this documentation requirement binding for around 29,500 companies. In practice, it is recommended to differentiate the SLA model per sector and per asset class: An OT system in a production facility has different maintenance windows than a classic office server, and an Internet-exposed web server has a different level of urgency for treatment than an internal back office system. The differentiation is stipulated in the patch policy, approved by management and versioned in the workspace. This creates a reliable basis that is not assessed as arbitrary in the audit, but rather as risk-based.

An NIS 2 compliant patching process distributes responsibility across three clearly separated roles. The information security officer (ISB) is responsible for the process as such: the patch policy, the SLA definition, the escalation channels and the reporting line to management. The asset owner is responsible for the implementation of each system: he decides on maintenance windows, coordinates with operations, and documents tests and rollback procedures. The management is responsible for the supervisory obligation in accordance with Article 20 NIS-2 and Section 130 OWiG: it approves the patch policy, regularly checks the reports and decides in the event of conflicts between IT security and business operations.

In practice, role clarity often fails due to dual functions. The IT manager is appointed ISB and examines his own areas, which violates independence. The asset owner is nominally the department, but operationally a service provider, which delays escalation. Management receives patch reports whose significance they cannot evaluate without context. CIVAC addresses these gaps through a documented appointment certificate for the ISB with termination protection, an asset owner workflow with a dual control principle and a ready-made quarterly management report that presents the most important KPIs: SLA hit rate, open critical vulnerabilities, average patch latency and trend compared to the previous quarter. This creates a reporting system that management can actually use, instead of an Excel list that ends up in the mailbox. Others run compliance like a filing cabinet. We run it like software. The role matrix is ​​complemented by a RACI table that identifies responsible, executing, interviewed and informed for each patch activity. This means that even in group structures with subsidiaries, outsourced IT service providers and platform services shared across the group, it can be clearly demonstrated who made which decision, when it was made and on what data basis. The same table serves as an onboarding document for new asset owners and as audit evidence for the demonstrable separation of responsibility and execution.

Before the first patch there is the asset inventory. Art. 21 NIS-2 requires a risk analysis, which is not possible without complete knowledge of the systems used. ISO/IEC 27001:2022 A.5.9 (Inventory of information and other assets) is the direct equivalent of the standard. A practical inventory lists at least the following attributes for each asset: unique ID, asset class (server, end device, network component, OT component, SaaS), asset owner, criticality (low, medium, high, critical), location, operating system with version, software components used, external accessibility, patch status and last audit deadline.

Classic CMDBs are often incomplete because they cover OT components, shadow IT, SaaS contracts and mobile Only display end devices incompletely. This is not enough for NIS-2. A combined collection of active scans, passive network monitoring and contractual recording of SaaS services is the minimum requirement. CIVAC integrates the asset inventory into the workspace and links it to the vulnerability feeds so that each new vulnerability is automatically mapped to affected assets. This significantly reduces the manual effort involved in vulnerability assessment, and management can answer the question of how many assets with a CVSS 9 vulnerability are currently untreated at the push of a button. This report is the first question in the BSI audit. If you don't have an answer, you have no process, and the BSI documents a significant deviation with the corresponding consequences for management liability. For this reason, before building a full-fledged patching process, we recommend first consolidating the asset inventory in three iterations: once by accounting and procurement, once by active network scans, once by identity provider and SaaS spend. The intersection results in a reliable starting point that is updated quarterly. On this basis, the workspace provides a cumulative view of asset inventory, criticality distribution and patch backlog, which serves as a situation report for management.

The pure CVSS score is not sufficient for patch prioritization. CVSS evaluates the technical severity of a vulnerability, not its actual exploitability in your environment. A CVSS-10 vulnerability in a component that is not internally accessible and does not process sensitive data is less urgent than a CVSS-7 vulnerability in a publicly accessible web server. The NIS-2 requirement for effective risk treatment therefore requires the combination of CVSS, threat intelligence (e.g. CISA KEV, MITER ATT&CK mapping, manufacturer-specific bulletins) and business impact (business process dependency, data classification, regulatory obligations).

A practical assessment method uses a three-dimensional matrix: severity (CVSS), probability (threat intelligence) and damage (business impact). These three dimensions result in a prioritised list that flows into the SLA model from levels 1 to 4. CIVAC comes with a pre-configured assessment matrix that can be customized to individual risk appetite and automatically integrates public feeds such as the NIST National Vulnerability Database and the CISA KEV catalogue. This means that the evaluation logic is documented, comprehensible and can be checked in the audit. Audit-proof, documented, § 130 OWiG-proof. Anyone who carries out the assessment without a documented methodology risks being accused of arbitrary prioritization in the audit and, in the event of damage, being accused of insufficient care on the part of management, which can extend to criminal liability. The evaluation methodology is set out in the patch policy, approved by management and reviewed at least annually. It should also explicitly document how vulnerabilities are dealt with for which there is no CVSS assessment, for example in the case of very new zero-day releases without official scoring, in order to ensure a reproducible decision-making process even in these special cases. A short escalation rule with documented approval from the ISB meets this requirement.

The technical core of patch management lies in the structured procedure from test to rollout to rollback. A proven process includes six steps. First: patch sourcing from a trusted source with signature verification. Second: Test in a pre-production environment with documented test cases and an acceptance criterion per asset class. Third: Approval by the asset owner with four eyes principle. Fourth: Rollout into productive systems with a maintenance window, communication to affected departments and logged implementation. Fifth: Verification that the patch is installed and effective (version check, functional test). Sixth: Rollback plan that can be activated within the first few hours in the event of malfunctions.

The rollback plan is often underestimated, but is relevant to audits. Auditors ask for documented cases where a patch was rolled back, documentation of recovery time, and lessons learned. Anyone who does not document rollback signals an immature understanding of the process. CIVAC integrates these six steps into a patch workflow with timestamp per step, assignee per step, and escalation rules in case of delay. The ISB can see in the dashboard how many patches are in which phase and whether SLA windows are being met. The auditor calls, the evidence is ready. Emergency patches receive an abbreviated process with immediate approval from the ISB or management, documented in the workspace with justification and follow-up measures, so that the chain of evidence remains closed even under time pressure. For emergency patches with potential data protection implications, the workflow is also linked to the Art. 33 GDPR reporting path, because an exploited vulnerability can lead to a data breach that must be reported. Deadline begins as soon as we become aware of it. Both paths run in the same workspace and share evidence collection, so that the CSIRT and the data protection officer work together without media disruption. This interlinking is one of the biggest weak points in the classic setup with separate systems, because escalations arrive with a delay and deadlines collide.

An NIS 2 compliant patching process produces five types of evidence required in the audit. First: the written patch policy with date, version, management approval and defined SLA windows. Second: the asset inventory with current status, criticality and asset owner. Third: the vulnerability assessments of the last 12 months with documented methodology (CVSS plus Threat Intelligence plus Business Impact). Fourth: the patch history with timestamp, SLA hits per vulnerability and justification for deviations. Fifth: the reporting line to management with a quarterly review protocol and documented resolutions.

These five types of evidence can hardly be generated consistently in fragmented systems. Anyone who keeps the policy in SharePoint, the inventory in a CMDB, the assessments in a vulnerability scanner and the patches in the ticket system creates days of search work in the audit, which the auditor rewards with deviation findings. CIVAC bundles all five evidence types in one workspace, with versioning per document and an audit mode that generates an evidence report for a deadline at the push of a button. The appointment certificate, signed, filed, verifiable. In this way, a technical IT task becomes a documented governance process that can withstand the BSI, the ISO auditor and the management equally and which clearly demonstrates the management's supervisory obligation in accordance with Section 130 OWiG. In addition, audit reports can be generated for each reporting date, which, in addition to the mandatory evidence, also include effectiveness reporting with a trend per quarter, which makes the management review significantly more meaningful than a pure activity list. The appointment certificate, signed, filed, verifiable. It is precisely this four-word chain of evidence that makes the difference between a light comment and a robust findings report in the BSI audit.

An existing patch process can be raised to NIS 2 level in 90 days. Days 1 to 30: Create inventory, name asset owner, order or confirm ISB, draft patch policy with defined SLA windows, management briefing. Days 31 to 60: Document assessment methodology, integrate vulnerability feed, make workflow for testing and rollout productive, first internal exercises with a critical vulnerability. Days 61 to 90: Prepare management quarterly report, audit readiness test, documented corrective actions from the first exercise, integration with the NIS-2 24/72 reporting path. The end result is a process that stands up to the BSI and the ISO auditor and that effectively addresses management liability according to Art. 20 NIS-2.

CIVAC accompanies this path as a compliance platform and officer-as-a-service. Licence the workspace for your internal representatives or have our representatives order it. Turn reading into an assignment. Write to us at info@civac.de or book an initial consultation using the contact form on civac.de. In 45 minutes you will receive an honest maturity assessment of your current patching process, a prioritised list of measures and a clear offer for implementation. Others run compliance like a filing cabinet. We run it like software. Anyone who takes this step today will not be the first case in the first BSI audit according to NIS-2, but rather documented proof that supervisory obligations and IT security function in the same architecture. The auditor calls, the evidence is ready. You can take this sentence literally because it describes the end result of a structured 90-day program that can be implemented in many medium-sized structures without additional tool investments beyond the workspace and demonstrably reduces management liability.