DORA-förordningen för fintech: Vad CTO:n måste veta innan 2027

DORA gäller sedan januari 2025, men för många fintech-CTO:er är det först nu det blir verkligt operativt arbete. Förordningen är inte en engångsbock utan ett löpande åtagande, och tillsynen av regelverket, inte minst av kritiska tredjepartsleverantörer, fortsätter att skärpas fram mot 2027. Den här genomgången tar CTO:ns perspektiv: vad det betyder för styrning, arkitektur och leverantörsrelationer, inte bara för compliance-funktionen.

Jag arbetar med fintech-bolag kring operativ resiliens inom cybersäkerhet och compliance. För grundgenomgången av de fem pelarna rekommenderar jag DORA för fintech; här fokuserar jag på de beslut som landar på CTO:ns bord. Skillnaden i perspektiv spelar roll. En compliance-genomgång svarar på frågan "uppfyller vi kraven?". En CTO behöver dessutom svara på "är vi faktiskt motståndskraftiga, och till vilket pris?". Det är två närliggande men inte identiska frågor, och det är i glappet mellan dem som de intressanta avvägningarna ligger.

DORA är ett tekniskt ansvar, inte bara ett juridiskt

Den vanligaste felställningen jag ser är att DORA hamnar helt hos compliance eller juridik. Men kärnan, ICT-riskhantering, resilienstestning, incidenthantering, är tekniska discipliner. CTO:n behöver äga dem, för det är arkitekturen och driften som avgör om bolaget faktiskt är motståndskraftigt. Compliance dokumenterar; tekniken levererar resiliensen.

Arkitektur för återhämtning, inte bara drift

DORA frågar inte bara om systemet fungerar, utan hur snabbt det reser sig. Det gör återhämtningsförmåga till ett arkitekturkrav. CTO:n bör kunna svara på: vad är vår återställningstid för de kritiska systemen, har vi testat den, och vad händer om en central leverantör faller bort? Det här hänger ihop med en testad incidentberedskap, som jag går igenom i incident response-planen.

Två begrepp är värda att internalisera här, eftersom de tvingar fram konkreta beslut. Det ena är hur mycket data ni har råd att förlora vid ett avbrott, mätt som hur långt tillbaka era säkerhetskopior tar er. Det andra är hur länge ett system får vara nere innan det blir affärskritiskt. Båda dessa är affärsbeslut förklädda till tekniska parametrar, och de bör sättas tillsammans med verksamheten, inte gissas av utvecklingsteamet. När målen väl är satta blir de styrande för arkitekturen: ett system som inte får vara nere mer än minuter kräver en helt annan lösning än ett som tål ett dygns avbrott. Att göra de avvägningarna explicit, system för system, är själva kärnan i resiliensarbetet och något DORA i praktiken kräver att ni kan redovisa.

Tredjepartsrisk: den fråga CTO:n underskattar mest

Fintech bygger på leverantörer, molnplattformar, betalningsinfrastruktur, externa API:er. DORA kräver register, avtalsvillkor (revisionsrätt, exit-strategier) och en analys av koncentrationsrisk. För en CTO är den svåraste delen ofta exit-strategin: kan vi faktiskt byta leverantör om vi måste, eller är vi inlåsta? Att besvara det ärligt avslöjar ofta arkitekturskuld.

Här gör jag mid-vägs alltid en leverantörs- och beroendekartläggning ur teknisk synvinkel: var sitter de verkliga inlåsningarna. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Incidentrapportering ur ett tekniskt perspektiv

Rapporteringskraven är lätta att avfärda som en pappersövning, men de har konkreta tekniska konsekvenser. För att kunna klassificera en incident och rapportera korrekt inom utsatt tid måste ni ha tillräcklig observerbarhet i era system: loggning som faktiskt fångar vad som händer, larm som väcker rätt person, och möjlighet att snabbt bedöma omfattning. Många bolag upptäcker vid första incidenten att de inte kan svara på grundläggande frågor, vilka data berördes, hur länge pågick det, hur kom angriparen in, eftersom loggningen var otillräcklig. CTO:n bör därför se rapporteringskravet som ett krav på observerbarhet, och investera i logghantering och övervakning innan en incident tvingar fram det under press.

Resilienstestning som en del av utvecklingscykeln

DORA kräver regelbunden testning av motståndskraften. Min rekommendation till CTO:er är att bygga in det i den befintliga utvecklingscykeln snarare än att behandla det som en separat årlig övning. Sårbarhetsskanning i CI/CD, regelbundna återställningstester och scenarioövningar gör resiliensen till en vana. Det överlappar med god sårbarhetshantering, som jag beskriver i SBOM med Syft och Grype.

Avvägningen mellan resiliens och hastighet

Den svåraste frågan för en fintech-CTO är inte teknisk utan strategisk: hur mycket resiliens ska byggas, och hur mycket bromsar det produktutvecklingen? Redundans, multi-region-arkitektur och leverantörsoberoende kostar pengar och utvecklingstid, och för ett tidigt bolag kan överdriven resiliens vara lika skadlig som för lite. DORA tvingar fram en medveten position i den frågan istället för att låta den avgöras av slentrian. Min rekommendation är att resonera utifrån kritikalitet: de system där ett avbrott är affärskritiskt eller drabbar kunder hårt förtjänar verklig redundans, medan resten kan ha enklare lösningar. Att göra den prioriteringen explicit, och dokumentera den, är i sig en stor del av vad DORA efterfrågar.

Vad CTO:n bör ha på plats inför fortsatt tillsyn

• Ett ICT-riskramverk som ledningen förstår och står bakom.
• Kända och testade återställningstider för de kritiska systemen.
• Ett leverantörsregister med rätt avtalsvillkor och en ärlig koncentrationsriskanalys.
• Incidentrutiner som klarar de harmoniserade rapporteringskraven.
• Återkommande resilienstester inbyggda i utvecklingsflödet.

Var jag brukar börja

Börja med beroendekartan och återställningstiderna. För nästan alla fintech-bolag är det där den verkliga risken sitter, inte i avsaknad av dokument, utan i att man inte vet hur snabbt man reser sig eller hur inlåst man är hos en leverantör. När det är klarlagt blir resten av DORA-arbetet en fråga om att formalisera och täppa konkreta luckor. Se hur jag lägger upp liknande arbete i kundcase.

Relaterat

• Säkerhetsgranskning av AI-applikationer: OWASP LLM Top 10
• Zero Trust-arkitektur för SMB: Praktisk implementation på 30 dagar
• Cloudflare Zero Trust för SMB: Ersätt VPN på en eftermiddag

Vill du ta det vidare?

Jag hjälper fintech-CTO:er att äga DORA där det hör hemma, i arkitektur, drift och leverantörsstrategi. Boka ett samtal så går vi igenom era kritiska beroenden.