What is patch management?
Patch management brings an update into production in a controlled way and shows that the vulnerability is closed afterwards. Which gap is handled and how urgently is decided upstream, in vulnerability management. Without that prioritisation, patch management installs whatever the vendors ship, which is not necessarily what carries the greatest risk.
The starting point is an asset inventory with versions and owners. It also covers embedded libraries, container base images and firmware; an SBOM shows which software components a product contains.
| Step | What happens |
|---|---|
| Monitor | evaluate vendor advisories and warnings from CERTs and authorities |
| Assess | check whether the vulnerable function is in use and reachable |
| Test | check the effect on function and interfaces in a representative environment |
| Approve | decide the change through change management, with a maintenance window and a fallback plan |
| Roll out | distribute in waves, starting with a small group |
| Verify | check that the vulnerable version is gone |
| Document | record the status, exceptions and missed deadlines |
The guide to implementing an ISMS shows how this process fits into a management system.
Which deadlines apply to security patches?
Neither the BSI Act (BSIG) nor DORA prescribes a fixed number of hours. For two groups, however, the rules require deadlines to exist and be met:
| Who | Basis | Requirement |
|---|---|---|
| particularly important entities (besonders wichtige Einrichtungen; "essential entities" in the NIS2 Directive) and important entities | § 30(2) sentence 2 no. 5 BSIG | security in the acquisition, development and maintenance of systems "including management and disclosure of vulnerabilities" (our translation); the provision sets no deadline |
| entities of the types listed in § 30(3) BSIG, such as cloud computing service providers and managed service providers | points 6.6.1 and 6.10.2 of the Annex to Implementing Regulation (EU) 2024/2690 | apply security patches "within a reasonable time after they become available" and test them first; address vulnerabilities identified as critical "without undue delay" |
| financial entities outside the simplified framework under Article 16 DORA | Article 10(4)(d) of Delegated Regulation (EU) 2024/1774 | set deadlines for installing patches, plus an escalation procedure for when a deadline cannot be met |
Under § 28(6) no. 1 BSIG, § 30 BSIG does not apply to financial entities under DORA. Under § 28(5) BSIG, it generally does not apply to telecoms and energy companies covered by §§ 5c to 5e of the Energy Industry Act (EnWG).
Grade your own deadlines by the criticality of the vulnerability and the importance of the system. Article 10(2) of the Delegated Regulation names these criteria for prioritisation: the criticality of the vulnerability, the classification of the affected ICT asset and its risk profile.
How do you check that a patch closed the gap?
A deployment tool reports that a package was installed. The vulnerability is fixed only when the vulnerable version no longer runs, for example because the service was restarted after the update. Check four points after every rollout:
| Check | Expected result | Evidence |
|---|---|---|
| installation status in the deployment tool | "installed" on every system in the rollout | dated status export |
| running version on the system | the service was restarted and reports the fixed version | version query or service start time |
| independent vulnerability scan | the vulnerability is no longer reported | scan report after the rollout |
| functional test | the core business function works | test record with sign-off from the business unit |
Fictional example: for a critical vulnerability in a web server library, the deployment tool reports "installed" on 40 of 40 servers. The scan the next day still finds the vulnerability on 6 servers, because the service was not restarted there. The figures are invented for illustration. The patch level is therefore 34 of 40; for the 6 servers the deadline keeps running, and escalation applies once it is missed.
What applies when a system cannot be patched?
Where vendor approval or certification is missing, as in medical technology, or a legacy application depends on the old version, compensating controls replace the patch. They include network segmentation, strict access restriction, disabling the affected function, upstream filtering and closer monitoring. A named risk owner accepts the remaining residual risk with a justification and a review date. Without that date, the exception becomes permanent.
For entities under § 30(3) BSIG, point 6.6.1(d) of the Implementing Regulation requires additional measures and the acceptance of residual risks in this case. They may decline to apply an available patch under point 6.6.2 only where the disadvantages of applying it outweigh the cybersecurity benefits; the decision must be documented and substantiated.
What does a product's end of support mean?
For a system without security updates there is nothing left to install. Newly discovered vulnerabilities stay open, and the question moves to procurement and lifecycle planning.
The Cyber Resilience Act requires manufacturers of products with digital elements to handle vulnerabilities effectively during the support period. Under Article 13(8) of Regulation (EU) 2024/2847, that period is at least five years, unless the product is expected to be in use for less time. The reporting obligations under Article 14 have applied since 11 September 2026, the remaining obligations apply from 11 December 2027. For products placed on the market before that date, Article 69(3) extends only the reporting obligations; the vulnerability-handling requirements reach them only after a substantial modification.
Record the end of the support period as a date in procurement requirements and in the asset inventory, and plan the replacement before that date.
Patch management in Rizzqo
In Rizzqo, the vulnerability handling requirements of frameworks such as ISO 27001 are attached to servers, databases and network components. The right person confirms per system whether patches are installed on time and uploads the scan report as evidence. If a system cannot be patched, you assess the risk in euros and plan a stopgap, such as isolating the system, as a task.