DORA-informationsregister: ISO 27001-vejledning

Klokken er 09:15 en tirsdag. Sarah, CISO i en hurtigt voksende fintech-virksomhed, sidder i en beredskabsøvelse sammen med sin complianceansvarlige, juridiske rådgiver, indkøbsansvarlige og cloudarkitekt. Den eksterne konsulent spiller rollen som repræsentant for DORA-tilsynet.

“Tak for præsentationen,” siger han. “Fremlæg venligst jeres informationsregister som krævet efter DORA Article 28, herunder de kontraktlige IKT-aftaler, der understøtter kritiske eller vigtige funktioner, synlighed over underleverandører, ejerskab af aktiver og bevismateriale for, at registeret vedligeholdes inden for jeres ramme for styring af IKT-risiko.”

Det første svar lyder selvsikkert: “Vi har en leverandørliste.”

Så begynder spørgsmålene.

Hvilke leverandører understøtter betalingsgodkendelse? Hvilke kontrakter indeholder revisionsrettigheder, hændelsesassistance, forpligtelser om datalokation, opsigelsesrettigheder og exit-support? Hvilke SaaS-platforme behandler kunders personoplysninger? Hvilke cloudtjenester understøtter kritiske eller vigtige funktioner? Hvilke underleverandører ligger bag leverandøren af administrerede sikkerhedstjenester? Hvilken intern aktivejer har godkendt afhængigheden? Hvilke risici i ISO/IEC 27001:2022-risikobehandlingsplanen er knyttet til disse udbydere? Hvilke poster i anvendelighedserklæringen (SoA) begrunder kontrollerne?

Klokken 10:30 har teamet åbnet fire regneark, et CMDB-udtræk, en SharePoint-mappe med PDF-kontrakter, en liste over databehandlere, en cloudfaktureringsrapport og et manuelt vedligeholdt SaaS-sporingsark. Ingen af dem stemmer overens.

Det er den praktiske udfordring med DORA-informationsregisteret i 2026. DORA-implementeringen er gået fra “vi har brug for en køreplan” til “vis mig bevismaterialet.” For finansielle virksomheder, IKT-tredjepartsudbydere, CISO’er, interne revisorer og complianceteams er registeret ikke længere en administrativ skabelon. Det er bindevævet mellem IKT-kontrakter, leverandørrisiko, underleverandørkæder, cloudtjenester, IKT-aktiver, kritiske funktioner, styringsejerskab og ISO/IEC 27001:2022-bevismateriale.

Clarysecs tilgang er enkel: Opbyg ikke DORA-informationsregisteret som et særskilt compliance-artefakt. Opbyg det som et levende bevislag i jeres ISMS, understøttet af styring af aktiver, leverandørsikkerhed, styring af brugen af cloudtjenester, kortlægning af juridiske og regulatoriske forpligtelser, revisionsmetadata og sporbarhed til risikobehandling.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls identificerer tre ISO/IEC 27001:2022 Annex A-ankerkontroller som særligt relevante for dette emne: A.5.9, fortegnelse over information og andre tilknyttede aktiver; A.5.19, informationssikkerhed i leverandørrelationer; og A.5.20, håndtering af informationssikkerhed i leverandøraftaler. Disse kontroller er ikke ekstra papirarbejde. De er den operationelle rygrad for at dokumentere, at registeret er fuldstændigt, ejet, aktuelt og egnet til revision.

Hvad DORA forventer af informationsregisteret

DORA finder anvendelse fra 17. januar 2025 og etablerer et regelsæt for IKT-robusthed i den finansielle sektor, der omfatter styring af IKT-risiko, hændelsesrapportering, robusthedstest, tredjepartsrisiko, kontraktlige aftaler, tilsyn med kritiske IKT-tredjepartsudbydere og tilsynsmæssig håndhævelse. For finansielle virksomheder, der også er identificeret under national gennemførelse af NIS2, fungerer DORA som den sektorspecifikke EU-retsakt for tilsvarende krav til styring af cybersikkerhedsrisici og hændelsesrapportering.

Registerforpligtelsen ligger i DORA’s disciplin for styring af IKT-tredjepartsrisiko. DORA Article 28 kræver, at finansielle virksomheder styrer IKT-tredjepartsrisiko som en del af rammen for styring af IKT-risiko, fortsat har det fulde ansvar for efterlevelse, også når de anvender IKT-udbydere, vedligeholder et informationsregister for kontraktlige aftaler om IKT-tjenester og skelner mellem aftaler, der understøtter kritiske eller vigtige funktioner.

DORA Article 29 tilføjer hensyn til koncentrationsrisiko og underleverandørrisiko. Det omfatter substitutionsmulighed, flere afhængigheder af samme eller forbundne udbydere, underleverandører i tredjelande, insolvensmæssige begrænsninger, datagendannelse, efterlevelse af databeskyttelseskrav og lange eller komplekse underleverandørkæder.

DORA Article 30 definerer derefter det kontraktindhold, som revisorer forventer at se. Det omfatter tjenestebeskrivelser, betingelser for underleverandører, lokationer for databehandling, forpligtelser vedrørende databeskyttelse, adgangs- og gendannelsesforpligtelser, serviceniveauer, hændelsessupport, samarbejde med myndigheder, opsigelsesrettigheder, deltagelse i træning, revisionsrettigheder og exit-strategier for aftaler, der understøtter kritiske eller vigtige funktioner.

Et modent DORA-informationsregister skal kunne besvare fire praktiske spørgsmål.

Et svagt register er et regneark, som indkøb opdaterer én gang om året. Et stærkt register er et styret datasæt, der forbinder leverandørportefølje, aktivfortegnelse, cloudregister, kontraktrepository, privatlivsregistreringer, beredskabsplaner (BCP’er), hændelsesplaybooks, risikoregister og ISO/IEC 27001:2022-bevismateriale.

Hvorfor ISO 27001 er den hurtigste vej til et forsvarligt DORA-register

ISO/IEC 27001:2022 giver organisationer den ledelsessystemstruktur, som DORA-bevismateriale ofte mangler. Punkt 4.1 til 4.4 kræver, at organisationen definerer kontekst, interessenter, juridiske, regulatoriske og kontraktlige forpligtelser, omfang, grænseflader og afhængigheder. Det er præcis dér, DORA hører hjemme i ISMS, fordi registeret afhænger af viden om, hvilke finansielle tjenester, IKT-udbydere, kunder, myndigheder, cloudplatforme og outsourcede processer der er inden for omfanget.

Punkt 5.1 til 5.3 kræver lederskab, tilpasning af politikker, ressourcer, ansvar og rapportering til øverste ledelse. Det er vigtigt, fordi DORA Article 5 placerer ansvaret hos ledelsesorganet for at definere, godkende, føre tilsyn med og fortsat stå til ansvar for rammen for styring af IKT-risiko, herunder politikker for IKT-tredjepartsydelser og rapporteringskanaler.

Punkt 6.1.1 til 6.1.3 er dér, registeret bliver risikobaseret. ISO/IEC 27001:2022 kræver en gentagelig risikovurderingsproces, risikoejere, analyse af sandsynlighed og konsekvens, risikobehandling, kontroludvælgelse, en anvendelighedserklæring (SoA) og risikoejerens godkendelse af restrisiko. Et DORA-register, der ikke er knyttet til risikobehandling, bliver en statisk liste. Et register, der er knyttet til risikoscenarier, kontroller og ejere, bliver revisionsbevismateriale.

Punkt 8.1 til 8.3 omsætter derefter planlægning til kontrolleret drift. De understøtter dokumenteret information, operationel planlægning og styring, ændringsstyring, styring af eksternt leverede processer, planlagte risikogenvurderinger, implementering af behandlingstiltag og opbevaring af bevismateriale. Det er kritisk i 2026, fordi tilsynsmyndigheder ikke kun spørger, om et register fandtes på et bestemt tidspunkt. De spørger, om nye kontrakter, ændrede tjenester, nye underleverandører, cloudmigreringer og exit-hændelser indfanges i styringscyklussen.

Kontrollaget i Annex A forstærker samme pointe. Leverandørrelationer, leverandøraftaler, IKT-risici i forsyningskæden, overvågning af leverandørtjenester, anskaffelse og exit for cloudtjenester, hændelsesstyring, forretningskontinuitet, juridiske og regulatoriske forpligtelser, privatliv, backups, logning, overvågning, kryptografi og sårbarhedsstyring bidrager alle til registerets kvalitet.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint forklarer aktivgrundlaget i fasen Controls in Action, Step 22:

I sin mest strategiske form fungerer en aktivfortegnelse som det centrale nervesystem i jeres ISMS. Den informerer, hvordan adgang tildeles (8.2), hvor kryptering skal anvendes (8.24), hvilke systemer der kræver backup (8.13), hvilke logfiler der indsamles (8.15), og endda hvordan klassificerings- og opbevaringspolitikker håndhæves (5.10, 8.10).

Citatet indfanger den praktiske pointe. I kan ikke vedligeholde et pålideligt DORA-informationsregister, medmindre den underliggende aktivfortegnelse er pålidelig. Hvis jeres register siger “Core Banking SaaS”, men jeres aktivfortegnelse ikke viser API’er, servicekonti, datasæt, logkilder, krypteringsnøgler, backupafhængigheder og ejere, er registeret ufuldstændigt fra et revisionsperspektiv.

Clarysecs datamodel: ét register, flere bevisvisninger

Et DORA-informationsregister bør ikke erstatte jeres leverandørregister, aktivregister eller cloudregister. Det bør forbinde dem. Clarysec designer normalt registeret som et overordnet bevislag med kontrollerede relationer til eksisterende ISMS-registreringer.

Den minimale, levedygtige model har syv forbundne objekter.

Denne struktur gør det muligt for ét register at understøtte flere anmodninger om bevismateriale. Et DORA-tilsyn kan se kontraktlige aftaler, der understøtter kritiske eller vigtige funktioner. En ISO-revisor kan spore leverandørkontroller til Annex A-referencer og risikobehandling. En GDPR-gennemgang kan vise databehandlere, datakategorier, lokationer og forpligtelser vedrørende databeskyttelse. En NIST-orienteret vurderingspart kan gennemgå styring af forsyningskæden, leverandørkritikalitet, kontraktkrav og livscyklusovervågning.

Registeret bliver mere end “hvem er vores leverandører?” Det bliver en afhængighedsgraf.

Politikgrundlag, der gør registeret egnet til revision

Clarysecs politiksæt giver registeret et operationelt hjem. For SMV’er starter Third-Party and Supplier Security Policy-sme Politik for tredjeparts- og leverandørsikkerhed - SMV med et klart registerkrav:

Et leverandørregister skal vedligeholdes og opdateres af den administrative kontakt eller indkøbskontakten. Det skal omfatte:

Den samme SMV-politik fastslår, at kontrakter skal indeholde definerede sikkerhedsforpligtelser:

Kontrakter skal indeholde obligatoriske klausuler, der dækker:

Selvom de citerede klausuler introducerer feltlister og kategorier af obligatoriske klausuler i selve politikken, er implementeringsbudskabet direkte: Leverandørstyring skal dokumenteres, tildeles og håndhæves kontraktligt.

For enterprise-miljøer ligger Clarysecs Supplier Dependency Risk Management Policy Politik for risikostyring af leverandørafhængigheder endnu tættere på DORA’s tilsynsforventninger:

Register over leverandørafhængigheder: Leverandørstyringsfunktionen (VMO) skal vedligeholde et ajourført register over alle kritiske leverandører, herunder oplysninger såsom leverede tjenester/produkter; om leverandøren er eneleverandør; tilgængelige alternative leverandører eller substitutionsmulighed; gældende kontraktvilkår; og en vurdering af konsekvensen, hvis leverandøren svigter eller kompromitteres. Registeret skal tydeligt identificere leverandører med høj afhængighed (f.eks. dem, hvor der ikke findes et hurtigt alternativ).

Dette passer direkte til DORA Article 29 om koncentrations- og substitutionsrisiko. Hvis en leverandør er eneleverandør, understøtter en kritisk funktion, opererer i et tredjeland, anvender en lang underleverandørkæde og ikke har en testet exit-vej, bør registeret ikke skjule risikoen i en fritekstnote. Det bør markere den, tildele en ejer og koble den til risikobehandling.

Clarysecs enterprise-Third party and supplier security policy Politik for tredjeparts- og leverandørsikkerhed gør omfanget eksplicit:

Den dækker både direkte leverandører og, hvor relevant, deres underleverandører og omfatter tredjepartssoftware, infrastruktur, support og administrerede tjenester.

Den sætning afdækker et almindeligt DORA-hul. Mange organisationer registrerer direkte IKT-udbydere, men dokumenterer ikke underleverandører, underdatabehandlere, værktøjer til administrerede tjenester, supportplatforme eller tredjepartssoftware indlejret i en tjeneste.

Kontraktbevismateriale er også vigtigt. Den samme enterprise-politik omfatter:

Revisionsrettigheder samt ret til inspektion og til at anmode om sikkerhedsbevismateriale

Den formulering bør være synlig i jeres tjekliste for kontraktgennemgang. Hvis en kontrakt med en kritisk IKT-udbyder mangler revisions- eller bevisrettigheder, bør registeret markere en afhjælpende foranstaltning.

Bevismateriale for aktiver er lige så vigtigt. Clarysecs SMV-Asset Management Policy Politik for styring af aktiver - SMV fastslår:

Den IT-ansvarlige skal vedligeholde en struktureret aktivfortegnelse, der som minimum omfatter følgende felter:

Enterprise-Asset Management Policy Politik for styring af aktiver fastslår tilsvarende:

Aktivfortegnelsen skal som minimum indeholde:

Registeret behøver ikke duplikere hvert aktivfelt, men det skal referere til aktivfortegnelsen. Hvis en betalingsmonitorerings-SaaS understøtter svigdetektion, bør DORA-registeret linke til applikationsaktivet, datasætaktivet, servicekonti, API-integrationer, logkilder og forretningsansvarlig.

Cloudtjenester fortjener en særskilt visning. Clarysecs SMV-Cloud Usage Policy Politik for brug af cloudtjenester - SMV kræver:

Et cloudtjenesteregister skal vedligeholdes af IT-udbyderen eller den daglige leder. Det skal registrere:

Det er særligt værdifuldt til at opdage shadow IT. Et DORA-register, der udelader cloudtjenester købt uden om indkøb, vil fejle den praktiske fuldstændighedstest.

Endelig omsætter Clarysecs Legal and Regulatory Compliance Policy Politik for juridisk og regulatorisk efterlevelse tværgående efterlevelse til et ISMS-krav:

Alle juridiske og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).

Det er broen fra DORA-register til ISO 27001-bevismateriale. Registeret bør ikke kun vise leverandører. Det bør vise, hvilke politikker, kontroller og ejere der opfylder den regulatoriske forpligtelse.

Kortlægning af DORA-krav til ISO 27001 og Clarysec-bevismateriale

Tabellen nedenfor kombinerer de centrale registerforventninger med ISO/IEC 27001:2022 Annex A-kontroller og praktiske Clarysec-bevisartefakter.

Denne kortlægning er dér, hvor registeret holder op med at være et regneark og bliver en bevismodel. Hver række bør have en kontraktejer, leverandørejer, serviceejer, forretningsansvarlig og complianceansvarlig. Hver kritisk relation bør have en risikopost, en tjekliste for kontraktklausuler, et aktivlink og et overvågningsinterval.

Praktisk eksempel: kortlægning af én IKT-kontrakt til ISO 27001-bevismateriale

Forestil dig, at en finansiel virksomhed bruger en cloudbaseret platform til sviganalyse. Tjenesten indtager transaktionsmetadata, understøtter svigscoring i realtid, integreres med betalingsplatformen, lagrer pseudonymiserede kundeidentifikatorer, bruger en cloudhosting-underleverandør og leverer administreret support fra en godkendt tredjelandslokation.

En svag registerrække siger: “Leverandør: FraudCloud. Tjeneste: sviganalyse. Kontrakt underskrevet. Kritisk: ja.”

En registerrække på tilsynsniveau ser meget anderledes ud.

Nu kan complianceteamet fremstille en sammenhængende bevispakke. Leverandørregisteret dokumenterer, at udbyderen findes og har en ejer. Aktivfortegnelsen dokumenterer, at interne systemer, API’er, datasæt og logfiler er kendt. Kontrakttjeklisten dokumenterer, at obligatoriske DORA-klausuler er gennemgået. Risikovurderingen dokumenterer, at koncentration, underleverandører, databeskyttelse og operationel robusthed er vurderet. Anvendelighedserklæringen (SoA) viser, hvilke kontroller der er valgt. Overvågningsgennemgangen dokumenterer, at aftalen ikke glemmes efter onboarding.

Zenith Blueprint, Risk Management-fasen, Step 13, anbefaler præcis denne type sporbarhed:

Krydsreferér reguleringer: Hvis bestemte kontroller er implementeret specifikt for at efterleve GDPR, NIS2 eller DORA, kan I notere det enten i risikoregisteret (som del af begrundelsen for risikokonsekvens) eller i SoA-noterne.

Det er sådan, DORA-registeret bliver ISO 27001-bevismateriale i stedet for parallel bureaukrati.

Leverandør- og underleverandørkæden er dér, registerkvaliteten fejler

De største registerfejl skyldes ikke manglende leverandører på øverste niveau. De skyldes skjulte afhængighedskæder.

En leverandør af administrerede sikkerhedstjenester kan bruge en SIEM-platform, en endpoint-telemetriagent, et helpdesk-sagsstyringssystem og et offshore-triageteam. En betalingsprocessor kan afhænge af cloudhosting, identitetstjenester, svigdatabaser og afviklingsforbindelser. En SaaS-udbyder kan være afhængig af flere underdatabehandlere til analytics, e-mail, observabilitet, kundesupport og backups.

DORA Article 29 tvinger fokus over på koncentrationsrisiko og underleverandørrisiko. NIS2 Article 21 kræver også sikkerhed i forsyningskæden for direkte leverandører og tjenesteudbydere og forventer, at enheder vurderer sårbarheder specifikke for hver direkte leverandør, den samlede produktkvalitet, leverandørers cybersikkerhedspraksis og procedurer for sikker udvikling. For finansielle virksomheder omfattet af DORA fungerer DORA som det sektorspecifikke regelsæt for overlappende NIS2-krav til styring af cybersikkerhedsrisici og hændelsesrapportering, men forsyningskædelogikken er den samme.

Clarysecs Zenith Blueprint, Controls in Action-fasen, Step 23, giver praktisk vejledning:

For hver kritisk leverandør skal I identificere, om de bruger underleverandører (underdatabehandlere), som kan få adgang til jeres data eller systemer. Dokumentér, hvordan jeres informationssikkerhedskrav videreføres til disse parter, enten gennem leverandørens kontraktvilkår eller jeres egne direkte klausuler.

Det er her, mange organisationer har behov for afhjælpning i 2026. Kontrakter indgået før DORA-beredskabet omfatter muligvis ikke gennemsigtighed om underleverandører, rettigheder til revisionsbevismateriale, samarbejde med myndigheder, hændelsesassistance, exit-support eller forpligtelser om lokation. Registeret bør derfor indeholde en status for kontraktafhjælpning, f.eks. fuldført, hul accepteret, genforhandling i gang eller exit-mulighed påkrævet.

Tværgående efterlevelse: DORA, NIS2, GDPR og NIST kræver den samme afhængighedssandhed

Et veldesignet DORA-informationsregister understøtter mere end DORA.

NIS2 Article 20 gør cybersikkerhed til et ansvar for ledelsesorganet gennem godkendelse, tilsyn og træning. Article 21 kræver risikoanalyse, politikker, håndtering af hændelser, kontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og vedligeholdelse, vurdering af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver og MFA, hvor det er relevant. Disse områder overlapper i høj grad med ISO/IEC 27001:2022 og registerets bevismodel.

GDPR tilføjer ansvarlighed for databeskyttelse. Dets territoriale anvendelsesområde kan omfatte organisationer i og uden for EU, der behandler personoplysninger i forbindelse med EU-etableringer, tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. GDPR-definitionerne af dataansvarlig, databehandler, behandling, pseudonymisering og brud på persondatasikkerheden er direkte relevante for kortlægning af IKT-leverandører. Hvis DORA-registeret identificerer IKT-udbydere og underleverandører, men ikke identificerer roller ved behandling af personoplysninger, datakategorier, lokationer og sikkerhedsforanstaltninger, understøtter det ikke GDPR-bevismateriale.

NIST CSF 2.0 giver en anden nyttig vinkel. GOVERN-funktionen kræver, at organisationer forstår mission, interessentforventninger, afhængigheder, juridiske og kontraktlige krav, tjenester som andre afhænger af, og tjenester som organisationen afhænger af. GV.SC-resultaterne for forsyningskæden kræver et program for risikostyring i forsyningskæden, definerede leverandørroller, integration i enterprise risk management, leverandørkritikalitet, kontraktkrav, due diligence, livscyklusovervågning, hændelseskoordinering og planlægning efter ophør af relationen.

En praktisk visning for tværgående efterlevelse ser sådan ud.

Pointen er ikke at skabe fem compliance-arbejdsgange. Pointen er at skabe én bevismodel, der kan filtreres for hvert framework.

Set med revisors øjne

Et DORA-tilsyn vil fokusere på fuldstændighed, kritiske eller vigtige funktioner, kontraktlige aftaler, underleverandører, koncentrationsrisiko, styring, rapportering og om registeret vedligeholdes. Tilsynet kan bede om en stikprøve af kritiske udbydere og forvente at se kontraktklausuler, risikovurderinger, exit-strategier, hændelsessupportvilkår og bevismateriale for ledelsesmæssigt tilsyn.

En ISO/IEC 27001:2022-revisor vil begynde med ISMS-omfang, interessenter, regulatoriske forpligtelser, risikovurdering, anvendelighedserklæring (SoA), operationel styring og dokumenteret information. Revisoren vil teste, om leverandørrelationer og aktivfortegnelser vedligeholdes, om eksternt leverede processer styres, om ændringer udløser genvurdering, og om bevismaterialet understøtter den påståede kontrolimplementering.

En NIST CSF 2.0-vurderingspart vil ofte bede om aktuelle profiler og målprofiler, styringsforventninger, afhængighedskortlægning, leverandørkritikalitet, kontraktintegration, livscyklusovervågning og prioriterede forbedringstiltag.

En COBIT 2019-orienteret revisor vil typisk undersøge styringsejerskab, procesansvarlighed, beslutningsrettigheder, performanceovervågning, risikorapportering og assurance. Revisoren vil spørge, om registeret er indlejret i virksomhedsstyring, ikke blot vedligeholdt af compliance.

Zenith Controls hjælper med at oversætte disse perspektiver ved at forankre emnet i ISO/IEC 27001:2022 Annex A-kontrollerne A.5.9, A.5.19 og A.5.20 og derefter bruge fortolkning for tværgående efterlevelse til at forbinde aktiver, leverandørrelationer og leverandøraftaler med regulatoriske, styringsmæssige og revisionsmæssige forventninger. Det er forskellen mellem “vi har et register” og “vi kan forsvare registeret.”

Clarysecs SMV-Audit and Compliance Monitoring Policy Politik for revision og overvågning af efterlevelse - SMV adresserer også kvaliteten af bevismateriale:

Metadata (f.eks. hvem der indsamlede det, hvornår og fra hvilket system) skal dokumenteres.

Det krav er lille, men stærkt. I en anmodning om bevismateriale i 2026 er et regneark uden indsamlingsmetadata svagt. Et registerudtræk, der viser kildesystem, udtræksdato, ansvarlig ejer, godkendelsesstatus og gennemgangsinterval, er stærkere.

Almindelige konstateringer om DORA-informationsregisteret i 2026

De hyppigste konstateringer er praktiske.

For det første: ufuldstændigt register. Cloudtjenester, supportværktøjer, overvågningsplatforme, udviklerværktøjer, helpdesk-sagsstyringssystemer og dataanalyseplatforme mangler ofte, fordi de ikke er klassificeret som IKT-tjenester af indkøb.

For det andet: svag kritikalitetslogik. Nogle teams markerer leverandører som kritiske ud fra forbrug, ikke forretningspåvirkning. DORA fokuserer på, om IKT-tjenesten understøtter en kritisk eller vigtig funktion.

For det tredje: huller i kontraktbevismateriale. Ældre leverandøraftaler mangler ofte DORA-klare klausuler om revisionsrettigheder, hændelsesassistance, underleverandører, samarbejde med myndigheder, tjenestelokationer, tilbagelevering af data, opsigelse og exit-support.

For det fjerde: svag aktivkobling. Registre angiver leverandører, men linker ikke til applikationer, datasæt, API’er, identiteter, logfiler, infrastruktur eller forretningstjenester. Det gør konsekvensanalyse vanskelig under hændelser og leverandørsvigt.

For det femte: uklarhed om underleverandører. Organisationen kender hovedudbyderen, men kan ikke forklare, hvilke underdatabehandlere eller tekniske udbydere der understøtter tjenesten.

For det sjette: ingen ændringsudløsere. En udbyder tilføjer en ny underdatabehandler, ændrer hostingregion, migrerer arkitektur eller ændrer supportadgang, men ingen opdaterer registeret eller genvurderer risikoen.

For det syvende: ingen beviskadence. Der er ingen defineret frekvens for leverandørgennemgang, kontraktgennemgang, adgangsvalidering af aktiver, afstemning af cloudregister eller ledelsesrapportering.

Disse problemer kan løses, men kun hvis registeret har ejere og arbejdsgange.

En praktisk 30-dages forbedringsplan

Start med omfanget. Identificér alle forretningsfunktioner, der kan være kritiske eller vigtige under DORA. For hver funktion skal I liste de IKT-tjenester, den afhænger af. Begynd ikke med indkøbsforbrug. Begynd med driftsmæssig afhængighed.

Afstem de centrale datakilder: leverandørregister, kontraktrepository, aktivfortegnelse og cloudtjenesteregister. Tilføj registreringer over databehandlere og afhængigheder i hændelseshåndtering, hvor det er relevant. Målet er ikke perfektion på dag ét. Målet er en samlet registerrygrad, hvor ukendte forhold er tydeligt markeret.

Klassificér leverandører og tjenester ud fra kriterier såsom understøttet funktion, datafølsomhed, operationel substitutionsmulighed, koncentration, underleverandører, lokationer, hændelseskonsekvens, genopretningstid og regulatorisk relevans.

Gennemgå kontrakter for hver kritisk eller vigtig IKT-aftale. Kontroller, om kontrakten omfatter tjenestebeskrivelser, betingelser for underleverandører, lokationer, forpligtelser vedrørende databeskyttelse, adgang og gendannelse, serviceniveauer, hændelsessupport, revisionsrettigheder, samarbejde med myndigheder, opsigelse, deltagelse i træning og exit-support.

Kortlæg ISO-bevismateriale for hver kritisk aftale. Link til aktivregistreringer, risikovurderingsposter, SoA-kontroller, leverandør-due diligence, overvågningsgennemgange, kontinuitetsplaner, hændelsesplaybooks og bevismateriale for exit-strategi.

Tildel kadence. Kritiske udbydere kan kræve kvartalsvis gennemgang, årlig assurance, kontraktgennemgang før fornyelse og øjeblikkelig genvurdering ved væsentlig ændring. Ikke-kritiske udbydere kan gennemgås årligt eller ved udløsende hændelser.

Brug denne tjekliste til at gøre registeret til en driftsproces:

• Opret en DORA-registerejer og en stedfortrædende ejer.
• Link hver registerrække til et kontrakt-id og en leverandørejer.
• Link hver kritisk eller vigtig IKT-tjeneste til forretningsfunktion og aktivregistreringer.
• Tilføj felter for underleverandører og underdatabehandlere, også hvis de indledningsvist markeres som ukendte.
• Tilføj kontraktklausulstatus for DORA-kritiske vilkår.
• Tilføj ISO/IEC 27001:2022-risiko- og SoA-referencer.
• Tilføj GDPR-rolle, personoplysninger og lokationsfelter, hvor det er relevant.
• Tilføj gennemgangsinterval og metadata for seneste gennemgang.
• Opret eskaleringsregler for manglende klausuler, ukendte underleverandører og høj koncentrationsrisiko.
• Rapportér kvalitetsmetrikker for registeret til ledelsen.

Det er her, Clarysecs 30-trins implementeringsmetode, politiksæt og Zenith Controls arbejder sammen. Zenith Blueprint giver implementeringsvejen, fra risikobehandling og SoA-sporbarhed i Step 13 til aktivfortegnelse i Step 22 og leverandørkontroller i Step 23. Politikkerne definerer, hvem der skal vedligeholde registre, hvilket kontrakt- og aktivbevismateriale der skal findes, og hvordan metadata om efterlevelse indsamles. Zenith Controls giver kompasset for tværgående efterlevelse til at kortlægge det samme bevismateriale på tværs af DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST og COBIT 19-revisionsforventninger.

Gør registeret til bevismateriale, før tilsynsmyndigheden spørger

Hvis jeres DORA-informationsregister stadig er et regneark uden forbindelse til kontrakter, aktiver, leverandører, underleverandører og ISO 27001-bevismateriale, er 2026 året, hvor det skal rettes.

Start med at bruge Zenith Blueprint Zenith Blueprint til at forbinde risikobehandling, aktivfortegnelse og leverandørstyring. Brug Zenith Controls Zenith Controls til at kortlægge ISO/IEC 27001:2022 Annex A-kontrollerne A.5.9, A.5.19 og A.5.20 til bevismateriale for tværgående efterlevelse. Operationalisér derefter kravene gennem Clarysecs politikker for leverandører, aktiver, cloud, juridisk efterlevelse og revisionsovervågning, herunder Politik for tredjeparts- og leverandørsikkerhed - SMV, Politik for risikostyring af leverandørafhængigheder, Politik for tredjeparts- og leverandørsikkerhed, Politik for styring af aktiver - SMV, Politik for styring af aktiver, Politik for brug af cloudtjenester - SMV, Politik for juridisk og regulatorisk efterlevelse og Politik for revision og overvågning af efterlevelse - SMV.

Det bedste tidspunkt at forbedre registerkvaliteten er før en myndighedsanmodning, intern revision, leverandørnedbrud eller kontraktfornyelse. Det næstbedste tidspunkt er nu. Download de relevante Clarysec-politikker, kortlæg jeres nuværende register mod bevismodellen ovenfor, og book en DORA-registervurdering for at omsætte spredte leverandørdata til bevismateriale på tilsynsniveau.