DORA-förordningen: robust digital motståndskraft för finanssektorn
Digital Operational Resilience Act, ofta kallad DORA-förordningen, är EU:s regelverk för att säkerställa att finansiella aktörer kan stå emot, reagera på och återhämta sig från IT-relaterade avbrott. Det betyder i praktiken att banker, försäkringsbolag, betalningsinstitut och även deras viktiga IT-leverantörer måste arbeta mer strukturerat med risk, incidenthantering och kontinuitet. I den här artikeln får du en översikt, praktiska exempel samt råd för hur du kan gå från tolkning till genomförande.
Kärnkrav och praktisk tolkning
DORA fokuserar på fem områden: styrning och riskhantering av IKT, incidenthantering och rapportering, testning av digital motståndskraft, hantering av tredjepartsrisk samt informationsdelning om hot. Översatt till vardagen innebär det att ledningen behöver äga IKT-riskerna, att incidenter klassas och rapporteras inom tydliga tidsramar, att kritiska affärsflöden testas mot realistiska hotbilder och att avtal med leverantörer inkluderar mätbara säkerhetskrav. En praktisk startpunkt är att kartlägga vilka system som faktiskt bär dina mest kritiska processer, till exempel betalningsflöden före kundleverans, och därefter koppla dem till tydliga återställningsmål (RTO/RPO).
Ett vanligt misstag jag ser i gap-analyser är att organisationen äger många policydokument men saknar spårbarhet mellan riskbedömning, kontroller och testresultat. Ett enkelt sätt att höja mognaden är att skapa en kontrollkatalog där varje risk får en ansvarig, en mätbar kontroll och ett datum för nästa test. Vid nästa ledningsgenomgång kan du då visa inte bara att kontrollerna finns, utan hur de faktiskt fungerar under tryck, till exempel vid ett simulerat avbrott i betalplattformen en fredagseftermiddag.
Tredjepartsrisk, incidenter och realistiska tester
Många finansiella verksamheter förlitar sig på moln, inloggningstjänster och betalväxlar. Det gör att tredjepartsrisk blir lika affärskritisk som den interna säkerheten. I upphandlingar bör du efterfråga tydliga servicenivåer, rätt till revision, plats för säkerhetsloggar och förpliktelser vid incidenter. Ett konkret exempel: om din identitetsleverantör får driftstörningar ska du i kontraktet ha krav på maximal nedtid, hur snabbt de kommunicerar status och hur loggar lämnas ut för forensik. Detta är extra viktigt när flera leverantörer är kedjade och påverkar varandras återställningstider.
När incidenter inträffar är klassning avgörande. Upprätta på förhand tröskelvärden för vad som räknas som en större incident och koppla dem till tydliga rapporteringsflöden internt och till behöriga myndigheter. Min erfarenhet är att en enkel incidentmatris, kombinerad med färdiga kommunikationsmallar, kapar dyrbar tid. Glöm inte övningar: bordsscenarier varje kvartal och minst en teknisk återställningsövning per år på kritiska system. Här passar dora förordningen som ramverk för att harmonisera frekvens, djup och dokumentation av testerna.
Ett mindre uppenbart men värdefullt grepp är att inkludera affärssidan i övningar. Be produktägare och kundservice spela sin verkliga roll när system ligger nere. Du får då fram beslutslogik, beroenden och kundpåverkan som ofta saknas i rent tekniska tester. Resultatet brukar bli skarpare prioriteringar, bättre fallback-processer och tydligare kundkommunikation vid avbrott.
Sammanfattningsvis gör DORA-förordningen att digital motståndskraft går från ”bra att ha” till ett uttryckligt ledningsansvar. Börja med en enkel nulägesbild: vilka är våra mest kritiska processer, vilka system och leverantörer bär dem, och hur snabbt måste vi återhämta oss. Bygg sedan vidare med en spårbar kontrollkatalog, realistiska tester och robusta leverantörsavtal. Vill du komma vidare, samla ett tvärfunktionellt team och schemalägg en första bordövning inom 30 dagar. Det är ett konkret steg som gör er mer redo redan i år.