DORA-exitstrategier for IKT med ISO 27001-kontroller

Kl. 07:42 en mandag modtager en driftsansvarlig i en fintech den besked, ingen ønsker at læse: virksomhedens cloudbaserede udbyder af transaktionsovervågning er ramt af et alvorligt regionalt nedbrud. Kl. 08:15 spørger risikodirektøren, om den berørte tjeneste understøtter en kritisk eller vigtig funktion. Kl. 08:40 vil juridisk afdeling vide, om kontrakten giver virksomheden ret til overgangsbistand, dataeksport, sletning og revision. Kl. 09:05 leder CISO’en efter bevismateriale for, at exitplanen er testet og ikke blot skrevet.

I en anden finansiel virksomhed åbner Sarah, CISO for en hastigt voksende fintechplatform, en informationsanmodning forud for revision som led i en DORA-efterlevelsesvurdering. Spørgsmålene er velkendte, indtil hun når afsnittet om IKT-tredjepartsudbydere, der understøtter kritiske eller vigtige funktioner. Revisorerne spørger ikke, om virksomheden har en leverandørpolitik. De beder om dokumenterede, testede og gennemførlige exitstrategier.

Hun tænker straks på den centrale cloududbyder, der hoster platformen, og derefter på den eksterne sikkerhedsdriftsleverandør (MSSP), der overvåger trusler døgnet rundt. Hvad hvis cloududbyderen rammes af en geopolitisk forstyrrelse? Hvad hvis MSSP’en bliver opkøbt af en konkurrent? Hvad hvis en kritisk SaaS-udbyder bliver insolvent, opsiger tjenesten eller mister kundernes tillid efter en større hændelse?

Det ubehagelige svar er det samme i mange virksomheder. Der findes en leverandørrisikovurdering, en forretningskontinuitetsplan (BCP), en kontraktmappe, en cloudfortegnelse og måske en backuprapport. Men der findes ikke én samlet, revisionsklar DORA-exitstrategi for IKT-tredjepartsudbydere, der forbinder forretningskritikalitet, kontraktlige rettigheder, teknisk portabilitet, forretningskontinuitetsplaner, backupbevismateriale, databeskyttelsesforpligtelser og ledelsesgodkendelse.

DORA ændrer tonen i leverandørstyring. I henhold til forordning (EU) 2022/2554 skal finansielle enheder håndtere IKT-tredjepartsrisiko som en del af rammen for styring af IKT-risiko. De forbliver fuldt ansvarlige for efterlevelse, skal føre et register over kontrakter om IKT-tjenester, skelne mellem IKT-arrangementer, der understøtter kritiske eller vigtige funktioner, vurdere koncentrationsrisiko og risici ved underleverandører og vedligeholde exitstrategier for kritiske IKT-tredjepartsafhængigheder. DORA finder anvendelse fra 17. januar 2025 og fastsætter ensartede EU-krav til styring af IKT-risiko, hændelsesrapportering, test af operationel robusthed, informationsdeling og styring af IKT-tredjepartsrisiko på tværs af en bred vifte af finansielle enheder.

En DORA-exitstrategi er ikke et afsnit i en leverandørkontrakt. Det er et kontrolsystem. Det skal være styret, risikovurderet, teknisk gennemførligt, kontraktligt bindende, testet, dokumenteret og løbende forbedret.

Clarysecs tilgang kombinerer Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, politikskabeloner til virksomheder og Zenith Controls: The Cross-Compliance Guide Zenith Controls, så mandag morgen-spørgsmålet kan besvares med forberedelse frem for improvisation.

Hvorfor DORA-exitstrategier fejler i reelle revisioner

De fleste fejl i DORA-exitstrategier for IKT er strukturelle, før de er tekniske. Organisationen har en leverandøransvarlig, men ingen ansvarlig risikoejer. Den har backupjobs, men intet bevismateriale for gendannelse. Den har et spørgeskema til leverandør-due diligence, men ingen dokumenteret beslutning om, hvorvidt udbyderen understøtter en kritisk eller vigtig funktion. Den har kontraktsprog om opsigelse, men ingen overgangsperiode, der er afstemt med planen for forretningskontinuitet.

DORA tvinger disse elementer sammen. Article 28 fastlægger de generelle principper for styring af IKT-tredjepartsrisiko, herunder behovet for at styre risikoen ved IKT-tredjepartsudbydere gennem hele livscyklussen og vedligeholde passende exitstrategier. Article 30 fastlægger detaljerede kontraktlige krav til IKT-tjenester, der understøtter kritiske eller vigtige funktioner, herunder tjenestebeskrivelser, lokationer for databehandling, sikkerhedsforanstaltninger, adgangs- og revisionsrettigheder, hændelsesassistance, samarbejde med kompetente myndigheder og opsigelsesrettigheder.

Reguleringen er også proportional. Articles 4 and 16 giver visse mindre eller undtagne enheder mulighed for at anvende en forenklet ramme for styring af IKT-risiko. Men forenklet betyder ikke udokumenteret. Mindre finansielle enheder har fortsat brug for dokumenteret styring af IKT-risiko, løbende overvågning, robuste systemer, hurtig identifikation af IKT-hændelser, identifikation af væsentlige IKT-tredjepartsafhængigheder, backup og gendannelse, forretningskontinuitet, respons og genopretning, test, erfaringsopsamling og træning.

En lille fintech kan ikke sige: “Vi er for små til exitplanlægning.” Den kan sige: “Vores DORA-exitstrategi er skaleret til vores størrelse, risikoprofil og servicekompleksitet.” Forskellen er bevismateriale.

For enheder, der også er omfattet af den nationale NIS2-afgrænsning, fungerer DORA som den sektorspecifikke EU-retsakt for overlappende cybersikkerhedsforpligtelser i den finansielle sektor. NIS2 har fortsat betydning i det bredere økosystem, især for managed service providers, Managed Detection and Response (MDR), cloududbydere, datacentre og digitale infrastrukturenheder. NIS2 Article 21 forstærker de samme temaer: risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, effektivitetsvurdering, træning, kryptografi, adgangsstyring, politik for styring af aktiver og autentifikation.

Tilsynsmyndigheder, kunder, revisorer og bestyrelser kan stille spørgsmålet forskelligt, men kernen er den samme: Kan I forlade en kritisk IKT-udbyder uden at miste kontrollen over tjenestekontinuitet, data, bevismateriale eller kundepåvirkning?

Gør exitstrategien til en del af ISMS

ISO/IEC 27001:2022 giver ledelsessystemets fundament for DORA-exitplanlægning.

Clauses 4.1 til 4.4 kræver, at organisationen definerer sin kontekst, interessenter, retlige, regulatoriske og kontraktlige krav, ISMS-omfang, grænseflader, afhængigheder og processer. Det er her, en finansiel enhed identificerer DORA, kundeforpligtelser, outsourcingforventninger, cloudafhængigheder, databeskyttelsesforpligtelser, underleverandører og IKT-tjenester inden for ISMS-grænsen.

Clauses 5.1 til 5.3 kræver lederskab, politik, ressourcer, rolletildeling og ansvarlighed. Det stemmer overens med DORAs styringsmodel, hvor ledelsesorganet definerer, godkender, fører tilsyn med og fortsat har ansvar for styring af IKT-risiko, herunder IKT-forretningskontinuitet, respons- og genopretningsplaner, IKT-revisionsplaner, budgetter, robusthedsstrategi og politik for IKT-tredjepartsrisiko.

Clauses 6.1.1 til 6.1.3 omsætter exitplanlægning til risikobehandling. Organisationen definerer risikokriterier, gennemfører gentagelige risikovurderinger, identificerer risici for fortrolighed, integritet og tilgængelighed, udpeger risikoejere, vurderer konsekvens og sandsynlighed, vælger behandlingsmuligheder, sammenholder kontroller med Annex A, udarbejder en erklæring om anvendelighed, forbereder en risikobehandlingsplan og indhenter risikoejerens godkendelse og accept af restrisiko.

Clause 8.1 kræver derefter operationel planlægning og styring. Organisationen skal planlægge, implementere og styre ISMS-processer, vedligeholde dokumenteret information, der viser, at processerne er udført som planlagt, styre ændringer og kontrollere eksternt leverede processer, produkter eller tjenester, der er relevante for ISMS.

ISO/IEC 27005:2022 styrker denne tilgang. Clause 6.2 anbefaler, at organisationer identificerer interessenters krav, herunder ISO/IEC 27001:2022 Annex A-kontroller, sektorspecifikke standarder, nationale og internationale regler, interne regler, kontraktlige krav og eksisterende kontroller fra tidligere risikobehandling. Clauses 6.4.1 til 6.4.3 forklarer, at risikokriterier bør tage højde for retlige og regulatoriske forhold, leverandørrelationer, databeskyttelse, driftsmæssige konsekvenser, kontraktbrud, tredjepartsdrift og omdømmemæssige konsekvenser. Clauses 8.2 til 8.6 understøtter et kontrolbibliotek og en behandlingsplan, der kan kombinere ISO/IEC 27001:2022 Annex A med DORA, NIS2, GDPR, kundeforpligtelser og interne politikker.

Driftsmodellen er enkel: én kravfortegnelse, ét leverandørrisikoregister, én erklæring om anvendelighed, én risikobehandlingsplan og én dokumentationspakke for hvert kritisk exitscenarie.

ISO/IEC 27001:2022-kontrollerne, der forankrer DORA-exitplanlægning

DORA-exitstrategier bliver klar til revision, når leverandørstyring, cloudportabilitet, kontinuitetsplanlægning og backupbevismateriale behandles som én sammenhængende kontrolkæde.

Clarysecs Zenith Controls kortlægger ISO/IEC 27001:2022 Annex A-kontroller til kontrolattributter, revisionsbevismateriale og forventninger på tværs af efterlevelsesområder. Det er ikke et separat kontrolrammeværk. Det er Clarysecs vejledning på tværs af efterlevelsesområder til at forstå, hvordan ISO/IEC 27001:2022-kontroller understøtter revision, regulatoriske krav og driftsmæssige resultater.

For en DORA-exitstrategi for IKT-tredjepartsudbydere bør revisionssporet vise:

• Leverandøren er klassificeret og knyttet til forretningsprocesser.
• Tjenesten er vurderet i forhold til, om den understøtter en kritisk eller vigtig funktion.
• Exitriskoen er registreret med en ansvarlig risikoejer.
• Kontraktklausuler understøtter overgang, adgang, revision, datareturnering, datasletning, samarbejde og kontinuitet.
• Cloudportabilitet og interoperabilitet er valideret.
• Backups og gendannelsestest dokumenterer muligheden for gendannelse.
• Midlertidig substitution eller alternativ behandling er dokumenteret.
• Resultater af exittest er gennemgået, afhjulpet og rapporteret til ledelsen.

Kontraktsproget er den første kontinuitetskontrol

En kontrakt bør være den første kontinuitetskontrol, ikke en barriere for kontinuitet. Hvis udbyderen kan opsige hurtigt, forsinke eksport, begrænse adgang til logfiler, opkræve udefinerede overgangsgebyrer eller nægte migrationsstøtte, er exitstrategien skrøbelig.

I Zenith Blueprint, fasen Controls in Action, Step 23, Control 5.20, forklares det, at leverandøraftaler bør indeholde de praktiske sikkerhedskrav, der gør exit mulig:

Centrale områder, der typisk behandles i leverandøraftaler, omfatter:

✓ Fortrolighedsforpligtelser, herunder omfang, varighed og begrænsninger for videregivelse til tredjeparter;

✓ Ansvar for adgangsstyring, f.eks. hvem der kan få adgang til jeres data, hvordan legitimationsoplysninger administreres, og hvilken overvågning der er etableret;

✓ Tekniske og organisatoriske foranstaltninger for databeskyttelse, kryptering, krypteret transmission, backup og tilgængelighedsforpligtelser;

✓ Tidsfrister og protokoller for rapportering af hændelser, ofte med definerede tidsrammer;

✓ Revisionsret, herunder frekvens, omfang og adgang til relevant bevismateriale;

✓ Underleverandørkontroller, som kræver, at leverandøren viderefører tilsvarende sikkerhedsforpligtelser til sine downstream-partnere;

✓ Bestemmelser ved kontraktophør, f.eks. returnering eller destruktion af data, genopretning af aktiver og deaktivering af konti.

Listen forbinder DORA Article 30-kontraktforventninger med ISO/IEC 27001:2022 Annex A-kontrol A.5.20.

Clarysecs politikformuleringer til virksomheder gør samme pointe operationel. I Politik for risikostyring af leverandørafhængigheder Politik for risikostyring af leverandørafhængigheder, afsnittet “Implementeringskrav”, fastslår clause 6.4.3:

Tekniske reserveordninger: Sørg for dataoverførbarhed og interoperabilitet for at understøtte serviceovergang, hvis det kræves (f.eks. regelmæssige backups i standardformater fra en SaaS-udbyder for at muliggøre migration).

Samme politik, clause 6.8.2, kræver:

Ret til overgangsbistand (overgangsbistandsklausul), hvor et leverandørskifte er påkrævet, herunder fortsat service i en defineret overgangsperiode.

Denne klausul afgør ofte, om en exitstrategi kan bestå en revision. Den gør exit fra en brat afbrydelse til en styret overgang.

For mindre enheder kræver Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV, afsnittet “Styringskrav”, clause 5.3.6:

Opsigelsesvilkår, herunder sikker returnering eller destruktion af data

For virksomhedsmiljøer kræver Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed, afsnittet “Krav til implementering af politikken”, clause 6.5.1.2:

Returnering eller certificeret destruktion af alle organisationsejede oplysninger

Disse politikkrav bør kunne spores direkte til kontraktklausuler, leverandørprocedurer, exit-runbooks og revisionsbevismateriale.

Cloudexit: test portabilitet, før I får brug for den

Cloudtjenester er dér, hvor DORA-exitstrategier ofte bliver uklare. Virksomheden antager, at den kan eksportere data, men ingen har testet formatet. Den antager, at sletning vil finde sted, men udbyderens opbevaringsmodel omfatter backups og replikeret lagring. Den antager, at en alternativ udbyder kan modtage dataene, men skemaer, identitetsintegrationer, krypteringsnøgler, secrets, logfiler, API’er og hastighedsbegrænsninger gør migrationen langsommere, end den fastlagte tolerancetærskel tillader.

ISO/IEC 27001:2022 Annex A-kontrol A.5.23 adresserer dette livscyklusproblem ved at kræve informationssikkerhedskontroller for anskaffelse, brug, styring og exit fra cloudtjenester.

Clarysecs Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV, afsnittet “Krav til implementering af politikken”, clause 6.3.4 kræver:

Dataeksportkapacitet bekræftet før onboarding (f.eks. for at undgå leverandørlåsning)

Clause 6.3.5 kræver:

Bekræftelse af procedurer for sikker sletning før kontolukning

Disse krav hører hjemme i begyndelsen af leverandørens livscyklus. Vent ikke til opsigelse med at spørge, om data kan eksporteres. Vent ikke til kontolukning med at spørge, om der findes bevismateriale for sletning.

En praktisk DORA-cloudexittest bør omfatte:

1. Eksportér et repræsentativt datasæt i det aftalte format.
2. Validér fuldstændighed, integritet, tidsstempler, metadata og adgangskontroller.
3. Importér datasættet til et stagingmiljø eller et alternativt værktøj.
4. Bekræft håndtering af krypteringsnøgler og rotation af secrets.
5. Bekræft eksport af logfiler og opbevaring af revisionsspor.
6. Dokumentér udbyderens sletteprocedurer, herunder opbevaring af backups og certificering af sletning.
7. Registrér problemer, afhjælpende foranstaltninger, ejere og frister.
8. Opdater leverandørrisikovurderingen, erklæringen om anvendelighed og exitplanen.

Portabilitet er ikke et indkøbsløfte. Det er en testet kapacitet.

Et ugelangt sprint for en revisionsklar DORA-exitplan

Forestil dig et betalingsinstitut, der anvender en SaaS-udbyder til sviganalyse. Udbyderen indsamler transaktionsdata, kundeidentifikatorer, enhedstelemetri, adfærdssignaler, svigregler, scoringsresultater og sagsnoter. Tjenesten understøtter en kritisk proces for svigdetektion. Virksomheden bruger også et cloudbaseret datalager til at opbevare eksporterede analyseresultater.

CISO’en ønsker en DORA-exitstrategi for IKT-tredjepartsudbydere, der kan klare intern revision og tilsynsmæssig gennemgang. Et ugelangt sprint kan afdække hullerne og opbygge dokumentationskæden.

Dag 1: Klassificér leverandøren og definér exitscenariet

Med Zenith Blueprint, fasen Controls in Action, Step 23, Action Items for Controls 5.19 til 5.37, starter teamet med at gennemgå og klassificere leverandørporteføljen:

Udarbejd en komplet liste over nuværende leverandører og tjenesteudbydere (5.19), og klassificér dem ud fra adgang til systemer, data eller driftsmæssig kontrol. For hver klassificeret leverandør skal det verificeres, at sikkerhedsforventninger er klart indarbejdet i kontrakter (5.20), herunder fortrolighed, adgang, hændelsesrapportering og efterlevelsesforpligtelser.

Leverandøren klassificeres som kritisk, fordi den understøtter en kritisk eller vigtig funktion, behandler følsomme driftsdata og påvirker resultaterne af transaktionsovervågningen.

Teamet definerer tre exitudløsere:

• Udbyderens insolvens eller ophør af tjenesten.
• Væsentligt sikkerhedsbrud eller tab af tillid.
• Strategisk migration for at reducere koncentrationsrisiko.

Dag 2: Opbyg kravfortegnelsen og risikoregistreringen

Teamet opretter én kravfortegnelse, der dækker DORA IKT-tredjepartsrisiko, ISO/IEC 27001:2022-leverandør- og cloudkontroller, GDPR-forpligtelser for personoplysninger, kundekontraktforpligtelser og intern risikoappetit.

I henhold til GDPR bekræfter virksomheden, om transaktionsidentifikatorer, enheds-id’er, lokationssignaler og adfærdsanalyser vedrører identificerede eller identificerbare personer. GDPR Article 5-principperne, herunder integritet, fortrolighed, opbevaringsbegrænsning og ansvarlighed, bliver en del af kravene til exitbevismateriale. Hvis exit indebærer overførsel til en ny udbyder, skal behandlingsgrundlag, formål, dataminimering, opbevaring, databehandlervilkår og sikkerhedsforanstaltninger dokumenteres.

Risikoregistreringen omfatter følgende:

Dag 3: Luk kontraktmæssige huller

Juridisk afdeling og indkøb sammenholder kontrakten med Clarysecs leverandørklausuler. De tilføjer overgangsbistand, fortsat service i en defineret overgangsperiode, adgang til revision og bevismateriale, underretning om underleverandører, dataeksportformat, certificering af sikker sletning, hændelsessamarbejde og forpligtelser om genopretningstid.

Politik for forretningskontinuitet og katastrofeberedskab Politik for forretningskontinuitet og katastrofeberedskab, afsnittet “Krav til implementering af politikken”, clause 6.5.1 fastslår:

Kontrakter med kritiske leverandører skal indeholde forpligtelser vedrørende forretningskontinuitet og forpligtelser om genopretningstid.

For SMV’er kræver Politik for forretningskontinuitet og katastrofeberedskab - SMV Politik for forretningskontinuitet og katastrofeberedskab - SMV, afsnittet “Risikobehandling og undtagelser”, clause 7.2.1.4, at teams:

dokumenterer midlertidige substitutionsplaner for leverandører eller partnere

Denne klausul omsætter “vi migrerer” til en handlingsklar reserveordning: hvilken udbyder, hvilken intern nødprocedure, hvilken manuel proces, hvilket dataudtræk, hvilken ejer og hvilken godkendelsesvej.

Dag 4: Test dataoverførbarhed og backupgendannelse

Teknologiteamet eksporterer svigregler, sagsdata, transaktionsscoringsresultater, logfiler, konfiguration, API-dokumentation og brugerlister for adgang. De tester, om data kan gendannes eller genbruges i et kontrolleret miljø.

Politik for backup og gendannelse - SMV Politik for backup og gendannelse - SMV, afsnittet “Styringskrav”, clause 5.3.3 kræver:

Gendannelsestest udføres mindst kvartalsvis, og resultaterne dokumenteres for at verificere muligheden for gendannelse

Den virksomhedsdækkende Politik for backup og gendannelse Politik for backup og gendannelse, afsnittet “Håndhævelse og efterlevelse”, clause 8.3.1 tilføjer:

Gennemfør periodisk revision af backup-logfiler, konfigurationsindstillinger og testresultater

I Zenith Blueprint, fasen Controls in Action, Step 19, Control 8.13, advarer Clarysec om, hvorfor dette er vigtigt:

Gendannelsestest er dér, hvor de fleste organisationer kommer til kort. En backup, der ikke kan gendannes rettidigt eller overhovedet, er en belastning, ikke et aktiv. Planlæg regelmæssige gendannelsesøvelser, også selv om de kun er delvise, og dokumentér resultatet.

Teamet opdager, at eksporterede sagsnoter ikke omfatter vedhæftede filer, og at API-hastighedsbegrænsninger gør en fuld eksport for langsom i forhold til det definerede genopretningsmål. Forholdet logges, tildeles og afhjælpes gennem et kontrakttillæg og et teknisk redesign af eksporten.

Dag 5: Gennemfør exit-tabletop og gennemgang af bevismateriale

Teamet gennemfører en tabletop-øvelse: Leverandøren meddeler opsigelse med 90 dages varsel efter en større hændelse. Driften skal fortsætte svigovervågningen, mens data migreres.

I Zenith Blueprint, fasen Controls in Action, Step 23, Control 5.30, forklarer Clarysec teststandarden:

IKT-parathed begynder længe før en forstyrrelse opstår. Den indebærer identifikation af kritiske systemer, forståelse af deres indbyrdes afhængigheder og kortlægning til forretningsprocesser.

Samme afsnit tilføjer:

Recovery Time Objectives (RTO’er) og Recovery Point Objectives (RPO’er), der er defineret i planen for forretningskontinuitet, skal afspejles i tekniske konfigurationer, kontrakter og infrastrukturdesign.

Dokumentationspakken omfatter leverandørklassificering, risikovurdering, kontraktklausuler, exit-runbook, resultater af dataeksport, bevismateriale for backupgendannelse, sletteprocedure, vurdering af alternativ udbyder, referat fra tabletop-øvelse, afhjælpningslog, ledelsesgodkendelse og beslutning om restrisiko.

CISO’en kan nu besvare bestyrelsens spørgsmål med bevismateriale, ikke optimisme.

Efterlevelse på tværs: én exitplan, flere revisionsperspektiver

En stærk DORA-exitstrategi reducerer dobbeltarbejde med efterlevelse på tværs af ISO/IEC 27001:2022, NIS2, GDPR, NIST og COBIT 2019-styringsforventninger.

Det vigtige er ikke, at ét rammeværk erstatter et andet. Værdien er, at et velopbygget ISMS gør det muligt for organisationen at generere bevismateriale én gang og genbruge det intelligent.

Clarysecs Zenith Controls hjælper teams med at forberede sig på disse revisionsperspektiver ved at forbinde ISO/IEC 27001:2022-kontroller med revisionsbevismateriale og forventninger på tværs af rammeværker.

En almindelig revisionsfejl er fragmenteret bevismateriale. Leverandøransvarlig har kontrakten. IT har backup-logfiler. Juridisk afdeling har databehandleraftalen. Risk har vurderingen. Compliance har den regulatoriske kortlægning. Ingen har det fulde billede.

Clarysec løser dette ved at designe dokumentationspakken omkring exitscenariet. Hvert dokument besvarer ét revisionsspørgsmål: Hvilken tjeneste forlades, hvorfor er den kritisk, hvilke data og systemer berøres, hvem ejer risikoen, hvilke kontraktrettigheder gør exit mulig, hvilke tekniske mekanismer gør migration mulig, hvilke kontinuitetsordninger holder forretningen kørende, hvilken test dokumenterer, at planen virker, hvilke forhold er afhjulpet, og hvem har godkendt restrisikoen.

Clarysecs tjekliste for DORA-exitstrategier

Brug denne tjekliste til at gøre en DORA-exitstrategi for IKT-tredjepartsudbydere fra et dokument til et revisionsbart kontrolsæt.

Gør exitplanlægning til en robusthedskontrol, bestyrelsen kan bruge

Hvis jeres DORA-exitstrategi kun er en kontraktklausul, er den ikke klar. Hvis jeres backup aldrig er blevet gendannet, er den ikke klar. Hvis jeres cloududbyder kan eksportere data, men ingen har valideret fuldstændigheden, er den ikke klar. Hvis bestyrelsen ikke kan se beslutningen om restrisiko, er den ikke klar.

Clarysec hjælper CISO’er, complianceansvarlige, revisorer og forretningsejere med at opbygge DORA-exitstrategier for IKT-tredjepartsudbydere, der er praktiske, proportionale og klar til revision. Vi kombinerer Zenith Blueprint Zenith Blueprint til sekventering af implementering, Zenith Controls Zenith Controls til kortlægning på tværs af efterlevelsesområder og politikskabeloner som Politik for risikostyring af leverandørafhængigheder Politik for risikostyring af leverandørafhængigheder, Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV, Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV og Politik for forretningskontinuitet og katastrofeberedskab Politik for forretningskontinuitet og katastrofeberedskab for at skabe en komplet kæde fra kontrol til bevismateriale.

Jeres næste skridt er enkelt og værdifuldt: Vælg én kritisk IKT-leverandør i denne uge. Klassificér den, gennemgå kontrakten, test én dataeksport, verificér én gendannelse, dokumentér én substitutionsplan, og opret én dokumentationspakke.

Den ene øvelse vil vise, om jeres DORA-exitstrategi er en reel robusthedskapacitet eller blot et dokument, der venter på at fejle under revision.