Faktagranskad mot Finansinspektionen och EUR-LexSenast granskad 3 min läsning
Kort sagt
- Deadline är 28 februari varje år, för förhållandena vid föregående årsskifte.
- Formatet är xbrl-csv och kanalen är Fidac. Inget av dem är valfritt.
- Mallarna finns i genomförandeförordningen (EU) 2024/2956.
- Entiteten ska identifieras med LEI-kod, vilket förutsätter att ni har en.
- Välj antingen gruppnivå eller entitetsnivå. Båda ger dubbelrapportering.
- Registret är inte bara en rapport. Det är också er egen karta över IKT-beroenden.
Vad kravet består av, exakt
Finansinspektionen formulerar det som att finansiella entiteter ska rapportera sitt register med information om kontraktsmässiga arrangemang. Ordet kontraktsmässiga är centralt: det är avtalen med IKT-tredjepartsleverantörer som registreras, inte era system.
Rapporteringen görs via Fidac i xbrl-csv-format, med mallarna i genomförandeförordningen (EU) 2024/2956, och entiteten identifieras med LEI-kod. Om ni inte redan har en LEI-kod är det den uppgift som tar längst tid att skaffa och den som stoppar hela inlämningen.
Finansiella entiteter inom en grupp får rapportera på gruppnivå, alltså på högsta konsoliderade nivå. Entiteter som inte ingår i en grupp, eller vars register inte täcks fullt ut på gruppnivå, rapporterar på entitetsnivå. Bara en av metoderna ska användas, för att undvika dubbelrapportering.
senast den 28 februari
| Del | Vad som gäller | Vad som stoppar er |
|---|---|---|
| Tidpunkt | Senast 28 februari, för föregående årsskifte | Att registret börjar sammanställas i februari |
| Format | xbrl-csv enligt mallarna | Att data ligger i fritext i ett avtalsregister |
| Kanal | Fidac | Behörigheter som inte är på plats |
| Identifiering | LEI-kod för entiteten | Att ni inte har en LEI-kod |
| Nivå | Grupp eller entitet, inte båda | Otydlighet om vem som rapporterar vad |
De tre saker som brukar fattas
Den första är underleverantörer. Registret handlar om kedjan, inte bara om den ni har avtal med. Ett avtal med en molnleverantör som i sin tur använder en underleverantör för en kritisk del är två uppgifter, inte en, och den andra måste hämtas från leverantören.
Den andra är avtal som inte ser ut som IKT-avtal. En marknadsföringsplattform som behandlar kunddata, ett HR-system, ett dokumentverktyg. De köps ofta utanför IT och finns därför inte i IT:s avtalsregister, vilket är precis varför de saknas.
Den tredje är funktionsklassificeringen. För varje arrangemang ska det framgå om det stödjer en kritisk eller viktig funktion, och den bedömningen är verksamhetens och inte inköpets. Den kan inte hämtas ur avtalet, den måste göras.
| Finns redanhämtas | Måste skapasbedöms | |
|---|---|---|
| Avtalsparter och löptider | ✓ | ✕ |
| Var tjänsten levereras ifrån | ~ | ✕ |
| Underleverantörer i kedjan | ✕ | ✓ |
| Om funktionen är kritisk eller viktig | ✕ | ✓ |
| Exitplan för arrangemanget | ✕ | ✓ |
| Avtal köpta utanför IT | ✕ | ✓ |
Kolumnen som måste skapas är den som avgör tidsplanen. Att hämta avtalsuppgifter går fort; att klassificera funktioner kräver verksamhetens tid.
Källa: Dora artikel 28
Registret som er egen karta
Det är lätt att behandla registret som en rapporteringsuppgift och lägga det i en mapp efter inlämning. Det är en missad möjlighet, eftersom sammanställningen producerar något som få organisationer har: en komplett förteckning över vilka utomstående som bär er verksamhet.
Den förteckningen är direkt användbar på tre andra ställen. Den är utgångspunkten för riskanalysen, eftersom den visar vilka beroenden som faktiskt finns. Den är underlaget för kontinuitetsplaneringen, eftersom den visar vad som faller om en leverantör faller. Och den är svaret på de leverantörskedjefrågor era egna kunder ställer.
Praktiskt betyder det att registret bör bo där riskarbetet bor och inte i en rapporteringsmapp. Formatet för inlämning är xbrl-csv, men källan bör vara något ni faktiskt använder mellan februarierna.
Vad registret hänger samman med
- 4 timmar
- till första underrättelse vid allvarlig incident, som ofta rör en leverantör
- 3 år
- högsta intervall mellan hotbildsstyrda tester, som omfattar leverantörskedjan
- 60 %
- av europeiska fall började med social manipulation, ofta mot en leverantör
- 21.3 %
- började med sårbarhetsutnyttjande, ofta i en komponent ni inte äger
- 72 timmar
- till mellanrapport, som ofta väntar på uppgifter från en leverantör
Källa: Dora artikel 26
Källa: ENISA Threat Landscape 2025
Källa: ENISA Threat Landscape 2025
En tidsplan som håller
Räkna baklänges från den 28 februari och lägg de tunga delarna först, eftersom de kräver andra människor än er själva.
Under hösten: kontrollera LEI-kod och Fidac-behörigheter, och begär in underleverantörsuppgifter från leverantörerna. Det senare är det som tar tid, eftersom svaren kommer när leverantören hinner.
Under fjärde kvartalet: klassificera funktionerna med verksamheten. I januari: sammanställ mot mallarna och validera formatet. Lämna in i god tid före den 28 februari, eftersom formatfel upptäcks vid inlämning och inte innan.
Frågor
Vanliga frågor
- När ska informationsregistret rapporteras?
- Senast den 28 februari varje år, för förhållandena vid föregående kalenderårs slut.
- I vilket format?
- xbrl-csv via Fidac, med mallarna i genomförandeförordningen (EU) 2024/2956. Entiteten identifieras med LEI-kod.
- Ska vi rapportera på grupp- eller entitetsnivå?
- Antingen eller. Entiteter i en grupp får rapportera på högsta konsoliderade nivå; övriga rapporterar på entitetsnivå. Bara en metod ska användas.
- Vad glöms oftast?
- Underleverantörer i kedjan, avtal som köpts utanför IT, och klassificeringen av om arrangemanget stödjer en kritisk eller viktig funktion.
- När bör vi börja?
- Under hösten. LEI-kod, Fidac-behörigheter och underleverantörsuppgifter tar tid eftersom de beror på andra, medan sammanställningen går fort.
Primärkällor
Källor
Varje regulatoriskt påstående på den här sidan går att spåra till en av källorna nedan. Ingen av dem är en konsultblogg.
- Informationsregister (Dora), Finansinspektionen— Deadline, format, kanal och nivå
- Genomförandeförordning (EU) 2024/2956, EUR-Lex— Mallarna för registret
- Dora artikel 28, EUR-Lex— Kraven på IKT-tredjepartsarrangemang
- Dora-förordningen (EU) 2022/2554, EUR-Lex— Förordningstexten i sin helhet
- Om Dora, Finansinspektionen— Kravområdet tredjepartsrisk
Fördjupning
