ar man reikia mūsų atsakymo planą kaip dokumentą siųsti klientui

Dažniausiai ne visą dokumentą, o pagrindinius duomenis

Ne, daugeliu atvejų pilnas incidento reagavimo planas nebūtina keliamas kaip priedas. Portalai, kurie klausia apie incidento reagavimą — kuris yra procedūrą saugumo incidentams tvarkyti — dažniausiai nori žinoti ar ar yra procedūra, kas yra atsakingas ir per kiek laiko incidentas yra pakeltas ir praneštas. Tai klausimai, kuriuos atsakai taip/ne ir trumpu paaiškinimu, o ne su visu veikimo planu, įskaitant kontaktų medžius ir sistemos pavadinimus.

Yra dvi situacijos, kai priedas iš tiesų prašomas: jei klientas aiškiai nurodė "keliame jūsų incidento reagavimo planą" kaip klausimo tipą, arba jei tai yra audito klausimynas, kuriame reikalaujami įrodymai. Tokiu atveju santrauka — vienas puslapis su apimtimi, vaidmenimis, pranešimo terminais ir eskalacijos keliais, be jautrios techninės informacijos — dažnai pakanka. Ar reikalingas pilnas planas ar santrauka, matyti iš pačio klausimo teksto; jei jame yra "aprašykite" vietoj "keliame", tekstinis atsakymas yra tinkamesnis nei priedas.

Kodėl toks skirtumas egzistuoja: Direktyvos NIS2 21 straipsnio 2 dalis

Direktyvos NIS2 21 straipsnio 2 dalyje incidentų tvarkymas nurodytas kaip viena iš dešimties privalomų priemonių, tačiau nenurodyta dokumentų forma — direktyva reikalauja proceso, o ne konkretaus įkėlimo formato. ISO/IEC 27001 Priedas A tai plėtoja į valdymo priemones, susijusias su atsakymu ir atsigavimu, ir jūs matote tą patį modelį: standartas tikrina, ar procesas egzistuoja ir veikia, o ne tai, ar yra vienas aiškiai apibrėžtas dokumentas, vadinamas „incidentų reagavimo planu". Tai paaiškina, kodėl daugelis portalų yra patenkinti aprašymu atsakymo lauke, ir kodėl priedas yra būtinas tik tada, kai klausimas tai tiesiogiai reikalauja. Jei dar nesutvarkei proceso, dažnai lengviau pirmiausia rizikos analizės ir informacijos saugumo politikos sutvarkyti — incidentų atsakas paprastai remiantis tuo remiasi.