Dora kräver att finansiella entiteter upprättar ett heltäckande testprogram för digital operativ motståndskraft som inkluderar årsvisa tester av IKT-system och hotbildsstyrda penetrationstester för utvalda enheter. Programmet ska ingå i den löpande IKT-riskhanteringen, inte fungera som en fristående kontrollpunkt. I Sverige kompletteras förordningen av nationell lagstiftning och tillsyn från Finansinspektionen och Riksbanken.
Kort sagt:
- Endast mer avancerade och riskbaserade tester, som hotbildsstyrda penetrationstester, krävs minst vart tredje år för vissa svenska finansiella enheter.
- Programmet ska integreras i den löpande riskhanteringen och omfattar sårbarhetsanalyser, scenariobaserade tester och fysiska säkerhetsgranskningar.
- Finansinspektionen bestämmer vilka organisationer som måste genomföra hotbildsstyrda penetrationstester, medan Riksbanken utfärdar erkännandebyten mellan medlemsstater.
- Leverantörer av säkerhetstester måste ha certifiering, dokumenterad sakkunskap och ofta ett säkerhetsskyddsavtal för att delta i TLPT.
- Organisationer bör noggrant definiera kritiska funktioner, ha avtal på plats och tydlig dokumentation för att klara tillsynens krav på tester och rapportering.
Innehållsförteckning
- Vad kräver artikel 24 av ett testprogram för digital motståndskraft?
- Så styr Finansinspektionen och Riksbanken urvalet till TLPT
- Vilka testmetoder och leverantörskrav gäller i praktiken?
- Checklista för ledningen innan testprogrammet startar
- Vanliga fallgropar i testarbetet och vad som faktiskt hjälper
- Hur Evertrust stöttar er inför och under testprogrammet
- Källor
- Vanliga frågor
Vad kräver artikel 24 av ett testprogram för digital motståndskraft?
Dora anger att finansiella entiteter ska inrätta, underhålla och se över ett program för testning av digital operativ motståndskraft som en integrerad del av ramverket för IKT-riskhantering. Programmet ska vara riskbaserat: hur ofta och hur omfattande testerna behöver vara beror på entitetens storlek, verksamhetens karaktär och hur kritiska de berörda IKT-systemen är.
Enligt DORA-förordningen ska finansiella entiteter som inte är mikroföretag genomföra årsvisa tester av IKT-system som stödjer kritiska eller viktiga funktioner. Testprogrammet omfattar flera nivåer av metoder, från enkla kontroller till avancerad simulering av verkliga angrepp.
Minimikomponenterna i ett program brukar innehålla:
- Sårbarhetsanalyser och sårbarhetsskanningar av system och nätverk.
- Nätverkssäkerhetstester och genomgångar av öppna källkodsanalyser.
- Gap-analyser mot gällande krav och tidigare testresultat.
- Fysiska säkerhetsgranskningar av kritisk infrastruktur.
- Scenariobaserade tester som simulerar verkliga incidenttyper.
- Penetrationstester, inklusive hotbildsstyrda tester för utvalda entiteter.
Kravet gäller oavsett om entiteten hanterar testerna internt eller via en extern part. Ansvaret för att programmet är heltäckande och riskbaserat ligger alltid hos ledningen, inte hos den som utför själva testet.
Så styr Finansinspektionen och Riksbanken urvalet till TLPT
Hotbildsstyrda penetrationstester, TLPT, är den mest avancerade testformen i Dora och innebär att en oberoende testleverantör simulerar ett verkligt angrepp mot en organisations kritiska funktioner under kontrollerade former. Inte alla entiteter omfattas: kravet riktas mot dem som är tillräckligt mogna och vars fallissemang skulle få stor spridningseffekt i det finansiella systemet.
I Sverige regleras detta genom lag (2024:1278), som kompletterar förordningen med nationella tillsynsroller. Finansinspektionen avgör vilka finansiella entiteter som ska genomföra TLPT, medan Riksbanken samordnar processen och utfärdar de intyg som krävs för ömsesidigt erkännande mellan jurisdiktioner.
Det praktiska genomslaget för en berörd organisation:
- Finansinspektionen kommunicerar urvalet och tidsramen direkt till entiteten.
- Riksbanken kan ta ut avgifter för sin samordnande roll i TLPT-processen.
- Sekretesskrav gäller för testresultat och metodik, eftersom informationen rör kritisk infrastruktur.
- Intyget från Riksbanken gör att ett test i ett land kan godkännas av tillsynsmyndigheter i andra medlemsstater.
Tidigare TIBER-EU-tester räknas inte automatiskt som Dora-kompatibla. Organisationer som redan genomfört sådana tester behöver verifiera att metodiken, inklusive dokumentation och purple teaming, uppfyller de tekniska standarder som Dora föreskriver.
Vilka testmetoder och leverantörskrav gäller i praktiken?
Ett testprogram enligt Dora rör sig längs en skala, från grundläggande kontroller till fullskaliga angreppssimuleringar. ECB beskriver hur förordningen stärker incidentrapporteringen samtidigt som avancerad testning krävs för vissa banker, vilket ökar tillsynsaktiviteten och ställer nya krav på organisatorisk beredskap.
De vanligaste metoderna, i stigande komplexitet:
- Sårbarhetsskanning av system, applikationer och nätverk.
- Scenariobaserade tester som efterliknar specifika incidenttyper, till exempel ett ransomwareangrepp mot betalningssystem.
- Red teaming och purple teaming, där testteamet samarbetar med den interna säkerhetsfunktionen för att stärka upptäckt och respons.
- Hotbildsstyrda penetrationstester enligt TLPT-standarden, som bygger på ramverket G7 och TIBER-EU.
Kraven på testleverantören är strikta. Den som utför TLPT måste ha relevant certifiering och dokumenterad sakkunskap, genomgå lämplighetsprövning och kunna visa ansvarsförsäkring som täcker uppdragets omfattning. När testet berör säkerhetsskyddad verksamhet krävs ofta ett separat säkerhetsskyddsavtal utöver det vanliga tjänsteavtalet.
Scope-principen är enkel att formulera men svår att göra rätt: testningen ska prioritera de funktioner som är kritiska eller viktiga för verksamheten, inte spridas tunt över hela IT-miljön. En riskbaserad avgränsning gör testerna mer relevanta och lättare att försvara inför tillsyn.
Proffstips: Låt affärsägaren, inte bara IT, peka ut vilka funktioner som räknas som kritiska. Det är affärskonsekvensen av ett avbrott som avgör scope, inte den tekniska komplexiteten.
Checklista för ledningen innan testprogrammet startar
Ett testprogram som håller för tillsyn byggs upp i tydliga steg, med ansvar förankrat hos rätt funktion från början.
- Fastställ scope tillsammans med CISO, juridik och affärsägare, och lista vilka funktioner som är kritiska eller viktiga.
- Kartlägg vilka IKT-system som stödjer dessa funktioner och vilken testfrekvens som är rimlig utifrån risknivå.
- Skriv avtal med testleverantören som täcker sekretess, ansvar och, där det behövs, säkerhetsskyddsutredning.
- Genomför lämplighetsprövning av leverantörens personal innan testet påbörjas.
- Dokumentera testplan, testresultat och åtgärdsplan i ett format som går att visa upp för tillsynsmyndigheten.
- Sätt en tidslinje och budget som inkluderar uppföljande tester av tidigare identifierade brister.
- Kommunicera internt vad testet innebär, vem som är kontaktperson och hur resultat hanteras.
Finansinspektionen publicerar föreskrifter om incidentrapportering och informationsregister som trädde i kraft den 17 januari 2025, vilket påverkar hur testresultat och relaterade incidenter ska dokumenteras och rapporteras.
Dokumentationen bör alltid kunna svara på tre frågor: vad testades, vad hittades och vad gjordes åt det. En testrapport utan tydlig koppling till en åtgärdsplan är ofullständig i tillsynens ögon, oavsett hur tekniskt grundlig den är. Analysen av testresultat handlar inte bara om att räkna sårbarheter, utan om att bedöma hur snabbt organisationen upptäckte avvikelsen, hur den svarade och hur väl den återhämtade sig. Scenarier värda att simulera inkluderar utpressningsattacker mot betalningsflöden, avbrott hos en kritisk molnleverantör och dataintrång som sprider sig mellan system. Den som vill fördjupa sig i hur kraven hänger ihop med den bredare regleringen kan läsa mer om Dora:s krav för finanssektorn och hur de förhåller sig till NIS2.
Vanliga fallgropar i testarbetet och vad som faktiskt hjälper
Det vanligaste misstaget är ett scope som är för snävt eller för brett: organisationer testar antingen bara det som är enkelt att testa, eller försöker täcka allt på en gång och tappar djupet där det behövs. Ett annat återkommande problem är avtal med testleverantörer som saknar tydlig reglering av sekretess och ansvar, vilket blir ett problem först när tillsynen frågar efter dem.
Bristande dokumentation är den tredje stora fallgropen. Många organisationer genomför tekniskt gedigna tester men kan inte visa hur resultaten kopplas till en åtgärdsplan med tidslinje. Vi arbetar med gap-analyser, kopplingen mellan testresultat och konsekvensbedömningar samt avtalsstöd för att täppa till just dessa luckor, ofta genom interim compliance-stöd när den interna kapaciteten är för tunn.
— Jesper
Hur Evertrust stöttar er inför och under testprogrammet
Ett testprogram enligt Dora kräver juridisk precision lika mycket som teknisk kompetens, och det är sällan en organisation har båda delarna redo internt samtidigt som testet ska planeras.
Vi kombinerar juridisk spetskompetens inom dataskydd och informationssäkerhet med praktiskt inriktade lösningar, byggda för att göra compliance-arbetet konkret snarare än teoretiskt. Det innebär stöd som passar in där ni redan står i processen:
- Gap-analyser och säkerhetsgranskningar som kartlägger var testprogrammet har luckor innan tillsynen gör det.
- Rådgivning och konsulttjänster för avtalsstöd, scope-definition och löpande projektledning.
- Interim compliance officer när ni behöver en erfaren resurs på plats under en avgränsad period.
- Trustview, en digital plattform för att hålla ordning på dokumentation, åtgärder och rapportering över tid.
Behöver ni en snabb kartläggning av var er organisation står i förhållande till testkraven, boka ett samtal via rådgivning och konsulttjänster så går vi igenom nästa steg tillsammans.
Källor
Den som vill gå till botten med detaljerna bör läsa primärkällorna direkt, inte bara sammanfattningar. EUR-Lex förordning (EU) 2022/2554 ger den fullständiga juridiska texten. Riksdagens lag (2024:1278) beskriver den nationella tillsynsordningen, och Finansinspektionens sida om IT-risker och Dora ger praktisk vägledning för rapportering och tillsyn.
- EUR‑Lex – Digital operational resilience for the financial sector (summary)
- Riksdagen – Lag (2024:1278) med kompletterande bestämmelser till DORA
- ECB – Operational resilience in the digital age (blogg om DORA‑implementering)
- Finansinspektionen – DORA och IKT‑risker
Vanliga frågor
Vad är syftet med testning av digital operativ motståndskraft enligt Dora?
Syftet är att verifiera att en finansiell entitet kan upptäcka, hantera och återhämta sig från IKT-relaterade störningar, inte bara att hitta tekniska brister. Dora kräver att detta sker genom ett program som är integrerat i den löpande riskhanteringen, med tester anpassade efter hur kritisk verksamheten är.
Hur ofta måste ett företag genomföra TLPT?
Entiteter som omfattas av kravet ska genomföra hotbildsstyrda penetrationstester minst vart tredje år, enligt den riskbaserade bedömning som Finansinspektionen och Riksbanken ansvarar för nationellt. Det är Finansinspektionen som avgör vilka entiteter som omfattas och när testet ska genomföras.
Vem avgör vilka svenska företag som ska genomföra TLPT?
Finansinspektionen beslutar vilka finansiella entiteter som ska genomföra hotbildsstyrda penetrationstester, medan Riksbanken samordnar processen och utfärdar de intyg som krävs för att testresultat ska erkännas i andra medlemsstater.
Räcker det med tidigare TIBER-EU-tester för att uppfylla Dora?
Nej, tidigare TIBER-EU-tester räknas inte automatiskt som godkända enligt Dora. Organisationer måste kontrollera att metodiken, inklusive dokumentation och samarbetsformer som purple teaming, uppfyller de tekniska standarder som förordningen och tillhörande föreskrifter ställer.
Kan Evertrust hjälpa till med förberedelser inför ett Dora-test?
Ja, Evertrust erbjuder gap-analyser, avtalsstöd och interim compliance-stöd som förbereder organisationer inför testprogram enligt Dora. Tjänsterna beskrivs närmare under rådgivning och konsulttjänster och gap-analyser.
