ISO/IEC 27031:2025 u praksi — Uvod: od BCMS-a ka IRBC-u (klauzule 5, 6.1–6.3)

ISO/IEC 27031:2025 u praksi — deo 1 od 9

Uvod: od BCMS-a ka IRBC-u

Serija ISO 22301 pratila je kako pivara „Zeleni Hmelj" d.o.o. gradi sistem upravljanja kontinuitetom poslovanja (BCMS) — politiku, BIA matricu, registar rizika, BCP plan za scenario pada SCADA sistema. Ta serija je odgovorila na pitanje šta firma radi kad nešto stane. Ova serija odgovara na uže, tehničko pitanje koje je ostalo otvoreno: kako se to isto obezbeđuje na nivou IT-ja — servera, mreže, aplikacija, cloud usluga — tako da ICT stvarno može da isporuči ono što BCMS obećava poslovnoj strani. To je ICT readiness for business continuity (IRBC), predmet standarda ISO/IEC 27031:2025.

5 — Struktura standarda i mesto IRBC-a u sistemu

ISO/IEC 27031:2025 nije samostalan sistem menadžmenta koji se sertifikuje odvojeno — to je smernica koja objašnjava kako ICT funkcija treba da se uklopi u već postojeći BCMS. Prvi konkretan korak nije pisanje novog dokumenta od nule, nego mapiranje: koji BCMS izlazi već postoje, i šta IRBC od njih nasleđuje.

Primer: Zeleni Hmelj je IRBC formalno pokrenuo kratkom beleškom koja povezuje postojeći BCMS sa novim IRBC radom — bez nje bi svaki naredni tekst serije počinjao od nule.

Zeleni Hmelj d.o.o. — interni dokument IRBC sistema
Beleška o uspostavljanju IRBC-a i vezi sa BCMS-om
Šifra dokumenta: ZH-IRBC-DOC-001 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Dragan Savić Odobrio: Vladimir Nikolić Datum: 03.02.2026.

1. Osnov za uvođenje IRBC-a
BCMS Zelenog Hmelja (uspostavljen 2025, videti seriju ISO 22301 u praksi) identifikovao je proizvodnju piva kao prioritetnu aktivnost sa MTPD od 48 sati i poslovnim RTO od 4 sata za prijem porudžbina. IT sektor do sada nije imao formalan dokument koji pokazuje da li i kako ICT sistemi mogu da ispune te rokove.

2. Nasleđeni ulazi iz BCMS-a

Izvor Dokument Šta IRBC preuzima
BIA matricaZH-BCMS-DOC-004Prioritetne aktivnosti i njihove ICT zavisnosti
Politika kontinuitetaZH-BCMS-DOC-001MTPD od 48h za proizvodnju
BCP plan (scenario SCADA)ZH-BCMS-DOC-011Poslovni RTO od 4h za porudžbine

3. Nosilac IRBC odgovornosti
Dragan Savić, administrator sistema, imenovan je za nosioca IRBC-a. Izveštava direktno direktoru i koordinira sa Jovanom Perić, BCM koordinatorkom, po pitanjima koja utiču na oba sistema.

4. Napomena o dupliranju
Registar rizika IRBC-a (deo 3 ove serije) neće ponavljati BCMS registar rizika — dodaje samo ICT-specifičan sloj detalja za rizike koji su u BCMS registru već označeni kao IT-zavisni.

Status: Usvojen, na snazi od 03.02.2026.

Šta ovo znači u praksi

Ovaj kratak dokument nije formalnost — on je referenca na koju će se pozivati svaki naredni tekst ove serije, isto kao što je Tekst 1 ISO 20000-1 serije bio referenca za svih devet koji su usledili.

6.1 — Rizik prekida: procena po ICT elementu

Standard traži da se rizik prekida ne procenjuje uopšteno ("IT može da otkaže"), nego po konkretnom ICT elementu i konkretnom uzroku. Ovo je prva stvarna tehnička radnja u IRBC uvođenju — popis ICT usluga i njihove izloženosti.

Primer: Dragan je napravio popis tri ključna ICT sistema Zelenog Hmelja i za svaki procenio dominantan uzrok rizika, oslanjajući se na kategorije iz standarda.

Zeleni Hmelj d.o.o. — interni dokument IRBC sistema
Popis ICT elemenata i procena izloženosti prekidu
Šifra dokumenta: ZH-IRBC-DOC-002 Verzija: 1.0 Status: Aktivan
Priprema: Dragan Savić Odobrio: — Datum: 05.02.2026.
ICT element Podržava aktivnost Dominantan uzrok rizika Kontrola dobavljača Napomena
SCADA sistem (variona)Proizvodnja pivaTehnički kvar / ljudska greška u konfiguracijiDelimična — ugovor sa spoljnim konsultantomNema redundantnog PLC kontrolera
Cloud platforma za porudžbinePrijem i obrada porudžbinaLanac snabdevanja — ispad kod cloud provajderaNema — van kontrole firmeSLA ne definiše jasno vreme oporavka
Lokalni ERP serverFinansije, zalihe, nabavkaTehnički kvar (hardver) + odsustvo off-site bekapaPuna — u vlasništvu firmePoslednji test bekapa: nepoznat datum

Zaključak procene: Lokalni ERP server nosi najveći rizik zbog nepostojanja proverenog off-site bekapa — ovo se prenosi kao hitna stavka u deo 4 ove serije (preduslovi za IRBC).

Šta ovo znači u praksi

Popis od tri reda deluje jednostavno, ali upravo je to poenta — dovoljno je konkretan da odmah otkrije rupu (nepostojanje off-site bekapa) koju uopštena izjava tipa "IT rizici su pod kontrolom" nikad ne bi pokazala.

6.2 — Popis kompetencija i uloga

Standard traži da organizacija zna ko šta radi kada dođe do prekida, i da vodi evidenciju kompetencija. Zeleni Hmelj je do sada oslanjao gotovo sve na Dragana i jednog spoljnog konsultanta — sledeći dokument to prvi put formalizuje.

Zeleni Hmelj d.o.o. — interni dokument IRBC sistema
Registar uloga i kompetencija za IRBC
Šifra dokumenta: ZH-IRBC-DOC-003 Verzija: 1.0 Status: Aktivan
Vlasnik dokumenta: Dragan Savić Odobrio: Vladimir Nikolić Datum: 07.02.2026.
Uloga Nosilac Kompetencija / obuka Zavisnost od trećeg lica
Nosilac IRBC-aDragan SavićInterna obuka o BCMS–IRBC vezi, mart 2026 (planirano)Ne
Podrška za SCADA/PLCMiloš Tanasković („AutomatikaPro", spoljni konsultant)Sertifikat proizvođača PLC opreme (2023)Da — ugovor obnavlja se godišnje
Administracija cloud platformeDragan SavićBez formalnog sertifikata — samostalno stečeno znanjeDelimično — eskalacija ka podršci provajdera
BCM koordinacijaJovana PerićInterni BCM koordinator od 2025.Ne

Nalaz: Podrška za SCADA/PLC u potpunosti zavisi od jednog spoljnog konsultanta bez internog backupa znanja — ovo je rizik koji ulazi u registar rizika u delu 3 ove serije.

Šta ovo znači u praksi

Ovakav registar retko ima više od četiri-pet redova u firmi veličine Zelenog Hmelja, ali svaki red koji pokazuje zavisnost od jedne osobe — internog ili spoljnog — auditor će prvi zapaziti, i to je tačno ono što ovaj dokument treba da otkrije, ne sakrije.

6.3 — Ciljevi kontinuiteta prevedeni na IRBC nivo

Poslovni ciljevi kontinuiteta (MTPD 48h, RTO 4h za porudžbine) postavljeni su na nivou BCMS-a. IRBC ih preuzima i postavlja pitanje: da li trenutna ICT arhitektura realno može da ih ispuni? Odgovor se dokumentuje kao formalna procena jaza, ne kao slobodna procena na sastanku.

Zeleni Hmelj d.o.o. — interni dokument IRBC sistema
Procena jaza između poslovnih ciljeva i trenutnog ICT stanja
Šifra dokumenta: ZH-IRBC-DOC-004 Verzija: 1.0 Status: Aktivan
Priprema: Dragan Savić Odobrio: — Datum: 10.02.2026.
ICT usluga Poslovni cilj (iz BCMS-a) Procenjeno trenutno stanje Jaz
Cloud platforma za porudžbineRTO 4hNepoznato — nikad testiranoDa
SCADA sistemPodržava MTPD 48h za proizvodnjuRučni restart, procenjeno 6–10h bez konsultantaDa
Lokalni ERPNije eksplicitno definisan — pretpostavlja se sličan proizvodnjiBekap postoji, poslednji test nepoznatDa

Zaključak: Nijedan od tri ICT elementa trenutno ne može sa sigurnošću da potvrdi ispunjenje poslovnog cilja. Ovo je očekivan nalaz na početku IRBC uvođenja i prosleđuje se Jovani Perić kao ulaz za sledeći kvartalni pregled BCMS-a.

Šta ovo znači u praksi

Ovaj dokument namerno ne rešava ništa — samo imenuje jaz. Rešenje (konkretan RTO/RPO po usluzi, sa realnim brojevima) dolazi tek u delu 4 i 5 ove serije, kada se preduslovi i ciljevi formalno postave. Ovde je poenta da rukovodstvo od prvog dana vidi realno stanje, a ne uverenje da je "IT to nekako rešio".

Sledeći deo serije prelazi na klauzulu 7 — kako se poslovna očekivanja iz BIA analize prevode u formalan popis kritičnih ICT usluga, sa registrom zavisnosti i prvim koracima ka merenju performansi trenutnog stanja.

Comments

Post a Comment

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

  Prvi tekst na blogu InfoSec bez stresa — i pitanje koje sebi postavi skoro svaki vlasnik male ili srednje firme onog trenutka kad prvi put čuje za ovaj standard. Realna situacija Zamislite ovo: firma ima 15 zaposlenih, radi razvoj softvera ili pruža IT usluge, posluje solidno, sve funkcioniše. Onda stigne mejl od velikog klijenta — banke, osiguravajuće kuće ili strane kompanije s kojom se pregovara o saradnji. U prilogu je bezbednosni upitnik, a na dnu jedna rečenica koja pokvari popodne: „Molimo dostavite ISO 27001 sertifikat ili plan implementacije u naredna tri meseca." Ili, druga verzija iste priče: firma konkuriše na tenderu, sve uslove ispunjava — sem jednog. Traži se ISO 27001. Prva reakcija je obično paničan Google upit u stilu „šta je ISO 27001" i „da li mi to stvarno treba", u ponoć, uz osećaj da se upravo otvorila rupa u budžetu i rasporedu koje niko nije planirao. Ako je ovo vaša situacija — ili slutite da bi mogla postati — ovaj tekst je tu da va...
Read more

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

Ova serija od osam članaka provodi vas kroz sve zahteve standarda ISO 22301:2019 — Sistemi upravljanja kontinuitetom poslovanja (BCMS) , klauzulu po klauzulu, na konkretnom praktičnom primeru: fiktivnoj proizvodnoj pivari „Zeleni Hmelj" d.o.o. , sa sopstvenom varionicom, punionicom i hibridnom IT/OT arhitekturom (SCADA/PLC industrijski sistemi, lokalni ERP i cloud servisi — Microsoft 365, cloud backup/DR, SaaS CRM). Umesto apstraktnog prepričavanja teksta standarda, svaki post gradi stvaran, upotrebljiv dokument — politiku, matricu, BIA analizu, BCP plan, zapisnik — kakav bi auditor tražio na sertifikacionoj proveri. Kroz celu seriju provlači se jedan princip: zahtevi kontinuiteta poslovanja dolaze od biznisa ka IT sektoru, a ne obrnuto — proizvodnja i komercijala definišu koliko dugo mogu da izdrže bez svog sistema, a IT/OT sektor sprovodi tehnička rešenja koja taj zahtev ispunjavaju. Sadržaj serije Deo 1 Uvod u BCMS i Klauzula 4 — Kontekst organizacije Razlika BCMS v...
Read more

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)

6.1 – Opšte Standard deli uzroke prekida u nekoliko grupa: prirodni uzroci – požar, poplava. Retki, ali fizički pogađaju celu lokaciju odjednom, ne samo jednu komponentu. tehnički kvarovi – hardver, softver, napajanje, klimatizacija. Najčešća kategorija u praksi, i ona za koju firme obično imaju najviše iskustva. ljudska greška – loše podešen bekap, propust u upravljanju izmenama. Retko ko je namerno kriv, ali posledice su iste kao da jeste. namerna akcija – hakovanje, malver, sabotaža. Ovde je pored oporavka bitna i istraga – ko je i kako ušao. društveni faktori – pandemija, štrajk. Ne pogađaju tehnologiju direktno, nego ljude koji je održavaju. cyber napadi – DoS, DDoS, napadi koji preplave sistem saobraćajem dok ne prestane da radi. lanac snabdevanja – prekid kod cloud provajdera, nejasni bezbednosni uslovi u ugovoru sa dobavljačem. Ovde firma nema direktnu kontrolu, samo ugovor i poverenje. Rizik da IT prestane da radi ima jedan prepoznatljiv obrazac: retko se ...
Read more