spørgeskemaet spørger, hvor hurtigt vi udrører sikkerhedsopdateringer

Patchpolitik falder under sårbarhedsstyring, ikke under hændelsessvar

Spørgsmålet om hastigheden af opdateringer og patches vedrører processen for håndtering af sårbarheder: hvor hurtigt signalerer du, at en patch er tilgængelig, og hvor hurtigt udrulles den. Det er en anden proces end hændelsesrespons — installation af en patch er forebyggende, håndtering af en hændelse er reaktiv. Kunder stiller ofte dette spørgsmål uafhængigt af hinanden på samme liste, og det er klogt at besvare det også uafhængigt: hvis man blander håndtering af sårbarheder med hændelsesrespons, giver man et svar, der ved nærmere forespørgsel ikke stemmer.

Konkret bevis for dette spørgsmål er normalt en tidslinje med frister pr. risikokategori: kritiske sårbarheder inden for X dage, høj risiko inden for Y dage, og så videre — plus en logfil, der viser, at disse frister også bliver overholdt. Hvis du ikke har dokumenteret dette, er "nej" det ærlige svar på dette spørgsmål, selvom patches i praksis går hurtigt nok; en udokumenteret skik er ikke en påviselig proces. Den tilhørende dossierdel om en proces for at identificere og afhjælpe sårbarheder er stedet til at kunne levere det næste gang. Bemærk også spørgsmålets omfang: nogle portaler spørger kun herom for systemer, der behandler kundedata, andre for hele it-miljøet inklusive arbejdssteder — det betyder meget for, hvad du skal kunne demonstrere.

Hvor det følger heraf: artikel 21, stk. 2 og Annex A

Artikel 21, stk. 2 i NIS2-direktivet nævner håndtering af sårbarheder og omgangen med opdagede svage punkter som en af ti obligatoriske foranstaltninger for enheder, der er omfattet af direktivet; cybersikkerhedsloven gennemfører dette i dansk lovgivning. Om denne forpligtelse gælder for virksomheden selv, afhænger af eller virksomheden er omfattet af NIS2-direktivet — men også uden denne forpligtelse spørger en større kunde ofte om dette alligevel som led i sin egen kædevurdering. ISO/IEC 27001 udbygger dette under kontrolforanstaltningerne i Annex A, hvor patchstyring og teknisk håndtering af sårbarheder vender tilbage som separate kontrolpunkter.