DORA og PCI DSS kræver det samme: et kortlagt IT-landskab
I 2024 bestod 93,5% af de finansielle institutioner ikke EBAs dry run for DORA Register of Information. Samtidig er PCI DSS 4.0.1 nu fuldt håndhævet. De sidste krav trådte i kraft den 31. marts 2025, og revisorerne finder stadig de samme mangler.
Det er ikke en tilfældighed. De to regulativer stiller reelt det samme spørgsmål: Kan man løbende og præcist dokumentere, hvilke systemer, data og leverandører, der understøtter den kritiske forretning? De fleste virksomheder kan ikke svare på det, og årsagen er den samme, uanset hvilket regulativ der er tale om.
Denne artikel er anden del af en serie om det fælles fundament bag NIS2, DORA/PCI DSS og AI Act. Har man allerede læst artiklen om NIS2, er en stor del af fundamentet nedenfor allerede lagt.
Hvad de to regulativer kræver, kort fortalt
DORA kræver et register over alle ICT-leverandører, klassificeret efter hvor kritiske de er for forretningen. PCI DSS kræver et tilsvarende scope-dokument for alt, der rører ved betalingskortdata, samt en liste over de leverandører, der har adgang til det. Det lyder som et dokumentationsprojekt. I praksis er det en øvelse i at vide, hvad man har, og hvem der er ansvarlig for det. Og det er præcis dér, de fleste virksomheder kommer til kort.
Hvorfor det er svært i praksis
Problemet er sjældent manglende vilje. Det er, at svaret på, hvad man har, og hvem der ejer det, ikke findes ét sted. IT kender systemerne, men ikke altid hvilken forretningsproces de understøtter. Indkøb kender kontrakterne, men ikke hvor kritiske leverandørerne reelt er for driften. Forretningen ved, hvad der er vigtigt, men sjældent hvilke systemer og leverandører, der ligger bag. Ingen af de tre har til opgave at holde det samlede billede opdateret, og når en medarbejder med den viden skifter job, forsvinder en del af overblikket med.
Samtidig er data selv spredt over et CMDB, et par regneark, en kontraktdatabase og nogle gamle slides fra sidste audit. At samle det til ét dokument bliver en manuel opgave. Den sættes i gang, når fristen nærmer sig, og er forældet igen få måneder, efter den er afleveret.
💡 Samme spørgsmål går igen i begge regulativer. Hvilke systemer og leverandører understøtter en kritisk funktion? Hvor befinder data sig? Og er svaret opdateret, eller er det lavet til sidste audit? |
Samme mønster, to regulativer
Sammenligner man de hyppigste fejl fra EBAs dry run for DORA med de mest almindelige fund i PCI DSS-revisioner, går mønsteret igen:
DORA Register of Information | PCI DSS 4.0.1 | Fælles gap |
CIF klassificering af kritiske funktioner | Scope af Cardholder Data Environment (krav 12.5.2) | Uden kortlagte kapabiliteter er begge dele gætværk |
Leverandør og underleverandørkæde | Tredjepartsstyring (krav 12.8) | Ingen systematisk kortlægning af leverandørkæden |
Geografisk dataplacering | Datastrøms og lagringskortlægning (krav 3, 4 og 12.5.2) | Ukendt hvor data faktisk behandles og opbevares |
Løbende opdatering | Årlig scope revision og ændringsstyring | Statisk dokumentation, forældet før næste revision |
Sådan står det danske marked
Danmarks Nationalbank følger robustheden i den finansielle sektor tæt, og tallene peger den forkerte vej. I den seneste undersøgelse, der bygger på svar fra 19 centrale aktører, steg andelen af banker med cyberangreb, der førte til betydelige hændelser, fra 25% i første halvår 2024 til 35% i andet halvår 2024:
Flere centrale aktører mangler exitstrategier, altså en reel mulighed for at skifte leverandør, hvilket er særligt svært, hvis man vil undgå at være afhængig af leverandører fra ét geografisk område.
Beredskabsplanerne er ikke altid tilstrækkelige til at sikre drift i ekstreme scenarier.
FSOR, Finansielt Sektorforum under Nationalbanken, har identificeret 29 risici på tværs af cyberangreb, databeskyttelse og forretningsvidereførelse.
Mange danske virksomheder havde svært ved at nå fristen for Register of Information-rapporteringen den 31. marts 2025.
I august 2025 blev en telekommunikationsleverandør til den fælleseuropæiske betalingsinfrastruktur TARGET Services ramt af et ransomwareangreb. Det ramte ikke selve betalingsafviklingen, men er et konkret eksempel på den type leverandørrisiko, DORAs register skal gøre synlig.
💡 Det er ikke mangel på regulering, der er problemet. Det er, at ingen af de 19 aktører har det kortlagte fundament, der kan vise, om foranstaltningerne rent faktisk dækker det, der er kritisk. |
Sådan hjælper Clariox
Vi løser det ikke med endnu et engangsdokument, der er forældet ved næste revision. Vi bygger et levende billede i Ardoq, hvor kapabiliteter, applikationer, ejerskab, leverandører og data hænger sammen og opdateres, i takt med at organisationen ændrer sig. Det samme billede genbruges til begge registre, i stedet for at DORA og PCI DSS vedligeholdes som to separate lister, der hele tiden bevæger sig væk fra hinanden. Det foregår i tre trin:
Fase 1: Applikations- og kapabilitetskortlægning
På samme måde som vi bygger fundamentet i NIS2, starter vi i DORA og PCI DSS med applikationerne, de forretningskapabiliteter de understøtter, og hvem der ejer hver del, altså de grundlæggende streger mellem IT og forretning, før vi kigger på leverandørerne. Vi går i detaljer med selve øvelsen i artiklen om NIS2. Er billedet allerede tegnet og holdt ved lige, kan det læses direkte ind i DORAs CIF-klassificering og PCI DSS' CDE-scope, i stedet for at blive tegnet forfra.
Fase 2: Leverandør- og datakortlægning via API-integrationer og Ardoq Surveys
Med kapabiliteter og applikationer på plads kobles ICT-tjenester, direkte leverandører, underleverandører og datastrømme på fundamentet. Det meste af den kobling behøver ikke være manuel. API-integrationer henter data direkte fra de systemer, der allerede findes, CMDB, indkøbssystemer, cloud-tenants og kontraktdatabaser, i stedet for at nogen skal eksportere regneark og samle dem manuelt. Der, hvor data ikke findes i et system, sendes en Ardoq Survey automatisk til den, der ejer processen eller leverandøren, med præcis de spørgsmål, der mangler svar på. Svarene går direkte ind i modellen, uden en mellemmand, der taster det ind bagefter. Det dækker både DORAs leverandørkæde og PCI DSS' krav til tredjeparter og datastrømme.
Fase 3: Strukturering og løbende opdatering
Data struktureres til EBAs format for Register of Information og til den dokumentation, QSA'en eller revisoren kræver til PCI DSS. Fordi kortlægningen er koblet til API-integrationer og surveys, opdateres begge rapporter, i takt med at et system, en leverandør eller en kontrakt ændrer sig, i stedet for at blive genskabt manuelt, hver gang fristen nærmer sig.
💡 Sidegevinst: Den samme kortlægning kan genbruges til NIS2-leverandørstyring og AI Act-dokumentation. Den giver også grundlag for kommerciel kontraktoptimering og reducerer typisk IT-omkostningerne med 15 til 30%. |
Klar til at samle compliance-fundamentet?
📅 Book en uforpligtende samtale på clariox.dk/contact
Clariox Advisory er en uafhængig IT-rådgivningsvirksomhed og Ardoq-partner, den eneste Ardoq-fokuserede partner i Danmark. Denne artikel er til informationsformål og udgør ikke juridisk eller regulatorisk rådgivning.
Danske tal i denne artikel stammer fra Danmarks Nationalbank, herunder rapporten Oversight of the financial infrastructure 2025, samt FSOR (Finansielt Sektorforum) og Finanstilsynet.
Troels Rendbæk Sørensen - CEO & Founder
