ISO 27001 klauzula po klauzula: 6.3 — Planiranje promena

Nastavljamo seriju klauzula po klauzula. Klauzula 6.3 zatvara šesto poglavlje standarda i, iako je najkraća klauzula na koju smo do sada naišli, formalizuje ideju koja se, neimenovana, provlačila kroz gotovo svaki prethodni tekst na ovom blogu.

U jednoj rečenici: kad god se nešto menja u firmi ili u sistemu bezbednosti, ta promena mora biti sprovedena planski i promišljeno — ne stihijski, uz nadu da će se dokumentacija nekako sama uskladiti kasnije.

Šta klauzula 6.3 traži

Sam tekst klauzule je izuzetno kratak — kraći od bilo koje druge klauzule u standardu do sada: kad firma odredi da je sistemu potrebna promena, ta promena mora biti sprovedena na planski način. To je sve što piše, ali iza te jedne rečenice stoji dobro poznata ideja iz opšte prakse upravljanja promenama: najveći broj bezbednosnih propusta ne nastaje zato što kontrole ne postoje, nego zato što je nešto promenjeno, a sistem nije stigao — ili niko nije stigao — da se prilagodi toj promeni.

Ova klauzula je nova u reviziji standarda iz 2022. godine, uvedena radi usklađivanja sa zajedničkom strukturom koju dele svi ISO standardi za sisteme upravljanja — ISO 9001 za kvalitet, na primer, već je imao sličan zahtev.

„Promena" u ovom kontekstu može biti gotovo bilo šta što utiče na sistem: nov IT sistem ili alat, promena obima poslovanja, novi veći klijent, značajna promena tima, nova lokacija, čak i promena u samom sistemu bezbednosti — nova kontrola, izmenjena procedura. Standard ne propisuje tačan format „plana promene" — traži samo da se promena ne prepusti slučaju.

Zašto je ova klauzula bitna

Ako pratite ovu seriju od početka, primetićete da se ideja iz ove klauzule zapravo provlačila kroz gotovo svaki prethodni tekst, samo nije bila imenovana. Kad smo u tekstu o proceni rizika pisali da se procena ažurira „kad se nešto značajno promeni", to je 6.3 u praksi. Kad je u mini-seriji primera dolazak ili odlazak zaposlenog izazivao propust jer pristup nije ažuriran na vreme, to je bio propust upravo u planiranju promene — promena se desila, ali sistem nije bio unapred pripremljen da je isprati.

Klauzula 6.3 postoji da bi ovu ideju formalizovala kao eksplicitan zahtev, ne samo implicitnu dobru praksu: pre nego što se promena sprovede, firma treba da razmisli šta ta promena znači za obim, rizike, uloge i dokumentaciju — ne da to otkriva unazad, tek kad nešto krene naopako.

Primer iz prakse

Knjigovodstvena agencija iz ove serije, pomenuta još u tekstu o klauzuli 4.1, dugo je vodila desetak starijih klijenata kroz lokalne Excel fajlove, dok je većina klijenata već bila na cloud platformi. Agencija odlučuje da konačno migrira i te preostale klijente na cloud sistem.

Nesprovedeno planski, ovako bi to verovatno izgledalo: IT saradnik jednostavno počinje da prebacuje podatke tokom redovnih radnih sati, bez najave timu, bez provere da li cloud platforma ima iste bezbednosne postavke i za ove klijente, i bez ikakve izmene postojeće dokumentacije. Klijenti saznaju za promenu tek kad primete drugačiji format izveštaja.

Sprovedeno u skladu sa 6.3, izgledalo bi ovako:

  • Pre migracije, koordinatorka sistema bezbednosti — uloga imenovana u 5.3 — proverava da li migracija menja obim iz 4.3. U ovom slučaju ne menja, jer su ovi klijenti već bili deo osnovne delatnosti, samo u drugačijem tehničkom obliku.
  • Procena rizika se ažurira pre, ne posle migracije — dodaje se privremeni rizik izložen tokom samog prenosa podataka, uz definisanu meru, na primer migraciju van radnog vremena uz proveru integriteta podataka nakon prenosa.
  • Migracija se prvo testira na jednom klijentu, pre nego što se sprovede za sve, kako bi se eventualni problemi otkrili na malom uzorku.
  • Zaposleni koji rade sa tim klijentima unapred su obavešteni o promeni i, po potrebi, kratko obučeni za rad u novom sistemu.
  • Klijenti su obavešteni o promeni pre nego što je primete kroz izmenjen format izveštaja.

Ista promena, ali sa jasnom razlikom — u drugom slučaju, promena je integrisana u sistem, umesto da sistem naknadno juri za promenom koja se već desila.

Gde se dokumentuje

Za veće promene korisno je imati kratak, jednostavan „plan promene" — nekoliko rečenica o tome šta se menja, ko je uključen, kakav je uticaj na obim, rizike i dokumentaciju, i do kada se promena sprovodi. Za manje promene dovoljno je da se to reši kroz redovan pregled menadžmenta ili kroz ažuriranje registra rizika u trenutku kad se promena desi — ne mora svaka sitnica da ima poseban dokument.

Najčešća greška

Najčešća greška je tretiranje ove klauzule kao nepotrebne birokratije za sitne, svakodnevne promene, kad je njena poenta zapravo suprotna: prepoznati koje promene su dovoljno značajne da zaslužuju trenutak razmišljanja pre sprovođenja, a koje nisu. Druga česta greška, koju smo više puta videli kroz mini-seriju primera, jeste tretiranje promena u sastavu tima — dolazaka i odlazaka zaposlenih, saradnika, dobavljača — kao nešto što rešava samo HR proces, a ne i ISMS, iako je upravo to jedna od najčešćih promena koje sistem treba da isprati.

Šta sledi

Ovim se zatvara šesto poglavlje standarda — planiranje. Sledeći tekst u seriji prelazi u sedmo poglavlje — podršku — klauzulom 7.1, gde standard konačno eksplicitno traži ono što smo pominjali kroz nekoliko prethodnih tekstova: da rukovodstvo stvarno obezbedi resurse, ne samo obeća ih.

Comments

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)