ISO/IEC 27001:2022 u praksi — Operativno sprovođenje i upravljanje rizikom u praksi (klauzula 8.1–8.3)

ISO/IEC 27001:2022 u praksi — deo 7 od 11

Operativno sprovođenje i upravljanje rizikom u praksi

Do sada je Kodni Krug napisao politiku, procenio i tretirao rizik, obezbedio resurse i kontrolisao dokumentaciju — sve to na papiru. Klauzula 8 postavlja pitanje koje razdvaja formalno usaglašen ISMS od stvarno funkcionalnog: da li se sve to zaista sprovodi u svakodnevnom radu, ponavlja u redovnim ciklusima, i kontroliše i kod dobavljača na koje se firma oslanja?

8.1 — Operativno planiranje i kontrola

Standard zahteva da organizacija planira, primenjuje i kontroliše procese potrebne za ispunjenje zahteva i sprovođenje akcija određenih u Klauzuli 6, uspostavljajući kriterijume za procese i kontrolišući ih u skladu sa tim kriterijumima. Takođe zahteva kontrolu planiranih promena, pregled posledica nenamernih promena, i — posebno relevantno za Kodni Krug — kontrolu nad eksterno pruženim procesima, proizvodima ili uslugama relevantnim za ISMS.

Za IT konsultantsku firmu koja svakodnevno radi sa AWS-om, Azure-om i spoljnim developerima, ovaj poslednji zahtev nije apstraktan — to je pitanje da li firma zna šta se dešava sa njenim rizikom kada deo odgovornosti leži van njenih zidova.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Kontrola eksterno pruženih procesa relevantnih za ISMS
Šifra dokumenta: KK-ISMS-DOC-015 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor
Eksterni proces/usluga Dobavljač Mehanizam kontrole Učestalost provere
Cloud infrastruktura (razvojna/testna okruženja)AWS, Microsoft AzurePregled shared responsibility modela; provera sertifikata provajdera (ISO 27001, SOC 2)Godišnje, pri obnavljanju ugovora
Angažovanje spoljnih developeraIndividualni ugovarači po projektuUgovor o poverljivosti (NDA); klauzula o bezbednosnim obavezama; obavezna uvodna obuka pre pristupaPri svakom novom angažmanu
Alat za upravljanje projektima/tiketima (SaaS)Treći dobavljač (SaaS platforma)Provera DPA (Data Processing Agreement) i lokacije skladištenja podatakaGodišnje
Email i produktivnost (Microsoft 365)MicrosoftPregled SLA i bezbednosnih podešavanja (MFA, DLP politike)Godišnje

Napomena o shared responsibility modelu: Kod cloud provajdera, AWS i Azure garantuju bezbednost same infrastrukture (fizički centri podataka, mrežni sloj), dok Kodni Krug ostaje odgovoran za bezbednu konfiguraciju sopstvenih resursa unutar tih platformi — tačno rizik identifikovan u Postu 3 ("pogrešna konfiguracija pristupnih prava u cloud okruženju"). Ova podela odgovornosti mora biti eksplicitno razumljena, ne pretpostavljena.

8.2 — Periodična procena rizika

Standard zahteva da se procena rizika sprovodi u planiranim intervalima ili kada se predlažu ili dešavaju značajne promene, koristeći iste kriterijume uspostavljene u 6.1.2 a). Ovo nije jednokratan zadatak sa kojim se Post 3 završava — to je ciklus koji se ponavlja.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Plan ciklusa procene rizika i okidača za vanrednu procenu
Šifra dokumenta: KK-ISMS-DOC-016 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor

Redovan ciklus: Puna procena rizika (svih kategorija imovine iz obima ISMS-a) sprovodi se jednom godišnje, pre godišnjeg preispitivanja od strane rukovodstva (Post 10). Rizici klasifikovani kao Visok nivo dodatno se preispituju kvartalno radi provere da li je tretman i dalje efikasan.

Okidači za vanrednu procenu (van redovnog ciklusa):

  • Početak novog klijentskog projekta sa pristupom novoj kategoriji podataka (npr. prvi projekat za klijenta iz finansijskog sektora)
  • Promena cloud arhitekture (npr. uvođenje nove usluge unutar AWS/Azure naloga)
  • Bezbednosni incident, bez obzira na njegovu težinu
  • Značajna promena u broju ili strukturi angažovanih spoljnih developera
  • Nalaz internog ili eksternog audita koji ukazuje na neidentifikovan rizik

Odgovornost: Menadžer bezbednosti informacija inicira procenu; vođe projekata i Tehnički direktor učestvuju kao izvor konteksta za rizike specifične za njihov domen, u skladu sa matricom vlasništva rizika iz Posta 3.

8.3 — Sprovođenje tretmana rizika

Standard zahteva da se plan tretmana rizika (Post 4) zaista primeni, uz dokumentovanu evidenciju rezultata — ne samo da postoji kao odobren plan. Za Kodni Krug, praćenje sprovođenja izgleda ovako, direktno nastavljajući na Plan tretmana rizika izrađen u Postu 4:

Kodni Krug d.o.o. — interni dokument ISMS sistema
Praćenje sprovođenja tretmana rizika — status
Šifra dokumenta: KK-ISMS-DOC-017 Dopuna uz: KK-ISMS-DOC-008 Status: U toku
Mera tretmana Status implementacije Dokaz sprovođenja Datum
Obavezna MFA za pristup repozitorijumu (A.8.5)ImplementiranoIzveštaj IAM alata — 100% naloga sa aktivnom MFA18.03.2026.
Maskiranje produkcionih podataka u razvoju (A.8.11)U toku — 2 od 5 aktivnih projekataInterna evidencija po projektuCilj: kraj Q3
Princip najmanjih privilegija u cloud IAM (A.8.2, A.8.3)ImplementiranoPrvi kvartalni pregled pristupnih prava sproveden 22.03.2026.22.03.2026.
Godišnja obuka o phishing prepoznavanju (A.6.3)ImplementiranoEvidencija učešća — 34/35 zaposlenih (1 na bolovanju, zakazano naknadno)15.03.2026.

Nalaz: Mera maskiranja podataka kasni u odnosu na plan (Post 4 je predvideo Q3 kao rok, trenutno na dobrom putu ali sa samo dva od pet projekata pokrivena do sredine perioda) — ovo se prati kao redovna stavka na sledećem kvartalnom sastanku sa rukovodstvom, u skladu sa komunikacionim planom iz Posta 5.

Zašto se ovo prati odvojeno od Plana tretmana

Plan tretmana rizika (Post 4) je odluka — šta se radi i ko odobrava. Praćenje sprovođenja je dokaz da se ta odluka zaista izvršava, korak po korak, sa realnim statusom koji uključuje i kašnjenja. Auditor koji vidi da jedna mera kasni, ali je to transparentno evidentirano sa novim ciljnim datumom, vidi zdrav sistem — mnogo zdraviji od dokumenta koji tvrdi da je "sve implementirano" bez ikakvog datiranog dokaza.

Šta sledi

Naredna dva posta prelaze na Annex A kroz konkretne scenarije — Post 8 pokriva organizacione i ljudske kontrole (screening, obuka, disciplinski postupak, rad na daljinu), a Post 9 fizičku i tehničku zaštitu (pristup, enkripcija, bekap, logovanje, dobavljači) — pokazujući kako izgledaju kada nisu samo redovi u SoA tabeli, već stvarno sprovedene mere u svakodnevnom radu Kodnog Kruga.

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