En fungerande DORA-ram ska visa vilka finansiella funktioner som är beroende av IT, vilka risker som kan störa dem och vem som kontrollerar att skydd och återställning fungerar. Dokumentationen behöver följa verksamheten hela vägen från ledningens beslut till ett verifierat resultat i systemen.
DORA, förordning EU 2022/2554, tillämpas sedan den 17 januari 2025. För en verksamhet som omfattas är arbetet därför löpande riskhantering och åtgärdande av luckor, inte ett framtida införandeprojekt. Här finns en arbetsplan för det ordinarie ramverket, med särskild avgränsning av artikel 16 och ett ifyllt beroendeexempel.
1. Fastställ vilket regelspår verksamheten tillhör
Börja med den juridiska personens tillstånd, verksamhet och kategori enligt artikel 2, inklusive tillämpliga undantag. Ett bolag blir inte automatiskt en finansiell entitet under DORA för att det säljer programvara till banker. En finansiell verksamhet kan å andra sidan omfattas även när den köper huvuddelen av sin IT externt.
Finansinspektionens översikt över DORA beskriver regelverkets områden och hänvisar till kompletterande tekniska standarder. Använd översikten för orientering och kontrollera därefter den aktuella entitetens rättsliga ställning i reglerna.
Dokumentera ett avgränsningsbeslut: juridisk person, relevant kategori, eventuellt undantag och om ordinarie artiklarna 5–15 eller artikel 16 gäller. Ange vem som kontrollerar beslutet när verksamheten eller tillståndet ändras. En koncerngemensam etikett kan inte ersätta bedömningen av varje berörd entitet.
2. Artikel 16 gäller inte automatiskt alla mikroföretag
Artikel 16 räknar upp särskilda kategorier, bland annat små och icke-sammanlänkade värdepappersföretag, vissa undantagna betalningsinstitut och institut för elektroniska pengar, vissa institut undantagna enligt direktiv 2013/36/EU och små tjänstepensionsinstitut. Den exakta kategorin och dess villkor måste kontrolleras i lagtexten.
För dessa entiteter ersätter artikel 16 kraven i artiklarna 5–15 med en förenklad IKT-riskhanteringsram. Den innehåller fortfarande krav på dokumentation, skydd, upptäckt, kontinuitet, tester och förbättring. Förenklad betyder inte att det räcker med ett löfte från IT-leverantören.
Mikroföretag har särskilda lättnader på olika ställen i det ordinarie regelverket. Det är en annan fråga än om artikel 16 är tillämplig. Exempelvis anger artikel 6.5 årlig översyn för ordinarie ramverk men periodisk översyn för mikroföretag. Läs DORA:s artiklar 2, 6 och 16 tillsammans innan ni väljer en förenklad mall.
3. Ge ledningen ett beslut som går att följa upp
Under det ordinarie ramverket har ledningsorganet enligt artikel 5 ansvar för att definiera, godkänna och övervaka genomförandet av IKT-riskhanteringen. Den dagliga driften kan fördelas, men ledningens ansvar försvinner inte genom utkontraktering.
Ett användbart ledningsunderlag innehåller riskbild, prioriteringar, resurser, ansvar och kvarstående brister. Ange vad ledningen behöver besluta och vilket resultat som ska följas upp. En rapport som bara räknar antalet stängda ärenden visar inte om en kritisk funktion fortfarande saknar fungerande återställning.
För en fiktiv finansiell tjänst kan beslutet lyda: ”Verksamhetsägaren ska verifiera återställning av kundernas betalningsinstruktioner tillsammans med avstämningsfunktionen. IT ansvarar för återläsning, riskfunktionen följer upp avvikelsen och ledningen får resultatet efter övningen. En dokumenterad manuell reservrutin ska finnas tills den tekniska lösningen är verifierad.”
Skilj operativt genomförande, kontroll och internrevision enligt de krav som gäller för entiteten. Artikel 6 innehåller bland annat regler om kontrollfunktion, åtskillnad och internrevision, med särskilda undantag för mikroföretag. Skriv inte en rollfördelning som samma person omöjligen kan upprätthålla i praktiken.
4. Kartlägg funktioner, information och teknik tillsammans
Börja med vad verksamheten behöver leverera. Identifiera sedan informations- och IKT-tillgångar som stöder funktionen: applikationer, identitetstjänster, nätverk, databaser, integrationsköer, personalroller och externa leverantörer. Artikel 8 kräver en löpande bild av risker och beroenden, inte bara en inköpslista över datorer.
En IT-systemkarta kan återanvändas, men behöver kompletteras med DORA:s funktioner och kritikalitet. GDPR:s registerförteckning beskriver behandling av personuppgifter och täcker inte automatiskt alla informations- och driftberoenden som är relevant enligt DORA.
| Funktion i ett fiktivt exempel | Beroende | Konsekvens vid bortfall | Kontroll som saknas |
|---|---|---|---|
| Ta emot kundinstruktion | Webbgränssnitt och identitetstjänst | Kunden kan inte lämna instruktionen | Alternativ mottagningsväg |
| Behandla instruktion | Arbetskö och verksamhetsregler | Instruktion blir försenad eller dubbel | Kontroll av återstart och dubbletter |
| Stämma av resultat | Dataexport och avstämningssystem | Fel upptäcks inte i tid | Sammanhängande återställningsövning |
| Informera kund | Meddelandetjänst | Kunden saknar besked om förseningen | Reservkanal vid leverantörsstörning |
Det centrala fyndet är att en fungerande webbserver inte bevisar att funktionen fungerar. Om avstämningen är nere kan verksamheten behöva begränsa driften trots att nya instruktioner tekniskt kan tas emot. Dokumentera sådana beroenden och beslutspunkter uttryckligen.
5. Koppla skyddsåtgärder till risk och bevis
Ordinarie ramverk omfattar skydd och förebyggande åtgärder enligt artikel 9. Den kompletterande delegerade förordningen 2024/1774 preciserar verktyg, metoder, processer och riktlinjer för IKT-riskhantering samt det förenklade ramverket. Kontrollera rätt avdelning för ert regelspår i den tekniska standarden.
Välj en risk och visa kedjan till kontrollen. För risken att ett gammalt administratörskonto används obehörigt behövs exempelvis ansvarig för behörighet, avvecklingsförfarande, autentisering och kontroll av kvarvarande konton. Ett allmänt säkerhetscertifikat visar inte att just detta konto har stängts.
Använd mallen för tekniska och organisatoriska åtgärder för att registrera omfattning, ägare och kontrollresultat. Håll krav som följer av DORA åtskilda från egna interna mål. En viss patchfrist kan vara organisationens val utifrån risk utan att vara en universell tidsgräns i förordningen.
6. Upptäck avvikelser och gör larmet användbart
Artikel 10 behandlar upptäckt av avvikande aktivitet. I arbetsplanen behöver varje viktig larmtyp ha en mottagare, en första bedömning och en eskaleringsväg. Ett centralt loggsystem som ingen övervakar enligt beslutad rutin ger svagt praktiskt skydd.
Prova ett avgränsat scenario: en tjänst hämtar ovanligt många kundposter eller en kritisk integration slutar leverera. Kontrollera att larmet kommer till rätt funktion och innehåller tillräcklig information för åtgärd. Ange hur behöriga kan nås utanför ordinarie arbetstid när verksamhetens behov kräver det.
Begränsa samtidigt personuppgifter i övervakningen till vad som behövs för ändamålet. Rutinen för säkerhetsloggning hjälper till att beskriva åtkomst, innehåll och lagring. DORA:s behov av motståndskraft gör inte all individuell övervakning av anställda nödvändig eller tillåten enligt GDPR.
7. Ange återställningsmål för hela funktionen
Skilj hur snabbt funktionen behöver vara tillbaka från hur mycket dataförlust som kan tolereras. RTO och RPO är användbara uttryck, men målen ska grundas i konsekvenserna för funktionen och relevanta krav. DORA anger inte att varje finansiellt system får ligga nere exakt fyra timmar.
I det fiktiva exemplet väljer verksamheten ett återställningsmål på två timmar för mottagning och avstämning tillsammans. Vid övningen återkommer databasen efter femtio minuter men identitetstjänsten efter tre timmar. Resultatet är då att det sammanhängande målet missas, trots en lyckad databasåterläsning.
Dokumentera gapet, ansvarig och ändring. Kontrollera också hur manuellt mottagna instruktioner förs tillbaka utan dubbletter. Återställningsplanen för RTO och RPO och kontinuitetsplanen ger två delar av samma arbetsflöde.
8. Planera tester efter de regler som faktiskt gäller
Ordinarie DORA-ramverk innehåller konkreta testkrav, bland annat för kontinuitets- och återställningsplaner. Kapitel IV reglerar dessutom testning av digital operativ motståndskraft. Registrera kravet, vilken funktion som omfattas, nästa genomförande och hur brister följs upp.
Avancerad hotbildsstyrd penetrationstestning, TLPT, gäller inte automatiskt varje finansiell entitet. Artikel 26 avgränsar vilka entiteter som ska identifieras för detta och innehåller undantag och regler för frekvens. Ett vanligt penetrationstest ska därför inte beskrivas som ett genomfört TLPT utan att förutsättningarna är uppfyllda.
När ni beställer en avgränsad teknisk kontroll, använd arbetsgången för att beställa penetrationstest och precisera syfte, system, tillstånd och resultat. Koppla sedan resultatet till riskramen. En identifierad brist är inte stängd förrän åtgärden har verifierats på relevant sätt.
9. Håll incidentrapportering och GDPR-bedömning parallella
En IKT-incident kan omfattas av DORA:s klassificerings- och rapporteringskrav och samtidigt vara en personuppgiftsincident enligt GDPR. Definitioner, trösklar, mottagare och frister är olika. Skapa därför en samordnad händelsebild men separata rättsliga bedömningar.
Finansinspektionens område för IKT-risker och DORA samlar aktuella rapporteringsanvisningar. Använd rätt format och tidsregler för DORA-rapporteringen; byt inte ut dem mot GDPR:s 72-timmarsregel. Vid hög risk för enskilda behöver även informationen till drabbade enligt artikel 34 hanteras.
DORA är dessutom en sektorsspecifik unionsrättsakt i den mening som anges i NIS2 artikel 4 för de relevanta finansiella entiteterna. Gör en avgränsning mellan regelverken, i stället för att anta att alla skyldigheter alltid ska tillämpas dubbelt. GDPR:s skydd av personuppgifter kvarstår inom sitt område.
10. Avsluta arbetsplanen med verifierbara prioriteringar
Prioritera risker som kan orsaka störst skada och skyldigheter som redan skulle ha varit uppfyllda. En projektplan kan ordna resurserna men ger ingen ny rättslig tidsfrist. Ange för varje åtgärd vad som ska fungera, vem som äger den och vilket underlag som visar resultatet.
I det fiktiva exemplet prioriteras först den återställningslucka som hindrar avstämning. Därefter kontrolleras att larm om avbruten integration verkligen når jourfunktionen. Ett senare arbete kan förbättra rapportens grafiska utformning, men det får inte tränga undan en kontroll som begränsar en konkret drift- eller kundrisk. För varje prioritet redovisas även vad som ännu inte är skyddat och vilka tillfälliga begränsningar verksamheten använder.
Bestäm vem som får acceptera en kvarstående risk och vilka risker som måste eskaleras till ledningen. Ett godkännande ska avse ett beskrivet förhållande med uppföljning, inte en allmän fullmakt att fortsätta med kända brister. Efter nästa kontroll jämförs det faktiska resultatet med beslutets antaganden.
Återanvänd befintliga säkerhets- och kvalitetsprocesser där de passar. ISO 27001 kan bidra med struktur, men certifiering är inte i sig bevis för att DORA:s specifika krav är uppfyllda. Undvik också gamla kontrollnummer från en annan standardversion som automatisk juridisk mappning.
Ta upp leverantörsberoenden som en egen del av förbättringsarbetet. Guiden om DORA, IKT-leverantörer och exitplan visar hur avtalsvillkor, koncentration och praktisk flyttbarhet kan kopplas till samma riskbild. Ledningen får då ett sammanhängande underlag för att besluta, följa upp och ändra ramen när verksamhetens beroenden förändras.