ISO 22301 – Klauzula 8.4: Planovi i procedure kontinuiteta poslovanja

U jednoj rečenici: ovde se sve što ste do sada uradili — BIA, procena rizika, odabrane strategije — konačno pretvara u konkretan, operativan dokument koji jasno kaže ko, šta, kada i kojim redosledom radi u trenutku krize.

Šta klauzula zapravo traži

Klauzula 8.4 ima tri međusobno povezana dela. Prvo, organizacija treba da uspostavi strukturu odgovora — dovoljno ljudi sa jasnom odgovornošću, ovlašćenjem i kompetencijom, koja je uključena pre, tokom i posle incidenta, ne samo u trenutku kad se nešto desi. Drugo, potrebne su procedure za upozorenje i komunikaciju — kako se incident otkriva i prati, i kako se komunicira sa svima koji treba da budu obavešteni. Treće, i najkonkretnije, organizacija treba da izradi i održava same planove i procedure koji sadrže: svrhu i obuhvat, ciljeve, uloge i odgovornosti, plan komunikacije, konkretne korake koje treba preduzeti, potrebne resurse, i proces beleženja odluka koje se donose tokom incidenta.

Zašto je ovo bitno

Sve što je urađeno u prethodnim koracima — BIA, procena rizika, strategije — ostaje analiza dok se ne pretoči u dokument koji neko realno može da otvori u trenutku panike i prati korak po korak. Razlika između dobrog i lošeg plana često nije u sadržaju analize iza njega, nego u tome da li je plan pisan tako da ga neko pod stresom, u tri ujutru, može da sledi bez dodatnog razmišljanja.

Detaljan primer: kompletan plan za oporavak ERP sistema

Umesto da opisujemo plan uopšteno, evo kako izgleda stvaran plan koji je Elektrotehna napravila za ERP sistem, sastavljen od svega što smo pratili kroz prethodne tekstove serije.

Svrha i obuhvat

Ovaj plan pokriva oporavak ERP sistema (moduli proizvodnje, fakturisanja i skladištenja) u slučaju nedostupnosti usled kvara hardvera, softverske greške ili sajber napada. Ne pokriva planirano održavanje sistema, koje se sprovodi po odvojenoj proceduri.

Ciljevi

RTO: 8 sati. RPO: 4 sata (maksimalan gubitak podataka od poslednje sinhronizacije).

Uloge i odgovornosti

• Vlasnik plana: IT menadžer (zamenik: viši IT administrator)
• Ovlašćen da aktivira plan: IT menadžer u radno vreme; dežurni menadžer smene van radnog vremena, sa ovlašćenjem da samostalno pokrene prvi krug poziva bez čekanja na potvrdu (uspostavljeno u klauzuli 5.3)
• Rukovodilac krizom za ovaj incident: operativni direktor, obaveštava se odmah po aktivaciji

Okidač za aktivaciju

Plan se aktivira kad je ERP sistem nedostupan duže od 30 minuta bez jasno utvrđenog uzroka i procenjenog vremena rešavanja. Kraći prekidi (do 30 minuta) tretiraju se kao redovan tehnički incident, ne kao aktivacija BCM plana.

Koraci — prvih 30 minuta

1. IT administrator koji primeti ili bude obavešten o nedostupnosti sistema odmah proverava uzrok (hardver, mreža, softver, sumnja na napad).
2. Ako se uzrok ne razreši u roku od 30 minuta, IT menadžer (ili dežurni menadžer smene van radnog vremena) proglašava aktivaciju plana i obaveštava operativnog direktora i BCM koordinatora.
3. Šalje se interno obaveštenje putem Viber grupe šefova smena (kanal uspostavljen u klauzuli 7.4, nezavisan od mejl sistema koji može biti nedostupan).

Koraci — prva 4 sata

4. IT tim pokreće postupak vraćanja iz lokalnog backup servera (strategija odabrana u klauzuli 8.3), po pisanoj i ranije testiranoj proceduri.
5. Magacin prelazi na papirnu proceduru za evidentiranje otpreme (uspostavljenu posle ranijeg incidenta, klauzula 7.3).
6. Ako se do kraja ovog perioda ne vidi jasan napredak u oporavku, IT menadžer obaveštava operativnog direktora o riziku premašivanja RTO-a od 8 sati.

Koraci — do isteka 8 sati (RTO)

7. Sistem se vraća u funkciju, uz proveru integriteta podataka (poređenje sa poslednjom poznatom ispravnom tačkom, u skladu sa RPO ciljem od 4 sata).
8. Komercijalni direktor, ako je rok od 8 sati premašen ili se to očekuje, aktivira pripremljen šablon poruke za ključne klijente (klauzula 7.4).

Ako se RTO premaši (posle 8 sati)

Eskalacija na generalnog direktora, aktivacija punog kriznog tima (klauzula 5.3), i razmatranje dodatnih mera (na primer, angažovanje spoljne IT podrške specijalizovane za hitne intervencije, ako interni tim ne uspeva da reši problem).

Procedura povratka na normalno stanje (stand-down)

Pre nego što se incident zvanično zatvori: potvrditi da sistem radi stabilno bar 2 sata bez novih grešaka, uporediti ručno unete podatke iz magacina sa sistemom i uskladiti razlike, obavestiti sve strane da je incident završen (istim kanalima kojima je najavljena aktivacija), i zakazati kratak sastanak u roku od nedelju dana za pregled incidenta — šta je dobro funkcionisalo, šta nije, i da li plan treba izmeniti (ovo se direktno nadovezuje na kontrolu promena iz klauzule 8.1 i preispitivanje iz klauzule 9.3).

Struktura odgovora — angažovanje pre, tokom i posle incidenta

Standard posebno naglašava da struktura odgovora mora biti uključena ne samo tokom incidenta, nego i pre i posle njega. Kod Elektrotehne, to znači: pre incidenta, krizni tim i vlasnici planova redovno učestvuju u vežbama (klauzula 8.5) i obukama (7.2), tako da im uloge nisu strane kad zaista zatreba. Tokom incidenta, uloge iz plana se sprovode kako je opisano gore. Posle incidenta, isti ljudi učestvuju u pregledu — što je razlika između plana koji se koristi jednom i baci, i sistema koji uči iz svakog incidenta.

Otkrivanje i praćenje incidenta

Pre nego što se plan uopšte može aktivirati, neko mora prvi da primeti da postoji problem. Elektrotehna kombinuje dva mehanizma: automatsko praćenje (IT sistem šalje upozorenje ako server ne odgovara duže od nekoliko minuta) i ljudsko praćenje (zaposleni obučeni, kroz program svesti iz klauzule 7.3, da prijave neuobičajeno ponašanje sistema umesto da čekaju i nadaju se da će se samo rešiti). Oba mehanizma vode ka istoj tački — proveri uzroka u prvih 30 minuta, opisanoj gore.

Smernice za dokumentaciju

Plan treba da bude kratak i akcioni — lista koraka sa jasnim vremenskim okvirima, ne esej. Najbolji test dobrog plana: da li neko ko ga nikad ranije nije video, pod stresom, može da ga prati bez dodatnih pitanja. Svaki plan se čuva u centralnom registru (klauzula 7.5), sa dostupnom papirnom kopijom, i povezan je sa strategijom (8.3) i ciljevima (6.2) iz kojih proizlazi, tako da je jasno zašto su baš ovi koraci, a ne neki drugi, odabrani.

Najčešća greška

Najčešća greška je plan pisan kao opširan narativni dokument umesto kao jasna, akciona lista koraka — pod stresom, niko nema vremena da čita pasuse teksta tražeći šta tačno treba da uradi. Druga česta greška je izostavljanje procedure povratka na normalno stanje — firme detaljno planiraju kako da odgovore na krizu, ali zaborave da definišu kako se zvanično zatvara incident, pa se sistem vrati u pogon bez provere integriteta podataka ili bez pregleda šta je naučeno, čime se gubi prilika da se plan unapredi za sledeći put.