Planlægning af forretningskontinuitet fejler oftest ikke under en krise, men under den vurdering, der går forud for en. Organisationer gennemfører Business Impact Analyses, dokumenterer mål for genopretningstid, opbygger omfattende genopretningshåndbøger og opdager derefter, på det værst tænkelige tidspunkt, at en tilsyneladende ikke-kritisk ældre godkendelsestjeneste er et enkelt fejlpunkt for hele deres e-handelsplatform, at COBOL-batchprogrammet, som alle antog havde lav prioritet, føder realtidsbetalingsvalideringstjenesten, eller at to applikationer, der er tildelt det samme genoprettelsesniveau, har en udokumenteret afhængighed, der gør sekventiel genopretning umulig. Scoringen blev udført. Afhængighederne blev ikke.
Scoring af applikationskritikalitet er processen med at tildele en kvantitativ eller niveaudelt måling af vigtighed til hver applikation i en organisations portefølje. Denne måling bestemmer dens genoprettelsesprioritet, dens redundansinvesteringsniveau, dens krav til ændringskontrol og dens position i sekvensering af katastrofegendannelse. Når denne scoring udelukkende er baseret på forretningsmæssige konsekvensundersøgelser og interviews med applikationsejere, afspejler den, hvad folk mener, at applikationerne gør. Når den er baseret på en strukturel analyse af, hvad applikationerne rent faktisk gør, hvem der ringer til hvem, hvilke data der flyder gennem hvilke programmer, og hvilke delte komponenter der befinder sig i den kritiske sti for flere systemer med højere prioritet, afspejler den den operationelle virkelighed.
Det er i kløften mellem tro og virkelighed, at forretningskontinuitetsplaner fejler.
Gendannelsessekvenser, der afspejler faktiske afhængigheder
SMART TS XL identificerer alle programmer i den kritiske sti for dine Tier 1-applikationer – på tværs af alle sprog i din portefølje.
FÅ MERE AT VIDE…Hvad applikationskritisk scoring rent faktisk måler
Kritiskhed er ikke en enkelt dimension. For at bestemme virksomhedsapplikationens kritiskhedsscore kan man tage brugerinput i betragtning for at vurdere en virksomhedsapplikations kritiskhed eller vigtighed, herunder den største indvirkning på strategiske forretningsbehov, indvirkning på forretningspartnere, kundeinteraktioner og indvirkning på andre virksomhedsapplikationer. Hver af disse dimensioner indfanger et forskelligt aspekt af, hvad "kritisk" betyder:
Forretningsmæssig påvirkning , hvad organisationen taber pr. times nedetid. Tab af omsætning er den mest synlige dimension: et betalingssystem, der håndterer 10 millioner dollars i timen, har en kvantificerbar omkostning pr. minuts afbrydelse. Men forretningsmæssig påvirkning rækker ud over omsætningen til lovgivningsmæssig eksponering (hvilke compliance-forpligtelser udløser afbrydelsen?), omdømmeskade (er kunderne direkte berørt?) og kontraktlige sanktioner (udløser SLA'er sanktionsklausuler?).
Operationel afhængighed , hvor mange andre systemer eller processer er afhængige af denne applikation. En applikation med lav direkte forretningsmæssig påvirkning kan have høj kritisk karakter, fordi den sidder i afhængighedsstien for applikationer med høj direkte påvirkning. Den godkendelsestjeneste, der muliggør alle andre kundevendte applikationer, er mere kritisk, end dens egen funktion antyder.
Gendannelseskompleksitet , hvor vanskelig og tidskrævende applikationen er at gendanne. En applikation med moderat forretningspåvirkning og en gendannelsestid på 48 timer kan kræve højere investeringer i redundans end en applikation med højere forretningspåvirkning og en gendannelsestid på 2 timer, fordi den samlede risiko for nedetid er større.
Reguleringspligt , hvilke applikationer er underlagt regulatoriske kontinuitetskrav. Finansielle institutioner, der er underlagt DORA, skal demonstrere, at kritiske eller vigtige funktioner kan modstå specificerede forstyrrelsesscenarier. Sundhedsorganisationer, der er underlagt HIPAA, skal beskytte tilgængeligheden af systemer, der indeholder beskyttede sundhedsoplysninger. Den regulatoriske dimension kan tilsidesætte scoren for forretningsmæssig påvirkning for specifikke applikationer.
Kritiskhedsscoren er en sammensætning af alle fire dimensioner, vægtet af organisationens specifikke risikotolerance, lovgivningsmæssige miljø og forretningsmodel.
Standardkritikniveauerne
De fleste porteføljer af virksomhedsapplikationer bruger en fire-lags kritikalitetsmodel. Kategorier af kritikalitet i en applikationskritikalitetsmatrix er Missionskritisk, Forretningskritisk, Forretningsdriftsmæssig og Administrativ. Definitionerne nedenfor afspejler den nuværende branchepraksis i overensstemmelse med ISO 22301 (Business Continuity Management Systems) og Business Continuity Institutes retningslinjer for god praksis:
Tier 1, Missionskritiske applikationer, hvis svigt øjeblikkeligt stopper kerneforretningens drift eller skaber en uacceptabel regulatorisk eller sikkerhedsmæssig risiko. Genopretningstidsmål (RTO): typisk 0-4 timer. Genopretningspunktsmål (RPO): typisk 0-1 time. Eksempler: kernebanktransaktionsbehandling, realtidshandelssystemer, nødforsendelsessystemer, industrielle kontrolgrænseflader, betalingsautorisationssystemer. Disse applikationer berettiger den højeste infrastrukturinvestering: aktiv-aktiv redundans, nul-RPO-replikering, automatiseret failover og den mest strenge ændringskontrol.
Tier 2, Forretningskritiske applikationer, hvis fejl forringer forretningsdriften betydeligt, men ikke stopper den øjeblikkeligt. Mål for genoprettelsestid: typisk 4-24 timer. Mål for genoprettelsespunkt: typisk 1-4 timer. Eksempler: CRM-systemer, ERP-moduler, ordrehåndtering, HR-systemer i lønperioder, rapporteringssystemer i vinduer for indsendelse af regulatoriske oplysninger. Disse applikationer berettiger infrastruktur med høj tilgængelighed, regelmæssig testet failover og prioriteret genoprettelsessekvensering.
Tier 3, Forretningsdriftsapplikationer , der understøtter forretningsdrift, men hvis midlertidige utilgængelighed kan håndteres med manuelle løsninger. Målsætning for genoprettelsestid: typisk 24-72 timer. Målsætning for genoprettelsespunkt: typisk 4-24 timer. Eksempler: interne samarbejdsværktøjer, ikke-kundevendt rapportering, administrative portaler, træningsplatforme. Standardprocedurer for backup og gendannelse er passende.
Tier 4, Administrative applikationer, der understøtter administrative funktioner uden direkte driftsmæssig påvirkning. Mål for gendannelsestid: typisk 72+ timer. Mål for gendannelsespunkt: 24+ timer eller sidste backup. Eksempler: wikier til intern dokumentation, ikke-essentielle udviklingsværktøjer, historisk rapportering. Gendannelse fra backup på et opportunistisk grundlag.
Tiertildelingen er ikke permanent. En applikation, der er Tier 3 det meste af året, kan blive Tier 2 i løbet af månedsafslutningen, regulatoriske rapporteringsperioder eller travle handelssæsoner. Dynamisk kritikalitet, hvor tiertildelingen ændres baseret på driftskalenderen, er en forbedring, som organisationer med modne BCP-programmer implementerer efter etablering af den grundlæggende tierstruktur.
Scoringsmetoden: Oversættelse af dimensioner til tal
En struktureret scoringsmetode konverterer de fire kritiske dimensioner til en numerisk score, der styrer niveautildeling objektivt snarere end ud fra organisationspolitik. Nedenstående tilgang producerer en sammensat score fra 0-100 ved hjælp af vægtede kriterier:
Dimension 1: Forretningsmæssig påvirkning (vægtning: 35%)
| Omsætningspåvirkning pr. time nedetid | Score |
|---|---|
| > 1 million dollars i timen | 35 |
| 100-1 dollars i timen | 28 |
| 10-100 dollars i timen | 21 |
| 1-10 dollars i timen | 14 |
| < $1 i timen | 7 |
| Ingen direkte indvirkning på indtægterne | 0 |
Reguleringsmæssig påvirkning (DORA, HIPAA, PCI-DSS, SOX-complianceforpligtelser udløst af strømafbrydelser) tilføjer op til 10 yderligere point til denne dimension.
Dimension 2: Operationel afhængighed (vægtning: 30%)
| Fan-In: Applikationer afhængigt af denne applikation | Score |
|---|---|
| > 20 afhængige applikationer | 30 |
| 10-20 afhængige applikationer | 24 |
| 5-9 afhængige applikationer | 18 |
| 2-4 afhængige applikationer | 12 |
| 1 afhængig applikation | 6 |
| Ingen pårørende (selvstændig) | 0 |
Fan-in-antallet her er antallet af strukturelle afhængigheder, antallet af applikationer, der kalder denne applikation, læser dens output eller er afhængige af dens data, ikke antallet af brugere eller den opfattede vigtighed. Denne dimension er den, der oftest fejlberegnes i undersøgelser, fordi applikationsejere ikke kender alle deres downstream-forbrugere.
Dimension 3: Genopretningskompleksitet (vægtning: 20%)
| Estimeret genopretningstid uden præbygget DR | Score |
|---|---|
| > 72 timer | 20 |
| 24-72 timer | 16 |
| 8-24 timer | 12 |
| 2-8 timer | 8 |
| <2 timer | 4 |
| Automatisk failover < 15 minutter | 0 |
Dimension 4: Datafølsomhed og lovgivningsmæssige forpligtelser (vægtning: 15%)
| Dataklassificering og lovgivningsmæssige krav | Score |
|---|---|
| Reguleret PII / PHI / CHD med eksplicit forpligtelse til gendannelsestid | 15 |
| Regulerede data uden specifik forpligtelse til gendannelsestid | 12 |
| Følsomme interne data (forretningshemmeligheder, økonomiske optegnelser) | 9 |
| Interne driftsdata | 6 |
| Ikke-følsomme interne data | 3 |
| Ingen data gemt | 0 |
Sammensat score til niveaukortlægning:
| Sammensat score | Niveautildeling |
|---|---|
| 75-100 | Niveau 1, Missionskritisk |
| 50-74 | Niveau 2, Forretningskritisk |
| 25-49 | Niveau 3, Forretningsdrift |
| 0-24 | Niveau 4, Administrativ |
Afhængighedsproblemet: Hvorfor spørgeskemabaseret scoring tager fejl
Dimensionen operationel afhængighed er den, der mest sandsynligt bliver fejlberegnet, og det er den, der har den største konsekvens, når den er forkert. En tilsyneladende ikke-kritisk, ældre godkendelsestjeneste kan være et enkelt fejlpunkt for en hel e-handelsplatform, og dens fejl kan stoppe alle indtægtsgenererende transaktioner. Denne proces går ud over abstrakte trusler til konkrete, målbare konsekvenser for serviceniveauaftaler.
Applikationsejere kender deres direkte upstream-afhængigheder, de systemer, de kalder. De kender sjældent deres komplette downstream-afhængigheder, de systemer, der kalder dem. En intern brugergodkendelsestjeneste kan betragtes som lavkritisk af sin ejer (den er ikke indtægtsgenererende, den er simpel, den fejler sjældent), mens den er afhængig af tolv kundevendte applikationer, der alle er Tier 1. Godkendelsestjenestens faktiske kritikalitet er Tier 1, ikke på grund af dens egen funktion, men på grund af dens placering i afhængighedsgrafen for systemer på højere niveau.
Kritikalitetsscoring baseret på spørgeskemaundersøgelser producerer denne fejl systematisk. En undersøgelse blandt applikationsejere spørger: "Hvor kritisk er denne applikation?" Ejeren af godkendelsestjenesten svarer "lav til medium" baseret på tjenestens egen funktion. De tolv afhængige applikationsejere besvarer ikke denne undersøgelse om godkendelsestjenesten, de svarer om deres egne applikationer. Afhængighedsforholdet registreres aldrig.
Konsekvensen vises i genoprettelsessekvenseringen: BCP'en definerer genoprettelsesrækkefølgen baseret på de undersøgelsesafledte kritikalitetsscorer, og godkendelsestjenesten er planlagt til Tier 3-gendannelse. Under en faktisk hændelse kan de Tier 1-applikationer, der først skal gendannes, ikke gendannes, fordi den godkendelsestjeneste, de er afhængige af, ikke er blevet gendannet. Gendannelsessekvensen fejler på det punkt, hvor den er mest kritisk afhængig.
Tre afhængighedstyper, som undersøgelser konsekvent overser:
Skjulte delte komponenter. Et internt COBOL-program, der håndterer valutakonvertering for tre separate forretningsprocesser, hvoraf ingen af undersøgelsen identificerede som delede komponent, er en skjult afhængighed, der påvirker gendannelsen af alle tre. Hvis valutakonverteringsprogrammet er niveau 3, og en af de tre forretningsprocesser er niveau 1, er valutakonverteringsprogrammets effektive kritikalitet niveau 1.
Afhængigheder i datapipelines. Applikationer, der forbruger batchbehandlede data fra andre applikationer, har en afhængighed, der er tidsmæssig snarere end realtidsafhængig. Risikoen er ikke samtidig fejl, men sekventiel: downstream-applikationen gendannes, men dens datakilde er ikke blevet gendannet til det samme gendannelsespunkt, hvilket giver indtryk af korrekt drift på forældede data. Denne klasse af afhængighed vises ikke i netværkstopologikort eller call-graph-analyse, medmindre selve dataflowet spores.
Delt konfiguration og skemaafhængigheder. Applikationer, der deler databaseskemaer, konfigurationstjenester eller identitetsudbydere, har en implicit afhængighed, selvom de aldrig kalder hinanden direkte. En skemaændring i en delt database kan påvirke flere applikationer. Gendannelse af én applikation efter en skemafejl uden at gendanne alle applikationer, der deler skemaet, producerer inkonsistent tilstand på tværs af applikationsporteføljen.
BCP-integration: Hvordan kritiske scorer driver beslutninger om genopretning
Kritiskhedsscoren er inputtet til seks specifikke BCP-designbeslutninger:
1. Definition af gendannelsessekvens. Applikationer gendannes i kritisk rækkefølge, niveau 1 før niveau 2 før niveau 3, men inden for et niveau bestemmer afhængighedsgrafen rækkefølgen. Applikationer uden indgående afhængigheder (ingen andre applikationer er afhængige af dem) kan gendannes i enhver rækkefølge inden for deres niveau. Applikationer med høj fan-in skal gendannes før deres afhængige, uanset deres relative score inden for niveauet. Gendannelsessekvensen er derfor: niveaurækkefølge anvendt på den afhængighedsbegrænsede undersekvens inden for hvert niveau.
2. Fastsættelse af RTO- og RPO-mål. Kritikalitetsscoren kalibrerer RTO- og RPO-målene. Den maksimalt tolerable nedetid (MTD) og gendannelsespunktsmålet (RPO) for hver produktionsapplikation danner det tekniske grundlag for hele kontinuitetsstrategien. MTD er den maksimale tid, virksomheden kan tolerere, at en applikation er utilgængelig. RTO skal være mindre end MTD. Marginalen mellem RTO og MTD er sikkerhedsbufferen. Tier 1-applikationer med høj forretningsmæssig påvirkning pr. times nedetid har smalle MTD/RTO-marginer og kræver infrastruktur designet til hurtig automatiseret gendannelse.
3. Kalibrering af infrastrukturinvesteringer. Kritikalitetsscorer styrer direkte investeringsbeslutninger om DR-infrastruktur. Tier 1-applikationer retfærdiggør aktiv-aktiv redundans i flere regioner. Tier 2-applikationer retfærdiggør aktiv-passiv med testet failover. Tier 3-applikationer retfærdiggør regelmæssig backup med dokumenterede gendannelsesprocedurer. Tier 4-applikationer kan stole på standard backuppolitikker. Uden kritikalitetsscorer ender beslutninger om infrastrukturinvesteringer som standard med enten ensartet overinvestering (dyrt) eller ensartet underinvestering (risikabelt).
4. Krav til ændringskontrol. Applikationer med højere kritikalitetsscorer kræver mere stringent ændringskontrol: længere vinduer til ændringsfrysning, flere obligatoriske godkendere, mere omfattende test før ændringer, mere konservative tilbagerulningsprocedurer. Anvendelse af Tier 1-ændringskontrol på Tier 4-applikationer spilder ingeniørtid. Anvendelse af Tier 4-ændringskontrol på Tier 1-applikationer skaber en uacceptabel risiko.
5. Test- og valideringsfrekvens. BCP kræver periodisk test af gendannelsesprocedurer, øvelser på komponentniveau, failover-tests på komponentniveau og fulde simuleringer af katastrofegendannelse. Kritikalitetsscorer bestemmer testfrekvensen: Tier 1-applikationer kræver kvartalsvise DR-tests; Tier 4-applikationer kræver årlige tests. Test af alle applikationer med samme hyppighed er hverken praktisk eller nødvendigt.
6. Krav til leverandør-SLA'er. For applikationer, der er afhængige af tredjepartstjenester, bestemmer kritikalitetsscoren de SLA-krav, der skal være i leverandørkontrakterne. En Tier 1-applikation med en 4-timers RTO kræver en tredjeparts-SLA, der garanterer tilgængelighed i overensstemmelse med den pågældende RTO. En Tier 4-applikation gør ikke.
Komplikationen med det ældre system
Ældre systemer komplicerer kritikalitetsscoring på måder, som moderne applikationsporteføljestyringsrammer ikke i tilstrækkelig grad adresserer. Standardkritikalitetsvurderingen antager, at applikationsejere ved, hvad deres applikationer gør, og hvem der er afhængige af dem. For ældre systemer, COBOL-programmer, der er blevet vedligeholdt af flere generationer af udviklere, JCL-jobstrømme, hvis afhængigheder sidst blev dokumenteret i 2008, og RPG-programmer, der producerer outputfiler, der forbruges af processer, som ingen i øjeblikket arbejder i organisationen har skrevet, holder denne antagelse ikke.
Den faktiske afhængighedsstruktur i et ældre system er kun synlig i selve koden. Et COBOL-program, der skriver til et datasæt, som tolv downstream-programmer læser, har tolv downstream-afhængigheder, men denne kendsgerning er muligvis ikke kendt af COBOL-programmets ejer, som kun ser programmets funktion (behandler daglige transaktioner) snarere end dets strukturelle rolle (producerer det datasæt, der muliggør tolv andre processer).
For ældre systemer kræver afhængighedsdimensionen af kritikalitetsscoring kodeanalyse snarere end ejerundersøgelser. Fan-in-antallet for et COBOL-program kan kun udledes ved at undersøge alle andre programmer i miljøet og bestemme, hvilke der refererer til det første programs outputdatasæt, kaldskonventioner eller delte kopibøger. Denne analyse er, hvad strukturelle kodeanalyseplatforme leverer, og uden den er afhængighedsdimensionen af enhver kritikalitetsscore, der er tildelt et ældre program, i bedste fald et informeret gæt.
Konsekvensen af at fejlvurdere kritiskheden af ældre applikationer er særligt alvorlig, fordi ældre systemer har en tendens til at være både meget kritiske (de indeholder ofte kerneforretningslogik, der er akkumuleret over årtier) og dårligt scorede (deres ejere kan ikke formulere, hvad der afhænger af dem, så de tildeler konservative scorer). Resultatet er ældre programmer tildelt Tier 3, som faktisk befinder sig i den kritiske sti for Tier 1-forretningsprocesser, den præcise fejltilstand, der opstår i fejl i genoprettelsessekvenser under faktiske hændelser.
Hvordan SMART TS XL Giver afhængighedsbeviset for kritiskhedsscoring
SMART TS XL adresserer afhængighedsdimensionen af applikationskritisk scoring direkte for den klasse af applikationer, hvor undersøgelsesbaserede tilgange er mindst pålidelige.
Funktionen til kortlægning af applikationsafhængigheder opbygger den komplette afhængighedsgraf på tværs af alle sprog i miljøet: hvert COBOL-program, der kalder hinanden, hvert JCL-jobtrin, der producerer data, der forbruges af downstream-programmer, hver delt kopibog, der opretter en implicit afhængighed mellem programmer, der aldrig kalder hinanden direkte, og hvert datasæt, der flyder mellem producent- og forbrugerprogrammer. Denne graf er det strukturelle evidensgrundlag for afhængighedsdimensionen af kritikalitetsscoring, fan-in-tællingerne, de delte komponentidentifikationer og de skjulte datapipeline-afhængigheder, som undersøgelser ikke pålideligt kan indfange.
Effektanalysefunktionen gør afhængighedsgrafen forespørgbar til BCP-planlægning: for enhver applikation i porteføljen skal alle andre applikationer, der afhænger af den, direkte eller transitivt, og derfor arver dens tilgængelighedskrav , opregnes. Et COBOL-program med tre direkte afhængige og tyve transitive afhængige (programmer, der afhænger af de direkte afhængige) har en effektiv kritikalitet, der afspejler de treogtyve programmer, det er i den kritiske sti for, ikke kun sin egen funktion.
Funktionen til statisk kodeanalyse afslører de strukturelle kompleksitetsmålinger, der informerer dimensionen for gendannelseskompleksitet: cyklomatisk kompleksitet, koblingsmålinger, procentdel af død kode og indikatorer for teknisk gæld, der forudsiger, hvor lang og hvor risikabel gendannelsen af hver applikation vil være. En applikation med høj kompleksitet og tæt kobling er dyrere at gendanne, dens dimension 3-gendannelseskompleksitetsscore er højere end en applikation med tilsvarende funktioner og ren arkitektur.
Virksomhedssøgningsfunktionen gør det muligt at forespørge på hele afhængighedsopgørelsen i hele BCP-livscyklussen: find alle programmer, der tilgår et specifikt datasæt (identificering af alle programmer , der er afhængige af dets tilgængelighed), alle programmer, der deler en specifik kopibog (identificering af alle programmer, der er berørt af dets tilgængelighed), og alle JCL-job, der kører i et specifikt batchvindue (identificering af alle programmer, der skal gendannes, før vinduet starter). Denne søgefunktion understøtter den årlige gennemgang af kritikalitetsscoren, opdateringsprocessen, der holder scorerne opdaterede, efterhånden som applikationsporteføljen udvikler sig.
For organisationer, der udfører arvemodernisering programmer sideløbende med BCP-udvikling, SMART TS XLs analyse tjener begge formål samtidigt: afhængighedskortet, der informerer kritikalitetsscoring, bestemmer også migrationssekvensering, og de kompleksitetsmålinger, der informerer genoprettelseskompleksitetsscoring, bestemmer også estimering af moderniseringsindsatsen.
Hold scorer opdateret: Den årlige evalueringscyklus
En modenhedsvurdering af forretningskontinuitet bør hjælpe dig med tre ting: at forstå din nuværende tilstand, identificere de mangler, der betyder mest, og opbygge en realistisk vej til forbedring. Det er det, der forvandler modenhedsscoring til et bedre program.
Scorer for applikationskritikalitet afviger fra virkeligheden, efterhånden som organisationer ændrer sig. Nye applikationer tilføjes. Gamle applikationer udfases, men tages ikke helt ud af drift. Integrationer bygges mellem applikationer, der tidligere ikke havde nogen afhængighed. Forretningsprocesser ændrer sig, og med dem de applikationer, de er afhængige af. Lovgivningsmæssige krav udvikler sig og pålægger nye gendannelsesforpligtelser.
Den årlige evalueringscyklus for kritikalitetsscorer bør omfatte:
Strukturel reanalyse. Gentag afhængighedskortlægningen for at identificere nye afhængigheder, der er introduceret siden sidste gennemgang. Applikationer, der var enkeltstående, kan nu have afhængigheder, der øger deres kritikalitet. Applikationer, der var meget afhængige af, kan have haft deres forbrugere, der migrerer til nyere systemer, hvilket reducerer deres kritikalitet.
Revurdering af forretningsmæssig påvirkning. Tallene for omsætning og driftsmæssig påvirkning ændrer sig, efterhånden som virksomheden vokser, og dens applikationsportefølje udvikler sig. En applikation, der håndterede en forretningsværdi på 1 USD i timen for tre år siden, kan nu håndtere ti gange så meget efter forretningsvækst.
Integration af resultater fra recovery-tests. DR-tests afslører forskelle mellem antaget og faktisk recovery-kompleksitet. En applikation, der scorede lavt på recovery-kompleksitet i den indledende vurdering, kan have klaret sig dårligt i en skemabaseret øvelse, hvilket tyder på en opjustering af scoren.
Gennemgang af reguleringsændringer. Nye reguleringer eller ændringer af eksisterende reguleringer kan pålægge nye forpligtelser til genopretningstid for specifikke applikationer. DORA-forordningens krav til operationel robusthed for EU's finansielle institutioner har for eksempel pålagt specifikke RTO-forpligtelser for "kritiske eller vigtige funktioner", som muligvis ikke er afspejlet i kritikalitetsscorerne før DORA.
Organisationer med veludviklede BCP-programmer behandler kritikalitetsscoring ikke som en engangsøvelse, men som en kontinuerlig proces: Scorer opdateres, når der sker væsentlige ændringer i applikationsafhængigheder, forretningsmæssig påvirkning eller lovgivningsmæssige forpligtelser, og valideres årligt gennem struktureret gennemgang.
Scoren er kun så god som dens afhængighedsbevis
Scoring af applikationskritikalitet giver mest værdi, når dens afhængighedsdimension er baseret på strukturel evidens snarere end undersøgelser. Dimensionerne for forretningsmæssig påvirkning og lovgivningsmæssige forpligtelser kan vurderes pålideligt gennem interviews og forretningsprocesanalyser. Dimensionen for operationel afhængighed kan ikke, fordi den kræver viden om, hvad der afhænger af hver applikation, og applikationsejere undervurderer systematisk deres downstream-forbrugere.
Fejltilstanden er forudsigelig: en gendannelsessekvens bygget på undersøgelsesafledte kritikalitetsscorer fejler ved de skjulte afhængigheder. En ældre godkendelsestjeneste gendanner sent. Et COBOL-valutakonverteringsprogram er offline, når de applikationer, der er afhængige af det, forsøger gendannelse. Et delt databaseskema er på et andet gendannelsespunkt end de applikationer, der læser fra det. Hver af disse fejl kan forebygges med den afhængighedsbevis, som strukturel analyse leverer, og hver af dem er dyre, når de opstår under en faktisk hændelse snarere end under en bordøvelse.
Scoringsmetoden er etableret. Rammerne eksisterer. Det hul, som de fleste organisationer har, ligger ikke i scoringsrammen, men i evidensgrundlaget for dens mest betydningsfulde dimension. Luk dette hul med strukturel analyse, før den næste hændelse kræver, at grænsekontrolpunktet fungerer.
