Regulatorni zahtjev nije sigurnosna kontrola, a dokumentirana politika nije dokaz da se kontrola stvarno provodi. Upravo tu nastaje najveći problem u pripremi za nadzor. Kada organizacija pita kako mapirati sigurnosne kontrole, stvarno traži način da poveže obveze iz propisa s konkretnim procesima, tehnologijama, odgovornim osobama i provjerljivim dokazima.
Mapiranje nije administrativna vježba za reviziju. Dobro izvedeno mapiranje pokazuje upravi gdje su stvarni rizici, CISO-u koje kontrole treba ojačati, a timu za usklađenost što može dokazati bez višednevnog prikupljanja dokumentacije. Za subjekte obuhvaćene Zakonom o kibernetičkoj sigurnosti, Uredbom, ZKS-om ili NIS2 obvezama, to je temelj dokazive i kontinuirane usklađenosti.
Što zapravo znači mapirati sigurnosne kontrole
Mapiranje sigurnosnih kontrola je strukturirano povezivanje četiri elementa: regulatornog ili internog zahtjeva, kontrole kojom se zahtjev ispunjava, vlasnika kontrole i dokaza njezine provedbe. Ako nedostaje bilo koji od tih elemenata, organizacija može imati dobru namjeru, ali ne i pouzdanu osnovu za ocjenu usklađenosti.
Primjer je zahtjev za upravljanje pristupima. On se ne zatvara tvrdnjom da organizacija koristi višefaktorsku autentifikaciju. Potrebno je utvrditi na koje se sustave ona odnosi, postoje li iznimke, tko periodično pregledava prava pristupa, gdje se čuvaju zapisi pregleda i kako se postupa kada se pronađe odstupanje. Jedan zahtjev često traži više povezanih kontrola, a jedna kontrola može pridonositi ispunjenju više zahtjeva.
Ta povezanost je razlog zašto tablice bez jasne metodologije brzo postaju nepouzdane. One mogu sadržavati stotine redaka, ali bez dosljednih oznaka, vlasništva i statusa dokaza ne daju odgovor na ključno pitanje: funkcionira li kontrola u stvarnom poslovnom okruženju?
Počnite od opsega, a ne od kataloga kontrola
Najčešća pogreška je preuzeti generički katalog kontrola i zatim pokušati pronaći mjesto za svaku stavku. U reguliranom okruženju bolji je obrnuti pristup. Prvo odredite opseg: koje usluge, informacijski sustavi, poslovni procesi, lokacije, vanjski dobavljači i kategorije podataka ulaze u procjenu.
Opseg mora odražavati stvarno stanje, ne samo organizacijsku shemu. Ako kritična poslovna usluga ovisi o pružatelju usluga u oblaku, vanjskom SOC-u ili sustavu koji održava treća strana, te ovisnosti pripadaju mapi kontrola. Formalno izdvajanje procesa izvan IT odjela ne uklanja odgovornost organizacije za upravljanje rizikom.
Nakon opsega, zahtjeve razvrstajte prema temama koje odgovaraju načinu rada organizacije: upravljanje rizicima, upravljanje imovinom, identiteti i pristupi, sigurnost mreže i krajnjih uređaja, upravljanje ranjivostima, sigurnosni incidenti, kontinuitet poslovanja, dobavljači, edukacija i nadzor. Takva struktura omogućuje da se regulatorni jezik pretvori u operativna pitanja.
Kako mapirati sigurnosne kontrole u pet radnih koraka
1. Rastavite zahtjev na provjerljive obveze
Širok zahtjev poput upravljanja sigurnosnim incidentima treba rastaviti na obveze koje se mogu provjeriti. To može uključivati postupak prijave, klasifikaciju ozbiljnosti, evidentiranje odluka, eskalaciju, komunikaciju s nadležnim dionicima, naknadnu analizu i testiranje procesa.
Cilj nije umjetno povećati broj kontrola. Cilj je spriječiti da jedna općenita formulacija sakrije više nepokrivenih aktivnosti. Svaka obveza mora biti dovoljno jasna da neovisna osoba može utvrditi postoji li kontrola i postoje li dokazi njezine provedbe.
2. Povežite obvezu s postojećom kontrolom
Tek tada identificirajte što organizacija već radi. Kontrola može biti tehnička, kao što su centralizirano evidentiranje događaja i segmentacija mreže. Može biti procesna, primjerice formalna procjena dobavljača prije ugovaranja. Može biti i upravljačka, poput redovitog izvješćivanja uprave o kibernetičkim rizicima.
Ne pretpostavljajte da naziv dokumenta dokazuje postojanje kontrole. Politika upravljanja pristupom opisuje pravila, ali kontrola je stvarna samo ako se prava dodjeljuju, mijenjaju i ukidaju prema tim pravilima. Zato u mapi jasno razlikujte politiku, postupak, tehničku konfiguraciju, operativnu aktivnost i revizijski trag.
3. Odredite vlasnika i učestalost
Svaka kontrola mora imati imenovanog vlasnika koji razumije njezinu svrhu i može potvrditi njezino stanje. Vlasnik nije nužno osoba koja svakodnevno izvodi aktivnost. Voditelj IT-a može biti vlasnik procesa upravljanja zakrpama, dok operativni tim provodi instalacije, a voditelj sigurnosti nadzire rizike i iznimke.
U mapu unesite i učestalost. Neke se kontrole provode kontinuirano, poput nadzora sigurnosnih događaja. Druge su mjesečne, kvartalne ili godišnje, primjerice pregled privilegiranih računa, test oporavka ili procjena ključnog dobavljača. Bez učestalosti nije moguće procijeniti je li kontrola zakasnila niti planirati prikupljanje dokaza.
4. Vežite dokaz uz svaku tvrdnju
Dokaz mora potvrditi da je kontrola provedena, a ne samo da je zamišljena. Za pregled pristupa to mogu biti zapisnik pregleda, popis pregledanih računa, odobrene korektivne radnje i datum zatvaranja. Za upravljanje ranjivostima to mogu biti izvještaji skeniranja, prioriteti temeljeni na riziku, zapisi o zakrpama i odobrena odstupanja.
Kvaliteta je važnija od količine. Snimka zaslona bez datuma, konteksta ili povezanosti s kontrolom često ima ograničenu revizijsku vrijednost. S druge strane, dosljedno označeni dokazi s vlasnikom, razdobljem važenja i vezom na zahtjev omogućuju brzo i vjerodostojno dokazivanje usklađenosti.
5. Ocijenite dizajn i stvarnu provedbu
Kontrola može biti dobro osmišljena, ali se ne provoditi dosljedno. Može se i redovito provoditi, a da pritom ne pokriva bitan rizik. Zato svaku kontrolu ocjenjujte kroz dva pitanja: je li njezin dizajn primjeren zahtjevu i riziku te postoje li dokazi da djeluje u predviđenoj učestalosti?
Statusi poput “postoji”, “djelomično postoji” i “ne postoji” često nisu dovoljni. Korisnije je zabilježiti konkretnu prazninu: kontrola pokriva interne korisnike, ali ne i račune dobavljača; izvještaji postoje, ali nema formalnog pregleda; plan oporavka je dokumentiran, ali nije testiran. Takvi nalazi neposredno se pretvaraju u plan aktivnosti.
Jedna kontrola, više okvira – bez dvostrukog rada
Organizacije rijetko posluju prema samo jednom okviru. Uz zakonske obveze mogu primjenjivati interne politike, zahtjeve matične grupe, ugovorne obveze kupaca ili norme poput ISO 27001. Zato mapa mora podržati odnos više-na-više: jedna kontrola može biti vezana uz više zahtjeva, a jedan zahtjev uz više kontrola.
To ne znači da sve treba svesti na najniži zajednički nazivnik. Pojedini propisi ili ugovori mogu imati drukčije rokove, pragove prijave, opseg primjene ili očekivanja za dokumentiranje. Zajednička kontrola može se koristiti ponovno, ali specifične obveze moraju ostati vidljive. Inače organizacija dobiva privid pokrivenosti, a u nadzoru otkriva da nedostaje upravo detalj koji je regulatorno presudan.
Dokazi su operativna imovina, ne arhiva
Mnoge organizacije počnu prikupljati dokaze tek kada stigne upit revizora ili najava nadzora. Tada se vrijeme troši na pretraživanje e-pošte, mrežnih diskova, sustava za izdavanje zahtjeva i privatnih mapa zaposlenika. Problem nije samo sporost. U takvom procesu teško je dokazati potpunost, ažurnost i sljedivost.
Učinkovit model upravljanja dokazima veže svaki dokument, zapis ili tehnički izvještaj uz točnu kontrolu, vlasnika i razdoblje. Tako se odmah vidi koji dokaz nedostaje, koji uskoro istječe i koje su neusklađenosti otvorene. AI analiza može ubrzati klasifikaciju dokumentacije i prepoznavanje relevantnih sadržaja, ali stručna odgovornost ostaje na vlasniku kontrole i osobama koje odobravaju procjenu.
Platforme poput ITrevizija.hr taj proces strukturiraju kroz AI vođenu procjenu, upravljanje dokazima, evidentiranje neusklađenosti i plan provedbe aktivnosti. Vrijednost nije u još jednom repozitoriju dokumenata, nego u tome da se iz dokaza može izvesti mjerljiva procjena stanja i dokaziv put do zatvaranja praznina.
Kada detaljnost postaje prepreka
Mapa s previše razina može biti jednako neupotrebljiva kao i mapa bez detalja. Ako se svaka tehnička postavka vodi kao samostalna kontrola, vlasnici gube pregled, a održavanje postaje preskupo. Ako su kontrole preširoke, nije moguće izolirati nedostatak niti dodijeliti jasnu akciju.
Prava razina detalja ovisi o kritičnosti usluge, izloženosti prijetnjama, regulatornim obvezama i zrelosti organizacije. Za kritične sustave ima smisla odvojeno pratiti privilegirane pristupe, zapisivanje aktivnosti, pregled prava i upravljanje iznimkama. Za manje rizične procese dio aktivnosti može biti obuhvaćen jednom, jasno definiranom kontrolom.
Mapiranje sigurnosnih kontrola treba živjeti zajedno s promjenama u poslovanju. Novi dobavljač, migracija u oblak, akvizicija, promjena kritične aplikacije ili sigurnosni incident mogu promijeniti rizike i učiniti postojeću mapu zastarjelom. Zato je najbolji trenutak za početak sada, ali cilj nije jednokratno popunjena matrica. Cilj je da svaka odgovorna osoba u svakom trenutku može pokazati što organizacija kontrolira, kako to dokazuje i što će poduzeti kada dokaz pokaže prazninu.