DORA-beredskap för finansiella enheter och deras IKT-leverantörer

DORA har tillämpats sedan den 17 januari 2025. För finansiella enheter innebär beredskap i dag att upprätthålla en arbetsmodell för digital operativ motståndskraft, inte att förbereda sig inför en framtida tidsfrist. För teknikleverantörer innebär det att förstå ansvaret gentemot kunderna och om en separat ordning för direkt tillsyn är tillämplig.

Ledningens fråga är praktisk: kan organisationen förklara vilka finansiella tjänster som är beroende av vilka IKT-system, hur störningar ska hanteras och vilka underlag som stöder antagandena om återställning? Policyer är viktiga, men de kan inte ensamma besvara den frågan. Ledningen behöver en sammanhängande bild av ansvar, beroenden, avtal, tester, incidenter och olösta risker.

Fastställ er roll innan ni bygger checklistan

Börja med ett dokumenterat beslut om tillämplighet för varje relevant juridisk person. Artikel 2 i DORA anger vilka kategorier som omfattas och vilka undantag som gäller. Ett företag som beskriver sig som fintech, startup eller små och medelstora företag omfattas inte automatiskt och är inte heller automatiskt undantaget.

Exempel på finansiella enheter som omfattas är kreditinstitut, betalningsinstitut, värdepappersföretag och försäkringsföretag, med förbehåll för förordningens detaljerade regler om tillämpningsområde. Dokumentera den tillämpliga kategorin, eventuella undantag eller befrielser, den relevanta behöriga myndigheten och resonemanget bakom slutsatsen.

För leverantörer, skilj mellan tre positioner:

En leverantör som stöder en kritisk eller viktig finansiell funktion är inte enbart av det skälet en utsedd kritisk tredjepartsleverantör av IKT-tjänster. Finansiella enheter bedömer hur viktiga deras funktioner och beroenden är; kritiska leverantörer utses inom tillsynsramverket enligt artikel 31.

Var leverantören finns avgör inte frågan. En amerikansk moln- eller programvaruleverantör kan få DORA-relaterade krav från kunder när den betjänar finansiella enheter i EU. Den kommersiella relationen innebär inte automatiskt att leverantören omfattas av varje skyldighet som åläggs en finansiell enhet.

Proportionalitet kräver också en motiverad bedömning. Artikel 4 tar hänsyn till faktorer som storlek, övergripande riskprofil samt tjänsternas art, omfattning och komplexitet. Artikel 16 innehåller ett förenklat ramverk för hantering av IKT-risker för angivna kategorier. Begreppen är inte utbytbara, och vanlig status som litet eller medelstort företag är ingen universell genväg. Förvara analysen av behörigheten tillsammans med beslutet om tillämpningsområdet.

Gör ledningens ansvar synligt

Enligt artikel 5 i DORA har ledningsorganet det yttersta ansvaret för hanteringen av den finansiella enhetens IKT-risker. Att delegera genomförandet till en CISO, ett teknikteam eller en extern leverantör flyttar inte det ansvaret.

Ledningen bör fastställa vem som föreslår beslut, vem som godkänner dem och vem som kontrollerar att genomförandet fungerar. Arbetsmodellen bör omfatta kontinuitetshantering, incidenthantering och återställning, tredjepartsarrangemang, budget och den kunskap som krävs för meningsfull tillsyn.

En praktisk rekommendation är att ge ledningen ett beslutsinriktat rapportpaket i stället för en instrumentpanel med andel slutfört. Ta med:

• Kritiska eller viktiga funktioner med otestade antaganden om återställning.
• Större incidenter, effekter för kunder och utestående korrigerande åtgärder.
• Leverantörsberoenden med ofullständiga avtal eller svaga exitalternativ.
• Betydande brister i kontroller, ansvariga ägare och datum för åtgärder.
• Beslut som kräver finansiering, ett leverantörsbyte eller en uttrycklig riskhantering.

Varje brist bör skilja mellan det regulatoriska kravet, den aktuella operativa svagheten och den föreslagna åtgärden. Ett saknat godkännandeprotokoll är något annat än en säkerhetskopia som inte kan återställas. Båda kan kräva åtgärder, men de kräver olika ägare och prioriteringar.

Ledningens godkännande av en åtgärdsplan är inget tillstånd att skjuta upp tillämpliga skyldigheter på obestämd tid. Där en brist är väsentlig, överväg omedelbara skyddsåtgärder, eskalering och eventuella konsekvenser för tillsynen vid sidan av den långsiktiga lösningen.

Bygg programmet kring de finansiella funktionerna

En förteckning över tillgångar är nödvändig, men planeringen för motståndskraft bör börja med den tjänst som måste fortsätta fungera. Identifiera den finansiella funktionen, dess verksamhetsägare, konsekvenserna av en störning och de system och leverantörer som stöder den.

För en betaltjänst, kartlägg identitet, molninfrastruktur, transaktionshantering, övervakning och eskalering till leverantörer. Ta med mindre synliga beroenden som DNS, uppkoppling, privilegierad åtkomst, krypteringsnycklar och supportverktyg. En alternativ produktionsmiljö kan vara oanvändbar om den är beroende av samma identitetstjänst som har fallerat.

Den resulterande kartan bör koppla varje funktion till:

• Stödjande applikationer, infrastruktur, informationstillgångar och externa tjänster.
• Relevanta avtal och tjänsteägare.
• Återställningsmål och den konsekvensanalys som stöder dem.
• Arrangemang för upptäckt, hantering, återställning och kommunikation.
• Tester, fynd och olösta beroenderisker.

Validera kartan med både drift- och verksamhetsteam. Inköpsunderlag visar vad som har köpts; de visar inte nödvändigtvis hur en tjänst fungerar i dag.

Använd modellen för att organisera hanteringen av IKT-risker, incidenthantering och rapportering, testning av motståndskraft och IKT-tredjepartsrisker. DORA innehåller även bestämmelser om frivilligt utbyte av information om cyberhot. Om ni deltar, definiera medlemskap, sekretess, tillåten användning och hanteringsregler i stället för att behandla utbytet som ett obegränsat utbyte av incidentdata.

Gör hanteringen av IKT-risker till finansierat arbete

DORA:s bestämmelser om hantering av IKT-risker omfattar identifiering, skydd och förebyggande, upptäckt, hantering och återställning, lärande och kommunikation. Ramverket måste koppla ihop dessa aktiviteter i stället för att lämna dem som separata samlingar av policyer.

Börja gapanalysen med de kartlagda funktionerna. Fråga om åtkomstkontroller skyddar deras system, om sårbarheter åtgärdas, om ändringar kontrolleras, om misstänkt aktivitet upptäcks och om arrangemangen för återställning speglar realistiska fel. Ta hänsyn till tekniska fel och operativa misstag såväl som till avsiktliga attacker.

För varje väsentlig svaghet, skapa en åtgärdspost som innehåller en ägare, påverkan på verksamheten, den åtgärd som krävs, kriterier för slutförande och underlag för avslut. Beroenden spelar roll: att förbättra återställningsrutiner kan kräva ändringar i åtkomsten till säkerhetskopior, leverantörsåtaganden och personalutbildning innan ett lyckat test är möjligt.

Återställningsmål bör utgå från verksamhetens behov och konsekvensanalys, inte från vad en leverantörs standardnivå för tjänsten råkar erbjuda. Där den tekniska förmågan inte kan nå målet måste ledningen besluta om arkitekturen ska förbättras, tjänstearrangemanget ändras eller arbetsmodellen omprövas. Ett mål som skrivits in i en kontinuitetsplan är inget bevis för att återställning är möjlig.

Förbered incidentbesluten före störningen

DORA kräver att finansiella enheter hanterar IKT-relaterade incidenter och rapporterar större incidenter till den relevanta behöriga myndigheten. Artiklarna 17–23 fastställer ramverket; de tillämpliga tekniska standarderna för tillsyn och genomförande innehåller detaljerade klassificeringskriterier, tröskelvärden, rapporteringsinnehåll och förfaranden.

Förlita er inte på en allmän incidentchecklista för den detaljerade rapporteringstidplanen. Upprätthåll en aktuell rapporteringsmatris som anger de tillämpliga standarderna, myndighetens instruktioner, inlämningskanalen, rapporteringsstegen och hur tidsfristerna beräknas. Utse någon som ansvarar för att hålla den aktuell.

Hanteringsprocessen bör göra flera beslut genomförbara under press:

• Vem dokumenterar tidpunkterna för upptäckt, bedömning och klassificering?
• Vem inhämtar information om påverkan från driften och leverantörerna?
• Vem avgör om kriterierna för en större incident är uppfyllda?
• Vem godkänner och skickar in rapporter, även utanför ordinarie arbetstid?
• Vem hanterar kommunikationen med kunder och andra tillämpliga anmälningar?

Dokumentera klassificeringsresonemanget även när en incident inte rapporteras som större. En ofullständig första bild bör leda till en ny bedömning när informationen utvecklas, inte till ett permanent antagande om att händelsen är mindre.

Leverantörers åtaganden om underrättelse bör ge den finansiella enheten tillräckligt med tid för att bedöma och uppfylla sina egna skyldigheter. Rapporteringsuppgifter kan läggas ut där det är tillåtet, men ansvaret ligger kvar hos den finansiella enheten.

När en större IKT-relaterad incident påverkar kundernas ekonomiska intressen kräver DORA att finansiella enheter utan onödigt dröjsmål informerar kunderna om incidenten och om de åtgärder som vidtagits för att begränsa dess negativa effekter. Bedöm separat skyldigheterna vid personuppgiftsincidenter och andra tillämpliga regler. En och samma störning kan leda till flera beslut om underrättelse, med olika mottagare och rättsliga kriterier.

Testa de antaganden som ledningen förlitar sig på

Ett program för testning av digital operativ motståndskraft bör vara proportionerligt och riskbaserat. Sårbarhetsbedömningar, scenarioövningar, säkerhetstester och återställningstester besvarar olika frågor; inget av dem bör behandlas som en universell ersättning för de andra.

En skrivbordsövning kan fastställa om beslutsfattarna förstår eskaleringen. Den kan inte bevisa att transaktionsdata kan återställas korrekt. Ett penetrationstest kan blotta utnyttjbara svagheter utan att bevisa att en alternativ leverantör kan ta över en tjänst.

För varje test, definiera funktionen, scenariot, omfattningen, framgångskriterierna, arrangemangen för oberoende där det krävs och de förväntade underlagen. Bevara resultat, fynd, beslut om åtgärder och utfall av nya tester. Kontrollera tillämpliga krav på täckning och frekvens mot DORA och de relevanta standarderna, inklusive eventuella undantag eller bestämmelser om det förenklade ramverket.

Hotbildsbaserad penetrationstestning är ett separat tillsynskrav för utvalda finansiella enheter enligt artikel 26. Det är ingen generell skyldighet för varje finansiellt företag eller IKT-leverantör.

Ledningen bör granska antaganden som visat sig felaktiga, inte bara om tester har genomförts. Om en övning visar att återställningen är beroende av en enda administratör som inte är tillgänglig är utfallet en operativ risk som kräver åtgärd, inte en avklarad milstolpe för testning.

Behandla tredjepartsrisker som en fråga om tjänstekontinuitet

Enligt DORA är en finansiell enhet fortsatt ansvarig för sina skyldigheter när den använder IKT-leverantörer. Artiklarna 28–30 kopplar ihop bedömning av tredjepartsrisker, avtalsarrangemang, övervakning och exitplanering.

Upprätthåll registret och den operativa bilden

Finansiella enheter ska upprätthålla ett informationsregister över avtalsarrangemang för IKT-tjänster på den nivå som krävs: enskild, delkonsoliderad och konsoliderad nivå. Använd de tillämpliga genomförandestandarderna för registrets struktur. Ett inköpskalkylblad eller en lista över godkända leverantörer räcker inte automatiskt.

Stäm av registret mot avtal, tjänsteägarskap och beroendekartor. Upprätthåll de distinktioner som krävs för tjänster som stöder kritiska eller viktiga funktioner. En ny underleverantör, en ny plats för tjänsten eller en utökad omfattning kan ändra riskbilden även när leverantörens namn är detsamma.

Granska avtalen mot den faktiska tjänsten

Bedöm de tillämpliga avtalskraven, inklusive tjänstebeskrivningar, platser, dataskydd, åtkomst till och återställning av data, stöd vid incidenter, samarbete, uppsägningsrätt och servicenivåer. Arrangemang som stöder kritiska eller viktiga funktioner kräver ytterligare bestämmelser, bland annat om relevant rapportering, kontinuitet, åtkomst, inspektion, revision och exit.

Juridik, inköp, teknik och verksamhetsägare bör granska dessa tillsammans. En avtalad revisionsrätt kan vara svår att utöva i praktiken; ett utlovat arrangemang för återställning kanske inte omfattar kundens hela tjänstekedja. Identifiera sådana begränsningar innan arrangemanget godtas.

Granska koncentration och förmåga till exit

Koncentrationsrisk är inte begränsad till att köpa flera tjänster från samma företag. Olika leverantörer kan vara beroende av samma molnplattform, region, nätverk eller underleverantör. Bedöm utbytbarhet, migreringens komplexitet och konsekvenserna av ett gemensamt fel.

En exitplan bör omfatta dataformat, extraktion, åtkomst, migreringsberoenden, övergångsstöd, radering och kontinuitet under flytten. För kritiska eller viktiga funktioner bör test och granskning av exit behandlas som substantiellt arbete, inte som en övning i att skriva dokument.

Leverantörer kan förbereda ett enhetligt paket med säkerhetsunderlag som innehåller tjänstens omfattning, ansvarsgränser, incidentkontakter, underlag om kontinuitet, information om underleverantörer och avtalspositioner. Kundspecifika krav behöver ändå granskas; ett certifikat ersätter dem inte.

Förstå var DORA och NIS2 möts

DORA är en EU-förordning som är direkt tillämplig. NIS2 är ett direktiv som genomförs genom nationell lagstiftning, och dess tillämplighet beror på sektor, storlek, tjänst och regler om inkludering. Tidsfristen för nationellt genomförande var den 17 oktober 2024; organisationer behöver granska det tillämpliga nationella genomförandet i stället för att anta en enda identisk ordning.

Artikel 1.2 i DORA fastställer tillsammans med artikel 4 i NIS2 det sektorsspecifika förhållandet för finansiella enheter som omfattas inom de relevanta områdena. Tolka inte detta som en instruktion att duplicera likvärdiga kontroller för riskhantering och incidentrapportering. Anta inte heller att det tar bort skyldigheter från varje företag i en finansiell koncern eller dess leveranskedja.

En leverantör av hanterade tjänster som betjänar en bank kan behöva göra en egen NIS2-bedömning samtidigt som den uppfyller DORA-relaterade avtalsåtaganden. En skyldighetsmatris per enhet bör dokumentera den rättsliga grunden, omfattningen, myndigheten, rapporteringsvägen och de underlag som krävs.

Gemensamma kontroller kan stödja DORA, ISO 27001, dataskyddsskyldigheter och säkerhetsgarantier till kunder där omfattning och underlag stämmer överens. Återanvänd en åtkomstgranskning eller ett återställningstest när det verkligen stöder flera krav, och bevara samtidigt de finanssektorsspecifika detaljerna. Ett ISO 27001-certifikat visar inte efterlevnad av DORA.

Tillsynen skiljer sig också åt. Tillsynsbefogenheter och sanktioner för finansiella enheter enligt DORA beror på förordningens bestämmelser och tillämpliga nationella åtgärder; utsedda kritiska leverantörer har en separat tillsynsordning. Budgetera inte risker utifrån en förmodad universell sanktionsavgift enligt DORA. Bedöm den relevanta rättsliga exponeringen och de operativa konsekvenserna av otillräcklig motståndskraft.

Exempel: granskning av beroenden för en betaltjänst

Tänk dig ett betalningsinstitut som använder en molnplattform, en identitetsleverantör och en utlagd övervakningstjänst. Anta att institutet omfattas av DORA och att genomförandet av betalningar klassificeras som en kritisk eller viktig funktion.

Den första granskningen identifierar tre svagheter: produktions- och återställningsmiljöerna delar samma identitetsberoende; övervakningsleverantörens process för incidenteskalering är otydlig; och exitplanen för molnet anger en alternativ leverantör utan att visa att data kan extraheras och migreras.

Ledningen beställer tre sammanhängande arbetspaket:

Verksamhetsägaren kontrollerar om återställningsmålen för betalningar fortfarande är möjliga att nå. Compliance verifierar att rapporteringsrutiner och registerposter speglar arrangemangen. Ledningen godkänner nödvändig finansiering och granskar kvarstående begränsningar.

Exemplet fastställer inte efterlevnad i sig. Det visar hur en enda funktion kan blotta beslut som annars skulle förbli dolda i separata checklistor för policyer, leverantörer och tester.

Etablera en evidensbaserad granskningsrytm

DORA har ingen universell certifieringsprocess som ersätter de löpande skyldigheterna. Oberoende granskning kan ge ledningen underlag, men beredskapen måste visas genom fungerande kontroller, dokumentation och dialog med tillsynsmyndigheten där det krävs.

Ett praktiskt nästa steg är att välja en kritisk eller viktig funktion och sammanställa dess beslut om tillämpningsområde, beroendekarta, riskbedömning, avtal, incidentrutiner, testresultat och öppna åtgärder. Granska om dokumentationen berättar en sammanhängande historia.

Secani stöder arbetsflödet genom att modellera system och tjänster, koppla ihop beroenden och hålla krav, underlag, ägare, uppgifter och granskningsbeslut i sitt sammanhang. Ladda upp befintligt material mot de relevanta objekten, omvandla brister till tilldelat arbete och behåll uttryckligt mänskligt godkännande av AI-stödda förslag och slutsatser.

Bygg ut från den första funktionen när ägarskap och vägar för underlag är tydliga. Ledningen bör kunna se vad som har visats, vad som fortfarande är osäkert och vilket beslut som behövs härnäst.