Not everything can be patched right away. How to make a decision you can defend
A municipal water utility in a mid-sized town. A Linux server runs the customer billing system, supplied by an outside company. A scan shows a high-severity vulnerability in a library the system uses. The fix has been available for a week. The billing system supplier replies that they have not yet tested the new library version and cannot guarantee that billing will work after the update. They promise certification in six weeks.
The administrator calls the head of customer service. They agree to wait. The call takes three minutes and nobody writes it down. After six weeks the supplier asks for another four, and a year later an auditor asks why a vulnerability with an available fix stayed open for ten months.
Waiting may well have been the sensible call. The problem is that nobody can show it any more.
What the law says
The Polish National Cybersecurity System Act (KSC), as amended in 2026, requires essential and important entities to run an information security management system. Three of its elements apply directly here.
Article 8(1)(1) covers systematic assessment and management of risk. Article 8(1)(5)(b) requires regular software updates in line with the manufacturer's recommendations, while taking into account an analysis of the update's impact on the security of the service provided and the criticality level of individual updates. Article 8(1)(5)(d) requires prompt action once a vulnerability is noticed, including, where necessary, temporarily restricting incoming network traffic.
My reading: the law does not require installing every fix the moment it is released. It expects that sometimes you have to assess whether the update will harm the service. It does not, however, allow nothing to happen once a vulnerability has been noticed. If the update has to wait, something else should work in the meantime, and someone should be accountable for it. Article 20 of the NIS2 Directive adds that management bodies approve the risk-management measures and oversee their implementation. That does not mean the board signs every operational decision, but it should know who in the company is authorised to make them. (For some public entities and the financial sector the Act sets separate rules; this text describes the general regime of Article 8(1).)
Where the gap is
In most companies the decision to defer an update is made the way it was at the water utility: a call, a chat message, "fine, we'll wait". It lacks four things, and without them it stops being a decision within a few months.
There is no written reason. Six months later nobody remembers whether it was the supplier's certification, the lack of a maintenance window or simply that it was Friday.
Nobody takes the risk on. The administrator should not decide alone that the billing system will run with a vulnerability for two months. That is a risk to how the company operates, so the person responsible for that area should accept it.
There is no review date. "We'll wait until the supplier gets back to us" turns into "we've been waiting for ten months", because nobody has a day in the calendar to ask again.
There is no safeguard for the waiting period. If the update is deferred, what reduces the chance of the vulnerability being exploited? If the answer is "nothing", that is also an answer, but then someone should accept it knowingly.
How to close it
The steps below work in a spreadsheet, a ticketing system or on paper. What matters is that every decision has the same fields and ends up in one place.
1. Record what the decision covers. Which vulnerability, in which package, on which server. Not "the billing library", but a specific item that can later be compared against the scan.
2. Record why the update has to wait. In one concrete sentence: "the billing system supplier has not certified version X; certification date given in writing: 14 December". "No time" is also a reason, but then the problem lies elsewhere, and I wrote about it in the previous part.
3. Record what you do instead. Restricting access to the server to the internal network only, switching off the vulnerable feature, extra monitoring, putting the service behind an additional layer of protection. If nothing can be done, write that down openly: "no compensating controls, risk accepted as is". That is more honest than an empty field, but such an entry does not settle the matter: someone has to assess whether running the system without safeguards is acceptable at all, and the review date should then be as short as possible.
4. Name a risk owner. A person who understands what happens if the vulnerability is exploited and has the authority to decide that the company accepts that risk. At the water utility that is the head of billing or a board member, not the administrator.
5. Set a review date. A short one. The supplier's date plus a few days, not "end of year". Shorter for vulnerabilities known to be exploited in attacks. On the review date someone checks whether the reason still holds and decides again.
6. Separate the request from the approval. The administrator knows the technical side best, so let them prepare the request. Someone else with the right authority should approve it. Two people are not bureaucracy; they are assurance that the decision is not a convenient shortcut for one of them.
7. After the date, the vulnerability returns to normal handling. If nobody has extended the decision, the item is an ordinary backlog item again, counted from the day it was detected, not from the day the decision expired. Otherwise every decision becomes a way to reset the clock.
Such a decision is not the same as stating that a vulnerability does not affect the company because the vulnerable component is not in use. That is a separate case and a separate part.
Where Secvalis helps, and where it does not
A risk acceptance in Secvalis requires a justification, a risk owner, a review date and information on compensating controls. The technical role can submit a request, which the account owner or administrator approves; they can also accept a risk directly.
A valid acceptance excludes an open item from current timeliness measurement, but in a period report it does not erase a deadline breach that occurred before the decision. After the review date it lapses and the item returns to measurement with the deadline counted from detection. The review date is capped by the account limit, 365 days from the decision by default. If the daily digest is enabled, it lists expired acceptances and those about to expire, and the ISO report separately flags accepted vulnerabilities that are in the KEV catalogue or critical. Such an acceptance sets the management report verdict to "Critical": deferring the update may be justified, but for a vulnerability exploited in attacks or a critical one, the board should see it rather than learn about it during an audit. The audit log records decisions, including risk acceptances, and can be exported to CSV. The risk acceptance register is also part of the Evidence Pack.
Secvalis will not judge for you whether a risk is acceptable. It will not check whether the safeguard described in the "compensating controls" field actually works, and it will not implement it. It does not negotiate certification dates with the supplier. The tool makes sure the decision has all its fields, is approved by the right person and stops applying after the review date instead of lasting forever. The content of the decision and the responsibility for it stay with people, and permissions in the tool do not replace the company's own rules on who may make such decisions.
You can see what the risk acceptance register looks like in an evidence bundle in the sample Evidence Pack, and the decision dialog for a vulnerability in the public demo, with no registration.
In the next part: the auditor is coming. What vulnerability management records you can show, and why a plan is not yet evidence.
Sources
Weekly CVE digest
One email a week with newly published vulnerabilities worth knowing about. No account needed.
This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.