La pianificazione della continuità operativa fallisce il più delle volte non durante una crisi, ma durante la valutazione che la precede. Le organizzazioni completano analisi dell'impatto aziendale, documentano gli obiettivi di tempo di ripristino, creano playbook di ripristino completi e poi scoprono, nel peggior momento possibile, che un servizio di autenticazione legacy apparentemente non critico rappresenta un singolo punto di guasto per l'intera piattaforma di e-commerce, che il programma batch COBOL che tutti consideravano a bassa priorità alimenta il servizio di convalida dei pagamenti in tempo reale, o che due applicazioni assegnate allo stesso livello di ripristino hanno una dipendenza non documentata che rende impossibile il ripristino sequenziale. La valutazione è stata fatta. Le dipendenze no.
La valutazione della criticità delle applicazioni è il processo di assegnazione di un punteggio quantitativo o a livelli di importanza a ciascuna applicazione nel portfolio di un'organizzazione. Tale punteggio determina la priorità di ripristino, il livello di investimento in ridondanza, i requisiti di gestione delle modifiche e la posizione nella sequenza di ripristino di emergenza. Quando la valutazione si basa esclusivamente su sondaggi sull'impatto aziendale e interviste ai responsabili delle applicazioni, riflette ciò che le persone credono che le applicazioni facciano. Quando invece si fonda su un'analisi strutturale di ciò che le applicazioni effettivamente fanno, di chi chiama chi, di quali dati transitano attraverso quali programmi e di quali componenti condivisi si trovano nel percorso critico di più sistemi ad alta priorità, riflette la realtà operativa.
Il divario tra le convinzioni e la realtà è il punto in cui i piani di continuità aziendale falliscono.
Sequenze di recupero che rispecchiano le dipendenze reali
SMART TS XL Identifica ogni programma nel percorso critico delle tue applicazioni di livello 1, in ogni linguaggio del tuo portfolio.
SCOPRI DI PIÙ…Cosa misura effettivamente il punteggio di criticità delle applicazioni?
La criticità non è una dimensione univoca. Per determinare il punteggio di criticità di un'applicazione aziendale, si può tenere conto del feedback degli utenti per valutare la criticità o l'importanza dell'applicazione stessa, considerando il maggiore impatto sulle esigenze strategiche aziendali, l'impatto sui partner commerciali, le interazioni con i clienti e l'impatto su altre applicazioni aziendali. Ciascuna di queste dimensioni coglie un aspetto diverso del significato di "critico":
L'impatto sul business si riferisce alle perdite subite dall'organizzazione per ogni ora di inattività. La perdita di fatturato è la dimensione più visibile: un sistema di elaborazione dei pagamenti che gestisce 10 milioni di dollari all'ora ha un costo quantificabile per ogni minuto di interruzione. Ma l'impatto sul business si estende oltre il fatturato e comprende l'esposizione normativa (quali obblighi di conformità comporta l'interruzione?), il danno reputazionale (i clienti sono direttamente interessati?) e le penali contrattuali (gli SLA prevedono clausole penali?).
Dipendenza operativa : quanti altri sistemi o processi dipendono da questa applicazione. Un'applicazione con un basso impatto diretto sul business può avere un'elevata criticità perché si trova nel percorso di dipendenza di applicazioni con un impatto diretto elevato. Il servizio di autenticazione che abilita tutte le altre applicazioni rivolte al cliente è più critico di quanto la sua stessa funzione lasci intendere.
Complessità del ripristino : quanto è difficile e dispendioso in termini di tempo ripristinare l'applicazione. Un'applicazione con un impatto aziendale moderato e un tempo di ripristino di 48 ore potrebbe richiedere un investimento maggiore in ridondanza rispetto a un'applicazione con un impatto aziendale maggiore e un tempo di ripristino di 2 ore, perché il rischio complessivo di inattività è maggiore.
Obbligo normativo , per cui le applicazioni sono soggette a requisiti di continuità normativa. Gli istituti finanziari soggetti al DORA devono dimostrare che le funzioni critiche o importanti possono resistere a specifici scenari di interruzione. Le organizzazioni sanitarie soggette all'HIPAA devono proteggere la disponibilità dei sistemi contenenti informazioni sanitarie protette. La dimensione normativa può prevalere sulla valutazione dell'impatto aziendale per applicazioni specifiche.
Il punteggio di criticità è una combinazione di tutte e quattro le dimensioni, ponderate in base alla tolleranza al rischio specifica dell'organizzazione, al contesto normativo e al modello di business.
I livelli di criticità standard
La maggior parte dei portfolio di applicazioni aziendali utilizza un modello di criticità a quattro livelli. Le categorie di criticità in una matrice di criticità delle applicazioni sono: Mission Critical, Business Critical, Business Operational e Administrative. Le definizioni riportate di seguito riflettono le attuali prassi del settore, in linea con la norma ISO 22301 (Sistemi di gestione della continuità operativa) e le linee guida sulle buone pratiche del Business Continuity Institute:
Applicazioni di livello 1, mission-critical, il cui guasto arresta immediatamente le operazioni aziendali principali o crea un rischio inaccettabile in termini di regolamentazione o sicurezza. Tempo di ripristino (RTO): in genere da 0 a 4 ore. Punto di ripristino (RPO): in genere da 0 a 1 ora. Esempi: elaborazione delle transazioni bancarie, sistemi di trading in tempo reale, sistemi di gestione delle emergenze, interfacce di controllo industriale, sistemi di autorizzazione dei pagamenti. Queste applicazioni giustificano il massimo investimento in infrastrutture: ridondanza attivo-attivo, replica a RPO zero, failover automatico e controllo delle modifiche più rigoroso.
Livello 2, applicazioni critiche per l'azienda il cui guasto compromette significativamente le operazioni aziendali ma non le arresta immediatamente. Obiettivo di tempo di ripristino (RTO): in genere 4-24 ore. Obiettivo di punto di ripristino (RPO): in genere 1-4 ore. Esempi: sistemi CRM, moduli ERP, gestione degli ordini, sistemi HR durante i periodi di elaborazione delle buste paga, sistemi di reporting durante le finestre di presentazione normativa. Queste applicazioni giustificano un'infrastruttura ad alta disponibilità, failover testati regolarmente e una sequenza di ripristino prioritaria.
Livello 3, Applicazioni operative aziendali che supportano le attività aziendali ma la cui indisponibilità temporanea può essere gestita con soluzioni alternative manuali. Obiettivo di tempo di ripristino (RTO): in genere 24-72 ore. Obiettivo di punto di ripristino (RPO): in genere 4-24 ore. Esempi: strumenti di collaborazione interna, reportistica non rivolta ai clienti, portali amministrativi, piattaforme di formazione. Sono appropriate le procedure standard di backup e ripristino.
Livello 4, Applicazioni amministrative che supportano funzioni amministrative senza impatto operativo diretto. Obiettivo di tempo di ripristino: in genere 72+ ore. Obiettivo di punto di ripristino: 24+ ore o ultimo backup. Esempi: wiki di documentazione interna, strumenti di sviluppo non essenziali, report storici. Ripristino da backup in base alle necessità.
L'assegnazione al livello non è permanente. Un'applicazione che si trova al livello 3 per la maggior parte dell'anno può diventare di livello 2 durante la chiusura finanziaria di fine mese, i periodi di rendicontazione normativa o i periodi di picco delle attività di trading. La criticità dinamica, in cui l'assegnazione al livello cambia in base al calendario operativo, è un perfezionamento che le organizzazioni con programmi BCP maturi implementano dopo aver stabilito la struttura di base dei livelli.
Metodologia di punteggio: tradurre le dimensioni in numeri
Una metodologia di punteggio strutturata converte le quattro dimensioni di criticità in un punteggio numerico che guida l'assegnazione dei livelli in modo oggettivo, anziché in base alle dinamiche politiche aziendali. L'approccio descritto di seguito produce un punteggio composito da 0 a 100 utilizzando criteri ponderati:
Dimensione 1: Impatto sul business (peso: 35%)
| Impatto sul fatturato per ora di inattività | Punti |
|---|---|
| > 1 milione di dollari all'ora | 35 |
| Da 100 a 1 milione di dollari all'ora | 28 |
| Da 10 a 100 dollari all'ora | 21 |
| Da 1 a 10 dollari all'ora | 14 |
| < 1 dollari all'ora | 7 |
| Nessun impatto diretto sulle entrate | 0 |
L'impatto normativo (obblighi di conformità a DORA, HIPAA, PCI-DSS e SOX derivanti dall'interruzione del servizio) aggiunge fino a 10 punti a questa dimensione.
Dimensione 2: Dipendenza operativa (peso: 30%)
| Fan-In: Applicazioni dipendenti da questa applicazione | Punti |
|---|---|
| > 20 applicazioni dipendenti | 30 |
| 10-20 applicazioni dipendenti | 24 |
| 5-9 applicazioni dipendenti | 18 |
| 2-4 applicazioni dipendenti | 12 |
| 1 applicazione dipendente | 6 |
| Nessun familiare a carico (indipendente) | 0 |
Il conteggio delle dipendenze in questo caso si riferisce al numero di applicazioni che richiamano questa applicazione, ne leggono gli output o dipendono dai suoi dati, non al numero di utenti o all'importanza percepita. Questa dimensione è quella che più frequentemente viene calcolata in modo errato nei sondaggi, perché i proprietari delle applicazioni non conoscono tutti i loro utilizzatori a valle.
Dimensione 3: Complessità del recupero (peso: 20%)
| Tempo di recupero stimato senza DR preinstallato | Punti |
|---|---|
| > 72 ore | 20 |
| 24-72 ore | 16 |
| 8-24 ore | 12 |
| 2-8 ore | 8 |
| <2 ore | 4 |
| Failover automatico < 15 minuti | 0 |
Dimensione 4: Sensibilità dei dati e obblighi normativi (peso: 15%)
| Classificazione dei dati e requisiti normativi | Punti |
|---|---|
| Dati personali/sanitari/cardiogrammi controllati con esplicito obbligo di tempo di recupero | 15 |
| Dati regolamentati senza obbligo specifico di tempo di recupero | 12 |
| Dati interni sensibili (segreti commerciali, documenti finanziari) | 9 |
| Dati operativi interni | 6 |
| dati interni non sensibili | 3 |
| Nessun dato memorizzato | 0 |
Mappatura del punteggio composito ai livelli:
| Punteggio composito | Assegnazione del livello |
|---|---|
| 75-100 | Livello 1, Missione critica |
| 50-74 | Livello 2, critico per l'attività aziendale |
| 25-49 | Livello 3, Operativo aziendale |
| 0-24 | Livello 4, Amministrativo |
Il problema della dipendenza: perché i punteggi basati sui sondaggi sono errati
La dimensione della dipendenza operativa è quella che più facilmente viene calcolata in modo errato, ed è anche quella con le conseguenze più gravi in caso di errore. Un servizio di autenticazione legacy apparentemente non critico può rappresentare un singolo punto di guasto per un'intera piattaforma di e-commerce, e il suo malfunzionamento potrebbe bloccare tutte le transazioni che generano ricavi. Questo processo va oltre le minacce astratte, considerando impatti concreti e misurabili sugli accordi sul livello di servizio (SLA).
I proprietari delle applicazioni conoscono le loro dipendenze dirette a monte, ovvero i sistemi che chiamano. Raramente conoscono tutte le loro dipendenze a valle, ovvero i sistemi che li chiamano. Un servizio interno di autenticazione degli utenti può essere considerato a bassa criticità dal suo proprietario (non genera entrate, è semplice e raramente si guasta), pur essendo utilizzato da dodici applicazioni rivolte ai clienti, tutte di livello 1. La criticità effettiva del servizio di autenticazione è di livello 1, non per la sua funzione in sé, ma per la sua posizione nel grafo delle dipendenze dei sistemi di livello superiore.
La valutazione della criticità basata su sondaggi produce sistematicamente questo errore. Un sondaggio rivolto ai proprietari delle applicazioni chiede: "Quanto è critica questa applicazione?". Il proprietario del servizio di autenticazione risponde "da bassa a media" in base alla funzione del servizio stesso. I dodici proprietari delle applicazioni dipendenti non rispondono a questo sondaggio in merito al servizio di autenticazione, bensì in merito alle proprie applicazioni. La relazione di dipendenza non viene mai rilevata.
La conseguenza si manifesta nella sequenza di ripristino: il BCP definisce l'ordine di ripristino in base ai punteggi di criticità derivati dal sondaggio e il servizio di autenticazione viene programmato per il ripristino di livello 3. Durante un incidente reale, le applicazioni di livello 1 che dovrebbero ripristinarsi per prime non possono farlo perché il servizio di autenticazione da cui dipendono non è stato ripristinato. La sequenza di ripristino fallisce nel punto di dipendenza più critica.
Tre tipologie di dipendenza che i sondaggi tendono a trascurare:
Componenti condivisi nascosti. Un programma COBOL interno che gestisce la conversione di valuta per tre processi aziendali distinti, nessuno dei quali, secondo l'indagine, condivide un componente, rappresenta una dipendenza nascosta che influisce sul ripristino di tutti e tre. Se il programma di conversione di valuta è di Livello 3 e uno qualsiasi dei tre processi aziendali è di Livello 1, la criticità effettiva del programma di conversione di valuta è di Livello 1.
Dipendenze della pipeline di dati. Le applicazioni che consumano dati elaborati in batch da altre applicazioni presentano una dipendenza temporale anziché in tempo reale. Il rischio non è un guasto simultaneo, bensì sequenziale: l'applicazione a valle si ripristina, ma la sua origine dati non è stata ripristinata allo stesso punto di ripristino, dando l'impressione di un corretto funzionamento su dati obsoleti. Questa classe di dipendenze non compare nelle mappe di topologia di rete o nell'analisi del grafo delle chiamate, a meno che non venga tracciato il flusso di dati stesso.
Dipendenze di configurazione e schema condivise. Le applicazioni che condividono schemi di database, servizi di configurazione o provider di identità presentano una dipendenza implicita, anche se non si richiamano mai direttamente. Una modifica dello schema in un database condiviso può influire su più applicazioni. Il ripristino di una singola applicazione dopo un danneggiamento dello schema, senza ripristinare tutte le applicazioni che condividono lo schema, genera uno stato incoerente nell'intero portfolio di applicazioni.
Integrazione del BCP: come i punteggi di criticità influenzano le decisioni di ripristino
Il punteggio di criticità è l'input per sei decisioni specifiche di progettazione del BCP:
1. Definizione della sequenza di ripristino. Le applicazioni vengono ripristinate in ordine di criticità, Livello 1 prima del Livello 2 e poi del Livello 3, ma all'interno di un livello, il grafo delle dipendenze determina la sequenza. Le applicazioni senza dipendenze in entrata (nessun'altra applicazione dipende da esse) possono essere ripristinate in qualsiasi ordine all'interno del loro livello. Le applicazioni con un elevato fan-in devono essere ripristinate prima delle loro dipendenze, indipendentemente dai loro punteggi relativi all'interno del livello. La sequenza di ripristino è quindi: l'ordinamento dei livelli applicato alla sottosequenza vincolata dalle dipendenze all'interno di ciascun livello.
2. Impostazione degli obiettivi RTO e RPO. Il punteggio di criticità calibra gli obiettivi RTO e RPO. Il tempo massimo di inattività tollerabile (MTD) e l'obiettivo del punto di ripristino (RPO) per ogni applicazione di produzione costituiscono il fondamento tecnico dell'intera strategia di continuità operativa. L'MTD è il tempo massimo che l'azienda può tollerare in caso di indisponibilità di un'applicazione. L'RTO deve essere inferiore all'MTD. Il margine tra RTO e MTD rappresenta il buffer di sicurezza. Le applicazioni di livello 1 con un elevato impatto aziendale per ora di inattività hanno margini MTD/RTO ristretti e richiedono un'infrastruttura progettata per un ripristino rapido e automatizzato.
3. Calibrazione degli investimenti infrastrutturali. I punteggi di criticità influenzano direttamente le decisioni di investimento nell'infrastruttura di ripristino d'emergenza. Le applicazioni di livello 1 giustificano la ridondanza multiregionale attivo-attivo. Le applicazioni di livello 2 giustificano la ridondanza attivo-passivo con failover testato. Le applicazioni di livello 3 giustificano backup regolari con procedure di ripristino documentate. Le applicazioni di livello 4 possono fare affidamento su politiche di backup standard. Senza punteggi di criticità, le decisioni di investimento infrastrutturale si basano per impostazione predefinita su un investimento eccessivo uniforme (costoso) o su un investimento insufficiente uniforme (rischioso).
4. Requisiti di controllo delle modifiche. Le applicazioni con punteggi di criticità più elevati richiedono un controllo delle modifiche più rigoroso: finestre di blocco delle modifiche più lunghe, un maggior numero di approvatori obbligatori, test preliminari più estesi, procedure di rollback più conservative. Applicare il controllo delle modifiche di Livello 1 ad applicazioni di Livello 4 comporta uno spreco di tempo per gli ingegneri. Applicare il controllo delle modifiche di Livello 4 ad applicazioni di Livello 1 crea un rischio inaccettabile.
5. Frequenza di test e convalida. Il BCP richiede test periodici delle procedure di ripristino, esercitazioni pratiche, test di failover a livello di componente e simulazioni complete di disaster recovery. I punteggi di criticità determinano la frequenza dei test: le applicazioni di livello 1 richiedono test di disaster recovery trimestrali; le applicazioni di livello 4 richiedono test annuali. Testare ogni applicazione con la stessa frequenza non è né pratico né necessario.
6. Requisiti SLA del fornitore. Per le applicazioni che dipendono da servizi di terze parti, il punteggio di criticità determina i requisiti SLA che devono essere inclusi nei contratti con i fornitori. Un'applicazione di livello 1 con un RTO di 4 ore richiede un SLA di terze parti che garantisca la disponibilità in linea con tale RTO. Un'applicazione di livello 4 non lo richiede.
La complicazione del sistema legacy
I sistemi legacy complicano la valutazione della criticità in modi che i moderni framework di gestione del portfolio applicativo non affrontano adeguatamente. La valutazione standard della criticità presuppone che i proprietari delle applicazioni sappiano cosa fanno le loro applicazioni e chi ne dipende. Per i sistemi legacy, i programmi COBOL mantenuti da più generazioni di sviluppatori, i flussi di lavoro JCL le cui dipendenze sono state documentate l'ultima volta nel 2008, i programmi RPG che producono file di output utilizzati da processi che nessuno attualmente in forza nell'organizzazione ha scritto, questo presupposto non è valido.
La struttura di dipendenza effettiva di un sistema legacy è visibile solo nel codice stesso. Un programma COBOL che scrive su un dataset letto da dodici programmi a valle ha dodici dipendenze a valle, ma questo fatto potrebbe non essere noto al proprietario del programma COBOL, che vede solo la funzione del programma (elaborare le transazioni giornaliere) piuttosto che il suo ruolo strutturale (produrre il dataset che abilita gli altri dodici processi).
Per i sistemi legacy, la dimensione di dipendenza del punteggio di criticità richiede un'analisi del codice piuttosto che sondaggi tra i proprietari. Il conteggio fan-in per un programma COBOL può essere ricavato solo esaminando ogni altro programma nell'ambiente e determinando quali di essi fanno riferimento ai dataset di output, alle convenzioni di chiamata o ai copybook condivisi del primo programma. Questa analisi è ciò che forniscono le piattaforme di analisi strutturale del codice e, senza di essa, la dimensione di dipendenza di qualsiasi punteggio di criticità assegnato a un programma legacy è, nella migliore delle ipotesi, una supposizione fondata.
La conseguenza di una valutazione errata della criticità delle applicazioni legacy è particolarmente grave, poiché i sistemi legacy tendono ad essere sia altamente critici (spesso contengono la logica aziendale fondamentale accumulata nel corso di decenni) sia mal valutati (i loro proprietari non sono in grado di spiegare cosa dipende da essi, quindi assegnano punteggi prudenti). Il risultato è che ai programmi legacy viene assegnato il livello 3, quando in realtà si trovano nel percorso critico dei processi aziendali di livello 1, ovvero la modalità di guasto che si verifica nelle sequenze di ripristino durante gli incidenti reali.
Come SMART TS XL Fornisce le prove di dipendenza per la valutazione della criticità
SMART TS XL Affronta direttamente la dimensione della dipendenza nella valutazione della criticità delle applicazioni, per la classe di applicazioni in cui gli approcci basati su sondaggi sono meno affidabili.
La funzionalità di mappatura delle dipendenze delle applicazioni crea il grafo completo delle dipendenze per ogni linguaggio presente nell'ambiente: ogni programma COBOL che richiama tutti gli altri, ogni passaggio di un job JCL che produce dati utilizzati dai programmi a valle, ogni copybook condiviso che crea una dipendenza implicita tra programmi che non si richiamano mai direttamente, ogni dataset che fluisce tra programmi produttori e consumatori. Questo grafo costituisce la base di prova strutturale per la dimensione delle dipendenze nell'assegnazione dei punteggi di criticità, per i conteggi fan-in, per le identificazioni dei componenti condivisi e per le dipendenze nascoste della pipeline di dati che i sondaggi non sono in grado di rilevare in modo affidabile.
La funzionalità di analisi dell'impatto rende il grafico delle dipendenze interrogabile per la pianificazione BCP: per qualsiasi applicazione nel portfolio, è possibile enumerare tutte le altre applicazioni che dipendono da essa, direttamente o indirettamente, e che quindi ne ereditano il requisito di disponibilità. Un programma COBOL con tre dipendenze dirette e venti dipendenze transitive (programmi che dipendono dalle dipendenze dirette) ha una criticità effettiva che riflette i ventitré programmi di cui fa parte nel percorso critico, e non solo la propria funzione.
La capacità di analisi statica del codice mette in luce le metriche di complessità strutturale che forniscono informazioni sulla dimensione della complessità di ripristino: complessità ciclomica, metriche di accoppiamento, percentuale di codice morto e indicatori di debito tecnico che prevedono quanto tempo e quanto rischioso sarà il ripristino di ciascuna applicazione. Un'applicazione con elevata complessità e accoppiamento denso è più costosa da ripristinare, il suo punteggio di complessità di ripristino (Dimensione 3) è più alto, rispetto a un'applicazione con funzioni equivalenti e architettura pulita.
La funzionalità di ricerca aziendale rende l'intero inventario delle dipendenze interrogabile durante l'intero ciclo di vita del BCP: è possibile trovare ogni programma che accede a uno specifico dataset (identificando tutti i programmi che dipendono dalla sua disponibilità), ogni programma che condivide uno specifico copybook (identificando tutti i programmi influenzati dalla sua disponibilità), ogni job JCL eseguito in una specifica finestra batch (identificando tutti i programmi che devono essere ripristinati prima dell'inizio della finestra). Questa funzionalità di ricerca supporta la revisione annuale del punteggio di criticità, il processo di aggiornamento che mantiene i punteggi aggiornati man mano che il portfolio applicativo si evolve.
Per le organizzazioni che conducono modernizzazione dell'eredità programmi paralleli allo sviluppo del BCP, SMART TS XLL'analisi di ' serve a entrambi gli scopi simultaneamente: la mappa delle dipendenze che fornisce informazioni sul punteggio di criticità determina anche la sequenza di migrazione, e le metriche di complessità che forniscono informazioni sul punteggio di complessità del ripristino determinano anche la stima dello sforzo di modernizzazione.
Mantenere aggiornati i punteggi: il ciclo di revisione annuale
Una valutazione della maturità della continuità operativa dovrebbe aiutarti a fare tre cose: comprendere la tua situazione attuale, identificare le lacune più importanti e definire un percorso di miglioramento realistico. È questo che trasforma un sistema di valutazione della maturità in un programma più efficace.
I punteggi di criticità delle applicazioni si discostano dalla realtà con il mutare delle organizzazioni. Vengono aggiunte nuove applicazioni. Le vecchie applicazioni vengono dismesse ma non completamente eliminate. Vengono create integrazioni tra applicazioni che in precedenza non avevano alcuna dipendenza. I processi aziendali cambiano e con essi le applicazioni da cui dipendono. I requisiti normativi si evolvono e impongono nuovi obblighi di ripristino.
Il ciclo di revisione annuale dei punteggi di criticità dovrebbe includere:
Rianalisi strutturale. Eseguire nuovamente la mappatura delle dipendenze per identificare le nuove dipendenze introdotte dall'ultima revisione. Le applicazioni che erano autonome potrebbero ora avere dipendenze che ne aumentano la criticità. Le applicazioni da cui si dipendeva fortemente potrebbero aver visto i loro utilizzatori migrare verso sistemi più recenti, riducendone la criticità.
Rivalutazione dell'impatto aziendale. I dati relativi al fatturato e all'impatto operativo cambiano con la crescita dell'azienda e l'evoluzione del suo portfolio di applicazioni. Un'applicazione che gestiva un valore aziendale di 1 dollari all'ora tre anni fa, potrebbe ora gestirne dieci volte tanto in seguito alla crescita aziendale.
Integrazione dei risultati dei test di ripristino. I test di ripristino d'emergenza (DR) rivelano discrepanze tra la complessità di ripristino ipotizzata e quella effettiva. Un'applicazione che ha ottenuto un punteggio basso in termini di complessità di ripristino nella valutazione iniziale potrebbe aver ottenuto risultati insoddisfacenti in un'esercitazione simulata, suggerendo una revisione al rialzo del punteggio.
Revisione delle modifiche normative. Nuove normative o modifiche a quelle esistenti possono imporre nuovi obblighi in materia di tempi di ripristino per applicazioni specifiche. I requisiti di resilienza operativa previsti dal regolamento DORA per gli istituti finanziari dell'UE, ad esempio, hanno imposto specifici obblighi di RTO (Recovery Time Objective) per le "funzioni critiche o importanti" che potrebbero non essere stati presi in considerazione nei punteggi di criticità precedenti all'entrata in vigore del DORA.
Le organizzazioni dotate di programmi BCP maturi considerano la valutazione della criticità non come un'attività una tantum, bensì come un processo continuo: i punteggi vengono aggiornati quando si verificano cambiamenti significativi nelle dipendenze delle applicazioni, nell'impatto sul business o negli obblighi normativi, e convalidati annualmente attraverso una revisione strutturata.
Il punteggio è valido solo quanto le prove di dipendenza
La valutazione della criticità delle applicazioni risulta più efficace quando la sua dimensione di dipendenza si basa su dati strutturali piuttosto che su sondaggi. Le dimensioni relative all'impatto sul business e agli obblighi normativi possono essere valutate in modo affidabile tramite interviste e analisi dei processi aziendali. La dimensione della dipendenza operativa, invece, non può essere valutata in questo modo, poiché richiede la conoscenza di cosa dipende da ciascuna applicazione, e i proprietari delle applicazioni tendono sistematicamente a sottovalutare i propri utenti a valle.
La modalità di errore è prevedibile: una sequenza di ripristino basata su punteggi di criticità derivati da sondaggi fallisce a causa di dipendenze nascoste. Un servizio di autenticazione legacy si ripristina in ritardo. Un programma COBOL di conversione valuta è offline quando le applicazioni che dipendono da esso tentano il ripristino. Uno schema di database condiviso si trova in un punto di ripristino diverso rispetto alle applicazioni che lo leggono. Ciascuno di questi errori è prevenibile grazie alle informazioni sulle dipendenze fornite dall'analisi strutturale, ed è costoso quando si verifica durante un incidente reale piuttosto che durante un'esercitazione.
La metodologia di punteggio è consolidata. I framework esistono. La lacuna che la maggior parte delle organizzazioni riscontra non risiede nel framework di punteggio, bensì nella base di dati a supporto della sua dimensione più rilevante. Colmate questa lacuna con un'analisi strutturale prima che il prossimo incidente richieda l'intervento del BCP.
