Ett DORA-avtal behöver fungera den dag leverantören inte längre kan leverera. Inköp, IT, juridik och verksamhetsansvarig behöver därför fatta ett gemensamt beslut om tjänstens beroenden, avtalsluckor och en genomförbar flytt. En avtalsbilaga med rätt rubriker visar inte att kundernas betalningar, åtkomst eller rapportering kan fortsätta under övergången.
Den här arbetsgången leder till ett granskningsbeslut och en provad exitplan. Den gäller finansiella företag som omfattas av DORA och deras IKT-arrangemang. Börja med företagets tillämplighetsbedömning i arbetsplanen för DORA och IKT-risker. En vanlig programvaruleverantör blir inte automatiskt ett finansiellt företag genom att sälja till en bank.
1. Bestäm vad leverantören faktiskt stödjer
Utgå från den finansiella funktionen och följ beroendena till tjänst, avtal, juridisk leverantör och underleverantör. Ett avtal kan stödja flera funktioner. Samma koncern kan dessutom återkomma som direkt leverantör, molnplattform och identitetstjänst bakom olika varumärken. Använd systemkartläggningen för att upptäcka gemensamma beroenden innan ni jämför anbud.
Skriv en kort motivering till om funktionen är kritisk eller viktig enligt DORA. Motiveringen bör beskriva konsekvensen av ett avbrott, påverkan på kunder och möjligheten att fortsätta uppfylla företagets skyldigheter. Att en tjänst har ett dyrt abonnemang är ingen självständig klassificeringsgrund. Att leverantören kallar tjänsten standardiserad gör inte den stödda funktionen mindre viktig.
Ett fiktivt betalningsföretag använder en extern tjänst för att ta emot och avstämma betalningsuppdrag. Företaget bedömer funktionen som kritisk eftersom ett avbrott stoppar kundernas uppdrag och avstämningen av redan mottagna transaktioner. Ett separat verktyg för interna mötesbokningar får en annan klassificering. Båda arrangemangen behöver beskrivas, men granskningens djup och avtalskraven blir inte identiska.
2. Gör en granskning före avtal
Begär underlag som besvarar era riskfrågor. En certifiering kan bidra med bevis, men läs omfattning, undantag och granskningsperiod. Kontrollera att rapporten gäller den juridiska enheten och tjänsten ni ska köpa. En rapport om leverantörens kontorsmiljö säger begränsat om en separat driftplattform.
Granska särskilt återställningsförmåga, incidenthantering, åtkomst, finansiell och organisatorisk förmåga, intressekonflikter samt möjligheten att övervaka tjänsten. Be leverantören visa ett exempel på en genomförd återställning och förklara hur kvarstående avvikelser följs upp. Dokumentera vad ni faktiskt har sett och vad som fortfarande bara är ett påstående.
Koncentrationsbedömningen behöver nå längre än antalet avtal. Två olika tjänster kan använda samma datacenter, administratörsidentitet eller underleverantör. Bedöm kostnad och nytta med alternativa lösningar, inklusive om de verkligen minskar beroendet. DORA innebär inte ett generellt krav att varje företag ska köpa två molnplattformar. En andra plattform med samma identitetstjänst kan lämna den viktigaste felkällan kvar.
Vid en utländsk leverantör behöver ni även förstå åtkomst till data vid insolvens, rättslig verkställbarhet och de faktiska behandlingsplatserna. Separera den operativa beroenderisken från prövningen av överföringsstöd enligt GDPR. En tillåten personuppgiftsöverföring är inte ett besked om att tjänsten kan ersättas snabbt.
3. Läs avtalet som en arbetsinstruktion
Artikel 30 skiljer mellan grundkrav för IKT-avtal och ytterligare krav när tjänsten stödjer en kritisk eller viktig funktion. Kontrollera bland annat tjänstebeskrivning, behandlings- och lagringsplatser, dataåterlämning, servicenivåer, incidentstöd, myndighetssamarbete och uppsägning. För kritiska eller viktiga funktioner behövs bland annat mer precisa prestationsmål, granskningsmöjligheter och en tillräcklig övergångsperiod. Läs den exakta kravfördelningen i DORA, artikel 30.
Översätt varje relevant avtalskrav till en kontrollfråga. Om bilagan säger att export är möjlig, fråga vem som beställer den, vilka data som ingår, hur lång tid arbetet tar och hur mottagaren kan läsa resultatet. Om incidentstöd ingår, kontrollera bemanning, kontaktväg och prissättning. Artikel 30.2 f medger stöd utan extra kostnad eller till en kostnad bestämd i förväg; den fastställer inte en generell fyratimmarsfrist för alla leverantörsmeddelanden.
Ett användbart granskningsprotokoll kan se ut så här. Exemplet avser det fiktiva betalningsföretaget och är inte en bedömning av någon verklig leverantör.
| Fråga | Underlag och konstaterad lucka | Beslut före avtal |
|---|---|---|
| Komplett export | Export innehåller uppdrag men saknar avstämningsstatus | Lägg till status, relationer och formatbeskrivning; prova import |
| Incidentkontakt | Allmän supportadress, ingen eskalering utanför kontorstid | Fastställ bemannad eskalering som motsvarar funktionens behov |
| Kostnad för hjälp | Pris ska avtalas efter incidenten | Bestäm kostnadsmodell före underskrift |
| Fortsatt tjänst vid byte | Avtalet upphör samma dag som åtkomsten | Förhandla övergångsperiod och arbetsfördelning |
| Granskningsrätt | Endast leverantörens publika sammanfattning erbjuds | Juridik prövar om kraven för funktionen kan uppfyllas |
Tilldela varje lucka en ägare. Skriv uttryckligen om avtalet är godkänt, villkorat eller stoppat. En kommersiell underskrift bör inte råka omvandla ett obesvarat säkerhetskrav till en accepterad risk. Beslutsfattaren behöver kunna se både exponeringen och skälet till att den eventuellt accepteras.
4. Följ ändringar i underleverantörskedjan
För underentreprenad som stödjer kritiska eller viktiga funktioner, eller väsentliga delar av dem, preciserar förordning 2025/532 bedömning och avtalsvillkor. Avtalet ska identifiera vad som får läggas ut och på vilka villkor. Väsentliga planerade ändringar ska meddelas så att företaget kan bedöma dem. En rimlig avtalsfrist ska möjliggöra godkännande eller invändning; reglerna innebär inte att varje ändring alltid kräver ett uttryckligt förhandssamtycke.
Låt meddelandet hamna hos någon som kan bedöma konsekvensen. En inköpsbrevlåda som ingen bevakar under semester ger inget fungerande skydd. Jämför ändringen med den dokumenterade kedjan och fråga om plats, åtkomst, kontinuitet, granskningsrätt eller koncentration påverkas. Spara svaret och tidpunkten när bedömningen avslutades.
I exemplet föreslår leverantören en ny underleverantör för driftövervakning. Företaget upptäcker att administrativ åtkomst ska ske från ett annat land och att den gamla riskbedömningen bara behandlade lagring. Ändringen skickas därför samtidigt till säkerhetsansvarig och dataskyddsansvarig. Inköp återkopplar inom avtalsfristen och dokumenterar de ändringar som krävs för att risknivån ska kunna accepteras.
5. Håll DORA och personuppgiftsbiträdesavtalet ihop
Ett DORA-avtal ersätter inte ett personuppgiftsbiträdesavtal när leverantören behandlar personuppgifter för företagets räkning. GDPR kräver en egen rollbedömning och relevanta instruktioner. DORA omfattar dessutom IKT-risker och data som inte behöver vara personuppgifter.
Kontrollera att samma tjänst, länder och underleverantörer beskrivs konsekvent i samtliga bilagor. En DORA-bilaga kan annars medge en driftmodell som biträdesinstruktionen förbjuder. Använd en konkret bilaga över tekniska och organisatoriska åtgärder för att beskriva hur säkerheten ska fungera, med tydliga ansvar och verifierbara åtgärder.
Håll också tidsfristerna isär. Företagets rapportering enligt DORA, leverantörens avtalade incidentmeddelande och GDPR:s skyldigheter vid personuppgiftsincidenter är olika frågor. Planera så att den första kontakten ger tillräcklig information för parallella bedömningar, även när orsaken eller antalet berörda fortfarande är okänt.
6. Prova exit med en avgränsad men komplett kedja
En exitplan ska för kritiska eller viktiga funktioner vara dokumenterad, tillräckligt provad och regelbundet omprövad. Bestäm omfattningen utifrån tjänsten och riskerna. Det finns ingen generell regel i artikel 28.8 att alla fullständiga leverantörsbyten måste simuleras en gång per år.
Det fiktiva företaget genomför en kontrollerad övning med syntetiska betalningsuppdrag. Alternativet är att tillfälligt köra en avgränsad funktion i egen miljö medan en ny tjänst etableras. Planen anger beslutsfattare, exportansvarig, mottagande tekniker, avstämningsansvarig och kundkommunikation. Leverantören deltar under den övergångsperiod som förhandlats fram.
Protokollet visar följande resultat: exporten skapades och kunde läsas, men mottagaren kunde inte skilja bokförda från ännu väntande uppdrag. Företaget stoppar godkännandet av exitplanen. Leverantören ska komplettera formatet med status och identifierare; avstämningsansvarig ska därefter verifiera att samma uppdrag inte behandlas två gånger. Att filen gick att ladda ned räckte alltså inte för att visa en fungerande flytt.
Koppla övningen till företagets återställningsplan och RTO/RPO. Ett återställningsmål för ordinarie drift blir inte automatiskt en realistisk tidsplan för leverantörsbyte. Dokumentera vilket reservförfarande som håller kundtjänsten igång under mellanperioden, vilka funktioner som måste begränsas och när ledningen ska fatta beslut om att avbryta en misslyckad övergång.
Kontrollera även sådant som lätt faller utanför exporten: nycklar, behörigheter, historiska loggar, dokumentation, integrationsinställningar och bevis om tidigare transaktioner. Bestäm när gamla behörigheter stängs och hur kvarvarande data hanteras utan att radera uppgifter som måste bevaras. Exit är avslutad först när verksamheten kan använda och kontrollera den nya lösningen.
7. Använd informationsregistret i den löpande styrningen
Informationsregistret ska hållas aktuellt och omfatta relevanta avtalsarrangemang, med åtskillnad för sådana som stödjer kritiska eller viktiga funktioner. Låt därför ett godkänt avtal, en väsentlig ändring och ett avslutat arrangemang utlösa uppdatering. Registret bör kunna kopplas till riskbeslut och avtalsversion, så att en handläggare hittar rätt underlag utan att förlita sig på en tidigare kollegas minne.
Skilj den löpande registreringen från en viss rapporteringsomgång. För 2026 angav Finansinspektionen den 28 februari som rapporteringsdatum med referensdatum den 31 december 2025. Dessa historiska datum ska inte användas som antagande om nästa rapportering. Kontrollera FI:s aktuella anvisningar för den rapportering ni ska göra. Se FI:s upplysningar om informationsregistret 2026.
Vanliga frågor vid avtalsbeslutet
Räcker det att leverantören står under europeisk tillsyn?
Nej. Europeisk övervakning av en utsedd kritisk IKT-leverantör flyttar inte företagets ansvar för det egna arrangemanget. Använd relevant tillsynsinformation som ett underlag, men bedöm fortfarande den tjänst, konfiguration och beroendekedja som ni själva använder. Att er funktion är kritisk betyder inte heller att leverantören automatiskt har utsetts till kritisk på EU-nivå.
Kan vi acceptera en avtalslucka eftersom ett byte är dyrt?
Beskriv först om luckan gäller ett bindande krav eller ett internt önskemål. Kostnad gör inte ett bindande krav valfritt. Förhandla en fungerande lösning, pröva ett annat upplägg eller avstå från arrangemanget om kraven inte kan uppfyllas. För risker där ett bedömningsutrymme finns ska beslutet ange kompensation, ansvar och när det omprövas.
Vad ska lämnas till ledningen?
Lämna tjänstens klassificering, de viktigaste beroendena, öppna avtalskrav, resultatet från exitövningen och ett tydligt beslutsförslag. I det fiktiva exemplet är förslaget villkorat godkännande först efter en komplett export och en lyckad avstämning. Det ger ledningen en konkret fråga att avgöra och teamet ett kontrollerbart villkor att uppfylla.