ISO/IEC 27001:2022 u praksi — Poboljšanje: neusaglašenosti, korektivne mere i sertifikacija (klauzula 10)

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

Poboljšanje: neusaglašenosti, korektivne mere i sertifikacija — finale serije

Interni audit iz prethodnog posta otkrio je neusaglašenost — pristup spoljnog developera nije oduzet u propisanom roku od 24h. Ovaj poslednji post pokazuje kako se ta neusaglašenost formalno zatvara, čime se zaokružuje PDCA ciklus Kodnog Kruga, i sumira kompletnu dokumentaciju izrađenu kroz seriju.

10.2 — Neusaglašenost i korektivna akcija

Standard zahteva da organizacija, kada dođe do neusaglašenosti, reaguje kontrolom i korekcijom, proceni potrebu za uklanjanjem uzroka kako se neusaglašenost ne bi ponovila, sprovede potrebnu akciju, proveri njenu efikasnost, i po potrebi izmeni ISMS.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Izveštaj o neusaglašenosti i korektivnoj meri (CAPA)
Šifra dokumenta: KK-ISMS-CAPA-2026-01 Izvor: Interni audit KK-ISMS-AUDIT-2026-01 Odgovoran za zatvaranje: IT rukovodilac

1. Opis neusaglašenosti
Pristup Git repozitorijumu za jednog spoljnog developera nije oduzet u propisanom roku od 24h po prestanku angažmana (A.6.5), već tek nakon 72 sata, suprotno Politici pristupa izvornom kodu (KK-ISMS-DOC-023) i cilju SO-04 (KK-ISMS-DOC-010).

2. Neposredna korekcija
Pristup je odmah oduzet po otkrivanju tokom audita; provereno da u periodu kašnjenja nije bilo neovlašćene aktivnosti na nalogu (potvrđeno kroz logove, A.8.15).

3. Analiza uzroka
Zahtev za oduzimanje pristupa poslat je IT rukovodiocu putem običnog e-maila u petak popodne, van radnog vremena, i ostao je nepročitan do ponedeljka. Proces oslanja se na ručnu komunikaciju bez potvrde prijema ili automatskog podsetnika.

4. Provera sličnih slučajeva
Pregledom preostalih slučajeva prestanka angažmana u poslednjih 6 meseci (ukupno 3 slučaja) nije pronađen dodatni slučaj kašnjenja, ali svi su se desili tokom radne nedelje — rizik je specifično povezan sa zahtevima koji stignu van radnog vremena.

5. Korektivna akcija
Uvesti automatizovanu integraciju između HR sistema i IAM alata: označavanje zaposlenog/saradnika kao "neaktivan" u HR sistemu automatski pokreće trenutno oduzimanje pristupa svim sistemima iz obima ISMS-a, nezavisno od radnog vremena ili dostupnosti IT rukovodioca. Ovo je ista mera koju je preispitivanje rukovodstva već odobrilo u prethodnom postu.

6. Rok i odgovorno lice
IT rukovodilac — rok 45 dana od datuma nalaza.

7. Provera efikasnosti
Naredna dva slučaja prestanka angažmana nakon implementacije automatizacije prate se posebno; potvrda efikasnosti na sledećem internom auditu.

8. Potrebne izmene ISMS-a
Da — ažurirati Politiku pristupa izvornom kodu (Post 9) sa opisom automatizovanog procesa, i ukloniti opis ručnog e-mail zahteva iz procedure.

Zašto se ne kažnjava odgovorna osoba, već se menja proces

Primetite da korektivna mera ne uključuje disciplinsku meru prema IT rukovodiocu (za razliku od Disciplinskog postupka opisanog u Postu 8, koji se primenjuje na namerna ili ponovljena kršenja). Analiza uzroka je pokazala da je problem sistemski — proces se oslanjao na ručnu, nepotvrđenu komunikaciju — ne na nemar pojedinca. Standard eksplicitno traži uklanjanje uzroka, ne kažnjavanje simptoma; kažnjavanje osobe bez izmene procesa ne bi sprečilo da se isti scenario ponovi sa drugim zahtevom koji stigne petkom popodne.

10.1 — Stalno poboljšanje

Standard zahteva kontinuirano unapređenje adekvatnosti, prikladnosti i efikasnosti ISMS-a. Za Kodni Krug, ovo nije poseban proces koji se dešava jednom godišnje — to je zbir svega prikazanog kroz ovu seriju: rezultati phishing testova hrane program svesti, nalazi audita pokreću korektivne mere, promene konteksta (novi klijent, nova pretnja) pokreću vanrednu procenu rizika, a sve se jednom godišnje sabira na preispitivanju rukovodstva koje daje pravac za naredni ciklus.

Zaključak serije

Kroz jedanaest postova, Kodni Krug d.o.o. je izgradio kompletan ISMS u skladu sa ISO/IEC 27001:2022 — od konteksta organizacije do zatvorenog PDCA kruga. U nastavku je pregled kompletne dokumentacije izrađene tokom serije:

Oznaka Dokument Post
KK-ISMS-DOC-001Analiza konteksta organizacije1
KK-ISMS-DOC-002Registar zainteresovanih strana1
KK-ISMS-DOC-003Izjava o obimu ISMS-a1
KK-ISMS-DOC-004Politika bezbednosti informacija2
KK-ISMS-DOC-005Odluka o imenovanju i matrica uloga2
KK-ISMS-DOC-006Metodologija procene rizika3
KK-ISMS-DOC-007Registar procene rizika3
KK-ISMS-DOC-008Plan tretmana rizika4
KK-ISMS-DOC-009Izjava o primenljivosti (SoA)4
KK-ISMS-DOC-010Registar ciljeva bezbednosti informacija4
KK-ISMS-DOC-011Matrica kompetencija5
KK-ISMS-DOC-012Program podizanja svesti5
KK-ISMS-DOC-013Plan internih i eksternih komunikacija5
KK-ISMS-DOC-014Registar kontrole dokumenata6
KK-ISMS-DOC-015Kontrola eksterno pruženih procesa7
KK-ISMS-DOC-016Plan ciklusa procene rizika7
KK-ISMS-DOC-017Praćenje sprovođenja tretmana rizika7
KK-ISMS-DOC-018Procedura provere pre angažovanja8
KK-ISMS-DOC-019Izveštaj sa phishing testa8
KK-ISMS-DOC-020Disciplinski postupak8
KK-ISMS-DOC-021Politika bezbednog rada na daljinu8
KK-ISMS-DOC-022Fizička bezbednost kancelarije9
KK-ISMS-DOC-023Politika pristupa izvornom kodu9
KK-ISMS-DOC-024Politika i zapisnik testiranja bekapa9
KK-ISMS-DOC-025Politika logovanja i monitoringa9
KK-ISMS-DOC-026Bezbednosna konfiguracija cloud pristupa9
KK-ISMS-DOC-027Plan monitoringa i merenja performansi10
KK-ISMS-AUDIT-2026-01Plan i nalazi internog audita10
KK-ISMS-MR-2026-01Zapisnik preispitivanja od strane rukovodstva10
KK-ISMS-CAPA-2026-01Izveštaj o korektivnoj meri11

Ovaj set od 30 dokumenata predstavlja realan, upotrebljiv temelj za implementaciju ISMS-a u IT/softverskoj organizaciji koja radi sa klijentskim kodom, podacima i cloud infrastrukturom. Kroz seriju smo pratili jedan dosledan tok: kontekst i politika postavljaju okvir, procena rizika identifikuje šta stvarno preti (kompromitovan nalog, curenje podataka, pogrešna cloud konfiguracija), tretman i Annex A kontrole to konkretno rešavaju, a merenje i audit dokazuju — sa iskrenim priznanjem kašnjenja i jedne stvarne neusaglašenosti — da sistem zaista radi, a ne samo postoji na papiru.

Hvala što ste pratili seriju. Ako gradite ISMS u sopstvenoj organizaciji, ovi obrasci mogu poslužiti kao polazna tačka — uz prilagođavanje stvarnoj veličini, delatnosti i rizicima vaše firme.

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