Czy istnieje procedura postępowania w przypadku incydentów bezpieczeństwa?

Obsługa incydentów jest jednym z dziesięciu obowiązkowych środków

Tak, to pytanie dotyczy w szczególności drugiego z dziesięciu środków z artykułu 21 ust. 2 dyrektywy NIS2: "obsługa incydentów" pojawia się dosłownie obok analizy ryzyka jako osobna kategoria. Osoba otrzymująca to pytanie musi nie tylko stwierdzić, że procedura istnieje, ale także wykazać, co w niej zawiera: jak incydent jest zgłaszany, kto go podejmuje, jakie kroki są podejmowane i jak rejestruje się to, co się stało. Procedura bez właściciela lub bez udokumentowanych kroków nie przekonuje audytora, nawet jeśli dokument istnieje.

Konkretnym dowodem jest zwykle opis procesu lub runbook, zawierający klasyfikację incydentów (powaga, wpływ), punkt zgłoszeniowy lub osobę kontaktową, i etap oceny po zakończeniu. Ta ocena nie jest dekoracyjna: bez ustalonego sposobu rejestrowania i przechowywania zdarzeń w systemach, nie ma podstawy do zrekonstruowania incydentu lub wykazania, że został obsłużony. Jeśli procedura jeszcze nie istnieje, to "nie, w opracowaniu" jest bardziej uczciwą odpowiedzią niż wymyślanie procedury, której nie ma — lista pytań pyta o to, co istnieje, a nie o zamiar.

Jak to się wiąże z ciągłością i analizą ryzyka

Artykuł 21 ust. 2 wymienia dziesięć środków jako całość, a obsługa incydentów nie istnieje w izolacji. Incydent dotykający świadczenia usługi często aktywuje punkt dotyczący kopii zapasowych i nadzwyczajnego środka do przywrócenia świadczenia usługi; procedura obsługi incydentów, która nie odnosi się do planu przywrócenia, jest niekompletna. Ponadto obsługa incydentów jest ukoronowaniem polityki analizy ryzyka i bezpieczeństwa systemów informatycznych: analiza ryzyka przewiduje, co może pójść nie tak, obsługa incydentów reguluje, co się dzieje, gdy i tak coś pójdzie nie tak. Klient pytający o procedurę w ten sposób niejawnie sprawdza, czy te dwa elementy na siebie zachodują.