Commission Implementing Regulation 2024/2690 expects in-scope entities to apply security patches within a reasonable time, test them first, check their source and integrity, and add compensating measures when a patch is not applied. An entity may skip a patch where the downsides outweigh the security benefit, but must document and substantiate the reasons.
What point 6.6 requires
The annex to the regulation, point 6.6.1, says patch procedures must be coherent with change management, vulnerability management and risk management. They must ensure that:
- security patches are applied within a reasonable time after they become available;
- patches are tested before they reach production;
- patches come from trusted sources and are checked for integrity;
- additional measures are put in place, and residual risk accepted, where a patch is unavailable or not applied.
Point 6.6.2 is the exception clause. An entity may choose not to apply a patch when the disadvantages outweigh the cybersecurity benefits, but it must "duly document and substantiate" the reasons.
The regulation does not define "reasonable time" in days. That is your policy decision, based on risk.
Writing a patch policy that fits
A short policy usually has these parts:
- Severity classes and target windows, for example faster for vulnerabilities that are known to be exploited.
- Testing step that fits the system, from automated tests to a canary rollout.
- Source rules: vendor repositories or signed packages only, with checksum or signature verification.
- Exception process with the fields below.
- Review cadence for open exceptions.
What an exception record contains
For every skipped or delayed patch, record:
- the system, component and vulnerability;
- why applying the patch is worse than not applying it (for example, an unstable fix or a known outage risk);
- compensating controls, such as network isolation, a virtual patch or tighter monitoring;
- the accepted residual risk and who accepted it;
- an expiry date after which the decision is reviewed.
Without an expiry date an exception becomes permanent by neglect.
Linking patching to the other duties
Point 6.10.2 of the same annex asks that vulnerability handling be compatible with patch, change, risk and incident management, and that critical vulnerabilities be addressed without undue delay. So the same ticket can carry the scan finding, the decision, the change record and the closure date.
A related duty appears in the text of Article 21(4): if an entity finds it does not comply, it must take corrective measures without undue delay. A backlog of old critical findings with no documented decision is the kind of gap that triggers it.
Where tooling helps
Dependency scanning shows which components are affected, and reachability data can show whether the vulnerable code is actually called, which informs the "disadvantages outweigh benefits" judgement. Safeguard's autonomous remediation with fix PRs is off by default and every category starts on Manual, so a human decides what merges.
Click through it at your own pace, or open it full screen.
Quick check
Can I skip a patch because it is inconvenient?
No. The exception applies where the disadvantages outweigh the cybersecurity benefits, and the reasons must be documented and substantiated.
Is there a fixed number of days for critical patches?
Not in this regulation. It says "reasonable time" and "without undue delay" for critical vulnerabilities, so set and document your own targets.
Sources
Last reviewed: 19 October 2026.
