ISO/IEC 27031:2025 u praksi — Strategije za tehnologiju, podatke, procese i dobavljače (klauzula 9.2.4–9.2.7)
ISO/IEC 27031:2025 u praksi — deo 6 od 9
Strategije za tehnologiju, podatke, procese i dobavljače
Prethodni deo je izabrao primarnu i dopunsku strategiju po ICT elementu i pokrio strategiju za prostor. Standard u nastavku klauzule 9.2 traži da se posebno razrade još četiri sloja — tehnološka arhitektura, kontinuitet podataka, procesi koji strategiju čine izvodljivom, i, možda najvažnije za firmu veličine Zelenog Hmelja, formalizacija odnosa sa dobavljačima. Ovaj deo zatvara klauzulu 9 pre nego što serija pređe na sam plan kontinuiteta.
9.2.4 — Tehnološka razmatranja
Standard traži da se pri izboru strategije eksplicitno razmotri niz tehničkih faktora — udaljenost između lokacija, broj lokacija, udaljeni pristup, zahtevi hlađenja i napajanja, nivo automatizacije, i priroda „failback" procesa (da li je povratak na normalno stanje ručan ili automatski). Ovo poslednje je često zanemareno — firme planiraju kako da pređu na rezervni sistem, ali ne i kako se vraćaju nazad.
Primer: za SCADA sistem, Dragan je prvi put eksplicitno dokumentovao da je i failover i failback trenutno potpuno ručan proces.
Šta ovo znači u praksi
Failback je često slepa tačka — firma zna kako da pređe na rezervni sistem pod pritiskom incidenta, ali povratak na normalno stanje se radi improvizovano jer deluje manje hitno. Upravo zato ga standard eksplicitno traži: greška napravljena pri failback-u (npr. gubitak podataka unetih na rezervnom sistemu) može poništiti korist celog oporavka.
9.2.5–9.2.6 — Kontinuitet podataka i procesa
Za podatke, standard traži da se kontinuitet dizajnira tačno prema RPO cilju svake usluge — način skladištenja, lokacija bekapa, i realno vreme potrebno za restore. Za procese, traži se da se identifikuju ključne veštine, kritični podaci i oprema neophodni da strategija uopšte proradi u praksi, ne samo na papiru.
Primer: Zeleni Hmelj je prvi put formalno testirao restore proceduru za ERP bekap — do sada je bekap postojao, ali nikad nije bio proveren da li stvarno radi.
Šta ovo znači u praksi
Ovo je prvi test u seriji koji je prošao bolje nego što je predviđeno — i to je podjednako vredan nalaz kao i otkriveni jaz. Test je takođe otkrio mali, lako rešiv nedostatak (nedokumentovan korak konfiguracije) koji bez testiranja ne bi bio poznat sve do stvarnog incidenta, kada bi svaki izgubljeni minut imao pravu cenu.
9.2.7 — Formalizacija odnosa sa dobavljačima
Standard traži da se ugovori sa dobavljačima eksplicitno pozivaju na IRBC zahteve — obaveze svake strane, dogovoreni nivoi usluge, odgovor na velike incidente, i učestalost testiranja. Do sada, odnos sa AutomatikaPro postojao je kao standardni ugovor o održavanju, bez posebne IRBC klauzule.
Primer: Dragan je pripremio kratak dodatak ugovoru koji AutomatikaPro treba da potpiše, sa jasno navedenim IRBC obavezama.
Šta ovo znači u praksi
Mali dodatak ugovoru od četiri stavke retko nailazi na otpor dobavljača — u ovom slučaju upravo je i to test IRBC zrelosti odnosa: dobavljač koji odbije da potvrdi da više od jedne osobe poznaje sistem klijenta signalizira rizik koji vredi razmotriti pri sledećem obnavljanju ugovora, nezavisno od toga da li dodatak bude potpisan.
Sledeći deo serije prelazi na klauzulu 10 — pretvaranje svih ovih strategija u konkretan ICT plan kontinuiteta: organizacionu strukturu za aktivaciju, vremenski okvir od detekcije do odluke o pokretanju IRBC-a, i plan po komponenti.
Comments
Post a Comment