A security update can wait because nobody wants to interrupt production. Then it waits again because the person who can approve the interruption is unavailable. The technical fix exists, but the business has not made room to install it.
As AI helps researchers find software weaknesses, Norwegian companies need to strengthen the work that turns a finding into protection. My recommendation is to make postponed updates a visible management decision, with a named owner, a temporary response and a date for reconsideration.
A new proposal from Microsoft
On 13 October 2026, Microsoft proposed grouping vulnerabilities by shared questions about the customer’s environment. It calls these experimental groups “risk cohorts”. The aim is to reduce repeated analysis as AI-assisted discovery contributes more findings. They are not official classifications, do not replace individual vulnerability assessment and do not mean one fix covers every item. Microsoft says its Security Update Guide does not currently display the groupings.
The opportunity is practical: spend less time repeatedly describing the same systems and more time getting appropriate fixes installed. The proposal does not establish that any particular Norwegian company is under attack, or that all newly reported weaknesses are equally urgent.
NSM’s notice for the October updates highlights no specific vulnerability but recommends updating as soon as practicable. That is not an all-clear to leave systems unchanged.
The missing decision is often permission to interrupt
Consider a hypothetical Norwegian manufacturer. Its IT provider can update ordinary employee computers automatically. A separate workstation runs the label software used before goods leave the warehouse. Operations keeps postponing its restart because dispatch is busy.
A report saying that most computers are updated can conceal this dependency. A single remaining workstation may be essential to tomorrow’s deliveries. Conversely, a long list of technical findings does not tell the CEO which delivery is affected or what decision is needed.
The provider should establish which updates apply and recommend a response. The operations manager should explain the consequences of a planned interruption and arrange a suitable window. Neither side should assume the other has accepted the risk of waiting.
For this manufacturer, the options might include a short interruption before dispatch starts, a tested spare workstation, or a temporary manual labelling procedure. These are hypothetical options to examine, not substitutes for the technical fix. Some equipment cannot be taken out of service safely without specialist planning.
The cost of delay belongs in the discussion alongside the cost of downtime. A small scheduled interruption can be preferable to an uncontrolled one. But the business should not invent a precise expected loss merely to make the decision look quantitative. State what is known, what remains uncertain and which customer commitments are exposed.
Give every postponement an expiry date
For a material update that cannot proceed, I would ask for a short decision record:
| Record | Question to resolve |
|---|---|
| Affected delivery | Which dispatch process depends on the workstation? |
| Reason for waiting | What prevents installation, and has that obstacle been checked? |
| Temporary protection | What approved restriction reduces exposure while the fix waits? |
| Accountable people | Who performs the work, and who accepts the operational consequences? |
| Next decision | When will installation happen, or when must the exception be reconsidered? |
| Completion evidence | Has the update installed successfully, and can the team print and reconcile a test order? |
This is my proposed management record, not a Microsoft or NSM template. The technical team must decide whether a temporary restriction actually helps with the relevant vulnerability. Moving a device behind another access control is not proof that every attack path has disappeared.
“No installation date” should trigger a decision about repair, replacement, isolation or discontinuing the affected service. It should not become an indefinitely renewable exception because the same busy week keeps arriving.
Automate the ordinary work, inspect the exceptions
NSM’s established advice favours rapid, centrally managed and largely automatic security updates, including software that handles external content. A new assessment method should not create a committee for every routine update.
For a small AS with outsourced IT, a useful arrangement could be agreed automatic updates for standard devices, a tested process for important applications, and direct escalation when installation fails or is postponed. The business needs evidence that devices actually received the update, including machines that were offline and systems outside the provider’s contract.
AI can assist with preparing an update summary or matching an advisory to an inventory. Treat that as a draft to check against current vendor information and the actual devices. A persuasive summary cannot establish that an unrecorded machine does not exist. Avoid giving the summarising tool authority to close exceptions automatically.
Measure whether the approach reduces time spent on administration while improving completed updates. Keep failed installations and unresolved important systems visible. A lower count of open findings is not a success if someone has simply grouped or closed them differently.
What management should bring to the board
Management owns the update process and its operational decisions. The board should challenge persistent exceptions that could materially disrupt the company, including whether resources or old systems make them unavoidable.
A useful escalation is specific: “This dispatch dependency remains unpatched; these temporary measures are in place; replacement requires a decision by this date.” Directors do not need to select individual software updates. They need to know whether management can resolve a recurring exposure within the company’s risk tolerance.
Use the next IT-provider meeting to examine one postponed update from notification through to demonstrated completion. Link the result to clear responsibility for outsourced IT and evidence in the board’s cyber report. Finding more weaknesses can improve security, provided the organisation can act on what it learns.
Sources checked on 15 October 2026. The manufacturer and its operating choices are hypothetical. The proposed decision record and management recommendations are the author’s analysis. NSM guidance is not presented as a new legal obligation for every Norwegian company. The illustration was generated using AI.

