ISO 27001 klauzula po klauzula: 4.4 — Sistem upravljanja bezbednošću informacija
Nastavljamo seriju klauzula po klauzula. Klauzula 4.4 je kratka, ali zatvara čitavo četvrto poglavlje standarda — i pretvara sve što smo do sada radili (kontekst, zainteresovane strane, obim) iz analize na papiru u stvaran, funkcionalan sistem.
U jednoj rečenici: klauzula 4.4 traži da kontekst, zainteresovane strane i obim, koje ste utvrdili u 4.1–4.3, spojite u stvaran sistem povezanih procesa koji se stalno održava i unapređuje — ne u fasciklu odvojenih dokumenata.
Šta klauzula 4.4 traži
Tekst same klauzule je kratak: firma treba da uspostavi, primeni, održava i stalno unapređuje sistem upravljanja bezbednošću informacija, uključujući procese koji su za to potrebni i način na koji se ti procesi međusobno prepliću.
Vredi rastaviti ova četiri glagola, jer svaki nosi drugačiju obavezu:
- Uspostaviti — izgraditi sistem prvi put, na osnovu svega utvrđenog u 4.1, 4.2 i 4.3.
- Primeniti — stvarno ga sprovesti u praksi, ne samo napisati dokumente o njemu.
- Održavati — držati ga tekućim i funkcionalnim, ne dozvoliti da zastari.
- Stalno unapređivati — ciklus poboljšanja ugrađen je već ovde, u samim temeljima standarda, ne tek u desetom, poslednjem poglavlju o unapređenju.
Druga bitna reč u klauzuli je „procesi i njihove interakcije". Sistem upravljanja bezbednošću informacija nije zbir izolovanih aktivnosti — procena rizika, kontrola pristupa, obuka zaposlenih, upravljanje incidentima, interni audit — nego mreža procesa koji se međusobno hrane. Rezultat jednog treba da utiče na sledeći. Upravo ta povezanost je ono što klauzula 4.4 formalno traži.
Zašto je ova klauzula bitna
Ovo je most između analize i stvarnog sistema. Ako se preskoči ili shvati kao formalnost, firma često završi sa tačno onim što izgleda dobro na papiru, a ne funkcioniše: procena rizika urađena jednom i odložena, procedura upravljanja incidentima koju niko zapravo ne prati, obuka koja se održi jednom i nikad ne ponovi.
Ovo je ujedno i klauzula koja u samim temeljima standarda ugrađuje ideju da sertifikacija nije završna linija, o čemu smo pisali u tekstu o zabludama — „stalno unapređivati" nije opcioni dodatak na kraju, nego formalni zahtev postavljen već u četvrtom poglavlju standarda. Svih šest narednih poglavlja standarda (5–10: liderstvo, planiranje, podrška, operacija, ocenjivanje učinka i unapređenje) u suštini samo detaljno objašnjavaju kako se ova jedna, kratka klauzula sprovodi u praksi.
Primer iz prakse
Setimo se incidenta pomenutog još u tekstu o klauzuli 4.1: zaposleni je pre dve godine greškom poslao finansijski izveštaj pogrešnom klijentu mejlom, a incident nikad nije formalno analiziran. To je tačno primer sistema koji ne funkcioniše kao celina — incident se desio, ali nijedan proces nije bio povezan sa njim. Niko nije pokrenuo analizu, procena rizika nije ažurirana, niko nije preispitao da li postojeće kontrole uopšte pokrivaju ovu vrstu greške.
Nakon što agencija uspostavi ISMS u skladu sa klauzulom 4.4, isti tip incidenta bi prošao kroz povezan lanac procesa:
- Prijava incidenta kroz definisanu proceduru upravljanja incidentima, umesto da se prećutno reši i zaboravi.
- Analiza uzroka — u ovom slučaju, nedostatak provere primaoca pre slanja osetljivih dokumenata.
- Ažuriranje procene rizika — dodaje se ili pojačava rizik vezan za slanje podataka klijentima, koristeći metodologiju koju smo opisali u tekstu o proceni rizika.
- Korektivna mera — na primer, uvođenje obavezne dvostruke provere primaoca pre slanja mejlova sa finansijskim prilozima.
- Prijava na sledećem pregledu menadžmenta, gde se odlučuje da li je mera dovoljna ili treba nešto dodatno.
- Uticaj na obuku zaposlenih — konkretan primer ulazi u narednu rundu edukacije, umesto apstraktnog upozorenja „budite pažljivi".
Isti incident, ali sad povezan sa celim sistemom, umesto da nestane bez traga. Upravo je ta razlika — između zbirke izolovanih aktivnosti i sistema procesa koji se međusobno hrane — ono što klauzula 4.4 formalno traži.
Gde se dokumentuje
Za razliku od 4.1–4.3, klauzula 4.4 sama po sebi ne traži poseban, izdvojen dokument. Ona se ogleda u tome kako je ceo set ISMS dokumentacije povezan — da li izveštaj o incidentu zaista vodi do ažurirane procene rizika, da li nalazi internog audita zaista stižu do dnevnog reda pregleda menadžmenta. Neke firme prave kratak pregledni dokument ili šemu koja prikazuje kako se procesi povezuju — nije strogo obavezno, ali korisno, jer je upravo to nešto što auditor na terenu voli da proveri: da zatraži da mu se pokaže kako je jedan konkretan nalaz ili incident stvarno prošao kroz sistem, od prijave do korektivne mere.
Najčešća greška
Najčešća greška je tretiranje ISMS-a kao gomile odvojenih dokumenata sastavljenih samo radi audita, od kojih svaki posle napisan nikad više nije otvoren niti povezan sa ostalima. Druga, srodna greška je nepovezivanje nalaza — podaci iz incidenta ili internog audita ne stižu nazad do procene rizika, pa se sistem u praksi ne uči iz sopstvenog iskustva. Treća je odsustvo jasnog vlasništva nad samim vezama između procesa — ako niko nije zadužen da nalaze internog audita prosledi na pregled menadžmenta, ta veza jednostavno neće postojati, koliko god pojedinačne procedure bile dobro napisane.
Šta sledi
Ovim se zatvara četvrto poglavlje standarda. Sledeći tekst u seriji prelazi u peto poglavlje — liderstvo — klauzulom 5.1: liderstvo i posvećenost menadžmenta, gde standard konačno eksplicitno traži da direktor ili vlasnik firme lično stane iza sistema koji smo do sada gradili.
Comments
Post a Comment