ISO 27031: Poslovna očekivanja od IRBC-a (klauzula 7)

7.1 – Pregled rizika

IRBC strategije moraju da prate firmu dok se menja. Svaka veća promena – nova IT usluga, spajanje firmi, gašenje sistema – treba prvo da prođe proveru uticaja na kontinuitet, pre nego što se sprovede. Standard traži i da firma redovno prati signale koji mogu da naruše spremnost:

• da li ključni ljudi i znanje ostaju u firmi
• da li se nešto menja u objektima gde stoji oprema
• da li tehnologija i budžet prate potrebe
• da li dobavljači i dalje isporučuju kako treba

Bez ove provere, promene ulaze u produkciju bez ikakvog uvida u to šta rade sa postojećom mrežom zavisnosti – a upravo tu se najčešće stvaraju novi rizici koje niko nije nameravao da napravi, samo su se desili usput.

Primer: VoxServis je pre dve godine uveo cloud CRM. Prošao je kroz nabavku i tehničku implementaciju, ali nikad kroz proveru "da li ovo menja naše zavisnosti?" Da je taj korak postojao, zavisnost identiteta koja je kasnije izazvala incident verovatno bi bila uočena ranije.

Šta treba uraditi

• Dodati obavezan korak u proces uvođenja svake nove IT usluge ili veće promene – provera uticaja na IRBC, sa formalnim potpisom da je urađena, pre puštanja u produkciju, ne posle.
• Ta provera treba konkretno da odgovori na pitanje da li nova usluga uvodi novu zavisnost (npr. deli infrastrukturu za prijavu korisnika sa postojećim sistemima), ne samo da li tehnički radi.
• Uz jednokratnu proveru pri uvođenju, uspostaviti i periodičnu – npr. jednom godišnje – koja prati promene u ljudima, objektima, tehnologiji, budžetu i dobavljačima, jer se rizik menja i bez ijedne velike odluke, samo protokom vremena.
• Odrediti ko je vlasnik ove provere – bez imenovane odgovorne osobe, korak se lako preskoči pod pritiskom rokova projekta.

7.2 – Ulazni podaci iz BIA

Svaki kritičan IT servis dobija sopstveni RTO, RPO i MBCO, izveden iz BIA – ne samo poslovna aktivnost u celini. RTO servisa je gotovo uvek kraći od RTO aktivnosti koju podržava, jer servisi zavise jedan od drugog i moraju da se oporave pre nje.

Ako se ovaj račun ne uradi, firma zna koliko vremena ima za celu aktivnost, ali ne zna da li pojedinačni delovi sistema uopšte mogu da stignu u taj rok – što znači da obećanje dato klijentu može biti matematički neizvodljivo, a da to niko nije primetio dok se ne desi.

Primer: VoxServis-ova aktivnost "prijem poziva podrške" ima ugovoren RTO od 30 minuta. Kad se razloži na servise koji je čine – telefonija, autentifikacija, CRM – svaki mora sopstveni, kraći rok. Ako autentifikacija ima RTO od dva sata, kao što trenutno ima, ne postoji način da ukupnih 30 minuta bude ispunjeno, bez obzira koliko brzo rade ostale komponente. Taj račun se do sad nigde nije video.

Šta treba uraditi

• Za svaku prioritetnu poslovnu aktivnost, napraviti spisak svih IT servisa koji je tehnički omogućavaju – ne stati na prvom nivou, nego uključiti i servise od kojih ti servisi zavise (npr. autentifikacija ispod CRM-a).
• Svakom servisu iz tog spiska dodeliti sopstveni RTO i RPO, kraći od RTO/RPO aktivnosti koju podržava, i proveriti da li je to tehnički realno.
• Pronaći najsporiju kariku u lancu i uporediti je sa ukupnim rokom koji je obećan poslovanju ili klijentu – ako najsporija karika sama premašuje ukupan rok, ostatak lanca je nebitan dok se to ne reši.
• Ovaj razlaganje ponoviti za svaku novu ili izmenjenu aktivnost, ne samo jednom pri prvom pisanju BIA – zavisnosti se menjaju kako se uvode nove usluge.

7.3 – Pokrivenost i zavisnosti

IRBC pokriva celu IT arhitekturu, ne samo ono što je u serverskoj sobi. Standard traži dokumentovan spisak svih dobavljača po servisu, i analizu jaza između onoga što dobavljač stvarno može da isporuči i onoga što je firmi potrebno.

Ugovor sa dobavljačem koji garantuje dostupnost servera ne kaže ništa o tome koliko brzo se oporavlja izgubljeni ili oštećeni nalog, niti koliko brzo radi internet veza kad ona otkaže – a firma retko razmišlja o vezi kao o dobavljaču, iako funkcioniše na potpuno isti način: ako otkaže, sve iza nje otkazuje s njom.

Primer: VoxServis ima ugovor sa cloud CRM dobavljačem koji obećava visoku dostupnost platforme – ali nikad nije proverio RTO tog dobavljača za scenario oštećenja naloga, što je sasvim drugo pitanje od dostupnosti servera. Ista provera nedostaje i za internet vezu ka cloud okruženju, koju retko ko tretira kao dobavljača u formalnom smislu.

Šta treba uraditi

• Napraviti spisak svih dobavljača povezanih sa kritičnim IT servisima – uključujući i one koji se retko doživljavaju kao "dobavljači", kao što je provajder internet veze.
• Za svakog od njih pronaći ne samo garantovanu dostupnost, nego i RTO za konkretne scenarije kvara – gubitak podataka, oštećenje naloga, prekid veze – jer to su često drugačiji brojevi od opšte dostupnosti platforme.
• Uporediti RTO koji dobavljač stvarno nudi sa RTO koji je firmi potreban za taj servis (iz 7.2) – jaz između ta dva broja je konkretan rizik, ne teoretsko pitanje.
• Gde jaz postoji, doneti svesnu odluku – pregovarati bolji SLA, uvesti alternativu (npr. rezervnu vezu), ili prihvatiti rizik uz saglasnost menadžmenta – ne ostaviti ga nezapisanog.