Ramverk och standarder

DORA

EU-förordning som fastställer enhetliga krav för IKT-riskhantering, incidentrapportering, resiliensprovning och tredjepartsstyrning i finanssektorn.

Var du ser detta: Används i styrning, risk- och efterlevnadsarbete: val av kontroller, revisioner, rapportering och säkerhetsroadmaps.

Vad det är

En bindande EU-förordning som standardiserar hur finansiella aktörer hanterar IKT-risk, incidenter, resiliensprovning och beroenden till externa IKT-leverantörer.

Nyckelpunkter
  • Gäller många finansiella aktörer i EU och inför tillsyn på EU-nivå för kritiska tredjepartsleverantörer av IKT-tjänster.
  • Kräver ett ramverk för IKT-riskhantering som omfattar förebyggande, detektion, respons, återhämtning och kommunikation.
  • Kräver rapportering av större IKT-relaterade incidenter till behöriga myndigheter och uppmuntrar strukturerat lärande efter incidenter.
  • Kräver tester av digital operativ resiliens, inklusive avancerad hotdriven penetrationstestning för vissa verksamheter.
  • Skärper tredjepartsriskhantering för IKT genom due diligence, avtalskrav, löpande uppföljning och exitplanering.

Hur det fungerar i stora drag

  1. Avgränsa kritiska tjänster och IKT-tillgångar, och etablera styrning samt ansvar på ledningsnivå.
  2. Bygg ett ramverk för IKT-riskhantering med policyer, kontroller, övervakning och dokumenterade resiliensmål för kritiska tjänster.
  3. Definiera klassificering och rapporteringsflöden för incidenter, inklusive playbooks, kommunikationsplaner och lärdomar.
  4. Driv ett testprogram för resiliens som matchar riskbilden, från grundläggande kontrolltester till hotdriven penetrationstestning där det krävs.
  5. Hantera tredjepartsrisk i IKT med strukturerad due diligence, avtalsklausuler, kontinuerlig uppföljning och realistiska exitplaner.

Konkret exempel

Ett betalningsbolag migrerar centrala arbetslaster till en molnleverantör. Under DORA behöver bolaget bedöma koncentrationsrisk, stärka identitet och loggning, avtala incidentstöd, testa återställning med realistiska övningar och ha en faktisk exitväg om leverantören blir en kritisk beroendepunkt.

Varför det är viktigt

Finansiella tjänster är starkt sammankopplade. Ett enskilt IKT-avbrott eller leverantörsfel kan få följdeffekter mellan flera aktörer. DORA harmoniserar förväntningarna i EU och flyttar fokus från dokumentation till bevisad motståndskraft.

Säkerhetsperspektiv

  • Behandla operativ resiliens som en livscykel: designa för fel, upptäck snabbt, agera beslutsamt, återställ stabilt och förbättra löpande.
  • Använd samma kritikalitetsbedömning för leverantörer som för interna system: tjänstekartläggning, koncentrationsrisk och delade beroenden.
  • Gör testning evidensdriven: testresultat ska påverka riskbeslut, investeringar och rapportering till styrelse/ledning.

Vanliga fallgropar

  • Att behandla DORA som ren dokumentation utan att höja mognaden i övervakning, testning och återställning.
  • Svag tjänstekartläggning som döljer kritiska beroenden och gör exitplaner orealistiska.
  • Övertro på moln- eller MSP-avtal utan verifierad observerbarhet, incidentstöd och återställningsförmåga.
  • Incidentrapportering som stannar vid administration i stället för att förbättra detektion, begränsning och återhämtningstid.
  • Generiska årliga tester som inte speglar verkliga angreppsvägar eller operativa felmoder.

FÖRDJUPNING

▾

Resiliens ska bevisas, inte beskrivas

DORA kräver att finansiella aktörer kan visa att kritiska tjänster står emot verkliga IKT-störningar, inte bara att policyer finns. Ett välfungerande DORA-program behandlar driftavbrott, cyberincidenter och leverantörsstörningar som normala lägen som måste kunna hanteras tekniskt och organisatoriskt.

I praktiken blir kärnfrågan enkel: när något går fel, kan ni upptäcka snabbt, fatta korrekta beslut under press och återställa inom satta mål. Sådan evidens kommer från övervakning, övade runbooks, testade backuper och tydliga eskaleringsvägar, inte från en engångsinsats inför revision.

Eftersom förordningen gäller hela EU:s finanssektor är förväntan jämförbarhet och konsekvens. Om två aktörer hävdar samma resiliensmål behöver de också kunna visa likvärdig kvalitet i underlaget.

De fem pelarna i praktiskt arbete

DORA samlar kraven i fem områden: IKT-riskhantering, incidenthantering och rapportering, resiliensprovning, tredjepartsrisk i IKT samt informationsdelning. I praktiken implementeras detta genom styrning på ledningsnivå och en återkommande cykel av kartlägg, skydda, övervaka, testa och förbättra.

Den tydligaste förändringen är tjänstecentrerat arbete. I stället för att börja med verktyg och plattformar börjar du med kritiska tjänster, deras återhämtningsmål samt de IKT-komponenter och leverantörer som bär tjänsten.

Mogna program knyter ihop pelarna. Avtalskrav påverkar loggåtkomst, loggkvalitet påverkar incidentdetektion, detektion påverkar rapportering och rapporteringslärdomar påverkar nästa testcykel.

Incidentrapportering som lärandeloop

Incidentrapportering enligt DORA missförstås ofta som administrativ rapportering. Den egentliga avsikten är robust klassificering, snabb intern beslutsförmåga och tillförlitlig extern kommunikation när incidenter är väsentliga.

Högpresterande team designar rapportering inifrån och ut. De definierar vilken evidens som behövs under respons, hur den säkras, vem som beslutar allvarlighetsgrad och hur myndigheter samt kunder uppdateras utan gissningar.

Den snabbaste mognadsökningen kommer efter incidenten. Varje större händelse bör bli en kort förbättringscykel som skärper detektion, respons och återhämtning och sedan matas tillbaka till testscenarier.

Tredjepartsrisk, koncentration och verklig exitförmåga

DORA är tydlig med att outsourcat ansvar fortfarande är eget ansvar. En molnleverantör, MSP eller SaaS-tjänst kan bli en single point of failure, vilket gör leverantörsstyrning till en teknisk och operativ fråga, inte bara en juridisk.

Praktiskt fokus ligger på observerbarhet, incidentstöd och återställbarhet. Avtal är bara värdefulla om du faktiskt kan få ut loggar, eskalera snabbt och genomföra en realistisk exit under tidspress.

Koncentrationsrisk är ofta den tysta utmaningen. Även om varje leverantör ser acceptabel ut var för sig kan delade beroenden skapa systemrisk över tjänster, regioner eller hela portföljer.

Så börjar du på ett sätt som håller i drift och revision

Börja med att kartlägga ett begränsat antal kritiska tjänster end-to-end, inklusive system, dataflöden, identiteter och leverantörer. Sätt tydliga återhämtningsmål och verifiera att de kan uppnås med nuvarande backuper och runbooks.

Bygg därefter ett evidenspaket per tjänst: övervakningssignaler, responsplaybooks, återställningstest och tredjepartsvillkor som säkerställer tillgång och stöd. Då blir gapen synliga och efterlevnad kan översättas till konkret ingenjörsarbete.

Iterera sedan med realistiska övningar. Välj scenarier som speglar verkliga felmoder, mät detektions- och återhämtningstid, åtgärda brister och skala metoden till nästa tjänstegrupp.