Plánování kontinuity podnikání nejčastěji selhává nikoli během krize, ale během hodnocení, které krizi předchází. Organizace provádějí analýzy dopadu na podnikání, dokumentují cílové časy obnovy, vytvářejí komplexní plány obnovy a pak v nejhorší možné chvíli zjistí, že zdánlivě nekritická starší ověřovací služba je jediným bodem selhání pro celou jejich e-commerce platformu, že dávkový program COBOL, o kterém všichni považovali nízkou prioritu, napájí službu ověřování plateb v reálném čase, nebo že dvě aplikace přiřazené ke stejné úrovni obnovy mají nezdokumentovanou závislost, která znemožňuje sekvenční obnovu. Bodové hodnocení bylo provedeno. Závislosti ne.
Bodování kritičnosti aplikací je proces přiřazování kvantitativního nebo stupňovitého měřítka důležitosti každé aplikaci v portfoliu organizace. Toto měřítko určuje její prioritu obnovy, úroveň investic do redundance, požadavky na řízení změn a její pozici v pořadí obnovy po havárii. Pokud je toto bodování založeno pouze na průzkumech dopadu na podnikání a rozhovorech s vlastníky aplikací, odráží to, co si lidé myslí, že aplikace dělají. Pokud je založeno na strukturální analýze toho, co aplikace skutečně dělají, kdo komu volá, která data protékají kterými programy a které sdílené komponenty se nacházejí v kritické cestě více systémů s vyšší prioritou, odráží provozní realitu.
Právě v rozporu mezi vírou a realitou selhávají plány na zajištění kontinuity podnikání.
Sekvence obnovy, které odrážejí skutečné závislosti
SMART TS XL identifikuje každý program v kritické cestě vašich aplikací 1. úrovně – napříč všemi jazyky ve vašem portfoliu.
ZJISTĚTE VÍCE…Co vlastně měří skóre kritickosti aplikací
Kritičnost není jediný rozměr. Pro určení skóre kritičnosti podnikové aplikace je možné vzít v úvahu vstupy od uživatelů k posouzení kritičnosti nebo důležitosti podnikové aplikace, včetně největšího dopadu na strategické obchodní potřeby, dopadů na obchodní partnery, interakcí se zákazníky a dopadů na další podnikové aplikace. Každý z těchto rozměrů zachycuje jiný aspekt toho, co znamená „kritický“:
Dopad na podnikání , kolik organizace ztrácí za hodinu výpadku. Ztráta příjmů je nejviditelnějším rozměrem: systém zpracování plateb, který zpracovává 10 milionů dolarů za hodinu, má kvantifikovatelné náklady na minutu výpadku. Dopad na podnikání však přesahuje příjmy a zahrnuje regulatorní expozici (jaké povinnosti v oblasti dodržování předpisů výpadek spouští?), poškození pověsti (jsou zákazníci přímo dotčeni?) a smluvní pokuty (spouštějí SLA pokutové doložky?).
Provozní závislost , kolik dalších systémů nebo procesů závisí na této aplikaci. Aplikace s nízkým přímým dopadem na podnikání může mít vysokou důležitost, protože se nachází v cestě závislostí aplikací s vysokým přímým dopadem. Autentizační služba, která umožňuje přístup ke všem ostatním aplikacím orientovaným na zákazníka, je důležitější, než naznačuje její vlastní funkce.
Složitost obnovy , jak obtížné a časově náročné je obnovit aplikaci. Aplikace s mírným dopadem na podnikání a dobou obnovy 48 hodin může vyžadovat vyšší investice do redundance než aplikace s vyšším dopadem na podnikání a dobou obnovy 2 hodiny, protože celkové riziko výpadku je větší.
Regulační povinnost , které aplikace podléhají požadavkům na regulační kontinuitu. Finanční instituce podléhající zákonu DORA musí prokázat, že kritické nebo důležité funkce odolávají specifickým scénářům narušení. Zdravotnické organizace podléhající zákonu HIPAA musí chránit dostupnost systémů obsahujících chráněné zdravotní informace. Regulační rozměr může u konkrétních aplikací převážit nad bodováním dopadu na podnikání.
Skóre kritičnosti je složeninou všech čtyř dimenzí, vážených specifickou tolerancí organizace k riziku, regulačním prostředím a obchodním modelem.
Standardní úrovně kritičnosti
Většina portfolií podnikových aplikací používá čtyřstupňový model kritičnosti. Kategorie kritičnosti v matici kritičnosti aplikací jsou Mission Critical (kritické pro misi), Business Critical (kritické pro obchod), Business Operational (provozní) a Administrative (administrativní). Níže uvedené definice odrážejí současnou praxi v oboru v souladu s normou ISO 22301 (Business Continuity Management Systems) a pokyny pro osvědčené postupy Institutu pro kontinuitu podnikání (Business Continuity Institute):
Tier 1, Kritické aplikace, jejichž selhání okamžitě zastaví hlavní obchodní operace nebo vytváří nepřijatelné regulační či bezpečnostní riziko. Cílový čas obnovy (RTO): obvykle 0–4 hodiny. Cílový bod obnovy (RPO): obvykle 0–1 hodina. Příklady: zpracování transakcí základního bankovnictví, systémy obchodování v reálném čase, systémy pro nouzové dispečing, rozhraní pro průmyslové řízení, systémy autorizace plateb. Tyto aplikace ospravedlňují nejvyšší investice do infrastruktury: redundance aktivní-aktivní, replikace s nulovým RPO, automatizované failover a nejpřísnější kontrola změn.
Úroveň 2, Obchodně kritické aplikace, jejichž selhání významně naruší obchodní operace, ale nezastaví je okamžitě. Cílová doba obnovy: obvykle 4–24 hodin. Cílový bod obnovy: obvykle 1–4 hodiny. Příklady: systémy CRM, moduly ERP, správa objednávek, HR systémy během mzdových období, systémy pro podávání zpráv během období pro podávání regulačních požadavků. Tyto aplikace ospravedlňují infrastrukturu s vysokou dostupností, pravidelně testované failovery a prioritní pořadí obnovy.
Úroveň 3, Provozní obchodní aplikace, které podporují obchodní operace, ale jejichž dočasnou nedostupnost lze zvládnout manuálními řešeními. Cílová doba obnovy: obvykle 24–72 hodin. Cílový bod obnovy: obvykle 4–24 hodin. Příklady: interní nástroje pro spolupráci, reporting nesouvisející se zákazníkem, administrativní portály, školicí platformy. Vhodné jsou standardní postupy zálohování a obnovy.
Úroveň 4, Administrativní aplikace, které podporují administrativní funkce bez přímého provozního dopadu. Cílová doba obnovy: obvykle 72+ hodin. Cílový bod obnovy: 24+ hodin nebo poslední záloha. Příklady: interní wiki s dokumentací, nepodstatné vývojové nástroje, historické reporty. Obnova ze zálohy na oportunistické bázi.
Přiřazení úrovně není trvalé. Aplikace, která je po většinu roku na úrovni 3, se může stát úrovní 2 během finanční uzávěrky na konci měsíce, období regulačního vykazování nebo vrcholných obchodních sezón. Dynamická kritičnost, kdy se přiřazení úrovně mění na základě provozního kalendáře, je upřesnění, které organizace s rozvinutými programy BCP implementují po stanovení základní struktury úrovní.
Metodika bodování: Převod dimenzí do čísel
Strukturovaná metodologie hodnocení převádí čtyři dimenze kritičnosti do číselného skóre, které objektivně řídí přiřazování úrovní, a nikoli na základě organizační politiky. Níže uvedený přístup vytváří kompozitní skóre od 0 do 100 s využitím vážených kritérií:
Dimenze 1: Dopad na podnikání (váha: 35 %)
| Dopad na tržby za hodinu prostoje | Skóre |
|---|---|
| > 1 milion dolarů za hodinu | 35 |
| 100 000 až 1 milion dolarů za hodinu | 28 |
| 10 000–100 000 USD za hodinu | 21 |
| 1 000–10 000 USD za hodinu | 14 |
| < 1 000 USD za hodinu | 7 |
| Žádný přímý dopad na příjmy | 0 |
Regulační dopad (povinnosti dodržování předpisů DORA, HIPAA, PCI-DSS, SOX vyvolané výpadkem) k tomuto rozměru přidává až 10 dalších bodů.
Dimenze 2: Provozní závislost (váha: 30 %)
| Fan-In: Aplikace závislé na této aplikaci | Skóre |
|---|---|
| > 20 závislých aplikací | 30 |
| 10–20 závislé aplikace | 24 |
| 5–9 závislé aplikace | 18 |
| 2–4 závislé aplikace | 12 |
| 1 závislá aplikace | 6 |
| Žádné vyživované osoby (samostatný) | 0 |
Počet připojení (fan-in) je zde počet strukturálních závislostí, tedy počet aplikací, které volají danou aplikaci, čtou její výstupy nebo jsou závislé na jejích datech, nikoli počet uživatelů nebo vnímaná důležitost. Tato dimenze je v průzkumech nejčastěji chybně vypočítávána, protože vlastníci aplikací neznají všechny své následné uživatele.
Dimenze 3: Složitost obnovy (váha: 20 %)
| Odhadovaná doba obnovy bez předpřipraveného DR | Skóre |
|---|---|
| > 72 hodin | 20 |
| 24-72 hodin | 16 |
| 8-24 hodin | 12 |
| 2-8 hodin | 8 |
| <2 hodin | 4 |
| Automatické přepnutí po selhání < 15 minut | 0 |
Dimenze 4: Citlivost dat a regulační povinnost (váha: 15 %)
| Klasifikace dat a regulační požadavky | Skóre |
|---|---|
| Regulované PII / PHI / CHD s explicitní povinností doby zotavení | 15 |
| Regulované údaje bez specifické povinnosti doby obnovení | 12 |
| Citlivé interní údaje (obchodní tajemství, finanční záznamy) | 9 |
| Interní provozní data | 6 |
| Necitlivá interní data | 3 |
| Nejsou uložena žádná data | 0 |
Mapování složeného skóre na úrovně:
| Složené skóre | Přiřazení úrovně |
|---|---|
| 75-100 | Úroveň 1, kriticky důležité |
| 50-74 | Úroveň 2, kritické pro podnikání |
| 25-49 | Úroveň 3, Provozní oddělení |
| 0-24 | Úroveň 4, Administrativní |
Problém závislosti: Proč je hodnocení založené na průzkumech chybné
Dimenze provozní závislosti je nejpravděpodobnějším faktorem, u kterého se chyba vypočítává, a má největší důsledky, když je chybná. Zdánlivě nekritická starší ověřovací služba může být jediným bodem selhání pro celou platformu elektronického obchodování a její selhání by mohlo zastavit všechny transakce generující příjmy. Tento proces přesahuje abstraktní hrozby a klade konkrétní, měřitelné dopady na dohody o úrovni služeb.
Vlastníci aplikací znají své přímé závislosti v upstreamu, tedy systémy, které volají. Zřídka znají své úplné závislosti v downstreamu, tedy systémy, které je volají. Interní služba ověřování uživatelů může být jejím vlastníkem považována za nízkokritickou (negeneruje příjmy, je jednoduchá, zřídka selhává), zatímco na ní závisí dvanáct aplikací orientovaných na zákazníka, které jsou všechny na úrovni Tier 1. Skutečná kritičnost ověřovací služby je na úrovni Tier 1, nikoli kvůli její vlastní funkci, ale kvůli její pozici v grafu závislostí systémů vyšší úrovně.
Hodnocení kritičnosti na základě průzkumu systematicky způsobuje tuto chybu. Průzkum mezi vlastníky aplikací se ptá: „Jak kritická je tato aplikace?“ Vlastník ověřovací služby odpovídá „nízká až střední“ na základě vlastní funkce služby. Dvanáct vlastníků závislých aplikací na tento průzkum neodpovídá o ověřovací službě, ale o svých vlastních aplikacích. Vztah závislosti se nikdy nezaznamená.
Důsledek se projeví v sekvenci obnovy: BCP definuje pořadí obnovy na základě skóre kritičnosti odvozených z průzkumu a autentizační služba je naplánována pro obnovu Tier 3. Během skutečného incidentu se aplikace Tier 1, které by se měly obnovit jako první, nemohou obnovit, protože autentizační služba, na které jsou závislé, nebyla obnovena. Sekvence obnovy selže v bodě své nejkritičtější závislosti.
Tři typy závislostí, které průzkumy soustavně přehlížejí:
Skryté sdílené komponenty. Interní program v COBOLu, který zpracovává převod měn pro tři samostatné obchodní procesy, z nichž žádný průzkum neidentifikoval jako sdílený komponent, je skrytá závislost, která ovlivňuje obnovu všech tří. Pokud je program pro převod měn úrovně 3 a kterýkoli ze tří obchodních procesů je úrovně 1, je efektivní kritická úroveň programu pro převod měn úrovně 1.
Závislosti datových kanálů. Aplikace, které spotřebovávají dávkově zpracovaná data z jiných aplikací, mají závislost, která je spíše časová než reálná. Riziko nespočívá v simultánním selhání, ale v sekvenčním: následná aplikace se obnoví, ale její zdroj dat nebyl obnoven do stejného bodu obnovy, což vytváří dojem správné funkčnosti na zastaralých datech. Tato třída závislosti se neobjevuje v mapách topologie sítě ani v analýze grafů volání, pokud není vysledován samotný tok dat.
Sdílená konfigurace a závislosti schémat. Aplikace, které sdílejí schémata databází, konfigurační služby nebo poskytovatele identit, mají implicitní závislost, i když se navzájem přímo nevolají. Změna schématu ve sdílené databázi může ovlivnit více aplikací. Obnovení jedné aplikace po poškození schématu bez obnovení všech aplikací, které schéma sdílejí, vede k nekonzistentnímu stavu v celém portfoliu aplikací.
Integrace BCP: Jak skóre kritičnosti ovlivňuje rozhodnutí o obnově
Skóre kritičnosti je vstupem pro šest specifických rozhodnutí o návrhu BCP:
1. Definice sekvence obnovy. Aplikace se obnovují v pořadí podle kritičnosti, úroveň 1 před úrovní 2 a poté úrovní 3, ale v rámci úrovně určuje sekvenci graf závislostí. Aplikace bez příchozích závislostí (žádná jiná aplikace na nich nezávisí) se mohou obnovit v libovolném pořadí v rámci své úrovně. Aplikace s vysokým stupněm závislosti se musí obnovit před svými závislými aplikacemi, bez ohledu na jejich relativní skóre v rámci úrovně. Sekvence obnovy je tedy: řazení úrovní aplikované na podsekvenci s omezenými závislostmi v rámci každé úrovně.
2. Stanovení cílů RTO a RPO. Skóre kritičnosti kalibruje cíle RTO a RPO. Maximální tolerovatelná doba výpadku (MTD) a cíl bodu obnovy (RPO) pro každou produkční aplikaci tvoří technický základ celé strategie kontinuity. MTD je maximální doba, kterou může podnik tolerovat nedostupnost aplikace. RTO musí být menší než MTD. Rozpětí mezi RTO a MTD představuje bezpečnostní rezervu. Aplikace úrovně 1 s vysokým dopadem na podnikání na hodinu výpadku mají úzké rezervy MTD/RTO a vyžadují infrastrukturu navrženou pro rychlou automatizovanou obnovu.
3. Kalibrace investic do infrastruktury. Skóre kritičnosti přímo ovlivňuje investiční rozhodnutí do infrastruktury DR. Aplikace úrovně Tier 1 ospravedlňují aktivní-aktivní multi-regionální redundanci. Aplikace úrovně Tier 2 ospravedlňují aktivní-pasivní redundanci s ověřeným failoverem. Aplikace úrovně Tier 3 ospravedlňují pravidelné zálohování se zdokumentovanými postupy obnovy. Aplikace úrovně 4 se mohou spoléhat na standardní zásady zálohování. Bez skóre kritičnosti se investiční rozhodnutí do infrastruktury standardně řídí buď jednotným nadměrným investováním (drahé), nebo jednotným nedostatečným investováním (rizikové).
4. Požadavky na řízení změn. Aplikace s vyšším skóre kritičnosti vyžadují přísnější řízení změn: delší okna pro zmrazení změn, více povinných schvalovatelů, rozsáhlejší testování před změnou, konzervativnější postupy vrácení změn. Aplikace řízení změn úrovně 1 na aplikace úrovně 4 plýtvá časem inženýrů. Aplikace řízení změn úrovně 4 na aplikace úrovně 1 vytváří nepřijatelné riziko.
5. Frekvence testování a validace. BCP vyžaduje pravidelné testování postupů obnovy, simulace simulace failoveru na úrovni komponent a úplné simulace obnovy po havárii. Frekvenci testování určují skóre kritičnosti: aplikace úrovně 1 vyžadují čtvrtletní testy DR; aplikace úrovně 4 vyžadují roční testy. Testování každé aplikace se stejnou frekvencí není ani praktické, ani nutné.
6. Požadavky na SLA dodavatele. U aplikací, které závisí na službách třetích stran, určuje skóre kritičnosti požadavky na SLA, které musí být uvedeny ve smlouvách s dodavateli. Aplikace úrovně 1 s 4hodinovou dobou trvání (RTO) vyžaduje SLA třetí strany, která zaručuje dostupnost v souladu s touto dobou trvání. Aplikace úrovně 4 nikoli.
Komplikace staršího systému
Zastaralé systémy komplikují hodnocení kritičnosti způsoby, které moderní rámce pro správu portfolia aplikací dostatečně neřeší. Standardní hodnocení kritičnosti předpokládá, že vlastníci aplikací vědí, co jejich aplikace dělají a kdo je na nich závislý. U starších systémů, programů v COBOLu, které byly udržovány několika generacemi vývojářů, toků úloh JCL, jejichž závislosti byly naposledy zdokumentovány v roce 2008, a programů RPG, které produkují výstupní soubory spotřebované procesy, které v současné době nikdo v organizaci nepsal, tento předpoklad neplatí.
Skutečná struktura závislostí staršího systému je viditelná pouze v samotném kódu. Program v COBOLu, který zapisuje do datové sady, kterou čte dvanáct následných programů, má dvanáct následných závislostí, ale tuto skutečnost nemusí znát vlastník programu v COBOLu, který vidí pouze funkci programu (zpracování denních transakcí) spíše než jeho strukturální roli (vytvoření datové sady, která umožňuje dvanáct dalších procesů).
U starších systémů vyžaduje dimenze závislostí skóre kritičnosti spíše analýzu kódu než průzkumy mezi vlastníky. Počet fan-inů pro program v COBOLu lze odvodit pouze prozkoumáním všech ostatních programů v prostředí a určením, které z nich odkazují na výstupní datové sady, konvence volání nebo sdílené sešity prvního programu. Tuto analýzu poskytují platformy pro strukturální analýzu kódu a bez ní je dimenze závislostí jakéhokoli skóre kritičnosti přiřazeného staršímu programu v nejlepším případě informovaným odhadem.
Důsledky chybného posouzení kritičnosti starších aplikací jsou obzvláště závažné, protože starší systémy bývají vysoce kritické (často obsahují základní obchodní logiku, která se hromadila po celá desetiletí) a špatně hodnocené (jejich majitelé neumí formulovat, co na nich závisí, takže jim přiřazují konzervativní skóre). Výsledkem jsou starší programy, kterým je přiřazena úroveň 3, ale které se ve skutečnosti nacházejí v kritické cestě obchodních procesů úrovně 1, což je přesný režim selhání, který se objevuje při selhání sekvence obnovy během skutečných incidentů.
Jak SMART TS XL Poskytuje důkazy o závislosti pro hodnocení kritičnosti
SMART TS XL přímo se zabývá dimenzí závislostí v bodování kritičnosti aplikací pro třídu aplikací, kde jsou přístupy založené na průzkumech nejméně spolehlivé.
Funkce mapování závislostí aplikací vytváří kompletní graf závislostí napříč všemi jazyky v prostředí: každý program v COBOLu, který volá všechny ostatní, každý krok úlohy JCL, který produkuje data spotřebovaná následnými programy, každý sdílený sešit, který vytváří implicitní závislost mezi programy, které se navzájem nikdy přímo nevolají, a každá datová sada, která proudí mezi programy producenta a spotřebitele. Tento graf představuje strukturální důkazní základnu pro dimenzi závislostí v bodování kritičnosti, počty fan-inů, identifikace sdílených komponent a skryté závislosti v datovém kanálu, které průzkumy nemohou spolehlivě zachytit.
Díky analýze dopadů je graf závislostí dotazovatelný pro plánování BCP: pro jakoukoli aplikaci v portfoliu vyjmenujte všechny ostatní aplikace, které na ní přímo nebo tranzitivně závisí, a proto dědí její požadavek na dostupnost. Program v COBOLu se třemi přímo závislými a dvaceti tranzitivními závislými (programy, které závisí na přímo závislých) má efektivní kritičnost, která odráží dvacet tři programů, u kterých se nachází v kritické cestě, nejen jeho vlastní funkci.
Funkce statické analýzy kódu odhaluje metriky strukturální složitosti, které ovlivňují dimenzi složitosti obnovy: cyklomatickou složitost, metriky propojení, procento mrtvého kódu a indikátory technického dluhu, které předpovídají, jak dlouho a jak riskantní bude obnova každé aplikace. Aplikace s vysokou složitostí a hustou vazbou je nákladnější na obnovu, její skóre složitosti obnovy v dimenzi 3 je vyšší než aplikace s ekvivalentní funkcí a čistou architekturou.
Funkce podnikového vyhledávání umožňuje dotazování na kompletní inventář závislostí v průběhu celého životního cyklu BCP: nalezení každého programu, který přistupuje ke specifické datové sadě (identifikace všech programů, které závisí na její dostupnosti), každého programu, který sdílí specifický sešit dat (identifikace všech programů ovlivněných její dostupností), každé úlohy JCL, která běží v specifickém dávkovém okně (identifikace všech programů, které se musí obnovit před začátkem tohoto okna). Tato funkce vyhledávání podporuje každoroční kontrolu skóre kritičnosti, proces aktualizace, který udržuje skóre aktuální s vývojem portfolia aplikací.
Pro organizace provádějící starší modernizace programy vedle vývoje BCP, SMART TS XLAnalýza slouží oběma účelům současně: mapa závislostí, která informuje o hodnocení kritičnosti, také určuje sekvenci migrace a metriky složitosti, které informují o hodnocení složitosti obnovy, také určují odhad modernizačního úsilí.
Udržování aktuálního skóre: Roční cyklus hodnocení
Posouzení vyspělosti kontinuity podnikání by vám mělo pomoci se třemi věcmi: pochopit váš současný stav, identifikovat nejdůležitější nedostatky a vytvořit realistickou cestu ke zlepšení. To je to, co promění hodnocení vyspělosti v lepší program.
Skóre kritickosti aplikací se s tím, jak se organizace mění, odchyluje od reality. Přidávají se nové aplikace. Staré aplikace jsou vyřazeny z provozu, ale nejsou zcela vyřazeny z provozu. Vytvářejí se integrace mezi aplikacemi, které dříve neměly žádnou závislost. Mění se obchodní procesy a s nimi i aplikace, na kterých závisí. Regulační požadavky se vyvíjejí a ukládají nové povinnosti obnovy.
Roční cyklus kontroly skóre kritičnosti by měl zahrnovat:
Strukturální reanalýza. Znovu spusťte mapování závislostí a identifikujte nové závislosti zavedené od poslední kontroly. Aplikace, které byly samostatné, nyní mohou mít závislosti, které zvyšují jejich důležitost. U aplikací, na kterých byla závislost vysoce závislá, mohlo dojít k migraci jejich uživatelů na novější systémy, což snížilo jejich důležitost.
Přehodnocení dopadu na podnikání. Údaje o tržbách a provozním dopadu se mění s růstem firmy a vývojem jejího portfolia aplikací. Aplikace, která před třemi lety zvládala obchodní hodnotu 1 000 dolarů za hodinu, může nyní po růstu firmy zvládat desetkrát více.
Začlenění výsledků testů obnovy. Testy DR odhalují rozdíly mezi předpokládanou a skutečnou složitostí obnovy. Aplikace, která v počátečním hodnocení dosáhla nízkého skóre složitosti obnovy, si mohla ve skupinovém testu vést špatně, což naznačuje revizi skóre směrem nahoru.
Přezkum změn v regulaci. Nové předpisy nebo změny stávajících předpisů mohou uložit nové povinnosti týkající se doby obnovy pro konkrétní aplikace. Například požadavky na provozní odolnost finančních institucí v EU podle nařízení DORA ukládají specifické povinnosti týkající se doby obnovy pro „kritické nebo důležité funkce“, které se nemusely odrážet ve skóre kritičnosti před vydáním nařízení DORA.
Organizace s rozvinutými programy BCP nepovažují hodnocení kritičnosti za jednorázové, ale za průběžný proces: skóre se aktualizuje, když dojde k významným změnám v závislostech aplikací, dopadu na podnikání nebo regulačních povinnostech, a každoročně se ověřuje prostřednictvím strukturovaného přezkumu.
Skóre je jen tak dobré, jako důkazy o jeho závislosti
Bodování kritickosti aplikací poskytuje největší hodnotu, když je jeho dimenze závislosti založena na strukturálních důkazech spíše než na průzkumech. Dimenze obchodního dopadu a regulačních povinností lze spolehlivě posoudit pomocí rozhovorů a analýzy obchodních procesů. Dimenzi provozní závislosti nelze, protože vyžaduje znalost toho, co na každé aplikaci závisí, a vlastníci aplikací systematicky podceňují své následné spotřebitele.
Způsob selhání je předvídatelný: sekvence obnovy postavená na skóre kritičnosti odvozených z průzkumu selže u skrytých závislostí. Starší ověřovací služba obnovuje pozdě. Program pro převod měn COBOL je offline, když se aplikace, které jsou na něm závislé, pokoušejí o obnovu. Schéma sdílené databáze je v jiném bodě obnovy než aplikace, které z něj čtou. Každému z těchto selhání lze předejít pomocí důkazů o závislostech, které poskytuje strukturální analýza, a každé z nich je nákladné, pokud k němu dojde během skutečného incidentu, nikoli během simulovaného cvičení.
Metodologie hodnocení je zavedena. Rámce existují. Mezera, kterou má většina organizací, nespočívá v rámci hodnocení, ale v důkazní základně pro jeho nejdůležitější rozměr. Tuto mezeru je třeba odstranit strukturální analýzou dříve, než další incident bude vyžadovat fungování BCP.
