ISO/IEC 20000-1, klauzula 9.3 — Pregled od strane rukovodstva

Šta standard zahteva

Klauzula 9.3 traži da najviše rukovodstvo, u planiranim intervalima, pregleda SMS organizacije i usluge, kako bi se obezbedila njihova stalna pogodnost, adekvatnost i efektivnost. Pregled od strane rukovodstva mora da uključi razmatranje:

  • statusa mera iz prethodnih pregleda;
  • promena u spoljašnjim i unutrašnjim pitanjima relevantnim za SMS;
  • informacija o performansama i efektivnosti SMS-a, uključujući trendove u neusaglašenostima i korektivnim merama, rezultatima praćenja i merenja, i rezultatima audita;
  • prilika za kontinuirano unapređenje;
  • povratnih informacija od korisnika i drugih zainteresovanih strana;
  • pridržavanja i pogodnosti politike upravljanja uslugama i drugih politika koje zahteva ovaj standard;
  • ostvarenja ciljeva upravljanja uslugama;
  • performansi usluga;
  • performansi drugih strana uključenih u isporuku usluga;
  • trenutnih i prognoziranih nivoa ljudskih, tehničkih, informacionih i finansijskih resursa, i sposobnosti ljudskih i tehničkih resursa;
  • rezultata procene rizika i efektivnosti preduzetih mera za rizike i prilike;
  • promena koje mogu uticati na SMS i usluge.

Izlazi pregleda od strane rukovodstva moraju uključiti odluke vezane za prilike za kontinuirano unapređenje i svaku potrebu za izmenama SMS-a i usluga. Organizacija mora da čuva dokumentovanu informaciju kao dokaz rezultata pregleda od strane rukovodstva.

Primer

Primer: Direktor Adria Trade-a i rukovodilac IT sektora sastaju se svakih šest meseci na formalnom pregledu SMS-a. Na dnevnom redu se sistematski prolazi kroz sve propisane tačke — proverava se da li su mere dogovorene na prethodnom pregledu sprovedene, razmatraju se nove promene poput regulative ili plana širenja, pregledaju se trendovi u neusaglašenostima, rezultati praćenja iz 9.1 i nalazi internog audita iz 9.2. Razmatraju se povratne informacije korisnika prikupljene kroz upravljanje poslovnim odnosom (8.3.2), da li se politika iz 5.2 i dalje pridržava i da li je i dalje pogodna, da li su ciljevi iz 6.2 ostvareni, kako usluge i dobavljači performiraju, kakvo je trenutno i planirano stanje resursa (7.1, 8.4.3), i kakvi su rezultati procene rizika iz 6.1.

Na osnovu svega ovoga, sastanak se ne završava samo diskusijom — donose se konkretne odluke: dodatno ulaganje u kapacitet service deska pred otvaranje novih prodavnica, ažuriranje politike upravljanja uslugama da odražava novu regulativu, i uvođenje dodatne kontrole za rizik prepoznat tokom godine. Zapisnik sa sastanka, sa svim razmotrenim tačkama i donetim odlukama, čuva se kao dokaz da je pregled sproveden.

Šta treba uraditi

  • Zakazati pregled od strane rukovodstva u planiranim intervalima, sa učešćem najvišeg rukovodstva, ne samo IT tima — ovo nije interni sastanak IT sektora, nego formalni pregled na nivou uprave.
  • Koristiti sistematičan dnevni red koji prolazi kroz sve propisane tačke, umesto neformalnog razgovora koji lako preskoči važne stavke.
  • Eksplicitno proveriti status mera dogovorenih na prethodnom pregledu — akcije koje se tiho zaborave narušavaju smisao celog procesa.
  • Objediniti na jednom mestu izlaze iz svih ranijih klauzula — rezultate audita (9.2), rezultate praćenja (9.1), procenu rizika (6.1), ostvarenje ciljeva (6.2), povratne informacije korisnika (8.3.2), stanje resursa (7.1, 8.4.3) i performanse dobavljača (8.3.4) — jer je upravo pregled od strane rukovodstva mesto gde se sve ovo sastavlja u celovitu sliku.
  • Obezbediti da pregled završi konkretnim odlukama — o prilikama za unapređenje i o potrebnim izmenama SMS-a ili usluga — a ne samo diskusijom bez zaključka.
  • Dokumentovati rezultate pregleda kao dokaz — zapisnik koji pokazuje šta je razmotreno i šta je odlučeno.

Comments

Post a Comment

Popular posts from this blog

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

  Prvi tekst na blogu InfoSec bez stresa — i pitanje koje sebi postavi skoro svaki vlasnik male ili srednje firme onog trenutka kad prvi put čuje za ovaj standard. Realna situacija Zamislite ovo: firma ima 15 zaposlenih, radi razvoj softvera ili pruža IT usluge, posluje solidno, sve funkcioniše. Onda stigne mejl od velikog klijenta — banke, osiguravajuće kuće ili strane kompanije s kojom se pregovara o saradnji. U prilogu je bezbednosni upitnik, a na dnu jedna rečenica koja pokvari popodne: „Molimo dostavite ISO 27001 sertifikat ili plan implementacije u naredna tri meseca." Ili, druga verzija iste priče: firma konkuriše na tenderu, sve uslove ispunjava — sem jednog. Traži se ISO 27001. Prva reakcija je obično paničan Google upit u stilu „šta je ISO 27001" i „da li mi to stvarno treba", u ponoć, uz osećaj da se upravo otvorila rupa u budžetu i rasporedu koje niko nije planirao. Ako je ovo vaša situacija — ili slutite da bi mogla postati — ovaj tekst je tu da va...
Read more

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

Ova serija od osam članaka provodi vas kroz sve zahteve standarda ISO 22301:2019 — Sistemi upravljanja kontinuitetom poslovanja (BCMS) , klauzulu po klauzulu, na konkretnom praktičnom primeru: fiktivnoj proizvodnoj pivari „Zeleni Hmelj" d.o.o. , sa sopstvenom varionicom, punionicom i hibridnom IT/OT arhitekturom (SCADA/PLC industrijski sistemi, lokalni ERP i cloud servisi — Microsoft 365, cloud backup/DR, SaaS CRM). Umesto apstraktnog prepričavanja teksta standarda, svaki post gradi stvaran, upotrebljiv dokument — politiku, matricu, BIA analizu, BCP plan, zapisnik — kakav bi auditor tražio na sertifikacionoj proveri. Kroz celu seriju provlači se jedan princip: zahtevi kontinuiteta poslovanja dolaze od biznisa ka IT sektoru, a ne obrnuto — proizvodnja i komercijala definišu koliko dugo mogu da izdrže bez svog sistema, a IT/OT sektor sprovodi tehnička rešenja koja taj zahtev ispunjavaju. Sadržaj serije Deo 1 Uvod u BCMS i Klauzula 4 — Kontekst organizacije Razlika BCMS v...
Read more

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

6.1 – Opšte Standard deli uzroke prekida u nekoliko grupa: prirodni uzroci – požar, poplava. Retki, ali fizički pogađaju celu lokaciju odjednom, ne samo jednu komponentu. tehnički kvarovi – hardver, softver, napajanje, klimatizacija. Najčešća kategorija u praksi, i ona za koju firme obično imaju najviše iskustva. ljudska greška – loše podešen bekap, propust u upravljanju izmenama. Retko ko je namerno kriv, ali posledice su iste kao da jeste. namerna akcija – hakovanje, malver, sabotaža. Ovde je pored oporavka bitna i istraga – ko je i kako ušao. društveni faktori – pandemija, štrajk. Ne pogađaju tehnologiju direktno, nego ljude koji je održavaju. cyber napadi – DoS, DDoS, napadi koji preplave sistem saobraćajem dok ne prestane da radi. lanac snabdevanja – prekid kod cloud provajdera, nejasni bezbednosni uslovi u ugovoru sa dobavljačem. Ovde firma nema direktnu kontrolu, samo ugovor i poverenje. Rizik da IT prestane da radi ima jedan prepoznatljiv obrazac: retko se ...
Read more