DORA: informationsregister (mall och guide)

Informationsregistret enligt artikel 28.3 i DORA är den strukturerade förteckningen över samtliga avtal om IKT-tjänster som tillhandahålls av tredjepartsleverantörer. Det följer bindande mallar i kommissionens genomförandeförordning (EU) 2024/2956, förs på entitetsnivå och på konsoliderad nivå, och lämnas minst en gång per år till Finansinspektionen i ett maskinläsbart format.

Den här guiden går igenom mallarnas struktur, vilka fält som ska fyllas i, hur registret lämnas in och varför registerförteckningen enligt GDPR inte kan användas i stället.

Viktigaste punkterna

• Rättslig grund: artikel 28.3 i förordning (EU) 2022/2554; formatet är fastställt i genomförandeförordning (EU) 2024/2956.
• Registret består av mallblock B_01 till B_07 som binds ihop av gemensamma identifierare.
• Varje avtal måste ange om tjänsten stödjer en kritisk eller viktig funktion — det fältet styr hur långt de övriga kraven sträcker sig.
• Underleverantörskedjan ska med, inte bara den direkta leverantören.
• Registret ligger till grund för utpekandet av kritiska IKT-leverantörer på EU-nivå: det är en tillsynsrapport, inte intern dokumentation.

Vad kräver artikel 28.3?

Bestämmelsen ålägger varje finansiell entitet att föra och uppdatera ett informationsregister över samtliga avtal om användning av IKT-tjänster som tillhandahålls av tredjepartsleverantörer — på entitetsnivå och, i förekommande fall, på undergrupps- och koncernnivå. Registret ska skilja de avtal som stödjer kritiska eller viktiga funktioner från övriga.

På registret vilar tre skyldigheter: att årligen rapportera till den behöriga myndigheten om antalet nya avtal, kategorierna av leverantörer, avtalstyperna och de tjänster och funktioner som omfattas; att på begäran lämna ut hela registret eller delar av det; och att i god tid informera om planerade avtal som rör kritiska eller viktiga funktioner. Ett inaktuellt register bryter mot alla tre samtidigt.

Vilka mallar gäller? Strukturen i förordning (EU) 2024/2956

Block	Innehåll
B_01.01–B_01.03	Entiteten som för registret, konsolideringskrets, filialer
B_02.01–B_02.03	Avtal: allmän information, specifik information, koncerninterna avtal
B_03.01–B_03.03	Avtalsslutande parter på kund- respektive leverantörssidan
B_04.01	Entiteter som faktiskt använder IKT-tjänsterna
B_05.01–B_05.02	IKT-tredjepartsleverantörer och underleverantörskedjor
B_06.01	Identifiering av entitetens funktioner
B_07.01	Bedömning av tjänster som stödjer kritiska eller viktiga funktioner

Blocken är inte fristående flikar. De kopplas ihop av nycklar — avtalets referensnummer, leverantörens LEI-kod, funktionens identifierare. Det är därför separata kalkylark nästan alltid faller på valideringen: en enda inkonsekvent identifierare gör att filen underkänns.

Fält för fält: vad som ska fyllas i

Fält	Block	Beskrivning	Exempel
Entitetens LEI	B_01	Identifierare för den som för registret	5493001…
Avtalsreferens	B_02	Unikt internt avtalsnummer	AVT-2025-014
Avtalstyp	B_02	Fristående, ramavtal eller efterföljande avtal	Ramavtal
Start- och slutdatum	B_02	Avtalets löptid	2025-03-01 / 2028-02-28
Uppsägningstid	B_02	För entiteten respektive leverantören	90 / 180 dagar
Tillämplig lag	B_02	Den lag avtalet styrs av	Sverige
Årlig kostnad	B_02	Utgift senaste räkenskapsåret samt valuta	840 000 SEK
Typ av IKT-tjänst	B_02	Kategori enligt förordningens taxonomi	Molntjänster
Leverantörens identitet	B_05	LEI eller EUID, registrerat och kommersiellt namn	LEI + firma
Leverantörens hemland	B_05	Jurisdiktion för huvudkontoret	Irland
Leverantörens moderbolag	B_05	Koncernens yttersta ägare	—
Underleverantörer	B_05	Led i kedjan och identifiering av relevanta underleverantörer	Led 1, led 2
Understödd funktion	B_06	Identifierare, benämning och affärsområde	Betalningshantering
Kritisk eller viktig funktion	B_06/B_07	Ja/nej med motivering och datum för bedömningen	Ja, 2026-01-15
Datalagring	B_07	Om lagring sker, land för lagring och land för förvaltning	Ja / Irland / Sverige
Uppgifternas känslighet	B_07	Åsatt känslighetsnivå	Hög
Utbytbarhet	B_07	Hur enkelt leverantören kan ersättas	Hög komplexitet
Exitplan	B_07	Om plan finns, möjlig återtagning, alternativa leverantörer	Ja
Senaste granskning	B_07	Datum för senaste revision eller riskbedömning	2025-11-30

Två fält förtjänar oproportionerligt mycket uppmärksamhet. Det första är kritisk eller viktig funktion: ett “ja” utlöser de skärpta avtalsvillkoren i artikel 30.3, kraven på revision och åtkomst, exitplanen och koncentrationsbedömningen. Ett “nej” utan dokumenterad motivering är den vanligaste anmärkningen vid granskning. Det andra är var uppgifterna finns: registret skiljer på landet där data lagras och landet varifrån de förvaltas, och uppgifterna måste stämma med vad ni redan har uppgett om tredjelandsöverföringar.

Hur lämnas registret in?

Entiteten lämnar registret till Finansinspektionen, som i sin tur vidarebefordrar det till de europeiska tillsynsmyndigheterna (EBA, Esma och Eiopa). Insamlingen sker årligen med en referensdag som myndigheten anger, och filen måste följa mallarnas struktur och valideringsregler.

Filens slutdestination förklarar den formella stramheten: det är utifrån de aggregerade registren som tillsynsmyndigheterna identifierar koncentrationer och utpekar IKT-tredjepartsleverantörer som kritiska, vilket ger direkt europeisk tillsyn över dem. Ett register med felaktiga LEI-koder eller felklassade funktioner är därför inte bara ett formfel.

Hur skiljer sig registret från GDPR:s registerförteckning?

	DORA informationsregister	Registerförteckning (art. 30 GDPR)
Föremål	Avtal om IKT-tjänster	Behandlingar av personuppgifter
Enhet	Avtal och leverantör	Ändamål med behandlingen
Format	Bindande EU-mallar	Fritt
Inlämning	Årligen till Finansinspektionen	Endast på begäran av IMY
Omfattning	Alla IKT-tjänster, med eller utan personuppgifter	Endast personuppgiftsbehandling

Sammanblandningen kostar tid åt båda håll. En leverantör som sköter serverdrift utan åtkomst till personuppgifter hör hemma i DORA-registret men inte i GDPR-förteckningen; en marknadsföringsbyrå som behandlar kunduppgifter utan att leverera en IKT-tjänst hör hemma i GDPR-förteckningen men inte i DORA-registret. Leverantörer som finns i båda — molndrift är typfallet — kräver separat dokumentation: personuppgiftsbiträdesavtalet enligt artikel 28 innehåller inte DORA:s obligatoriska avtalsvillkor enligt artikel 30. Samma resonemang gäller koncernbolag som omfattas av cybersäkerhetslagen och för egna leverantörsförteckningar.

Hur bedöms “kritisk eller viktig funktion”?

Fältet är registrets tyngdpunkt, och bedömningen ska göras på funktionen — inte på leverantören eller systemet. DORA definierar en kritisk eller viktig funktion som en funktion vars avbrott väsentligt skulle försämra entitetens finansiella resultat, soliditet eller kontinuitet i verksamheten, eller dess förmåga att uppfylla villkoren i tillståndet och skyldigheterna enligt tillämplig finansiell reglering. Det är alltså en verksamhetsbedömning som ska göras av de affärsansvariga, inte en IT-klassificering.

Ett arbetssätt som håller: utgå från B_06 och lista entitetens funktioner ur tillståndets perspektiv — kreditgivning, betalningsförmedling, orderutförande, skadereglering, kundmedelshantering. Bedöm varje funktion mot avbrottets konsekvens och dokumentera motiveringen och datumet. Koppla först därefter avtalen till funktionerna. Bygger ni i omvänd ordning, från leverantörslistan mot funktionerna, hamnar bedömningen hos inköp eller IT och blir svår att försvara vid granskning. Bedömningen ska dessutom omprövas — vid nya avtal, vid förändrad verksamhet och inför varje årlig inlämning.

Vanliga misstag

• Att bara registrera den direkta leverantören. Underleverantörskedjan för kritiska funktioner ska framgå av registret.
• Att blanda ihop avtalspart och användare. Den som skriver under avtalet (B_03) och den som faktiskt använder tjänsten (B_04) är olika fält och sammanfaller sällan i en koncern.
• Att skjuta upp kritikalitetsbedömningen. Utan en daterad och motiverad bedömning går B_07 inte att fylla i på ett försvarbart sätt.
• Att utelämna koncerninterna avtal. IKT-tjänster från ett annat bolag i koncernen ska med (B_02.03).
• Att bygga registret en gång. Det är en återkommande rapportering, inte ett projekt: varje nytt avtal och varje tillägg ändrar filen.

Att hålla registret levande

Det tunga arbetet är inte den första versionen. Det är att hålla avtal, funktioner och klassificeringar konsekventa över året, genom förlängningar, tilläggsavtal och byten av underleverantörer. Mönstret känns igen från dataskyddsdokumentationen, med den skärpningen att formatet här är bindande och valideras maskinellt hos myndigheten.

Det är detta som skiljer den som förvaltar registret i en fil från den som förvaltar det i ett system. En plattform där leverantörer, avtal, funktioner och kritikalitetsbedömningar hänger ihop och kan exporteras i EU-formatet — vilket är kärnan i en DORA-programvara för svenska finansföretag — tar bort den årliga manuella avstämningen. För den som redan använder ett verktyg för dataskydd är det oftast billigare att utöka den befintliga leverantörsbasen än att köpa en fristående DORA-svit; jämför funktioner i vår programvarujämförelse och prisnivåer i kostnadsguiden.

Vanliga frågor

Hur ofta ska informationsregistret lämnas in?

Minst en gång per år till Finansinspektionen, med den referensdag myndigheten anger. Därutöver kan tillsynen begära in registret eller delar av det när som helst.

Omfattas avtal med bolag i samma koncern?

Ja. Koncerninterna avtal om IKT-tjänster har en egen mall (B_02.03) och räknas vid bedömningen av kritikalitet och koncentration.

Räcker det med ett kalkylark?

För att samla in uppgifter, ja. För inlämning, nej: filen måste följa strukturen, identifierarna och valideringsreglerna i mallarna enligt förordning (EU) 2024/2956.

Vad händer om registret är ofullständigt?

Bristande efterlevnad av artikel 28 omfattas av tillsynsbefogenheterna och det nationella ingripandesystemet. I praktiken signalerar ett ofullständigt register svag styrning och tenderar att bredda granskningen — se den kompletta DORA-guiden om ledningsorganets ansvar.

Slutsats

Informationsregistret är DORA:s mest arbetskrävande skyldighet och det första tillsynen frågar efter. Bygg det utifrån avtalen, inte utifrån systemen; bestäm och dokumentera varje funktions kritikalitet innan ni fyller i de fält som hänger på den; ta med underleverantörskedjan och de koncerninterna avtalen; och håll identifierarna konsekventa mellan blocken, eftersom det är där valideringen brister. Den som behandlar registret som en löpande rapportering, och inte som ett avslutat projekt, når den årliga insamlingen utan extraarbete.