
DORA har fundet anvendelse siden den 17. januar 2025. For finansielle enheder betyder parathed nu at opretholde en driftsmodel for digital operationel modstandsdygtighed, ikke at forberede sig på en fremtidig frist. For teknologileverandører betyder det at forstå ansvaret over for kunderne, og om der gælder en særskilt ordning med direkte tilsyn.
Ledelsens spørgsmål er praktisk: Kan organisationen forklare, hvilke finansielle tjenester der afhænger af hvilke IKT-systemer, hvordan afbrydelser vil blive håndteret, og hvilken dokumentation der understøtter dens antagelser om genopretning? Politikker er vigtige, men de kan ikke besvare det spørgsmål alene. Ledelsen har brug for et sammenhængende overblik over ansvarsområder, afhængigheder, kontrakter, tests, hændelser og uafklarede risici.
Begynd med en dokumenteret beslutning om anvendelsesområdet for hver relevant juridisk enhed. Artikel 2 i DORA angiver de omfattede kategorier og undtagelserne. En virksomhed, der beskriver sig selv som fintech, startup eller SMV, er ikke automatisk omfattet eller undtaget.
Eksempler på omfattede finansielle enheder er kreditinstitutter, betalingsinstitutter, investeringsselskaber og forsikringsselskaber, med forbehold af forordningens detaljerede regler om anvendelsesområdet. Registrér den relevante kategori, eventuelle undtagelser eller fritagelser, den relevante kompetente myndighed og begrundelsen for jeres konklusion.
For leverandører skal der skelnes mellem tre positioner:
| Position | Hvad ledelsen skal fastlægge |
|---|---|
| Omfattet finansiel enhed | Dens egne DORA-forpligtelser, governanceordninger og tilsynsrelation |
| IKT-leverandør til en finansiel enhed | De kontraktlige forpligtelser, den dokumentation, det samarbejde og de serviceordninger, som kunderne kræver |
| Udpeget kritisk tredjepartsudbyder af IKT-ydelser | De yderligere forpligtelser, der følger af udpegningen og DORA's tilsynsramme |
En leverandør, der understøtter en kritisk eller vigtig finansiel funktion, er ikke alene af den grund en udpeget kritisk tredjepartsudbyder af IKT-ydelser. Finansielle enheder vurderer betydningen af deres funktioner og afhængigheder; udpegningen af kritiske udbydere sker gennem tilsynsrammen efter artikel 31.
Placeringen afgør ikke leverandørspørgsmålet. En amerikansk cloud- eller softwareudbyder kan blive mødt med DORA-relaterede krav fra kunder, når den betjener finansielle enheder i EU. Den kommercielle relation gør ikke automatisk udbyderen omfattet af alle forpligtelser, der pålægges en finansiel enhed.
Proportionalitet kræver også en begrundet vurdering. Artikel 4 tager hensyn til faktorer som størrelse, samlet risikoprofil samt tjenesternes karakter, omfang og kompleksitet. Artikel 16 indeholder en forenklet ramme for IKT-risikostyring for bestemte kategorier. Det er ikke indbyrdes udskiftelige begreber, og almindelig SMV-status er ikke en universel genvej. Opbevar analysen af berettigelsen sammen med beslutningen om anvendelsesområdet.
Efter artikel 5 i DORA har ledelsesorganet det endelige ansvar for at styre den finansielle enheds IKT-risiko. Delegering af implementeringen til en CISO, et teknologiteam eller en ekstern udbyder overfører ikke dette ansvar.
Ledelsen bør fastlægge, hvem der foreslår beslutninger, hvem der godkender dem, og hvem der kontrollerer, om implementeringen virker. Driftsmodellen bør dække forretningskontinuitet, hændelseshåndtering og genopretning, tredjepartsordninger, budget og den viden, der er nødvendig for et reelt tilsyn.
En praktisk anbefaling er at give ledelsen en beslutningsorienteret rapporteringspakke i stedet for et dashboard med procentvis færdiggørelse. Medtag:
Hver mangel bør skelne mellem det lovgivningsmæssige krav, den aktuelle operationelle svaghed og den foreslåede løsning. En manglende godkendelsesregistrering er noget andet end en sikkerhedskopi, der ikke kan gendannes. Begge kan kræve handling, men de kræver forskellige ejere og prioriteter.
Ledelsens godkendelse af en afhjælpningsplan er ikke en tilladelse til at udskyde gældende forpligtelser på ubestemt tid. Hvor en mangel er væsentlig, bør umiddelbare sikringsforanstaltninger, eskalering og eventuelle tilsynsmæssige konsekvenser overvejes sammen med den langsigtede løsning.
En aktivfortegnelse er nødvendig, men planlægningen af modstandsdygtighed bør begynde med den tjeneste, der skal fortsætte. Identificér den finansielle funktion, dens forretningsejer, konsekvenserne af en afbrydelse og de systemer og udbydere, der understøtter den.
For en betalingstjeneste skal identitet, cloudinfrastruktur, transaktionsbehandling, overvågning og eskalering til leverandører kortlægges. Medtag mindre synlige afhængigheder som DNS, forbindelser, privilegeret adgang, krypteringsnøgler og supportværktøjer. Et alternativt produktionsmiljø kan være ubrugeligt, hvis det afhænger af den samme fejlende identitetstjeneste.
Det resulterende kort bør forbinde hver funktion med:
Validér kortet med både drifts- og forretningsteams. Indkøbsregistreringer viser, hvad der er købt; de viser ikke nødvendigvis, hvordan en tjeneste fungerer i dag.
Brug denne model til at organisere IKT-risikostyring, håndtering og indberetning af hændelser, test af modstandsdygtighed og IKT-tredjepartsrisiko. DORA indeholder også bestemmelser om frivillig udveksling af oplysninger om cybertrusler. Hvis I deltager, skal I definere medlemskab, fortrolighed, tilladt anvendelse og håndteringsregler i stedet for at behandle udvekslingen som en ubegrænset deling af hændelsesdata.
DORA's bestemmelser om IKT-risikostyring dækker identifikation, beskyttelse og forebyggelse, detektion, reaktion og genopretning, læring samt kommunikation. Rammen skal forbinde disse aktiviteter i stedet for at efterlade dem som separate samlinger af politikker.
Begynd mangelvurderingen med de kortlagte funktioner. Spørg, om adgangskontroller beskytter deres systemer, om sårbarheder håndteres, om ændringer kontrolleres, om mistænkelig aktivitet opdages, og om genopretningsordningerne afspejler realistiske fejl. Overvej tekniske fejl og driftsmæssige fejltagelser lige så vel som ondsindede angreb.
Opret for hver væsentlig svaghed en afhjælpningsregistrering med en ejer, forretningsmæssig konsekvens, påkrævet handling, kriterier for gennemførelse og dokumentation for lukning. Afhængigheder har betydning: En forbedring af gendannelsesprocedurerne kan kræve ændringer i adgangen til sikkerhedskopier, leverandørforpligtelser og medarbejderuddannelse, før en vellykket test er mulig.
Genopretningsmål bør udspringe af forretningsbehov og konsekvensanalyse, ikke af det, en leverandørs standardserviceniveau tilfældigvis tilbyder. Hvor den tekniske kapacitet ikke kan opfylde målet, skal ledelsen beslutte, om arkitekturen skal forbedres, serviceordningen ændres, eller driftsmodellen genovervejes. Et mål, der står i en beredskabsplan, er ikke dokumentation for, at genopretning er mulig.
DORA kræver, at finansielle enheder håndterer IKT-relaterede hændelser og indberetter større hændelser til den relevante kompetente myndighed. Artikel 17–23 fastlægger rammen; de relevante reguleringsmæssige og gennemførelsesmæssige tekniske standarder fastsætter detaljerede klassifikationskriterier, tærskler, indberetningsindhold og procedurer.
Forlad jer ikke på en generisk tjekliste for hændelser, når det gælder den detaljerede indberetningsplan. Vedligehold en aktuel indberetningsmatrix, der angiver de gældende standarder, myndighedens instruktioner, indberetningskanalen, indberetningsfaserne og beregningen af frister. Placér ansvaret for at holde den opdateret.
Reaktionsprocessen bør gøre flere beslutninger gennemførlige under pres:
Registrér begrundelsen for klassifikationen, også når en hændelse ikke indberettes som større. Et ufuldstændigt første billede bør udløse en ny vurdering, efterhånden som oplysningerne udvikler sig, ikke en permanent antagelse om, at hændelsen er mindre.
Leverandørernes forpligtelser til underretning bør give den finansielle enhed tid nok til at vurdere og opfylde sine egne forpligtelser. Indberetningsopgaver kan outsources, hvor det er tilladt, men ansvaret forbliver hos den finansielle enhed.
Hvor en større IKT-relateret hændelse påvirker kunders finansielle interesser, kræver DORA, at finansielle enheder uden unødig forsinkelse underretter disse kunder om hændelsen og om de foranstaltninger, der er truffet for at afbøde dens negative virkninger. Vurder særskilt forpligtelserne ved brud på persondatasikkerheden og andre gældende regler. Én afbrydelse kan give anledning til flere beslutninger om underretning med forskellige modtagere og juridiske kriterier.
Et program for test af digital operationel modstandsdygtighed bør være proportionalt og risikobaseret. Sårbarhedsvurderinger, scenarieøvelser, sikkerhedstest og genopretningstests besvarer forskellige spørgsmål; ingen af dem bør behandles som en universel erstatning for de andre.
En skrivebordsøvelse kan fastslå, om beslutningstagerne forstår eskaleringen. Den kan ikke bevise, at transaktionsdata kan gendannes korrekt. En penetrationstest kan afsløre udnyttelige svagheder uden at bevise, at en alternativ leverandør kan overtage en tjeneste.
Definér for hver test funktionen, scenariet, omfanget, succeskriterierne, uafhængighedsordninger, hvor det kræves, og den forventede dokumentation. Bevar resultaterne, fundene, beslutningerne om afhjælpning og resultaterne af gentestning. Kontrollér de gældende krav til dækning og hyppighed i forhold til DORA og de relevante standarder, herunder eventuelle undtagelser eller bestemmelser om den forenklede ramme.
Trusselsbaseret penetrationstest (TLPT) er et særskilt tilsynskrav for udvalgte finansielle enheder efter artikel 26. Det er ikke en generel forpligtelse for enhver finansiel virksomhed eller IKT-leverandør.
Ledelsen bør gennemgå antagelser, der har vist sig ikke at holde, ikke blot om tests har fundet sted. Hvis en øvelse afslører, at gendannelse afhænger af én administrator, der ikke er tilgængelig, er resultatet en operationel risiko, der kræver handling, ikke en gennemført testmilepæl.
Efter DORA forbliver en finansiel enhed ansvarlig for sine forpligtelser, når den anvender IKT-leverandører. Artikel 28–30 forbinder vurdering af tredjepartsrisiko, kontraktlige ordninger, overvågning og exitplanlægning.
Finansielle enheder skal føre et informationsregister over aftaler om IKT-ydelser på de påkrævede niveauer: individuelt, delkonsolideret og konsolideret. Brug de gældende gennemførelsesstandarder til registrets struktur. Et indkøbsregneark eller en liste over godkendte leverandører er ikke automatisk tilstrækkeligt.
Afstem registret med kontrakter, ejerskab af tjenester og afhængighedskort. Oprethold de påkrævede sondringer for tjenester, der understøtter kritiske eller vigtige funktioner. En ny underleverandør, en ny tjenesteplacering eller et udvidet omfang kan ændre risikobilledet, selv når leverandørens navn er det samme.
Vurder de gældende kontraktkrav, herunder beskrivelser af tjenester, placeringer, databeskyttelse, adgang til og gendannelse af data, bistand ved hændelser, samarbejde, opsigelsesrettigheder og serviceniveauer. Aftaler, der understøtter kritiske eller vigtige funktioner, kræver yderligere bestemmelser, herunder relevante ordninger for rapportering, kontinuitet, adgang, inspektion, audit og exit.
Jura, indkøb, teknologi og forretningsejere bør gennemgå disse sammen. En kontraktlig auditret kan være vanskelig at udøve i praksis; en lovet genopretningsordning dækker måske ikke kundens fulde tjenestekæde. Identificér disse begrænsninger, før aftalen accepteres.
Koncentrationsrisiko er ikke begrænset til at købe flere tjenester fra én virksomhed. Forskellige leverandører kan afhænge af den samme cloudplatform, region, det samme netværk eller den samme underleverandør. Vurder erstattelighed, migreringens kompleksitet og konsekvenserne af en fælles fejl.
En exitplan bør omfatte dataformater, udtræk, adgang, migreringsafhængigheder, overgangsstøtte, sletning og kontinuitet under flytningen. For kritiske eller vigtige funktioner skal test og gennemgang af exit behandles som reelt arbejde, ikke som en skriveøvelse.
Leverandører kan forberede en ensartet dokumentationspakke med tjenesteomfang, ansvarsgrænser, kontaktpersoner ved hændelser, kontinuitetsdokumentation, oplysninger om underleverandører og kontraktpositioner. Kundespecifikke krav skal stadig gennemgås; et certifikat erstatter dem ikke.
DORA er en EU-forordning, der finder direkte anvendelse. NIS 2-direktivet gennemføres i national lovgivning, og dets anvendelse afhænger af sektor, størrelse, tjeneste og regler om omfattede enheder. Fristen for national gennemførelse var den 17. oktober 2024; organisationer skal undersøge den gældende nationale gennemførelse i stedet for at gå ud fra én ensartet ordning.
Artikel 1, stk. 2, i DORA fastlægger sammen med artikel 4 i NIS2 det sektorspecifikke forhold for omfattede finansielle enheder på de relevante områder. Fortolk det ikke som en instruks om at duplikere tilsvarende kontroller for risikostyring og indberetning af hændelser. Gå heller ikke ud fra, at det fjerner forpligtelser for alle virksomheder i en finansiel koncern eller dens forsyningskæde.
En udbyder af administrerede tjenester, der betjener en bank, kan have brug for sin egen NIS2-vurdering, samtidig med at den opfylder DORA-relaterede kontraktlige forpligtelser. En forpligtelsesmatrix enhed for enhed bør registrere retsgrundlag, omfang, myndighed, indberetningsvej og den påkrævede dokumentation.
Fælles kontroller kan understøtte DORA, ISO 27001, databeskyttelsesforpligtelser og dokumentation over for kunder, hvor omfang og dokumentation passer sammen. Genbrug en adgangsgennemgang eller genopretningstest, når den reelt understøtter flere krav, og bevar samtidig detaljerne, der er specifikke for den finansielle sektor. Et ISO 27001-certifikat dokumenterer ikke overholdelse af DORA.
Håndhævelsen er også forskellig. DORA's tilsynsbeføjelser og sanktioner over for finansielle enheder afhænger af forordningens bestemmelser og de gældende nationale foranstaltninger; udpegede kritiske udbydere har en særskilt tilsynsordning. Budgettér ikke risikoen ud fra en formodet universel DORA-bøde. Vurder den relevante juridiske eksponering og de operationelle konsekvenser af utilstrækkelig modstandsdygtighed.
Tag som illustration et betalingsinstitut, der bruger en cloudplatform, en identitetsudbyder og en outsourcet overvågningstjeneste. Antag, at instituttet er omfattet af DORA, og at gennemførelse af betalinger er klassificeret som en kritisk eller vigtig funktion.
Den første gennemgang finder tre svagheder: Produktions- og genopretningsmiljøerne deler den samme identitetsafhængighed; overvågningsleverandørens proces for eskalering af hændelser er uklar; og exitplanen for skyen nævner en alternativ udbyder uden at påvise udtræk og migrering af data.
Ledelsen igangsætter tre sammenhængende arbejdspakker:
| Arbejdspakke | Ansvarlig ejer | Dokumentation, der kræves for lukning |
|---|---|---|
| Validér genopretningsadgang ved svigt i identitetstjenesten | Teknologiansvarlig | Testet procedure for nødadgang og genopretningsresultater |
| Etablér leverandøreskalering og støtte til indberetning | Ejer af leverandørrelationen | Aftalt kontaktmatrix, kontraktgennemgang og registrering af øvelse |
| Vurder en realistisk exit fra skyen | Ejer af forretningstjenesten | Afhængighedsanalyse, udtrækstest, migreringsbegrænsninger og kontinuitetsvurdering |
Forretningsejeren kontrollerer, om genopretningsmålene for betalinger fortsat kan nås. Compliance kontrollerer, at indberetningsprocedurer og registreringer i registret afspejler ordningerne. Ledelsen godkender den nødvendige finansiering og gennemgår de resterende begrænsninger.
Dette eksempel dokumenterer ikke i sig selv overholdelse. Det viser, hvordan én funktion kan afdække beslutninger, der ellers ville forblive skjult i separate tjeklister for politikker, leverandører og tests.
DORA har ingen universel certificeringsproces, der erstatter løbende forpligtelser. Uafhængig sikkerhed kan informere ledelsen, men parathed skal påvises gennem fungerende kontroller, registreringer og tilsynsdialog, hvor det kræves.
Et praktisk næste skridt er at vælge én kritisk eller vigtig funktion og samle dens beslutning om anvendelsesområde, afhængighedskort, risikovurdering, kontrakter, hændelsesprocedurer, testresultater og åbne handlinger. Gennemgå, om registreringerne fortæller en sammenhængende historie.
Secani understøtter denne arbejdsgang ved at modellere systemer og tjenester, forbinde afhængigheder og holde krav, dokumentation, ejere, opgaver og beslutninger fra gennemgange i kontekst. Upload eksisterende materiale til de relevante objekter, omdan mangler til tildelt arbejde, og bevar eksplicit menneskelig godkendelse af AI-understøttede forslag og konklusioner.
Udvid fra den første funktion, når ejerskab og dokumentationsveje er klare. Ledelsen bør kunne se, hvad der er påvist, hvad der fortsat er usikkert, og hvilken beslutning der skal træffes som den næste.
Secani forbinder scopes, dokumentation, opgaver og AI-agenter i ét fælles arbejdsområde.
Forbind CRA's anvendelsesområde, sårbarhedshåndtering, supportforpligtelser og produktevidens med den aktuelle tidsplan for indberetning og anvendelse.
Brug den næste databeskyttelsesdag til at øve anmodninger, gennemgå dataflows, forbedre opbevaringen og måle praktiske resultater.
Forbind GDPR-vilkår for databehandlere med faktiske dataflow, underdatabehandlere, sikkerhedsforanstaltninger, støtte ved hændelser og håndtering ved kontraktens ophør.