ISO 27031: Rizik, incidenti i BCM strategija kao okvir za IRBC (klauzula 6.4–6.6)

6.4 – Upravljanje rizikom i kontrole za IRBC

Rizik gubitka dostupnosti se ne procenjuje odvojeno – ide kroz isti proces upravljanja rizikom koji firma već koristi za bezbednost informacija. Tretman tog rizika mora da uključi konkretne kontrole kontinuiteta, ne samo unos u tabelu. Standard ovde direktno povezuje IRBC sa kontrolom 5.30 "IT spremnost za kontinuitet poslovanja" iz ISO/IEC 27002:2022.

Ono što ovaj rizik izdvaja od drugih: mala verovatnoća, veliki uticaj, i lako se potcenjuje baš zato što se retko dešava. Bez direktne veze sa kontrolom 5.30, IRBC ostaje odvojen dokument koji nema oslonac u formalnom sistemu upravljanja rizikom – lep na papiru, ali nepovezan sa onim što firma već radi za 27001.

Primer: Ako je VoxServis prošao kroz 27001, kontrola 5.30 "IT spremnost za kontinuitet poslovanja" već stoji u njihovoj Izjavi o primenljivosti, pod tim tačnim nazivom. Problem je što taj naziv dosad nije imao stvaran sadržaj – IRBC je taj koji ga popunjava konkretnim merama.

Šta treba uraditi

• Uzeti spisak sedam kategorija pretnji iz 6.1 i uneti svaku kao imenovan rizik u risk registar – ne kao jednu opštu stavku "IT prekid", nego pojedinačno.
• Za svaki uneti rizik, povezati ga sa konkretnom kontrolom koja ga tretira – najčešće 5.30 iz ISO 27002, ali i drugim relevantnim kontrolama gde je primenljivo.
• Proveriti da li Izjava o primenljivosti već sadrži 5.30 – ako da, ovo je prilika da joj se doda stvaran sadržaj umesto praznog naziva; ako ne, razmotriti da li treba dodati.
• Tretirati ovu vezu kao stalnu, ne kao jednokratnu formalnost – risk registar i IRBC dokumentacija treba da upućuju jedno na drugo, ne da postoje paralelno bez veze.

6.5 – Upravljanje incidentima i veza sa IRBC-om

IRBC se ne aktivira za svaki kvar – samo za one na najvišem nivou ozbiljnosti, retke, ali sa značajnim uticajem. Standard traži jasan trenutak predaje: kad koordinator incidenta prepozna da RTO ili RPO ne mogu da se ispune, čak ni potencijalno, ili da je pogođen bar jedan kritičan poslovni proces, veza sa IRBC odgovornim se uspostavlja odmah, uz pripremljen kanal komunikacije. Kad se kriza reši, odgovornost se vraća nazad koordinatoru, koji piše izveštaj.

Bez tog jasnog trenutka predaje, eskalacija zavisi od procene onoga ko je slučajno na dužnosti u tom trenutku – subjektivno i nepredvidivo, baš u momentu kad brzina najviše znači.

Primer: Kod VoxServis-a, upravo je nedostatak tog jasnog trenutka predaje usporio stvari kad je trebalo odobriti test posle prošlog incidenta – niko nije bio potpuno siguran čija je to odluka, pa se čekalo umesto da se odmah krene.

Šta treba uraditi

• Definisati konkretan prag – koji nivo uticaja (npr. koji RTO/RPO se ne mogu ispuniti, koji poslovni procesi su pogođeni) automatski prebacuje odgovornost sa IT tima na IRBC odgovornog.
• Prag ne sme da zavisi od subjektivne procene dežurnog – mora biti unapred definisan i svima poznat, tako da se aktivira automatski kad se uslov ispuni, bez čekanja na nečiju odluku u trenutku.
• Pripremiti kanal komunikacije unapred – ko koga zove, kojim putem – da se ne gubi vreme na traženje kontakta usred krize.
• Jasno odrediti i trenutak vraćanja odgovornosti nazad koordinatoru, uz obavezu pisanja izveštaja – da se zna kad je kriza zvanično zatvorena, ne samo tehnički rešena.

6.6 – BCM strategije i usklađivanje sa IRBC-om

Pre nego što IRBC uopšte krene da radi, poslovanje bira strategiju za slučaj prekida – to je poslovna odluka, ne tehnička. Standard navodi tri takva izbora: prosto zaustaviti aktivnost na neko vreme i sačekati, za nešto što nije hitno; preseliti rad na drugu lokaciju; ili prebaciti posao na dobavljača ili partnera dok se ne oporavi. Koji god izbor poslovanje napravi, IRBC ga tehnički omogućava – ne bira umesto poslovanja.

Iz toga proizlaze dva moguća ishoda. Ako IRBC može da ispuni RTO/RPO za sve procese, plan kontinuiteta je usklađen. Ako ne može za neke – poslovanje mora da ima način da radi bez IT-a dok se to ne popravi. Tu se prvi put uvodi MBCO: minimalan nivo usluge koji firma mora da održi tokom prekida. Bez ove usklađenosti, firma može da ima IRBC plan koji tehnički "radi", a i dalje ne odgovara onome što je poslovanje stvarno obećalo klijentima.

Primer: Za VoxServis, izbor da se rad preseli na drugu lokaciju znači Beograd → Novi Sad. Ali usklađenost ide dalje od same strategije: ugovor VoxServis-a traži povratak za 30 minuta, dok je tehnički procenjen RTO za identitet dva sata. To nije sitnica – to je razlika između ispunjenog ugovora i penala, i dosad nije bila zapisana nigde gde bi se dva broja videla jedan pored drugog.

Šta treba uraditi

• Za svaku prioritetnu poslovnu aktivnost, staviti poslovni (ugovoreni) RTO i tehnički (realno procenjen) RTO jedan pored drugog, u istoj tabeli ili dokumentu.
• Isto uraditi i za RPO gde je relevantno – koliko podataka ugovor ili klijent očekuju da se ne izgubi, naspram koliko tehnički stvarno može da se garantuje.
• Gde se brojevi ne poklapaju, preneti to menadžmentu kao eksplicitnu odluku – zatvoriti razliku (investicijom, promenom arhitekture) ili je svesno prihvatiti kao rizik, uz razlog zašto.
• Za procese gde IRBC ne može da ispuni RTO/RPO, definisati MBCO – minimalan nivo usluge (npr. rad sa smanjenim kapacitetom, ručni proces) koji poslovanje može da održi dok se IT ne oporavi.
• Ne ostavljati ovu razliku prećutno – dokumentovati je kao deo BCM plana, tako da bude vidljiva pri svakom pregledu ili reviziji.