Strategie di uscita ICT ai sensi di DORA con controlli ISO 27001

Alle 07:42 di un lunedì, il responsabile operativo di una fintech riceve il messaggio che nessuno vorrebbe leggere: il fornitore cloud di monitoraggio delle transazioni dell’azienda ha subito una grave indisponibilità regionale. Alle 08:15, il Chief Risk Officer chiede se il servizio interessato supporti una funzione critica o importante. Alle 08:40, la funzione legale vuole sapere se il contratto riconosca all’impresa assistenza alla transizione, esportazione dei dati, cancellazione e diritto di audit. Alle 09:05, il responsabile della sicurezza delle informazioni cerca evidenze che dimostrino che il piano di uscita sia stato testato, non solo redatto.

In un’altra impresa di servizi finanziari, Sarah, CISO di una piattaforma fintech in rapida crescita, apre una richiesta informativa pre-audit per una valutazione di conformità DORA. Le domande le sono familiari, fino a quando arriva alla sezione sui fornitori terzi di servizi ICT che supportano funzioni critiche o importanti. Gli auditor non chiedono se l’azienda abbia una politica sui fornitori. Chiedono strategie di uscita documentate, testate e attuabili.

Il pensiero va subito al fornitore cloud principale che ospita la piattaforma, poi al fornitore di servizi di sicurezza gestiti che monitora le minacce 24 ore su 24. Che cosa succede se il fornitore cloud subisce un’interruzione geopolitica? Che cosa succede se il MSSP viene acquisito da un concorrente? Che cosa succede se un fornitore SaaS critico diventa insolvente, interrompe il servizio o perde la fiducia dei clienti dopo un incidente rilevante?

In molte organizzazioni la risposta scomoda è la stessa. Esistono una valutazione del rischio dei fornitori, un piano di continuità operativa, una cartella contrattuale, un inventario cloud e forse un report dei backup. Ma non esiste un’unica strategia di uscita ICT DORA per fornitori terzi, pronta per l’audit, che colleghi criticità aziendale, diritti contrattuali, portabilità tecnica, piani di continuità, evidenze di backup, obblighi privacy e approvazione della direzione.

DORA cambia il tono della gestione dei fornitori. Ai sensi del Regolamento (UE) 2022/2554, le entità finanziarie devono gestire il rischio ICT di terze parti nell’ambito del quadro di gestione del rischio ICT. Restano pienamente responsabili della conformità, mantengono un registro dei contratti per servizi ICT, distinguono gli accordi ICT che supportano funzioni critiche o importanti, valutano i rischi di concentrazione e subappalto e mantengono strategie di uscita per le dipendenze critiche da fornitori terzi ICT. DORA si applica dal 17 gennaio 2025 e stabilisce requisiti uniformi dell’UE per gestione del rischio ICT, segnalazione degli incidenti, test di resilienza, condivisione delle informazioni e gestione del rischio ICT di terze parti per un ampio insieme di entità finanziarie.

Una strategia di uscita DORA non è un paragrafo in un contratto con un fornitore. È un sistema di controlli. Deve essere governata, valutata in base al rischio, tecnicamente realizzabile, contrattualmente applicabile, testata, supportata da evidenze e migliorata in modo continuo.

L’approccio di Clarysec combina Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, template di politiche aziendali e Zenith Controls: The Cross-Compliance Guide Zenith Controls per trasformare quella domanda del lunedì mattina in una risposta già pronta.

Perché le strategie di uscita DORA falliscono negli audit reali

La maggior parte dei fallimenti delle strategie di uscita ICT DORA è strutturale prima ancora che tecnica. L’organizzazione ha un responsabile del fornitore, ma non un titolare del rischio responsabile. Ha job di backup, ma nessuna evidenza di ripristino. Ha un questionario di due diligence del fornitore, ma nessuna decisione documentata sul fatto che il fornitore supporti una funzione critica o importante. Ha una formulazione contrattuale sulla risoluzione, ma nessun periodo di transizione allineato al piano di continuità operativa.

DORA costringe a collegare questi elementi. Article 28 definisce i principi generali per la gestione del rischio ICT di terze parti, compresa la necessità di gestire il rischio dei fornitori terzi di servizi ICT lungo tutto il ciclo di vita e di mantenere adeguate strategie di uscita. Article 30 stabilisce requisiti contrattuali dettagliati per i servizi ICT che supportano funzioni critiche o importanti, incluse descrizioni dei servizi, ubicazioni del trattamento dei dati, misure di sicurezza, diritti di accesso e di audit, assistenza in caso di incidente, cooperazione con le autorità competenti e diritti di risoluzione.

Il regolamento è anche proporzionato. Articles 4 and 16 consentono ad alcune entità più piccole o esentate di applicare un quadro semplificato di gestione del rischio ICT. Ma semplificato non significa non documentato. Anche le entità finanziarie più piccole devono disporre di gestione del rischio ICT documentata, monitoraggio continuo, sistemi resilienti, identificazione tempestiva degli incidenti ICT, identificazione delle principali dipendenze ICT da terze parti, backup e ripristino, continuità operativa, risposta e ripristino, test, lezioni apprese e formazione.

Una piccola fintech non può dire: “Siamo troppo piccoli per la pianificazione dell’uscita”. Può dire: “La nostra strategia di uscita DORA è proporzionata alla nostra dimensione, al profilo di rischio e alla complessità del servizio”. La differenza sono le evidenze.

Per le entità che rientrano anche negli ambiti nazionali NIS2, DORA opera come atto giuridico dell’Unione specifico di settore per gli obblighi di cibersicurezza sovrapposti nel settore finanziario. NIS2 resta rilevante nell’ecosistema più ampio, in particolare per i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti, i fornitori cloud, i data center e le entità di infrastruttura digitale. NIS2 Article 21 rafforza gli stessi temi: analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione sicura, valutazione dell’efficacia, formazione, crittografia, controllo degli accessi, gestione degli asset e autenticazione.

Autorità di vigilanza, clienti, auditor e consigli di amministrazione possono formulare la domanda in modo diverso, ma il punto centrale è lo stesso: siete in grado di uscire da un fornitore ICT critico senza perdere il controllo della continuità del servizio, dei dati, delle evidenze o dell’impatto sui clienti?

Integrare la strategia di uscita nel SGSI

ISO/IEC 27001:2022 fornisce l’ossatura del sistema di gestione per la pianificazione dell’uscita DORA.

Le clausole da 4.1 a 4.4 richiedono all’organizzazione di definire il proprio contesto, le parti interessate, i requisiti legali, normativi e contrattuali, il campo di applicazione del SGSI, le interfacce, le dipendenze e i processi. È qui che un’entità finanziaria identifica DORA, impegni verso i clienti, aspettative di esternalizzazione, dipendenze cloud, obblighi privacy, subappaltatori e servizi ICT all’interno del perimetro del SGSI.

Le clausole da 5.1 a 5.3 richiedono leadership, politica, risorse, assegnazione di ruoli e responsabilità. Questo si allinea al modello di governance di DORA, in cui l’organo di gestione definisce, approva, supervisiona e resta responsabile della gestione del rischio ICT, inclusi continuità operativa ICT, piani di risposta e ripristino, piani di audit ICT, budget, strategia di resilienza e politica sul rischio ICT di terze parti.

Le clausole da 6.1.1 a 6.1.3 trasformano la pianificazione dell’uscita in trattamento del rischio. L’organizzazione definisce criteri di rischio, esegue valutazioni del rischio ripetibili, identifica i rischi per riservatezza, integrità e disponibilità, assegna i titolari del rischio, valuta conseguenze e probabilità, seleziona le opzioni di trattamento, confronta i controlli con l’Allegato A, produce una Dichiarazione di applicabilità, prepara un piano di trattamento del rischio e ottiene l’approvazione del titolare del rischio e l’accettazione del rischio residuo.

La clausola 8.1 richiede quindi pianificazione e controllo operativi. L’organizzazione deve pianificare, attuare e controllare i processi del SGSI, mantenere informazioni documentate che dimostrino che i processi sono stati svolti come pianificato, gestire le modifiche e controllare processi, prodotti o servizi forniti dall’esterno e rilevanti per il SGSI.

ISO/IEC 27005:2022 rafforza questo approccio. La clausola 6.2 raccomanda alle organizzazioni di identificare i requisiti delle parti interessate, inclusi i controlli dell’Allegato A di ISO/IEC 27001:2022, standard specifici di settore, normative nazionali e internazionali, regole interne, requisiti contrattuali e controlli esistenti derivanti da precedenti trattamenti del rischio. Le clausole da 6.4.1 a 6.4.3 spiegano che i criteri di rischio devono considerare aspetti legali e normativi, rapporti con i fornitori, privacy, impatti operativi, violazioni contrattuali, operazioni di terze parti e conseguenze reputazionali. Le clausole da 8.2 a 8.6 supportano una libreria di controlli e un piano di trattamento che possono combinare l’Allegato A di ISO/IEC 27001:2022 con DORA, NIS2, GDPR, impegni verso i clienti e politiche interne.

Il modello operativo è semplice: un inventario dei requisiti, un registro dei rischi dei fornitori, una Dichiarazione di applicabilità, un piano di trattamento del rischio e un pacchetto di evidenze per ogni scenario di uscita critico.

I controlli ISO/IEC 27001:2022 che ancorano la pianificazione dell’uscita DORA

Le strategie di uscita DORA diventano pronte per l’audit quando governance dei fornitori, portabilità cloud, pianificazione della continuità ed evidenze di backup sono trattate come un’unica catena di controlli collegati.

Zenith Controls di Clarysec mappa i controlli dell’Allegato A di ISO/IEC 27001:2022 su attributi dei controlli, evidenze di audit e aspettative di conformità trasversale. Non è un quadro di controlli separato. È la guida di cross-compliance di Clarysec per comprendere come i controlli ISO/IEC 27001:2022 supportino risultati di audit, normativi e operativi.

Per una strategia di uscita ICT DORA per fornitori terzi, la traccia di audit dovrebbe dimostrare che:

• Il fornitore è classificato e collegato ai processi aziendali.
• Il servizio è valutato per stabilire se supporta una funzione critica o importante.
• Il rischio di uscita è registrato con un titolare del rischio responsabile.
• Le clausole contrattuali supportano transizione, accesso, audit, restituzione dei dati, cancellazione dei dati, cooperazione e continuità.
• Portabilità e interoperabilità cloud sono state convalidate.
• I backup e i test di ripristino dimostrano la recuperabilità.
• La sostituzione temporanea o l’elaborazione alternativa sono documentate.
• I risultati dei test di uscita sono stati riesaminati, oggetto di azioni correttive e comunicati alla direzione.

Il linguaggio contrattuale è il primo controllo di continuità

Un contratto dovrebbe essere il primo controllo di continuità, non un ostacolo alla continuità. Se il fornitore può risolvere rapidamente il contratto, ritardare le esportazioni, limitare l’accesso ai log, addebitare costi di transizione non definiti o rifiutare il supporto alla migrazione, la strategia di uscita è fragile.

In Zenith Blueprint, nella fase Controls in Action, Step 23, Control 5.20, si spiega che gli accordi con i fornitori dovrebbero includere i requisiti pratici di sicurezza che rendono possibile l’uscita:

Le aree chiave normalmente trattate negli accordi con i fornitori includono:

✓ obblighi di riservatezza, inclusi ambito, durata e restrizioni alla divulgazione a terze parti;

✓ responsabilità di controllo degli accessi, quali chi può accedere ai dati, come vengono gestite le credenziali e quale monitoraggio è in essere;

✓ misure tecniche e organizzative per protezione dei dati, cifratura, trasmissione sicura, backup e impegni di disponibilità;

✓ tempistiche e protocolli di segnalazione degli incidenti, spesso con tempi definiti;

✓ diritto di audit, inclusi frequenza, ambito e accesso alle evidenze pertinenti;

✓ controlli sui subappaltatori, che richiedono al fornitore di trasferire obblighi di sicurezza equivalenti ai propri partner a valle;

✓ disposizioni di fine contratto, come restituzione o distruzione dei dati, recupero degli asset e disattivazione degli account.

Questo elenco collega le aspettative contrattuali di DORA Article 30 al controllo A.5.20 dell’Allegato A di ISO/IEC 27001:2022.

Il linguaggio delle politiche aziendali di Clarysec esprime lo stesso punto in termini operativi. Nella Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, sezione “Requisiti di attuazione”, clause 6.4.3 stabilisce:

Meccanismi tecnici di fallback: garantire portabilità e interoperabilità dei dati per supportare la transizione del servizio, se richiesta (ad es. backup regolari in formati standard da un fornitore SaaS per consentire la migrazione).

La stessa policy, clause 6.8.2, richiede:

Un diritto all’assistenza alla transizione (clausola di assistenza all’uscita) quando è richiesto un cambio di fornitore, incluso il mantenimento del servizio durante un periodo di transizione definito.

Questa clausola spesso determina se una strategia di uscita supera l’audit. Trasforma l’uscita da un evento improvviso e non governato in una transizione gestita.

Per le entità più piccole, la Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, sezione “Requisiti di governance”, clause 5.3.6, richiede:

Termini di risoluzione, inclusa la restituzione sicura dei dati o la loro distruzione

Per gli ambienti enterprise, la Third party and supplier security policy Third party and supplier security policy, sezione “Requisiti di applicazione della policy”, clause 6.5.1.2 richiede:

Restituzione o distruzione certificata di tutte le informazioni di proprietà dell’organizzazione

Questi requisiti di policy devono essere tracciabili direttamente verso clausole contrattuali, procedure dei fornitori, runbook di uscita ed evidenze di audit.

Uscita dal cloud: testare la portabilità prima che serva

I servizi cloud sono il punto in cui le strategie di uscita DORA diventano spesso vaghe. L’impresa presume di poter esportare i dati, ma nessuno ha testato il formato. Presume che la cancellazione avverrà, ma il modello di conservazione del fornitore include backup e archiviazione replicata. Presume che un fornitore alternativo possa ricevere i dati, ma schemi, integrazioni di identità, chiavi di cifratura, segreti, log, API e limitazione della frequenza delle richieste rendono la migrazione più lenta della tolleranza d’impatto consentita.

Il controllo A.5.23 dell’Allegato A di ISO/IEC 27001:2022 affronta questo problema di ciclo di vita richiedendo controlli di sicurezza delle informazioni per acquisizione, uso, gestione e uscita dai servizi cloud.

La Cloud Usage Policy-sme di Clarysec Cloud Usage Policy - SME, sezione “Requisiti di applicazione della policy”, clause 6.3.4 richiede:

Capacità di esportazione dei dati confermata prima dell’onboarding (ad es. per evitare il lock-in del fornitore)

La clause 6.3.5 richiede:

Conferma delle procedure di cancellazione sicura prima della chiusura dell’account

Questi requisiti appartengono all’inizio del ciclo di vita del fornitore. Non aspettare la risoluzione per chiedere se i dati possano essere esportati. Non aspettare la chiusura dell’account per chiedere se esistano evidenze di cancellazione.

Un test pratico di uscita cloud DORA dovrebbe includere:

1. Esportare un set di dati rappresentativo nel formato concordato.
2. Validare completezza, integrità, marche temporali, metadati e controlli degli accessi.
3. Importare il set di dati in un ambiente di staging o in uno strumento alternativo.
4. Confermare la gestione delle chiavi di cifratura e la rotazione dei segreti.
5. Confermare l’esportazione dei log e la conservazione della traccia di audit.
6. Documentare le procedure di cancellazione del fornitore, incluse conservazione dei backup e certificazione della cancellazione.
7. Registrare problemi, azioni correttive, responsabili e scadenze.
8. Aggiornare la valutazione del rischio del fornitore, la Dichiarazione di applicabilità e il piano di uscita.

La portabilità non è una promessa di procurement. È una capacità testata.

Uno sprint di una settimana per un piano di uscita DORA pronto per l’audit

Si consideri un istituto di pagamento che utilizza un fornitore SaaS di analisi antifrode. Il fornitore acquisisce dati di transazione, identificativi dei clienti, dati di telemetria dei dispositivi, segnali comportamentali, regole antifrode, output di scoring e note sui casi. Il servizio supporta un processo critico di rilevamento delle frodi. L’impresa utilizza inoltre un data warehouse cloud per archiviare i risultati di analisi esportati.

Il CISO vuole una strategia di uscita ICT DORA per fornitori terzi in grado di superare audit interno e riesame dell’autorità di vigilanza. Uno sprint di una settimana può far emergere le lacune e costruire la catena delle evidenze.

Giorno 1: classificare il fornitore e definire lo scenario di uscita

Utilizzando Zenith Blueprint, nella fase Controls in Action, Step 23, Action Items for Controls 5.19 to 5.37, il team inizia riesaminando e classificando il portafoglio dei fornitori:

Compilare un elenco completo dei fornitori e dei prestatori di servizi attuali (5.19) e classificarli in base all’accesso a sistemi, dati o controllo operativo. Per ciascun fornitore classificato, verificare che le aspettative di sicurezza siano chiaramente integrate nei contratti (5.20), inclusi riservatezza, accesso, segnalazione degli incidenti e obblighi di conformità.

Il fornitore è classificato come critico perché supporta una funzione critica o importante, tratta dati operativi sensibili e incide sugli esiti del monitoraggio delle transazioni.

Il team definisce tre trigger di uscita:

• Insolvenza del fornitore o cessazione del servizio.
• Grave violazione della sicurezza o perdita di fiducia.
• Migrazione strategica per ridurre il rischio di concentrazione.

Giorno 2: costruire l’inventario dei requisiti e la registrazione del rischio

Il team crea un unico inventario dei requisiti che copre il rischio ICT di terze parti DORA, i controlli ISO/IEC 27001:2022 sui fornitori e sul cloud, gli obblighi GDPR per i dati personali, gli impegni contrattuali verso i clienti e la propensione al rischio interna.

Ai sensi del GDPR, l’impresa conferma se identificativi di transazione, ID dei dispositivi, segnali di localizzazione e analisi comportamentali riguardino persone identificate o identificabili. I principi di GDPR Article 5, inclusi integrità, riservatezza, limitazione della conservazione e accountability, diventano parte del requisito di evidenza dell’uscita. Se l’uscita comporta il trasferimento a un nuovo fornitore, devono essere documentati base giuridica, finalità, minimizzazione, conservazione, clausole del responsabile del trattamento e misure di sicurezza.

La registrazione del rischio include quanto segue:

Giorno 3: correggere le lacune contrattuali

Legale e procurement confrontano il contratto con le clausole per i fornitori di Clarysec. Aggiungono assistenza alla transizione, mantenimento del servizio durante un periodo di transizione definito, accesso ad audit ed evidenze, notifica dei subappaltatori, formato di esportazione dei dati, certificazione della cancellazione sicura, cooperazione in caso di incidente e impegni sui tempi di ripristino.

La Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy, sezione “Requisiti di applicazione della policy”, clause 6.5.1 stabilisce:

I contratti con fornitori critici devono includere obblighi di continuità e impegni sui tempi di ripristino.

Per le PMI, la Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, sezione “Trattamento del rischio ed eccezioni”, clause 7.2.1.4 richiede ai team di:

documentare piani temporanei di sostituzione del fornitore o del partner

Quella clausola trasforma “migreremo” in un fallback attuabile: quale fornitore, quale soluzione alternativa interna, quale processo manuale, quale estratto di dati, quale titolare e quale percorso di approvazione.

Giorno 4: testare portabilità dei dati e recuperabilità dei backup

Il team tecnologico esporta regole antifrode, dati dei casi, output di scoring delle transazioni, log, configurazione, documentazione API ed elenchi degli accessi degli utenti. Verifica se i dati possano essere ripristinati o riutilizzati in un ambiente controllato.

La Backup and Restore Policy-sme Backup and Restore Policy - SME, sezione “Requisiti di governance”, clause 5.3.3 richiede:

I test di ripristino sono eseguiti almeno trimestralmente e i risultati sono documentati per verificare la recuperabilità

La Backup and Restore Policy enterprise Backup and Restore Policy, sezione “Applicazione e conformità”, clause 8.3.1 aggiunge:

Eseguire audit periodici dei log di backup, delle impostazioni di configurazione e dei risultati dei test

In Zenith Blueprint, nella fase Controls in Action, Step 19, Control 8.13, Clarysec avverte perché questo aspetto è essenziale:

I test di ripristino sono il punto in cui la maggior parte delle organizzazioni fallisce. Un backup che non può essere ripristinato in tempo, o non può esserlo affatto, è una passività, non un asset. Pianificare esercitazioni di ripristino regolari, anche solo parziali, e documentarne l’esito.

Il team scopre che le note sui casi esportate non includono gli allegati e che la limitazione della frequenza delle API rende un’esportazione completa troppo lenta rispetto all’obiettivo di ripristino definito. Il problema viene registrato, assegnato e corretto tramite un addendum contrattuale e una riprogettazione tecnica dell’esportazione.

Giorno 5: eseguire l’esercitazione tabletop di uscita e il riesame delle evidenze

Il team svolge un’esercitazione tabletop: il fornitore comunica la risoluzione del contratto a 90 giorni dopo un incidente rilevante. Le operazioni devono continuare il monitoraggio antifrode mentre i dati vengono migrati.

In Zenith Blueprint, nella fase Controls in Action, Step 23, Control 5.30, Clarysec spiega lo standard del test:

La prontezza ICT inizia molto prima che si verifichi un’interruzione. Richiede l’identificazione dei sistemi critici, la comprensione delle loro interdipendenze e la loro mappatura sui processi aziendali.

La stessa sezione aggiunge:

Gli obiettivi di tempo di ripristino (RTO) e gli obiettivi di punto di ripristino (RPO) definiti nel piano di continuità operativa devono riflettersi nelle configurazioni tecniche, nei contratti e nella progettazione dell’infrastruttura.

Il pacchetto di evidenze include classificazione del fornitore, valutazione del rischio, clausole contrattuali, runbook di uscita, risultati dell’esportazione dei dati, evidenze di ripristino dei backup, procedura di cancellazione, valutazione del fornitore alternativo, verbali dell’esercitazione tabletop, log delle azioni correttive, approvazione della direzione e decisione sul rischio residuo.

Il CISO ora può rispondere alla domanda del consiglio di amministrazione con evidenze, non con ottimismo.

Cross-compliance: un piano di uscita, più prospettive di audit

Una solida strategia di uscita DORA riduce il lavoro duplicato di conformità tra aspettative di governance ISO/IEC 27001:2022, NIS2, GDPR, NIST e COBIT 2019.

Il punto importante non è che un quadro di riferimento ne sostituisca un altro. Il valore sta nel fatto che un SGSI ben costruito consente all’organizzazione di generare evidenze una volta e riutilizzarle in modo intelligente.

Zenith Controls di Clarysec aiuta i team a prepararsi a queste prospettive di audit collegando i controlli ISO/IEC 27001:2022 alle evidenze di audit e alle aspettative cross-framework.

Un fallimento di audit comune è la frammentazione delle evidenze. Il responsabile del fornitore ha il contratto. L’IT ha i log di backup. La funzione legale ha l’accordo sul trattamento dei dati (DPA). La funzione rischio ha la valutazione. La conformità ha la mappatura normativa. Nessuno ha il quadro completo.

Clarysec risolve questo problema progettando il pacchetto di evidenze intorno allo scenario di uscita. Ogni documento risponde a una domanda di audit: quale servizio viene dismesso, perché è critico, quali dati e sistemi sono interessati, chi possiede il rischio, quali diritti contrattuali rendono possibile l’uscita, quali meccanismi tecnici rendono possibile la migrazione, quali accordi di continuità mantengono operativa l’attività, quale test dimostra che il piano funziona, quali problemi sono stati corretti e chi ha approvato il rischio residuo.

La checklist Clarysec per la strategia di uscita DORA

Usa questa checklist per trasformare una strategia di uscita ICT DORA per fornitori terzi da documento a insieme di controlli verificabile in audit.

Trasformare la pianificazione dell’uscita in un controllo di resilienza per il consiglio di amministrazione

Se la tua strategia di uscita DORA è solo una clausola contrattuale, non è pronta. Se il tuo backup non è mai stato ripristinato, non è pronto. Se il tuo fornitore cloud può esportare i dati ma nessuno ne ha validato la completezza, non è pronto. Se il tuo consiglio di amministrazione non può vedere la decisione sul rischio residuo, non è pronto.

Clarysec aiuta CISO, Compliance Manager, auditor e business owner a costruire strategie di uscita ICT DORA per fornitori terzi pratiche, proporzionate e pronte per l’audit. Combiniamo Zenith Blueprint Zenith Blueprint per la sequenza di attuazione, Zenith Controls Zenith Controls per la mappatura cross-compliance e template di policy come la Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, la Cloud Usage Policy - SME Cloud Usage Policy - SME, la Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME e la Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy per creare una catena completa dal controllo all’evidenza.

Il prossimo passo è semplice e ad alto valore: seleziona un fornitore ICT critico questa settimana. Classificalo, riesamina il suo contratto, testa un’esportazione dei dati, verifica un ripristino, documenta un piano di sostituzione e crea un pacchetto di evidenze.

Questo singolo esercizio mostrerà se la tua strategia di uscita DORA è una reale capacità di resilienza o solo un documento destinato a fallire in sede di audit.