ISO/IEC 27001:2022 u praksi — Tretman rizika i Izjava o primenljivosti (klauzula 6.1.3, 6.2)

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

Tretman rizika i Izjava o primenljivosti (SoA)

Registar procene rizika iz prethodnog posta identifikovao je tri rizika Visokog nivoa. Ovaj post pretvara tu procenu u akciju — bira se tretman za svaki rizik, mapiraju se potrebne kontrole naspram Annex A liste, i sastavlja se dokument koji je srce svakog ISO 27001 sertifikacionog audita: Izjava o primenljivosti (Statement of Applicability, SoA).

6.1.3 — Proces tretmana rizika

Standard traži da organizacija odabere odgovarajuće opcije tretmana rizika, odredi potrebne kontrole, uporedi ih sa Annex A listom da proveri da ništa nije izostavljeno, i formuliše plan tretmana koji odobravaju vlasnici rizika. Standardne opcije tretmana su: modifikacija (primena kontrole koja smanjuje rizik), izbegavanje (prestanak aktivnosti koja rizik izaziva), deljenje (npr. osiguranje ili prenos na treću stranu), i prihvatanje (svesno zadržavanje rizika bez dodatne mere).

Kodni Krug d.o.o. — interni dokument ISMS sistema
Plan tretmana rizika — rizici Visokog nivoa
Šifra dokumenta: KK-ISMS-DOC-008 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor
Rizik (iz Posta 3) Opcija tretmana Odabrane kontrole Rezidualni nivo Odobrio vlasnik rizika
Kompromitovan nalog spoljnog developeraModifikacijaObavezna MFA za sve naloge sa pristupom repozitorijumu (A.8.5); politika jakih lozinki (A.5.17); godišnja obuka o prepoznavanju phishing napada (A.6.3)6 — SrednjiDa, 12.02.2026.
Kopiranje produkcionih podataka radi debagovanjaModifikacijaMaskiranje/anonimizacija podataka pre korišćenja u razvojnom okruženju (A.8.11); politika prihvatljive upotrebe podataka (A.5.10)4 — NizakDa, 12.02.2026.
Pogrešna konfiguracija pristupnih prava u cloud okruženjuModifikacijaPrincip najmanjih privilegija kroz IAM politike (A.8.2, A.8.3); periodičan pregled pristupnih prava (A.5.18); automatizovano skeniranje konfiguracije (A.8.9)6 — SrednjiDa, 14.02.2026.

Napomena o rezidualnom riziku: Nijedan od tretmana ne svodi rizik na nulu — cilj je svesno sniziti nivo do prihvatljivog, uz formalno odobrenje vlasnika. Rezidualni rizik od 6 ("Srednji") za kompromitovan nalog i cloud konfiguraciju smatra se prihvatljivim jer dalje mere (npr. potpuna zabrana rada od kuće) nisu srazmerne poslovnoj potrebi firme.

Izjava o primenljivosti (Statement of Applicability)

SoA je dokument koji za svaku od 93 kontrole iz Annex A navodi da li je primenjena, sa obrazloženjem uključenja ili isključenja. Ovo je dokument koji svaki sertifikacioni auditor prvo traži — on pokazuje da je organizacija sistematski razmotrila celu Annex A listu, ne samo one kontrole koje su joj "pale na pamet". Ispod je reprezentativan izvod iz SoA Kodnog Kruga — pun dokument sadrži svih 93 reda.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Izjava o primenljivosti — izvod (13 od 93 kontrole)
Šifra dokumenta: KK-ISMS-DOC-009 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor
Kontrola Naziv Primenjena? Obrazloženje
A.5.9Popis informacija i druge povezane imovineDAVođen kroz interni CMDB alat; obavezan preduslov za procenu rizika iz Posta 3
A.5.10Prihvatljiva upotreba informacija i imovineDAAdresira rizik kopiranja produkcionih podataka; deo tretmana iz ovog posta
A.5.19Bezbednost informacija u odnosima sa dobavljačimaDADirektno relevantno za angažovanje spoljnih developera
A.5.23Bezbednost informacija za korišćenje cloud uslugaDAFirma aktivno koristi AWS i Azure za razvojna/testna okruženja
A.6.3Svest, obrazovanje i obuka o bezbednosti informacijaDADeo tretmana rizika kompromitovanog naloga
A.6.7Rad na daljinuDAHibridni model rada je osnovna karakteristika organizacije (Post 1)
A.7.1Fizički bezbednosni perimetarDAPrimenjuje se na kancelariju u Beogradu
A.7.4Monitoring fizičke bezbednostiNEIsključeno — kancelarija je u zajedničkom poslovnom prostoru sa fizičkim obezbeđenjem zgrade koje ovu kontrolu već pokriva na nivou zgrade
A.8.2Privilegovana prava pristupaDADeo tretmana rizika cloud konfiguracije
A.8.5Bezbedna autentifikacijaDAMFA je obavezna mera iz tretmana rizika kompromitovanog naloga
A.8.11Maskiranje podatakaDADirektna mera tretmana rizika kopiranja produkcionih podataka
A.8.23Veb filtriranjeNEIsključeno — firma ne upravlja centralizovanom mrežnom infrastrukturom za hibridne radne stanice; rizik se pokriva kroz A.6.3 (obuka) i EDR softver na uređajima
A.8.28Bezbedno kodiranjeDAOsnovna delatnost firme je razvoj softvera; direktno relevantno za sve klijentske projekte

Napomena: Kontrola A.7.4 je primer opravdanog isključenja iz Annex A — standard eksplicitno dozvoljava isključenje kontrole ako organizacija dokaže da rizik koji ta kontrola adresira već pokriva druga mera (u ovom slučaju, fizičko obezbeđenje na nivou cele zgrade). Isključenje bez obrazloženja nije prihvatljivo; isključenje sa jasnim, dokumentovanim razlogom jeste.

6.2 — Ciljevi bezbednosti informacija

Standard zahteva merljive ciljeve usklađene sa politikom, koji uzimaju u obzir rezultate procene i tretmana rizika, uz plan koji odgovara na pet pitanja: šta, koji resursi, ko je odgovoran, kada, i kako se rezultat vrednuje.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Registar ciljeva bezbednosti informacija
Šifra dokumenta: KK-ISMS-DOC-010 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor
ID Cilj Merljiv indikator Resursi Odgovoran Rok
SO-01Uvesti obaveznu MFA na svim sistemima sa pristupom klijentskom kodu100% naloga sa aktivnom MFALicence za MFA alat, vreme IT rukovodiocaMenadžer bezbednosti informacijaQ2 tekuće godine
SO-02Uvesti automatizovano maskiranje podataka u razvojnim okruženjima100% aktivnih projekata koristi maskirane podatke umesto sirovih produkcionihAlat za maskiranje podataka, angažovanje developera po projektuTehnički direktorQ3 tekuće godine
SO-03Uspostaviti kvartalni pregled pristupnih prava u cloud okruženjima4 sprovedena pregleda godišnje, sa evidencijom nalazaVreme IT rukovodioca, IAM alatMenadžer bezbednosti informacijaKontinuirano, počev od Q2
SO-04Formalizovati proces oduzimanja pristupa po prestanku angažmanaPristup oduzet u roku od 24h za 100% slučajeva prestanka angažmanaHR checklist, koordinacija sa IT-jemRukovodilac ljudskih resursaQ1 tekuće godine

Svi ciljevi direktno proizlaze iz plana tretmana rizika prikazanog ranije u ovom postu — SO-01 do SO-03 adresiraju tri rizika Visokog nivoa, dok SO-04 adresira rizik Srednjeg nivoa identifikovan u registru procene rizika (Post 3). Ovo je konkretan primer zahteva 6.2 c): ciljevi moraju uzeti u obzir rezultate procene i tretmana rizika, ne mogu biti nezavisno izmišljeni.

6.3 — Planiranje promena

Standard kratko, ali eksplicitno traži da se svaka promena ISMS-a sprovodi planski. Za Kodni Krug, ovo znači da svaki novi klijentski projekat sa specifičnim bezbednosnim zahtevima (npr. projekat za banku sa dodatnim ugovornim obavezama) pokreće proveru da li postojeća procena rizika, SoA i ciljevi i dalje adekvatno pokrivaju firmu, umesto da se nova pravila uvode ad hoc, mimo formalnog ISMS procesa.

Šta sledi

U narednom postu prelazimo na Klauzulu 7.1–7.4 — Podršku sistemu: resurse, matricu kompetencija za tehničke uloge Kodnog Kruga, program podizanja svesti o bezbednosti, i plan internih/eksternih komunikacija.

Коментари

Постави коментар

Популарни постови са овог блога

Š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...
Прикажи све

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 ...
Прикажи све

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...
Прикажи све