ISO 27031: Posle prvog kruga – širenje, integracija i godišnji ritam

Prošli tekst je proveo VoxServis kroz šesnaest nedelja za jedan servis – zavisnost identiteta. Ovaj tekst odgovara na pitanje koje neizbežno sledi: dobro, a šta sad sa svime ostalim? Tri teme: kako se ciklus širi na ostale kritične servise, kako IRBC prestaje da bude poseban projekat i postaje deo postojećih ISO 27001 i ISO 22301 procesa, i kako izgleda godina kad program više nije novost nego rutina.

Širenje na sledeće servise

Dobra vest: drugi krug ne traje šesnaest nedelja. Najveći deo prvog ciklusa – imenovanje vlasnika, definisanje praga eskalacije, uspostavljanje šablona za mapiranje i planove – rađen je jednom, za celu firmu, ne za jedan servis. Ono što se ponavlja za svaki novi servis je suštinski faza 2 do faze 5 iz prošlog teksta: BIA i mapiranje, izbor strategije, izgradnja plana, prva vežba. Realno, to skraćuje sledeći ciklus na osam do deset nedelja, a sa iskustvom i još kraće.

Pitanje koje ostaje jeste redosled – koji servis ide sledeći. Odgovor dolazi direktno iz BIA rezultata prvog ciklusa, ne iz abecede ili iz onoga što je tehnički najlakše (četvrti tekst ove serije). Za VoxServis, prirodni sledeći kandidati, na osnovu onoga što smo identifikovali kroz seriju, jesu: API integracija između PBX-a i CRM-a (treći tekst) – tiha zavisnost koja ne pada potpuno, samo degradira funkcionalnost, što je lako da promakne prioritetima; jedina mrežna veza između Beograda i cloud okruženja (treći i deveti tekst) – jedna tanka žica koja nosi previše tereta; i sposobnost samog cloud CRM dobavljača da izdrži istovremenu aktivaciju za više svojih klijenata (deseti tekst, klauzula 10.5) – ovo poslednje ne zahteva tehničku izgradnju sa VoxServis-ove strane, samo formalni upit i evaluaciju dobavljača.

Vredi napomenuti i suprotnu stranu: nisu svi servisi kandidati za pun šesnaestonedeljni (ili čak osmonedeljni) tretman. Za servise nižeg prioriteta, dovoljan je lakši prolaz – kratka BIA procena, familijarizaciona vežba bez pune tehničke investicije, i eksplicitna odluka (klauzula 12) da se ostaje na tom nivou dok se prioritet ne promeni. Trošenje istog napora na svaki servis, bez obzira na uticaj, tačno je greška o kojoj smo pisali u četvrtom tekstu – ravnomerno umesto proporcionalno.

Integracija sa ISO 27001 i ISO 22301

Standard je od samog uvoda jasan po ovom pitanju: IRBC se gradi na postojećim procesima informacione bezbednosti i kontinuiteta poslovanja, ne pored njih. Za firmu koja je već prošla kroz ISO 27001 (i, kako smo pretpostavili kroz ovu seriju, ISO 22301), integracija znači konkretno sledeće:

Risk registar je jedan, ne dva. IRBC rizici – kao što je zavisnost identiteta koju smo pratili kroz celu seriju – ulaze u isti risk registar koji već postoji iz ISO 27001 procesa (šesti tekst, klauzula 6.4), sa istom metodologijom procene, ne u poseban "IRBC risk registar" koji niko sa 27001 strane nikad ne vidi.

Incident klasifikacija je ista. Prag eskalacije koji smo definisali u prvoj nedelji prošlog teksta nadovezuje se na postojeću klasifikaciju incidenata iz ISO 27001 procesa (osmi tekst, klauzula 8.1.1), ne gradi paralelnu skalu ozbiljnosti.

BIA se radi jednom. Ako ISO 22301 proces već ima BIA za poslovne aktivnosti, IRBC BIA rad (faza 2 iz prošlog teksta) razrađuje taj isti BIA na nivo IT servisa, ne ponavlja razgovore sa vlasnicima aktivnosti od nule.

Uloge se preklapaju, ne dupliraju. Vlasnik rizika iz ISO 27001 procesa za dati sistem je često prirodan kandidat i za IRBC odgovornost nad tim sistemom (deseti tekst, klauzula 10.1.3) – nova uloga se dodaje samo tamo gde stvarno nedostaje, ne kao pravilo.

Audit ide zajedno. Godišnji IRBC audit (dvanaesti tekst, klauzula 11.4) može da se zakaže unutar istog ciklusa kao interni audit za ISO 27001, sa auditorima obučenim za oboje – umesto dva odvojena audit kalendara koji troše duplo vremena istih ljudi.

Izjava o primenljivosti dobija sadržaj. Kontrola 5.30 iz ISO/IEC 27002:2022 (šesti tekst ove serije), koja kod većine firmi u Izjavi o primenljivosti stoji kao formalno "primenjena" bez stvarnog sadržaja iza sebe, sad konačno ima na šta da se pozove – dokumentaciju, planove i testove izgrađene kroz ovu seriju.

Za VoxServis, ovo znači da IRBC program koji smo izgradili kroz prošli tekst ne postoji kao šesti odvojeni sistem upravljanja u firmi – uklapa se u iste sastanke, iste registre i iste ljude koji već rade na informacionoj bezbednosti i kontinuitetu poslovanja, samo sa jasnijim, IT-specifičnim slojem koji je do sad nedostajao.

Godišnji ritam

Kad nekoliko servisa prođe kroz ciklus, program prestaje da liči na projekat i počinje da liči na kalendar. Grubo, jedna godina za firmu veličine VoxServis-a mogla bi da izgleda ovako:

• Kontinuirano, kroz celu godinu: svaka veća IT promena (nova usluga, migracija, novi dobavljač, gašenje sistema) prolazi kroz proveru uticaja na IRBC pre puštanja u produkciju (sedmi tekst, klauzula 7.1) – ovo je disciplina, ne događaj sa datumom.
• Kvartalno: pregled statusa jazova iz risk registra – koji su zatvoreni, koji su i dalje svesno prihvaćeni, da li se apetit za rizik promenio (poslednji tekst klauzula-po-klauzula dela, klauzula 12).
• Dva do tri puta godišnje: program vežbi za već pokrivene servise – familijarizacija ili test komponente za servise nižeg prioriteta, integrisan ili uživo test za one najkritičnije, poput identiteta (dvanaesti tekst, klauzula 11.2.5).
• Jednom godišnje: formalni interni audit IRBC-a, po mogućstvu usklađen sa ISO 27001 audit ciklusom (dvanaesti tekst, klauzula 11.4); obnavljanje procene sposobnosti kritičnih dobavljača (deseti tekst, klauzula 10.5); pregled i, po potrebi, ponovno odobrenje IRBC strategija od strane top menadžmenta (poslednji tekst, klauzula 13.2).
• Po potrebi, ali bar jednom godišnje: proširenje na sledeći servis po prioritetu, koristeći skraćeni, osam-do-deset-nedeljni ciklus.

Ono što ovaj ritam čini održivim jeste da nijedan pojedinačan korak nije ogroman – kvartalni pregled jazova traje sat-dva, ne nedelju dana. Teret koji je bio veliki u prvih šesnaest nedelja (uspostavljanje osnove) se ne ponavlja; ono što ostaje je održavanje, koje je po prirodi lakše od izgradnje.

Iskren pogled unazad

Vredi na kraju priznati nešto što smo nagovestili još u četvrtom tekstu: ovaj ritam neće sam sebe održavati bez povremenog spoljnog pritiska koji ISO 27001 sertifikacija prirodno pruža, a IRBC nema. Rešenje nije čekati da se pojavi taj pritisak – rešenje je ono što smo upravo opisali: ugraditi IRBC ritam u iste kalendare i iste sastanke gde već postoji disciplina za ISO 27001 i 22301, tako da IRBC "vozi" na istom spoljnom pritisku koji ti sistemi već imaju, umesto da čeka sopstveni koji nikad neće doći.

Sledeći tekst

Poslednji tekst serije je čeklista za samoprocenu – kratak, praktičan alat kojim firma može sama da proveri gde stoji u odnosu na ono što smo pokrili kroz ovih devetnaest tekstova, bez potrebe da ponovo čita celu seriju da bi znala odakle da počne.