Kako da poglavlje 4 stvarno zaživi u praksi — šta vam treba da klauzula 4.4 bude realna, ne samo na papiru

Kroz deset primera u prethodnoj mini-seriji, ista šema se ponavljala iz teksta u tekst: incident se dešava, pokreće ažuriranje procene rizika, vodi ka korektivnoj meri, ulazi u obuku. Ta šema deluje jednostavno na papiru — ali pretpostavlja da određena infrastruktura već postoji u firmi. Ovaj tekst se bavi upravo tim pitanjem: šta konkretno treba uvesti da bi ta šema stvarno radila, a ne samo lepo zvučala u tekstu na blogu.

Zašto je ovo pitanje bitno

Klauzula 4.4, o kojoj smo pisali u glavnoj seriji, traži sistem procesa koji se međusobno hrane — ne zbirku odvojenih dokumenata. U praksi, ta veza između procesa ne nastaje sama od sebe samo zato što postoji politika koja kaže da postoji. Ona zahteva par sasvim konkretnih, opipljivih elemenata: način da se problem uopšte primeti i prijavi, mesto gde se to beleži, osobu koja to prati, i redovan trenutak kada se sve to sabere i donesu odluke. Bez tih elemenata, klauzula 4.4 ostaje lepa rečenica u dokumentaciji koju niko zapravo ne primenjuje.

Šta je zapravo potrebno, element po element

1. Jasan, svima poznat kanal za prijavu

Ne treba vam poseban sistem za tiketiranje niti skup softver. Dovoljna je jedna email adresa ili jedan Slack/Teams kanal, pod uslovom da ga baš svi u firmi znaju i da je korišćenje jednostavno. Ključni test: da li bi novozaposleni, posle jedne rečenice objašnjenja, znao gde da prijavi da je, recimo, slučajno poslao dokument pogrešnoj osobi? Ako odgovor nije očigledno da, kanal nije dovoljno jasan.

2. Kultura bez kažnjavanja

Ovo je element koji se najčešće zanemari, a bez njega ništa drugo na ovoj listi ne funkcioniše. Većina incidenata koje smo koristili kao primere kroz mini-seriju — pogrešno poslat mejl, zaboravljeno ukidanje pristupa, deljena lozinka — su iskrene ljudske greške, ne zloba. Ako zaposleni ima utisak da će prijava greške dovesti do ukora ili posledica po njega lično, prestaće da prijavljuje, a firma gubi tačno onu vidljivost koja je ISMS-u potrebna. Menadžment mora eksplicitno i ponavljano da komunicira da je cilj popravka sistema, a ne kažnjavanje osobe — ne samo da to napiše jednom u politici, nego da se tako i ponaša kad se prvi incident zaista prijavi.

3. Osoba zadužena za trijažu

Čak i u firmi od petnaest ljudi, neko mora da bude ta osoba — vlasnik, operativni menadžer, ili neko ko vodi ISMS — kojoj prijave stižu i koja odlučuje šta dalje: da li je ozbiljno, ko još treba da zna, da li se odmah reaguje ili se rešava kroz redovan proces. Ovo ne mora biti nova pozicija, samo jasno dodeljena odgovornost.

4. Registar incidenata

Jednostavna tabela je sasvim dovoljna: datum, kratak opis, ko je prijavio, uzrok, preduzeta mera, ko je odgovoran, rok, status. Ovo je, u praksi, ono što auditor najčešće traži da vidi — ne da mu opišete proces, nego da mu pokažete konkretan red u tabeli i ispričate kako je taj slučaj prošao od prijave do zatvaranja.

5. Analiza uzroka, ne samo zapis šta se desilo

Razlika između beleženja „poslat je pogrešan mejl" i „poslat je pogrešan mejl jer ne postoji korak provere primaoca pre slanja osetljivih dokumenata" jeste razlika između registra koji ništa ne menja i registra koji stvarno unapređuje sistem. Cilj analize nije da se pronađe ko je kriv, nego šta je u procesu nedostajalo da bi se greška uopšte mogla desiti.

6. Procedura za dodelu i ukidanje pristupa

Ako ste pratili mini-seriju, primetili ste da se ista vrsta propusta — neko je otišao, a pristup mu je ostao aktivan — pojavila kod developera, inženjera, prevoznika, agenta za nekretnine. To nije slučajnost, nego jedan od najčešćih stvarnih propusta u malim firmama uopšte. Zato zaslužuje da bude eksplicitno imenovan kao poseban proces: kratka lista koraka koja se pokreće svaki put kad neko — zaposleni, honorarni saradnik, spoljni partner — stupi u ili napusti saradnju, sa jasnim rokom u kom se pristup dodeljuje, odnosno ukida.

7. Živ registar procene rizika, sa jasno definisanim okidačima za ažuriranje

Umesto da se procena rizika ažurira „kad se neko seti", korisnije je unapred napisati tačno kada se to dešava: kad se desi incident, kad se uvede novi sistem ili alat, kad se potpiše veći klijent, kad se značajno promeni tim, i redovno, jednom godišnje. Kad su okidači jasno napisani, ažuriranje prestaje da zavisi od nečijeg pamćenja.

8. Redovan pregled menadžmenta, sa fiksnim dnevnim redom

Ovo je tačka gde se sve prethodno navedeno stvarno spaja u sistem, a ne samo teoretski postoji odvojeno. Za malu firmu, dovoljno je da se ovo dešava dva puta godišnje, uz uvek isti dnevni red: pregled incidenata od poslednjeg sastanka, status korektivnih mera, ažuriranja procene rizika, predlozi za unapređenje, i odluke o resursima ili budžetu ako su potrebni. Ovo je ujedno i tačka gde direktor ili vlasnik firme stvarno, vidljivo stoji iza sistema — tema kojom ćemo se detaljnije baviti u sledećem tekstu glavne serije, o liderstvu.

9. Obuka koja koristi stvarne, ne generičke primere

Kroz čitavu mini-seriju, obuka zaposlenih je gotovo uvek bila poslednja karika lanca posle incidenta — i to nije slučajno. Godišnja prezentacija sa opštim savetima poput „čuvajte svoje lozinke" retko ostaje u sećanju. Kratak pregled jednog ili dva stvarna, anonimizovana incidenta iz same firme, sa objašnjenjem šta je uvedeno da se ne ponovi, gradi mnogo realnije razumevanje i mnogo veću spremnost zaposlenih da sami prijave sledeći problem.

Minimalna, realna lista za malu firmu

Ako biste od svega ovoga izdvojili samo ono bez čega sistem stvarno ne funkcioniše, to je:

• jedan poznat, jednostavan kanal za prijavu,
• jasno komunicirana kultura bez kažnjavanja,
• jedna osoba zadužena za trijažu prijava,
• registar incidenata (dovoljna je tabela),
• procedura za dodelu i ukidanje pristupa pri promeni saradnje,
• registar rizika sa jasnim okidačima za ažuriranje,
• pregled menadžmenta bar dva puta godišnje, sa fiksnim dnevnim redom.

Sve ostalo — specijalizovan softver, detaljnije procedure, dodatni slojevi izveštavanja — ima smisla dodati kasnije, kad sistem naraste, ne pre nego što ovih sedam stvari stvarno proradi.

Najčešće greške pri uvođenju

• Preterano komplikovan sistem od početka. Skup alat za praćenje tiketa nema smisla za firmu od petnaest ljudi kad dobro organizovana deljena tabela odrađuje isti posao.
• Kažnjavanje umesto učenja. Ovo tiho ubija ceo sistem — ne odjednom, nego postepeno, kroz sve manji broj prijava, dok se firma ne nađe u situaciji da „nema incidenata" jednostavno zato što ih niko više ne prijavljuje.
• Odsustvo jasnog vlasnika. Ako niko nije formalno zadužen da nalaze iz registra incidenata prosledi na pregled menadžmenta, ta veza jednostavno neće nastati sama od sebe, koliko god pojedinačni delovi sistema izgledali uredno.
• Dokumentacija koja živi samo pred audit. Registar koji se odjednom napuni unazad nedelju dana pred nadzornu proveru jedan je od najlakše prepoznatljivih signala za iskusnog auditora — i, što je važnije, ne donosi firmi nikakvu stvarnu korist van tog jednog dana.

Šta sledi

Vraćamo se na glavnu seriju klauzula po klauzula, poglavljem 5 — liderstvom. Klauzula 5.1 direktno se nastavlja na ono što smo upravo opisali: standard eksplicitno traži da direktor ili vlasnik firme lično, vidljivo stoji iza ovakvog sistema, ne samo da ga odobri na papiru.