En sikkerhetsoppdatering blir utsatt fordi ingen vil avbryte produksjonen. Så blir den utsatt igjen fordi personen som kan godkjenne driftsstansen, ikke er tilgjengelig. Feilen kan rettes, men virksomheten har ikke satt av tid til å gjøre det.
Når KI hjelper forskere med å finne svakheter i programvare, må norske bedrifter også bli bedre til å følge opp funnene. Min anbefaling er å gjøre utsatte oppdateringer til en synlig beslutning i ledelsen, med en ansvarlig person, midlertidige tiltak og en frist for ny vurdering.
Microsoft foreslår å samle vurderingene
13. oktober 2026 foreslo Microsoft å gruppere sårbarheter etter felles spørsmål om kundens systemer. De foreløpige gruppene kalles «risk cohorts». Hensikten er å redusere gjentatt analyse når KI-støttet forskning bidrar med flere funn. Gruppene er ikke offisielle kategorier og erstatter ikke vurderingen av hver sårbarhet. Én rettelse dekker heller ikke nødvendigvis hele gruppen. Microsoft opplyser at gruppene foreløpig ikke vises i Security Update Guide.
Muligheten er konkret: mindre tid på å beskrive de samme systemene om igjen, mer tid på å få nødvendige rettelser på plass. Forslaget dokumenterer verken at en bestemt norsk bedrift er under angrep, eller at alle nye funn haster like mye.
NSMs varsel om oppdateringene i oktober fremhever ingen bestemte sårbarheter, men anbefaler å oppdatere så snart det lar seg gjøre. Det er ikke et klarsignal til å la systemene stå uendret.
Ofte mangler tillatelsen til å avbryte driften
Se for deg en hypotetisk norsk produksjonsbedrift. IT-leverandøren kan oppdatere vanlige medarbeider-PC-er automatisk. En egen arbeidsstasjon kjører etikettprogrammet som brukes før varene forlater lageret. Driftsavdelingen utsetter stadig omstarten fordi det er travelt med utsendingene.
En rapport om at de fleste maskinene er oppdatert, kan skjule denne avhengigheten. Én gjenværende maskin kan være avgjørende for morgendagens leveranser. Samtidig forteller en lang liste med tekniske funn lite om hvilken levering som kan rammes, eller hva daglig leder må ta stilling til.
Leverandøren bør avklare hvilke oppdateringer som gjelder, og anbefale tiltak. Driftslederen bør forklare konsekvensene av en planlagt stans og finne et egnet tidspunkt. Ingen av dem bør anta at den andre har akseptert risikoen ved å vente.
Bedriften kan for eksempel undersøke en kort stans før utsendingene starter, en testet reservemaskin eller midlertidig manuell merking. Dette er hypotetiske alternativer som må vurderes, ikke erstatninger for å rette feilen. Noe utstyr kan ikke tas ut av drift forsvarlig uten planlegging fra fagfolk.
Kostnaden ved å vente må vurderes sammen med kostnaden ved driftsstans. Et kort, planlagt avbrudd kan være å foretrekke fremfor et ukontrollert. Bedriften bør likevel ikke finne på et presist tapsanslag bare for å få vurderingen til å se tallfestet ut. Beskriv det dere vet, hva som er usikkert, og hvilke kundeløfter som kan bli rammet.
Sett en frist for hver utsettelse
Når en viktig oppdatering ikke kan gjennomføres, ville jeg bedt om et kort beslutningsgrunnlag:
| Registrer | Spørsmål til bedriften |
|---|---|
| Berørt leveranse | Hvilken del av utsendingen er avhengig av maskinen? |
| Grunnen til utsettelsen | Hva hindrer installasjonen, og er hindringen undersøkt? |
| Midlertidig beskyttelse | Hvilken godkjent begrensning reduserer eksponeringen mens rettelsen venter? |
| Ansvarlige personer | Hvem gjør arbeidet, og hvem tar stilling til konsekvensene for driften? |
| Neste beslutning | Når skal oppdateringen installeres, eller når må unntaket vurderes på nytt? |
| Bekreftet resultat | Er oppdateringen installert, og kan teamet skrive ut og kontrollere en testordre? |
Dette er mitt forslag til beslutningsgrunnlag, ikke en mal fra Microsoft eller NSM. Fagfolkene må vurdere om et midlertidig tiltak faktisk hjelper mot den aktuelle sårbarheten. En ekstra tilgangskontroll beviser ikke at alle angrepsmuligheter er borte.
Hvis ingen dato kan settes, må noen ta stilling til utbedring, utskifting, isolering eller avvikling av den berørte tjenesten. Utsettelsen bør ikke kunne forlenges i det uendelige fordi det stadig er en travel uke.
Automatiser det vanlige, følg opp unntakene
NSMs etablerte råd er raske, sentralt styrte og mest mulig automatiske sikkerhetsoppdateringer, blant annet av programvare som behandler eksternt innhold. En ny vurderingsmetode bør ikke føre til et møte om hver rutineoppdatering.
For et lite AS med ekstern IT-leverandør kan en nyttig ordning være avtalte automatiske oppdateringer av standardutstyr, en testet fremgangsmåte for viktige programmer og direkte varsling når en installasjon mislykkes eller utsettes. Bedriften trenger dokumentasjon på at oppdateringen faktisk er installert, også på maskiner som har vært frakoblet og systemer som ikke inngår i leverandørens avtale.
KI kan hjelpe med å oppsummere et varsel eller sammenholde det med utstyrsoversikten. Behandle resultatet som et utkast som må kontrolleres mot oppdatert leverandørinformasjon og de faktiske maskinene. En overbevisende oppsummering kan ikke bevise at en uregistrert maskin ikke finnes. Ikke gi verktøyet som oppsummerer, fullmakt til å lukke unntak automatisk.
Undersøk om arbeidsmåten reduserer administrasjon og samtidig gir flere gjennomførte oppdateringer. Hold mislykkede installasjoner og viktige systemer med uløste problemer synlige. Færre åpne funn er ingen gevinst hvis noen bare har gruppert eller lukket dem på en annen måte.
Dette bør ledelsen ta med til styret
Ledelsen har ansvar for oppdateringsarbeidet og beslutningene om drift. Styret bør utfordre vedvarende unntak som kan gi vesentlige avbrudd, blant annet om manglende ressurser eller gamle systemer gjør dem vanskelige å løse.
En nyttig sak er konkret: «Denne avhengigheten i utsendingen er fortsatt ikke oppdatert. Disse midlertidige tiltakene er på plass. Vi trenger en beslutning om utskifting innen denne datoen.» Styret trenger ikke velge hver programvareoppdatering. Det må vite om ledelsen kan få kontroll på et tilbakevendende problem innenfor risikoen selskapet kan akseptere.
Bruk neste møte med IT-leverandøren til å følge én utsatt oppdatering fra varsel til dokumentert gjennomføring. Knytt resultatet til tydelig ansvar når IT er satt ut og dokumentasjon i styrets cyberrapport. Flere funn kan gi bedre sikkerhet, så lenge virksomheten klarer å handle på det den får vite.
Kildene er kontrollert 15. oktober 2026. Produksjonsbedriften og driftsalternativene er hypotetiske. Beslutningsgrunnlaget og ledelsesrådene er forfatterens vurderinger. NSMs veiledning fremstilles ikke som nye lovkrav for alle norske bedrifter. Illustrasjonen er KI-generert.