frågelistan frågar hur snabbt vi implementerar säkerhetuppdateringar

Patchpolicy faller under sårbarhetshantering, inte under incidentrespons

Frågan om uppdaterings- och patchhastighet gäller processen för sårbarhetshantering: hur snabbt signalerar du att en patch är tillgänglig, och hur snabbt rullar du ut den. Det är en annan process än incidenthantering — installation av en patch är förebyggande, hantering av en incident är reaktiv. Kunder frågar ofta om detta separat från varandra i samma lista, och det är klokt att också svara separat: den som blandar sårbarhetshantering med incidenthantering ger ett svar som inte stämmer vid förfrågan.

Konkret bevis för denna fråga är vanligtvis en tidslinje med tidsfrister per riskkategori: kritiska sårbarheter inom X dagar, högt risiko inom Y dagar, och så vidare — plus en logg som visar att dessa tidsfrister faktiskt uppnås. Om du inte dokumenterat detta är "nej" det ärliga svaret på denna fråga, även om patchar i praktiken går tillräckligt snabbt; en odokumenterad vana är ingen påvisbar process. Den motsvarande dossierkomponenten om en process för att identifiera och åtgärda sårbarheter är platsen för att kunna leverera det nästa gång. Observera också frågornas omfattning: vissa portaler frågar detta endast för system som behandlar kunddata, andra för den fullständiga IT-miljön inklusive arbetsstationer — det skiljer ganska mycket i vad du måste kunna visa.

Där det följer från: artikel 21 punkt 2 och Annex A

Artikel 21 punkt 2 i NIS2-direktivet nämner sårbarhetshantering och hantering av bekanta svaga punkter som en av de tio obligatoriska åtgärderna för enheter som omfattas av direktivet; cybersäkerhetsvårdanden genomför detta i nederländsk lagstiftning. Huruvida denna förpliktelse gäller för företaget själv beror på eller om verksamheten omfattas av NIS2-direktivet — men även utan denna förpliktelse frågar en större kund ofta detta ändå, som en del av sin egen kedjebedömning. ISO/IEC 27001 utvecklar detta vidare under kontrollåtgärderna i Annex A, där patchhantering och teknisk sårbarhetshantering återkommer som en separat kontrollpunkt.