Kontinuita začíná v byznysu: BIA pro IT

Pondělí, osm ráno

ERP nenaběhlo. IT obnovuje, ale v jakém pořadí? Fakturace, sklad, výroba, e-shop, mzdy? Kdo rozhodne, co počká? A ví IT, že výroba vydrží čtyři hodiny na papírových průvodkách, ale expedice bez skladu ani hodinu?

Bez BIA se tato rozhodnutí dělají až během výpadku, pod tlakem a podle toho, kdo je nejhlasitější.

Co BIA dává IT

• Priority obnovy odvozené od dopadu na firmu, ne od velikosti serveru.
• Cíle obnovy od vlastníka procesu, ne odhadnuté IT: RTO (Recovery Time Objective) pro čas do obnovení služby a RPO (Recovery Point Objective) pro přípustnou ztrátu dat.
• Pořadí obnovy a závislosti mezi procesy, systémy, lidmi a dodavateli.
• Argument pro rozpočet: když vedení samo stanoví, že proces musí běžet do čtyř hodin, je jasné, kolik to stojí.

Od dopadu k cíli obnovy

BIA nezačíná u RTO, ale otázkou, jak dlouho proces může stát, než jsou dopady pro firmu nepřijatelné (MTPD, Maximum Tolerable Period of Disruption). Cíl obnovy se z této hranice odvozuje a musí být kratší. Druhou důležitou veličinou je minimální přijatelný provoz během výpadku (MBCO, Minimum Business Continuity Objective). Firma často nepotřebuje obnovit všechno naráz, potřebuje vědět, co musí běžet hned.

Kde se ukáže mezera

Teprve když vedle sebe stojí požadavek byznysu a naměřený čas obnovy, je vidět rozdíl. Například výroba potřebuje systém do čtyř hodin, ale test obnovy ukázal dvanáct. S takovou mezerou se dá pracovat: změnit architekturu, upravit postup, nebo vědomě přijmout riziko. To poslední je rozhodnutí vedení, ne IT.

Pozor jen na to, co se měří. Obnovená data ještě nejsou obnovená služba.

Na co se zeptat

• Kdo u vás stanovil cíle obnovy: vlastník procesu, nebo IT?
• Víte, jak dlouho vydrží bez IT váš nejdůležitější proces?
• Porovnali jste požadovaný čas obnovy s naměřeným?

Norma ISO 22301 analýzu dopadů výslovně vyžaduje a NIS2 požaduje řízení kontinuity provozu. Hlavní důvod je ale praktický: bez BIA obnova nemá podle čeho určit, co je důležité.