DORA-exitstrategier för IKT med ISO 27001-kontroller

Klockan 07:42 en måndag får en driftansvarig på ett fintechbolag det meddelande ingen vill läsa: organisationens molnbaserade leverantör för transaktionsövervakning har drabbats av ett allvarligt regionalt avbrott. Klockan 08:15 frågar riskchefen om den berörda tjänsten stödjer en kritisk eller viktig funktion. Klockan 08:40 vill juristfunktionen veta om avtalet ger företaget rätt till övergångsstöd, dataexport, radering och revision. Klockan 09:05 söker informationssäkerhetschefen efter underlag som visar att exitplanen har testats, inte bara dokumenterats.

På ett annat finansiellt tjänsteföretag öppnar Sarah, informationssäkerhetschef för en snabbt växande fintechplattform, en informationsbegäran inför revision för en DORA-bedömning av regelefterlevnad. Frågorna är välbekanta tills hon kommer till avsnittet om IKT-tredjepartstjänsteleverantörer som stödjer kritiska eller viktiga funktioner. Revisorerna frågar inte om organisationen har en leverantörspolicy. De begär dokumenterade, testade och genomförbara exitstrategier.

Tankarna går direkt till den centrala molnleverantören som driftar plattformen och därefter till den hanterade säkerhetstjänsteleverantören som övervakar hot dygnet runt. Vad händer om molnleverantören drabbas av en geopolitisk störning? Vad händer om MSSP:n förvärvas av en konkurrent? Vad händer om en kritisk SaaS-leverantör blir insolvent, avvecklar tjänsten eller förlorar kundernas förtroende efter en större incident?

Det obekväma svaret är detsamma i många organisationer. Det finns en leverantörsriskbedömning, en plan för verksamhetskontinuitet, en avtalsmapp, en molnförteckning och kanske en rapport om säkerhetskopiering. Men det finns ingen samlad, revisionsklar DORA-exitstrategi för IKT-tredjepartsleverantörer som binder samman verksamhetskritikalitet, avtalsrättigheter, teknisk portabilitet, kontinuitetsplaner, underlag för säkerhetskopiering, integritetskrav och ledningens godkännande.

DORA förändrar utgångspunkten för leverantörshantering. Enligt förordning (EU) 2022/2554 ska finansiella entiteter hantera IKT-tredjepartsrisk som en del av ramverket för IKT-riskhantering. De behåller det fulla ansvaret för efterlevnad, ska föra ett register över avtal om IKT-tjänster, särskilja IKT-arrangemang som stödjer kritiska eller viktiga funktioner, bedöma koncentrationsrisker och risker kopplade till underleverantörer samt upprätthålla exitstrategier för kritiska IKT-tredjepartsberoenden. DORA tillämpas från den 17 januari 2025 och fastställer enhetliga EU-krav för IKT-riskhantering, incidentrapportering, resiliensprövning, informationsdelning och IKT-tredjepartsriskhantering för ett brett spektrum av finansiella entiteter.

En DORA-exitstrategi är inte ett stycke i ett leverantörsavtal. Det är ett kontrollsystem. Det ska vara styrt, riskbedömt, tekniskt genomförbart, avtalsmässigt bindande, testat, styrkt med underlag och föremål för kontinuerlig förbättring.

Clarysecs arbetssätt kombinerar Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, policymallar för organisationer och Zenith Controls: The Cross-Compliance Guide Zenith Controls för att omvandla måndagsmorgonens fråga till ett förberett svar.

Varför DORA-exitstrategier faller i verkliga revisioner

De flesta brister i DORA-exitstrategier för IKT är strukturella innan de är tekniska. Organisationen har en leverantörsansvarig men ingen utsedd riskägare. Den har säkerhetskopieringsjobb men inget underlag som visar återställning. Den har ett frågeformulär för leverantörsgranskning men inget dokumenterat beslut om huruvida leverantören stödjer en kritisk eller viktig funktion. Den har avtalsformuleringar om uppsägning men ingen övergångsperiod som är anpassad till planen för verksamhetskontinuitet.

DORA tvingar ihop dessa delar. Article 28 anger de allmänna principerna för IKT-tredjepartsriskhantering, inklusive kravet att hantera risker kopplade till IKT-tredjepartstjänsteleverantörer under hela livscykeln och att upprätthålla lämpliga exitstrategier. Article 30 anger detaljerade avtalskrav för IKT-tjänster som stödjer kritiska eller viktiga funktioner, inklusive tjänstebeskrivningar, platser för databehandling, säkerhetsskydd, åtkomst- och revisionsrätt, incidentstöd, samarbete med behöriga myndigheter och rätt att säga upp avtalet.

Förordningen är också proportionerlig. Articles 4 and 16 tillåter vissa mindre eller undantagna entiteter att tillämpa ett förenklat ramverk för IKT-riskhantering. Men förenklat betyder inte odokumenterat. Mindre finansiella entiteter behöver fortfarande dokumenterad IKT-riskhantering, kontinuerlig övervakning, resilienta system, snabb identifiering av IKT-incidenter, identifiering av viktiga IKT-tredjepartsberoenden, säkerhetskopiering och återställning, verksamhetskontinuitet, respons och återhämtning, testning, erfarenhetsåterföring och utbildning.

Ett litet fintechbolag kan inte säga: ”Vi är för små för exitplanering.” Det kan säga: ”Vår DORA-exitstrategi är anpassad till vår storlek, riskprofil och tjänstekomplexitet.” Skillnaden är underlag.

För entiteter som även omfattas av nationell NIS2-tillämpning fungerar DORA som den sektorsspecifika unionsrättsakten för överlappande cybersäkerhetskrav i finanssektorn. NIS2 är fortfarande relevant i det bredare ekosystemet, särskilt för hanterade tjänsteleverantörer, hanterade säkerhetstjänsteleverantörer, molnleverantörer, datacenter och entiteter inom digital infrastruktur. NIS2 Article 21 förstärker samma teman: riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning, bedömning av effektivitet, utbildning, kryptografi, åtkomstkontroll, tillgångshantering och autentisering.

Tillsynsmyndigheter, kunder, revisorer och styrelser kan formulera frågan på olika sätt, men kärnfrågan är densamma: kan ni lämna en kritisk IKT-leverantör utan att förlora kontrollen över tjänstekontinuitet, data, underlag eller kundpåverkan?

Gör exitstrategin till en del av ISMS

ISO/IEC 27001:2022 ger ledningssystemets ryggrad för DORA-exitplanering.

Klausulerna 4.1 till 4.4 kräver att organisationen definierar sin kontext, intressenter, rättsliga, regulatoriska och avtalsmässiga krav, ISMS-omfattning, gränssnitt, beroenden och processer. Det är här en finansiell entitet identifierar DORA, kundåtaganden, outsourcingförväntningar, molnberoenden, integritetskrav, underleverantörer och IKT-tjänster inom ISMS-gränsen.

Klausulerna 5.1 till 5.3 kräver ledarskap, policy, resurser, rolltilldelning och ansvarsskyldighet. Detta överensstämmer med DORA:s styrningsmodell, där ledningsorganet definierar, godkänner, övervakar och ytterst ansvarar för IKT-riskhantering, inklusive IKT-verksamhetskontinuitet, planer för respons och återhämtning, IKT-revisionsplaner, budgetar, resiliensstrategi och policy för IKT-tredjepartsrisk.

Klausulerna 6.1.1 till 6.1.3 omvandlar exitplanering till riskbehandling. Organisationen definierar riskkriterier, genomför repeterbara riskbedömningar, identifierar risker för konfidentialitet, riktighet och tillgänglighet, tilldelar riskägare, bedömer konsekvens och sannolikhet, väljer behandlingsalternativ, jämför kontroller med Annex A, tar fram en tillämplighetsförklaring (SoA), upprättar en riskbehandlingsplan och inhämtar riskägarens godkännande samt acceptans av kvarstående risk.

Klausul 8.1 kräver därefter operativ planering och styrning. Organisationen ska planera, genomföra och styra ISMS-processer, bevara dokumenterad information som visar att processerna har genomförts enligt plan, hantera ändringar och styra externt tillhandahållna processer, produkter eller tjänster som är relevanta för ISMS.

ISO/IEC 27005:2022 stärker detta arbetssätt. Klausul 6.2 rekommenderar att organisationer identifierar krav från intressenter, inklusive ISO/IEC 27001:2022 Annex A-kontroller, sektorsspecifika standarder, nationella och internationella regelverk, interna regler, avtalskrav och befintliga kontroller från tidigare riskbehandling. Klausulerna 6.4.1 till 6.4.3 förklarar att riskkriterier bör beakta rättsliga och regulatoriska aspekter, leverantörsrelationer, integritetsskydd, operativa konsekvenser, avtalsöverträdelser, tredjepartsdrift och konsekvenser för anseendet. Klausulerna 8.2 till 8.6 stödjer ett kontrollbibliotek och en behandlingsplan som kan kombinera ISO/IEC 27001:2022 Annex A med DORA, NIS2, GDPR, kundåtaganden och interna policyer.

Driftmodellen är enkel: en kravförteckning, ett leverantörsriskregister, en SoA, en riskbehandlingsplan och ett underlagspaket för varje kritiskt exitscenario.

ISO/IEC 27001:2022-kontrollerna som förankrar DORA-exitplanering

DORA-exitstrategier blir revisionsklara när leverantörsstyrning, portabilitet i molnet, kontinuitetsplanering och underlag för säkerhetskopiering behandlas som en sammanhängande kontrollkedja.

Clarysecs Zenith Controls mappar ISO/IEC 27001:2022 Annex A-kontroller till kontrollattribut, revisionsbevis och förväntningar på tvärgående regelefterlevnad. Det är inte ett separat kontrollramverk. Det är Clarysecs vägledning för tvärgående regelefterlevnad för att förstå hur ISO/IEC 27001:2022-kontroller stödjer revisionsmässiga, regulatoriska och operativa resultat.

För en DORA-exitstrategi för IKT-tredjepartsleverantörer bör revisionsspåret visa att:

• Leverantören är klassificerad och kopplad till verksamhetsprocesser.
• Tjänsten har bedömts avseende stöd för en kritisk eller viktig funktion.
• Exitrisken är registrerad med en ansvarig riskägare.
• Avtalsklausuler stödjer övergång, åtkomst, revision, dataåterlämning, dataradering, samarbete och kontinuitet.
• Portabilitet och interoperabilitet i molnet har validerats.
• Säkerhetskopior och återställningstester visar återställningsförmåga.
• Tillfällig ersättning eller alternativ behandling har dokumenterats.
• Resultat från exittestning har granskats, åtgärdats och rapporterats till ledningen.

Avtalsspråket är den första kontinuitetskontrollen

Ett avtal bör vara den första kontinuitetskontrollen, inte ett hinder för kontinuitet. Om leverantören kan säga upp avtalet med kort varsel, fördröja exporter, begränsa loggåtkomst, debitera odefinierade övergångsavgifter eller vägra migreringsstöd är exitstrategin sårbar.

I Zenith Blueprint, fasen Kontroller i praktiken, steg 23, kontroll 5.20, förklaras att leverantörsavtal bör innehålla de praktiska säkerhetskrav som gör exit möjlig:

Viktiga områden som typiskt hanteras i leverantörsavtal omfattar:

✓ Sekretesskyldigheter, inklusive omfattning, varaktighet och begränsningar för utlämnande till tredje part;

✓ Ansvar för åtkomstkontroll, såsom vem som får åtkomst till era data, hur autentiseringsuppgifter hanteras och vilken övervakning som finns;

✓ Tekniska och organisatoriska åtgärder för dataskydd, kryptering, säker överföring, säkerhetskopiering och åtaganden om tillgänglighet;

✓ Tidslinjer och protokoll för incidentrapportering, ofta med definierade tidsramar;

✓ Revisionsrätt, inklusive frekvens, omfattning och åtkomst till relevant underlag;

✓ Underleverantörskontroller som kräver att leverantören för vidare likvärdiga säkerhetskrav till sina nedströms partner;

✓ Bestämmelser vid avtalets upphörande, såsom dataåterlämning eller förstöring, återställning av tillgångar och avaktivering av konton.

Listan knyter samman avtalsförväntningarna i DORA Article 30 med ISO/IEC 27001:2022 Annex A-kontroll A.5.20.

Clarysecs policyspråk för organisationer gör samma punkt operativ. I Policy för hantering av risker kopplade till leverantörsberoenden Policy för hantering av risker kopplade till leverantörsberoenden, avsnittet ”Krav på genomförande”, klausul 6.4.3, anges:

Tekniska fallback-lösningar: Säkerställ dataportabilitet och interoperabilitet för att stödja tjänsteövergång vid behov (t.ex. regelbundna säkerhetskopior i standardformat från en SaaS-leverantör för att möjliggöra migrering).

Samma policy, klausul 6.8.2, kräver:

Rätt till övergångsstöd (exit support-klausul) när leverantörsbyte krävs, inklusive fortsatt tjänsteleverans under en definierad övergångsperiod.

Denna klausul avgör ofta om en exitstrategi klarar revision. Den omvandlar exit från ett abrupt avbrott till en styrd övergång.

För mindre entiteter kräver Policy för leverantörssäkerhet och tredjepartssäkerhet – SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME, avsnittet ”Styrningskrav”, klausul 5.3.6:

Uppsägningvillkor, inklusive säker dataåterlämning eller förstöring

För större organisationer kräver Policy för leverantörssäkerhet och tredjepartssäkerhet Policy för leverantörssäkerhet och tredjepartssäkerhet, avsnittet ”Krav för genomförande av policyn”, klausul 6.5.1.2:

Återlämning eller certifierad förstöring av all organisationsägd information

Dessa policykrav ska kunna spåras direkt till avtalsklausuler, leverantörsrutiner, exit-runbooks och revisionsbevis.

Molnexit: testa portabilitet innan ni behöver den

Molntjänster är området där DORA-exitstrategier ofta blir vaga. Företaget antar att data kan exporteras, men ingen har testat formatet. Det antar att radering kommer att ske, men leverantörens bevarandemodell omfattar säkerhetskopior och replikerad lagring. Det antar att en alternativ leverantör kan ta emot data, men scheman, identitetsintegrationer, krypteringsnycklar, hemligheter, loggar, API:er och hastighetsbegränsningar gör migreringen långsammare än verksamhetens tolerans för påverkan medger.

ISO/IEC 27001:2022 Annex A-kontroll A.5.23 hanterar detta livscykelproblem genom att kräva informationssäkerhetskontroller för anskaffning, användning, hantering och exit från molntjänster.

Clarysecs Policy för användning av molntjänster – SME Policy för användning av molntjänster – SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.3.4 kräver:

Bekräftad förmåga till dataexport före införande (t.ex. för att undvika leverantörsinlåsning)

Klausul 6.3.5 kräver:

Bekräftelse av rutiner för säker radering före kontostängning

Dessa krav hör hemma i början av leverantörslivscykeln. Vänta inte till uppsägningen med att fråga om data kan exporteras. Vänta inte till kontostängningen med att fråga om raderingsunderlag finns.

Ett praktiskt DORA-test av molnexit bör omfatta:

1. Exportera ett representativt dataset i det överenskomna formatet.
2. Validera fullständighet, riktighet, tidsstämplar, metadata och åtkomstkontroller.
3. Importera datasetet till en stagingmiljö eller ett alternativt verktyg.
4. Bekräfta hantering av krypteringsnycklar och rotation av hemligheter.
5. Bekräfta loggexport och bevarande av revisionsspår.
6. Dokumentera leverantörens raderingsrutiner, inklusive bevarande av säkerhetskopior och intyg om radering.
7. Registrera avvikelser, avhjälpande åtgärder, ägare och tidsfrister.
8. Uppdatera leverantörsriskbedömningen, SoA och exitplanen.

Portabilitet är inte ett löfte i upphandlingen. Det är en testad förmåga.

En veckosprint för en revisionsklar DORA-exitplan

Tänk dig ett betalningsinstitut som använder en SaaS-leverantör för bedrägerianalys. Leverantören tar emot transaktionsdata, kundidentifierare, enhetstelemetri, beteendesignaler, bedrägeriregler, poängsättningsresultat och ärendeanteckningar. Tjänsten stödjer en kritisk process för bedrägeridetektering. Företaget använder även ett datalager i molnet för att lagra exporterade analysresultat.

Informationssäkerhetschefen vill ha en DORA-exitstrategi för IKT-tredjepartsleverantörer som håller för internrevision och tillsynsgranskning. En veckosprint kan synliggöra luckorna och bygga beviskedjan.

Dag 1: klassificera leverantören och definiera exitscenariot

Med Zenith Blueprint, fasen Kontroller i praktiken, steg 23, åtgärdspunkter för kontrollerna 5.19 till 5.37, börjar teamet med att granska och klassificera leverantörsportföljen:

Sammanställ en fullständig lista över aktuella leverantörer och tjänsteleverantörer (5.19) och klassificera dem utifrån åtkomst till system, data eller operativ styrning. För varje klassificerad leverantör ska teamet verifiera att säkerhetsförväntningar tydligt ingår i avtal (5.20), inklusive sekretess, åtkomst, incidentrapportering och krav på efterlevnad.

Leverantören klassificeras som kritisk eftersom den stödjer en kritisk eller viktig funktion, behandlar känsliga operativa data och påverkar resultat från transaktionsövervakning.

Teamet definierar tre exitutlösare:

• Leverantörens insolvens eller avveckling av tjänsten.
• Väsentlig säkerhetsöverträdelse eller förlorat förtroende.
• Strategisk migrering för att minska koncentrationsrisk.

Dag 2: bygg kravförteckningen och riskposten

Teamet skapar en kravförteckning som omfattar DORA IKT-tredjepartsrisk, ISO/IEC 27001:2022-kontroller för leverantörer och moln, GDPR-krav för personuppgifter, kundavtalsåtaganden och intern riskaptit.

Enligt GDPR bekräftar företaget om transaktionsidentifierare, enhets-ID:n, positionssignaler och beteendeanalys avser identifierade eller identifierbara personer. Principerna i GDPR Article 5, inklusive riktighet, konfidentialitet, lagringsbegränsning och ansvarsskyldighet, blir en del av kravet på exitunderlag. Om exiten innebär överföring till en ny leverantör ska rättslig grund, ändamål, minimering, bevarande, villkor för personuppgiftsbiträde och skyddsåtgärder dokumenteras.

Riskposten innehåller följande:

Dag 3: åtgärda avtalsluckor

Juridik och upphandling jämför avtalet med Clarysecs leverantörsklausuler. De lägger till övergångsstöd, fortsatt tjänst under en definierad övergångsperiod, åtkomst till revision och underlag, underrättelse om underleverantörer, format för dataexport, intyg om säker radering, incidentsamarbete och åtaganden om återställningstid.

Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning, avsnittet ”Krav för genomförande av policyn”, klausul 6.5.1 anger:

Avtal med kritiska leverantörer ska innehålla kontinuitetsförpliktelser och åtaganden om återställningstid.

För små och medelstora företag kräver Policy för verksamhetskontinuitet och katastrofåterställning – SME Policy för verksamhetskontinuitet och katastrofåterställning – SME, avsnittet ”Riskbehandling och undantag”, klausul 7.2.1.4 att team ska:

dokumentera planer för tillfällig ersättning av leverantör eller partner

Den klausulen omvandlar ”vi migrerar” till en genomförbar fallback: vilken leverantör, vilket internt alternativt arbetssätt, vilken manuell process, vilket datauttag, vilken ägare och vilken godkännandeväg.

Dag 4: testa dataportabilitet och återställningsförmåga från säkerhetskopior

Teknikteamet exporterar bedrägeriregler, ärendedata, poängsättningsresultat för transaktioner, loggar, konfiguration, API-dokumentation och användaråtkomstlistor. De testar om data kan återställas eller återanvändas i en kontrollerad miljö.

Policy för säkerhetskopiering och återställning – SME Policy för säkerhetskopiering och återställning – SME, avsnittet ”Styrningskrav”, klausul 5.3.3 kräver:

Återställningstester genomförs minst kvartalsvis, och resultaten dokumenteras för att verifiera återställningsförmåga

Den organisationsövergripande Policy för säkerhetskopiering och återställning Policy för säkerhetskopiering och återställning, avsnittet ”Efterlevnad och tillämpning”, klausul 8.3.1 tillägger:

Granska regelbundet loggar för säkerhetskopiering, konfigurationsinställningar och testresultat

I Zenith Blueprint, fasen Kontroller i praktiken, steg 19, kontroll 8.13, varnar Clarysec för varför detta är viktigt:

Återställningstestning är där de flesta organisationer brister. En säkerhetskopia som inte kan återställas i tid, eller inte alls, är en belastning, inte en tillgång. Schemalägg regelbundna återställningsövningar, även om de bara är partiella, och dokumentera resultatet.

Teamet upptäcker att exporterade ärendeanteckningar inte innehåller bilagor och att API-hastighetsbegränsningar gör en fullständig export för långsam för det definierade återställningsmålet. Avvikelsen loggas, tilldelas och åtgärdas genom ett avtalstillägg och en teknisk omdesign av exporten.

Dag 5: genomför en skrivbordsövning för exit och granska underlaget

Teamet genomför en skrivbordsövning: leverantören meddelar uppsägning med 90 dagars varsel efter en större incident. Verksamheten måste fortsätta bedrägeriövervakningen medan data migreras.

I Zenith Blueprint, fasen Kontroller i praktiken, steg 23, kontroll 5.30, förklarar Clarysec teststandarden:

IKT-beredskap börjar långt innan störningen inträffar. Den omfattar identifiering av kritiska system, förståelse för deras inbördes beroenden och mappning mot verksamhetsprocesser.

Samma avsnitt tillägger:

De Recovery Time Objective (RTO) och Recovery Point Objective (RPO) som definieras i planen för verksamhetskontinuitet ska återspeglas i tekniska konfigurationer, avtal och infrastrukturdesign.

Underlagspaketet omfattar leverantörsklassificering, riskbedömning, avtalsklausuler, exit-runbook, resultat från dataexport, underlag från återställning av säkerhetskopior, raderingsrutin, bedömning av alternativ leverantör, protokoll från skrivbordsövning, åtgärdslogg, ledningens godkännande och beslut om kvarstående risk.

Informationssäkerhetschefen kan nu besvara styrelsens fråga med underlag, inte optimism.

Tvärgående regelefterlevnad: en exitplan, flera revisionsperspektiv

En stark DORA-exitstrategi minskar dubbelarbete inom regelefterlevnad över ISO/IEC 27001:2022, NIS2, GDPR, NIST och COBIT 2019-styrningsförväntningar.

Det viktiga är inte att ett ramverk ersätter ett annat. Värdet är att ett väl uppbyggt ISMS gör det möjligt för organisationen att ta fram underlag en gång och återanvända det på ett intelligent sätt.

Clarysecs Zenith Controls hjälper team att förbereda sig för dessa revisionsperspektiv genom att koppla ISO/IEC 27001:2022-kontroller till revisionsbevis och förväntningar i andra ramverk.

Ett vanligt revisionsfel är fragmenterat underlag. Leverantörsansvarig har avtalet. IT har loggar för säkerhetskopiering. Juridik har personuppgiftsbiträdesavtalet. Riskfunktionen har bedömningen. Funktionen för regelefterlevnad har den regulatoriska mappningen. Ingen har hela bilden.

Clarysec löser detta genom att utforma underlagspaketet kring exitscenariot. Varje dokument besvarar en revisionsfråga: vilken tjänst lämnas, varför är den kritisk, vilka data och system påverkas, vem äger risken, vilka avtalsrättigheter gör exit möjlig, vilka tekniska mekanismer gör migrering möjlig, vilka kontinuitetsarrangemang håller verksamheten igång, vilket test visar att planen fungerar, vilka avvikelser åtgärdades och vem godkände den kvarstående risken.

Clarysecs checklista för DORA-exitstrategi

Använd denna checklista för att omvandla en DORA-exitstrategi för IKT-tredjepartsleverantörer från ett dokument till en granskningsbar kontrolluppsättning.

Gör exitplanering till en resilienskontroll för styrelsen

Om er DORA-exitstrategi bara är en avtalsklausul är den inte klar. Om er säkerhetskopia aldrig har återställts är den inte klar. Om er molnleverantör kan exportera data men ingen har validerat fullständigheten är den inte klar. Om styrelsen inte kan se beslutet om kvarstående risk är den inte klar.

Clarysec hjälper informationssäkerhetschefer, complianceansvariga, revisorer och verksamhetsägare att bygga DORA-exitstrategier för IKT-tredjepartsleverantörer som är praktiska, proportionerliga och revisionsklara. Vi kombinerar Zenith Blueprint Zenith Blueprint för genomförandesekvensering, Zenith Controls Zenith Controls för mappning av tvärgående regelefterlevnad och policymallar såsom Policy för hantering av risker kopplade till leverantörsberoenden Policy för hantering av risker kopplade till leverantörsberoenden, Policy för användning av molntjänster – SME Policy för användning av molntjänster – SME, Policy för leverantörssäkerhet och tredjepartssäkerhet – SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME och Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning för att skapa en komplett kedja från kontroll till underlag.

Nästa steg är enkelt och har högt värde: välj en kritisk IKT-leverantör denna vecka. Klassificera den, granska avtalet, testa en dataexport, verifiera en återställning, dokumentera en ersättningsplan och skapa ett underlagspaket.

Den enda övningen visar om er DORA-exitstrategi är en verklig resiliensförmåga eller bara ett dokument som väntar på att fallera i revision.