Najčešći propusti u cyber dokumentaciji rijetko nastaju zato što organizacija nema nijedan dokument. Puno je češći problem to što su politike, procjene rizika, zapisnici, tehnički dokazi i planovi rasuti po mapama, zastarjeli ili međusobno nepovezani. Kada dođe nadzor, incident ili zahtjev uprave za jasnim stanjem usklađenosti, takva dokumentacija ne daje odgovor koji se može provjeriti.
Za subjekte obuhvaćene Zakonom o kibernetičkoj sigurnosti, Uredbom o kibernetičkoj sigurnosti i zahtjevima NIS2 regulative dokumentacija nije administrativni dodatak sigurnosti. Ona je dokaz da uprava upravlja rizicima, da su kontrole određene, da se provode i da organizacija može pokazati njihov rezultat. Razlika između dokumenta koji postoji i dokumenta koji dokazuje provedbu često odlučuje o stvarnoj regulatornoj spremnosti.
1. Politike postoje, ali nisu povezane s praksom
Politika informacijske sigurnosti može biti kvalitetno napisana, odobrena i objavljena, a ipak ne vrijedi mnogo ako zaposlenici, informacijski sustavi i operativni procesi rade drukčije. Tipičan primjer je politika upravljanja pristupima koja propisuje redovitu provjeru korisničkih ovlasti, dok ne postoji zapis o tome kada je provjera provedena, tko ju je odobrio i koje su nepravilnosti uklonjene.
Nadzor ne procjenjuje samo tekst politike. Procjenjuje može li organizacija dokazati njezinu primjenu. Zato svaki ključni zahtjev iz politike treba imati vlasnika, učestalost provedbe, očekivani dokaz i način evidentiranja odstupanja. Ako politika traži periodične sigurnosne kopije, dokaz nisu samo postavke alata, nego i zapisi o uspješnosti kopija, testiranju obnove te postupanje u slučaju neuspjeha.
Previše općenita politika također stvara rizik. Dokument koji kaže da će organizacija poduzeti „odgovarajuće mjere” ne određuje što se konkretno radi, tko je odgovoran i kako se mjeri izvršenje. Općenitost može imati smisla za temeljna načela, ali operativne kontrole moraju biti dovoljno precizne da budu provedive i provjerljive.
2. Procjena rizika ne vodi do odluka
Procjena rizika često se izrađuje kao jednokratna tablica za potrebe projekta, revizije ili certifikacije. Nakon toga ostaje u arhivi, dok se poslovanje mijenja: uvode se novi dobavljači, aplikacije u oblaku, udaljeni pristupi, automatizirani procesi i nove kategorije podataka. Rizik koji je procijenjen prije godinu dana možda više nema istu vjerojatnost ni posljedicu.
Veći propust nastaje kada procjena rizika ne rezultira odlukom. Za svaki značajan rizik treba biti vidljivo hoće li ga organizacija smanjiti, prihvatiti, prenijeti ili izbjeći. Ako se rizik prihvaća, mora biti jasno tko ima ovlast donijeti takvu odluku, na temelju kojih informacija i do kada ona vrijedi.
Dokumentacija rizika treba povezati imovinu, prijetnju, ranjivost, postojeću kontrolu, preostali rizik i plan postupanja. Ne mora svaka organizacija koristiti jednaku metodologiju ni istu skalu ocjenjivanja. Međutim, metodologija mora biti dosljedna, razumljiva upravi i dovoljno stabilna da se rizici mogu uspoređivati kroz vrijeme.
3. Dokazi se prikupljaju tek kada se najavi nadzor
Mnoge organizacije mogu relativno brzo pronaći pravilnike, ugovore i izvješća. Problem nastaje kod operativnih dokaza: zapisnika o testiranju planova kontinuiteta, izvoda iz sustava za upravljanje zakrpama, potvrda o edukacijama, evidencija pregleda pristupa ili zapisa o procjeni dobavljača. Kada se dokazi počnu prikupljati tek na zahtjev, nastaju praznine, dvostruke verzije i nepotrebni pritisak na IT, pravne poslove i vlasnike procesa.
Dokaz mora biti vezan uz konkretnu obvezu ili kontrolu, imati vlasnika i datum te biti zaštićen od neovlaštene izmjene. Snimka zaslona bez konteksta može pomoći, ali sama po sebi često nije dovoljna. Potrebno je znati iz kojeg je sustava preuzeta, na koje razdoblje se odnosi i što zapravo potvrđuje.
Dobra praksa je unaprijed odrediti minimalni skup dokaza za svaku kontrolu te rok njihova osvježavanja. Time se dokumentacija pretvara iz jednokratnog prikupljanja u trajni proces upravljanja usklađenošću.
4. Neusklađenosti se evidentiraju, ali ne zatvaraju
Popis nalaza iz interne revizije, vanjske procjene ili incidenta nije plan poboljšanja. Svaka neusklađenost treba imati opis problema, procjenu utjecaja, odgovornu osobu, rok, korektivnu aktivnost i dokaz zatvaranja. Bez tih elemenata organizacija ne može razlikovati stvarno riješeni problem od aktivnosti koja je samo označena kao dovršena.
Česta je pogreška i zatvaranje nalaza na temelju izrade dokumenta. Ako je nalaz utvrdio da se incidenti ne klasificiraju dosljedno, izrada nove procedure nije sama po sebi korektivna mjera. Treba dokazati da se procedura primjenjuje, da su relevantne osobe upoznate s njom te da zapisi o incidentima pokazuju poboljšanje.
Posebnu pozornost zaslužuju ponavljajući nalazi. Ako se ista slabost vraća iz godine u godinu, uzrok vjerojatno nije nedostatak dokumenta, nego nejasna odgovornost, nedostatak resursa, neprimjeren alat ili neusklađen proces.
5. Uloge uprave i operativnih timova nisu dokumentirane
Kibernetička sigurnost nije isključiva odgovornost IT odjela. Regulatorni okvir stavlja snažan naglasak na upravljačku odgovornost, odlučivanje o rizicima i nadzor nad provedbom mjera. Kada su odgovornosti implicitne, važni zadaci lako ostanu između funkcija: IT očekuje odluku uprave, uprava očekuje preporuku sigurnosnog tima, a vlasnik poslovnog procesa smatra da je riječ o tehničkom pitanju.
Dokumentacija mora jasno odrediti tko odobrava politike, tko procjenjuje rizike, tko upravlja incidentima, tko prati dobavljače i kome se izvještava o stanju usklađenosti. To ne znači da velika organizacija mora stvarati složenu hijerarhiju. Srednji subjekt može imati manji broj osoba s više uloga, ali njihove ovlasti i zamjene moraju biti nedvosmislene.
Zapisnici upravljačkih tijela također su važni. Oni mogu potvrditi da je uprava zaprimila informacije o rizicima, razmotrila prioritetne mjere, odobrila resurse ili prihvatila preostali rizik. Bez tog traga teško je dokazati da je upravljanje sigurnošću stvarno dio upravljačkog procesa.
6. Planovi za incidente i kontinuitet nisu testirani
Plan odgovora na incident koji nikada nije testiran često skriva pretpostavke koje neće izdržati stvarni pritisak. Kontakt osoba možda više ne radi u organizaciji, put eskalacije nije jasan, pristup ključnim sustavima nije dostupan izvan mreže ili komunikacijski predlošci ne uzimaju u obzir regulatorne obveze.
Test ne mora uvijek biti skupa simulacija. Stolna vježba s realnim scenarijem, primjerice kompromitiranim korisničkim računom ili nedostupnošću poslovne aplikacije, može otkriti ozbiljne nedostatke. Ključno je dokumentirati scenarij, sudionike, odluke, vrijeme reakcije, utvrđene slabosti i aktivnosti koje slijede nakon testa.
Isto vrijedi za kontinuitet poslovanja i oporavak od katastrofe. Postojanje sigurnosnih kopija nije dokaz da se poslovanje može obnoviti u prihvatljivom roku. Dokaz nastaje tek kada se obnova testira i kada organizacija može pokazati rezultat.
7. Dobavljači su izvan opsega sigurnosne dokumentacije
Oslanjanje na pružatelje usluga u oblaku, vanjske održavatelje, razvojne partnere i obrađivače podataka mijenja profil rizika organizacije. Ipak, ugovor se često smatra dovoljnim dokazom kontrole. Ugovorna odredba o sigurnosti jest važna, ali ne govori automatski provodi li dobavljač dogovorene mjere.
Potrebna je dokumentirana procjena dobavljača koja odgovara razini rizika. Za kritičnog dobavljača to može uključivati sigurnosne upitnike, potvrde, izvješća, ugovorne obveze prijave incidenata i periodični pregled. Za manje rizične usluge opseg može biti jednostavniji. Cilj nije stvoriti administraciju bez svrhe, nego pokazati da organizacija razumije ovisnosti i upravlja njima razmjerno riziku.
8. Dokumentacija nema vlasnika, verziju ni životni ciklus
Najtiši propust je dokument bez jasnog vlasnika. Nitko tada ne zna tko treba ažurirati politiku nakon promjene sustava, tko potvrđuje važenje procjene rizika ili kada treba povući zastarjelu proceduru. Posljedica su paralelne verzije, dokumenti bez datuma i postupci koji više ne odgovaraju stvarnom stanju.
Svaki ključni dokument treba imati oznaku verzije, datum odobrenja, vlasnika, sljedeći rok pregleda i povezane dokaze. Pregled ne mora uvijek dovesti do izmjene, ali treba ostaviti zapis da je proveden. Kod važnih promjena, kao što su novi ključni sustav, akvizicija, ozbiljan incident ili promjena dobavljača, dokumentaciju treba preispitati prije redovitog roka.
Platforme poput ITrevizija.hr mogu objediniti obveze, dokaze, neusklađenosti i planove provedbe u jedinstven trag koji je spreman za pregled. Vrijednost nije samo u bržem prikupljanju datoteka, nego u povezivanju regulatornog zahtjeva s odgovornom osobom, stvarnim dokazom i mjerljivim statusom aktivnosti.
Krenite od jedne kontrole koja je poslovno važna, primjerice upravljanja pristupima ili odgovora na incidente. Provjerite možete li u nekoliko minuta pokazati važeće pravilo, odgovornu osobu, posljednji dokaz provedbe, otvorene nedostatke i odluku o riziku. Ako odgovor nije potvrdan, upravo ste pronašli prioritet za sljedeći korak prema dokazivoj usklađenosti.