ISO/IEC 20000-1, klauzula 7.4 — Komunikacija

Šta standard zahteva

Klauzula 7.4 traži da organizacija odredi interne i eksterne komunikacije relevantne za SMS i usluge, uključujući:

  • o čemu će se komunicirati;
  • kada komunicirati;
  • sa kim komunicirati;
  • kako komunicirati;
  • ko je odgovoran za komunikaciju.

Primer

Primer: IT sektor Adria Trade-a pravi jednostavan plan komunikacije za nekoliko tipičnih situacija:

  • Planirani prekid rada zbog održavanja: komunicira se svim pogođenim korisnicima najmanje 48 sati unapred, putem interne mejling liste i internog portala, odgovoran service delivery menadžer.
  • Veliki incident (na primer, pad ERP sistema): komunicira se odmah pogođenim sektorima, putem telefona i hitne poruke na internom kanalu, odgovoran dežurni inženjer koji je prvi primio prijavu.
  • Mesečni izveštaj o performansama SMS-a: komunicira se upravi jednom mesečno, putem sastanka i pisanog izveštaja, odgovoran service delivery menadžer.
  • Izmena uslova SLA sa cloud ERP dobavljačem: komunicira se internim sektorima koji zavise od ERP-a, putem mejla sa kratkim objašnjenjem šta se menja i od kada, odgovoran rukovodilac IT sektora.

Šta treba uraditi

  • Napraviti spisak tipičnih situacija u kojima IT sektor treba da komunicira sa nekim — planirano održavanje, veći incidenti, redovno izveštavanje, promene koje utiču na korisnike.
  • Za svaku situaciju odgovoriti na svih pet pitanja iz standarda — šta, kada, sa kim, kako i ko je odgovoran — u vidu jednostavne tabele, umesto opisnog teksta koji se teško prati.
  • Razdvojiti hitnu komunikaciju (veći incident) od rutinske (mesečni izveštaj) — hitna komunikacija zahteva brz kanal (telefon, hitna poruka), dok rutinska može ići mejlom ili kroz redovan sastanak.
  • Eksplicitno obuhvatiti i eksternu komunikaciju — sa dobavljačima, spoljnim agencijama, po potrebi i regulatornim telima — ne samo internu komunikaciju sa zaposlenima.
  • Dodeliti jasnu odgovornost za svaki tip komunikacije — kad nastupi hitna situacija, ne sme se gubiti vreme na pitanje ko treba da javi korisnicima da nešto ne radi.
  • Ažurirati plan komunikacije kad se pojavi nova zainteresovana strana ili nova vrsta situacije (na primer, kad se doda novi dobavljač identifikovan u 4.2) — plan komunikacije ne treba da zaostaje za promenama u organizaciji.

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