DORA-informationsregister: ISO 27001-guide

Klockan är 09.15 en tisdag. Sarah, informationssäkerhetschef på ett snabbväxande fintechbolag, sitter i en beredskapsbedömning tillsammans med sin chef för regelefterlevnad, juridiska rådgivare, upphandlingsansvariga och molnarkitekt. Den externa konsulten spelar rollen som DORA-tillsynsmyndighet.

”Tack för presentationen”, säger han. ”Vänligen tillhandahåll ert informationsregister enligt DORA artikel 28, inklusive de IKT-avtalsarrangemang som stödjer kritiska eller viktiga funktioner, insyn i underleverantörsledet, ägarskap för tillgångar och underlag som visar att registret förvaltas inom ert ramverk för IKT-riskhantering.”

Det första svaret låter självsäkert: ”Vi har en leverantörslista.”

Sedan börjar frågorna.

Vilka leverantörer stödjer auktorisering av betalningar? Vilka avtal innehåller revisionsrätt, incidentstöd, åtaganden om datalagringsplats, uppsägningsrätt och exitstöd? Vilka SaaS-plattformar behandlar kunders personuppgifter? Vilka molntjänster stödjer kritiska eller viktiga funktioner? Vilka underleverantörer ligger bakom den hanterade säkerhetsleverantören? Vilken intern tillgångsägare har godkänt beroendet? Vilka risker i riskbehandlingsplanen enligt ISO/IEC 27001:2022 är kopplade till dessa leverantörer? Vilka poster i tillämpbarhetsförklaringen motiverar kontrollerna?

Klockan 10.30 har teamet öppnat fyra kalkylblad, en CMDB-export, en SharePoint-mapp med PDF-avtal, en lista över personuppgiftsbiträden, en faktureringsrapport för molntjänster och en manuellt underhållen SaaS-förteckning. Inget av underlagen stämmer överens.

Det är den praktiska utmaningen med DORA-informationsregistret 2026. Genomförandet av DORA har gått från ”vi behöver en färdplan” till ”visa underlaget”. För finansiella entiteter, IKT-tredjepartstjänsteleverantörer, CISO:er, internrevisorer och regelefterlevnadsteam är registret inte längre en administrativ mall. Det är den sammanhållande väven mellan IKT-avtal, leverantörsrisk, underleverantörskedjor, molntjänster, IKT-tillgångar, kritiska funktioner, styrningsansvar och underlag enligt ISO/IEC 27001:2022.

Clarysecs tillvägagångssätt är enkelt: bygg inte DORA-informationsregistret som en separat efterlevnadsartefakt. Bygg det som ett levande underlagslager i ert ISMS, med stöd av tillgångshantering, leverantörssäkerhet, styrning av molnanvändning, mappning av rättsliga och regulatoriska skyldigheter, revisionsmetadata och spårbarhet till riskbehandling.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls identifierar tre ankarkontroller i ISO/IEC 27001:2022 bilaga A som är särskilt relevanta för detta område: A.5.9, förteckning över information och andra tillhörande tillgångar; A.5.19, informationssäkerhet i leverantörsrelationer; och A.5.20, hantering av informationssäkerhet i leverantörsavtal. Dessa kontroller är inte extra pappersarbete. De är den operativa ryggraden för att visa att registret är fullständigt, ägt, aktuellt och granskningsbart.

Vad DORA förväntar sig av informationsregistret

DORA gäller från den 17 januari 2025 och skapar ett regelverk för IKT-resiliens i finanssektorn, med krav på IKT-riskhantering, incidentrapportering, resiliensprovning, tredjepartsrisk, avtalsarrangemang, tillsyn över kritiska IKT-tredjepartsleverantörer och tillsynsåtgärder. För finansiella entiteter som även omfattas av nationellt införlivande av NIS2 fungerar DORA som den sektorsspecifika unionsrättsakten för motsvarande krav på cybersäkerhetsriskhantering och incidentrapportering.

Registerkravet ingår i DORA:s disciplin för hantering av IKT-tredjepartsrisk. DORA artikel 28 kräver att finansiella entiteter hanterar IKT-tredjepartsrisk som en del av ramverket för IKT-riskhantering, fortsatt bär fullt ansvar för efterlevnad även när IKT-leverantörer används, för ett informationsregister över avtalsarrangemang avseende IKT-tjänster och särskiljer arrangemang som stödjer kritiska eller viktiga funktioner.

DORA artikel 29 lägger till överväganden om koncentrationsrisk och underleverantörsrisk. Detta omfattar utbytbarhet, flera beroenden till samma eller närstående leverantörer, underleverantörer i tredjeland, insolvensbegränsningar, dataåterställning, efterlevnad av dataskyddskrav och långa eller komplexa underleverantörskedjor.

DORA artikel 30 definierar därefter det avtalsinnehåll som revisorer förväntar sig att se. Det omfattar tjänstebeskrivningar, villkor för underleverantörer, platser för databehandling, dataskyddsåtaganden, åtkomst- och återställningsskyldigheter, servicenivåer, incidentstöd, samarbete med myndigheter, uppsägningsrätt, deltagande i utbildning, revisionsrätt och exitstrategier för arrangemang som stödjer kritiska eller viktiga funktioner.

Ett moget DORA-informationsregister måste besvara fyra praktiska frågor.

Ett svagt register är ett kalkylblad som upphandling uppdaterar en gång per år. Ett starkt register är ett styrt dataset som kopplar samman leverantörsportfölj, tillgångsförteckning, molnregister, avtalsarkiv, integritetsregister, kontinuitetsplaner, incidentåtgärdsplaner, riskregister och underlag enligt ISO/IEC 27001:2022.

Varför ISO 27001 är den snabbaste vägen till ett försvarbart DORA-register

ISO/IEC 27001:2022 ger organisationer den ledningssystemstruktur som DORA-underlag ofta saknar. Klausulerna 4.1 till 4.4 kräver att organisationen definierar sammanhang, intressenter, rättsliga, regulatoriska och avtalsmässiga skyldigheter, omfattning, gränssnitt och beroenden. Det är precis här DORA hör hemma i ISMS, eftersom registret förutsätter kunskap om vilka finansiella tjänster, IKT-leverantörer, kunder, myndigheter, molnplattformar och outsourcade processer som ingår i omfattningen.

Klausulerna 5.1 till 5.3 kräver ledarskap, policyanpassning, resurser, ansvar och rapportering till högsta ledningen. Det är relevant eftersom DORA artikel 5 lägger ansvaret på ledningsorganet att definiera, godkänna, övervaka och fortsatt ansvara för ramverket för IKT-riskhantering, inklusive policyer för IKT-tredjepartstjänster och rapporteringskanaler.

Klausulerna 6.1.1 till 6.1.3 är där registret blir riskbaserat. ISO/IEC 27001:2022 kräver en repeterbar riskbedömning, riskägare, analys av sannolikhet och konsekvens, riskbehandling, kontrollval, en tillämpbarhetsförklaring och riskägarens godkännande av kvarstående risk. Ett DORA-register som inte är kopplat till riskbehandling blir en statisk lista. Ett register som är kopplat till riskscenarier, kontroller och ägare blir revisionsbevis.

Klausulerna 8.1 till 8.3 omvandlar därefter planering till styrd verksamhet. De stödjer dokumenterad information, operativ planering och styrning, ändringsstyrning, styrning av externt tillhandahållna processer, planerade omprövningar av risk, genomförande av riskbehandling och bevarande av underlag. Detta är kritiskt inför 2026, eftersom tillsynsmyndigheter inte bara frågar om ett register fanns vid en viss tidpunkt. De frågar om nya avtal, ändrade tjänster, nya underleverantörer, molnmigreringar och exithändelser fångas i styrningscykeln.

Kontrollagret i bilaga A förstärker samma poäng. Leverantörsrelationer, leverantörsavtal, risk i IKT-leveranskedjan, övervakning av leverantörstjänster, anskaffning och avveckling av molntjänster, incidenthantering, verksamhetskontinuitet, rättsliga och regulatoriska skyldigheter, integritet, säkerhetskopiering, loggning, övervakning, kryptografi och sårbarhetshantering bidrar alla till registrets kvalitet.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint förklarar tillgångsgrunden i fasen Controls in Action, steg 22:

I sin mest strategiska form fungerar en tillgångsförteckning som det centrala nervsystemet i ert ISMS. Den styr hur åtkomst tilldelas (8.2), var kryptering måste tillämpas (8.24), vilka system som kräver säkerhetskopiering (8.13), vilka loggar som samlas in (8.15) och till och med hur policyer för klassificering och bevarande tillämpas (5.10, 8.10).

Citatet fångar den praktiska poängen. Det går inte att föra ett tillförlitligt DORA-informationsregister om den underliggande tillgångsförteckningen inte är tillförlitlig. Om registret anger ”SaaS för kärnbankssystem”, men tillgångsförteckningen inte visar API:er, tjänstekonton, dataset, loggkällor, krypteringsnycklar, säkerhetskopieringsberoenden och ägare, är registret ofullständigt ur revisionsperspektiv.

Clarysecs datamodell: ett register, flera underlagsvyer

Ett DORA-informationsregister bör inte ersätta leverantörsregister, tillgångsregister eller molnregister. Det bör sammanföra dem. Clarysec utformar normalt registret som ett övergripande underlagslager med styrda relationer till befintliga ISMS-poster.

Den minsta fungerande modellen har sju länkade objekt.

Denna struktur gör att ett register kan stödja flera typer av underlagsbegäranden. En DORA-tillsynsmyndighet kan se avtalsarrangemang som stödjer kritiska eller viktiga funktioner. En ISO-revisor kan spåra leverantörskontroller till referenser i bilaga A och riskbehandling. En GDPR-granskare kan se personuppgiftsbiträden, datakategorier, platser och dataskyddsåtaganden. En NIST-inriktad bedömare kan granska leveranskedjestyrning, leverantörskritikalitet, avtalskrav och livscykelövervakning.

Registret blir mer än ”vilka är våra leverantörer?” Det blir en beroendegraf.

Policygrunder som gör registret granskningsbart

Clarysecs policypaket ger registret ett operativt hem. För små och medelstora företag börjar policy för leverantörssäkerhet och tredjepartssäkerhet – SME policy för leverantörssäkerhet och tredjepartssäkerhet – SME med ett tydligt registerkrav:

Ett leverantörsregister ska underhållas och uppdateras av den administrativa kontakten eller upphandlingskontakten. Det ska innehålla:

Samma SME-policy fastställer att avtal ska innehålla definierade säkerhetsskyldigheter:

Avtal ska innehålla obligatoriska klausuler som omfattar:

Även om de citerade klausulerna i själva policyn introducerar fältlistor och kategorier av obligatoriska klausuler är budskapet för genomförandet tydligt: leverantörsstyrning ska dokumenteras, ansvar ska tilldelas och kraven ska göras bindande genom avtal.

För större organisationer ligger Clarysecs Policy för hantering av risker kopplade till leverantörsberoenden Policy för hantering av risker kopplade till leverantörsberoenden ännu närmare DORA:s tillsynsförväntningar:

Leverantörsberoenderegister: VMO ska underhålla ett aktuellt register över alla kritiska leverantörer, inklusive uppgifter om tillhandahållna tjänster/produkter; om leverantören är enda källa; tillgängliga alternativa leverantörer eller utbytbarhet; aktuella avtalsvillkor; samt en bedömning av påverkan om leverantören skulle fallera eller bli komprometterad. Registret ska tydligt identifiera leverantörer med högt beroende (t.ex. sådana där inget snabbt alternativ finns).

Detta mappar tydligt mot DORA artikel 29 avseende koncentrationsrisk och utbytbarhet. Om en leverantör är enda källa, stödjer en kritisk funktion, verkar i ett tredjeland, använder en lång underleverantörskedja och saknar en testad exitväg, ska registret inte gömma den risken i en fritextanteckning. Det ska flagga risken, tilldela en ägare och koppla den till riskbehandling.

Clarysecs enterprise-version av policy för leverantörssäkerhet och tredjepartssäkerhet policy för leverantörssäkerhet och tredjepartssäkerhet gör omfattningen tydlig:

Den omfattar både direkta leverantörer och, där det är tillämpligt, deras underleverantörer, och omfattar tredjepartsprogramvara, infrastruktur, support och hanterade tjänster.

Den meningen motsvarar en vanlig DORA-lucka. Många organisationer fångar direkta IKT-leverantörer men dokumenterar inte underleverantörer, underbiträden, verktyg för hanterade tjänster, supportplattformar eller tredjepartsprogramvara som är inbäddad i en tjänst.

Avtalsunderlag är också viktigt. Samma enterprise-policy omfattar:

Revisionsrätt, rätt att inspektera och rätt att begära säkerhetsunderlag

Den formuleringen bör vara synlig i checklistan för avtalsgranskning. Om ett avtal med en kritisk IKT-leverantör saknar revisionsrätt eller rätt att begära underlag ska registret markera en avhjälpande åtgärd.

Underlag för tillgångar är lika viktigt. Clarysecs SME-version av policy för tillgångshantering policy för tillgångshantering – SME anger:

IT-ansvarig ska underhålla en strukturerad tillgångsförteckning som minst innehåller följande fält:

Enterprise-versionen av policy för tillgångshantering policy för tillgångshantering anger på motsvarande sätt:

Tillgångsförteckningen ska minst innehålla:

Registret behöver inte duplicera varje tillgångsfält, men det måste referera till tillgångsförteckningen. Om en SaaS-tjänst för betalningsövervakning stödjer bedrägeridetektering bör DORA-registret länka till applikationstillgången, datasettillgången, tjänstekonton, API-integrationer, loggkällor och verksamhetsägare.

Molntjänster förtjänar en särskild vy. Clarysecs SME-version av Policy för användning av molntjänster Policy för användning av molntjänster – SME kräver:

Ett register över molntjänster ska underhållas av IT-leverantören eller verkställande chef. Det ska registrera:

Detta är särskilt värdefullt för upptäckt av skugg-IT. Ett DORA-register som exkluderar molntjänster som köpts utanför upphandling kommer att falla på det praktiska fullständighetstestet.

Slutligen gör Clarysecs Policy för rättslig och regulatorisk efterlevnad Policy för rättslig och regulatorisk efterlevnad samordnad regelefterlevnad till ett ISMS-krav:

Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.

Det är bryggan från DORA-register till ISO 27001-underlag. Registret ska inte bara visa leverantörer. Det ska visa vilka policyer, kontroller och ägare som uppfyller den regulatoriska skyldigheten.

Mappning av DORA-krav till ISO 27001 och Clarysec-underlag

Tabellen nedan sammanför de viktigaste registerförväntningarna med kontroller i ISO/IEC 27001:2022 bilaga A och praktiska Clarysec-underlag.

Denna mappning är där registret upphör att vara ett kalkylblad och blir en underlagsmodell. Varje rad bör ha en avtalsägare, leverantörsägare, tjänsteägare, verksamhetsägare och ägare för regelefterlevnad. Varje kritisk relation bör ha en riskpost, en checklista för avtalsklausuler, en tillgångslänk och en övervakningsfrekvens.

Praktiskt exempel: mappning av ett IKT-avtal till ISO 27001-underlag

Föreställ dig att en finansiell entitet använder en molnbaserad plattform för bedrägerianalys. Tjänsten tar in transaktionsmetadata, stödjer bedrägeripoängsättning i realtid, integrerar med betalningsplattformen, lagrar pseudonymiserade kundidentifierare, använder en underleverantör för molndrift och tillhandahåller hanterad support från en godkänd plats i tredjeland.

En svag registerrad säger: ”Leverantör: FraudCloud. Tjänst: Bedrägerianalys. Avtal signerat. Kritisk: ja.”

En registerrad på tillsynsnivå ser helt annorlunda ut.

Nu kan regelefterlevnadsteamet ta fram ett sammanhängande underlagspaket. Leverantörsregistret visar att leverantören finns och har en ägare. Tillgångsförteckningen visar att interna system, API:er, dataset och loggar är kända. Avtalschecklistan visar att obligatoriska DORA-klausuler har granskats. Riskbedömningen visar att koncentration, underleverantörer, dataskydd och operativ resiliens har beaktats. Tillämpbarhetsförklaringen visar vilka kontroller som har valts. Övervakningsgranskningen visar att arrangemanget inte glöms bort efter introduktion.

Zenith Blueprint, fasen Risk Management, steg 13, rekommenderar just den typen av spårbarhet:

Korsreferera regelverk: Om vissa kontroller införs specifikt för att följa GDPR, NIS2 eller DORA kan du notera detta antingen i riskregistret (som en del av motiveringen av riskpåverkan) eller i SoA-anteckningarna.

Det är så DORA-registret blir ISO 27001-underlag i stället för parallell byråkrati.

Leverantörs- och underleverantörskedjan är där registerkvaliteten fallerar

De största registerbristerna beror inte på att leverantörer på högsta nivån saknas. De beror på dolda beroendekedjor.

En hanterad säkerhetsleverantör kan använda en SIEM-plattform, en agent för slutpunktstelemetri, ett ärendehanteringssystem och ett offshoreteam för triagering. En betalningsförmedlare kan vara beroende av molndrift, identitetstjänster, bedrägeridatabaser och avvecklingsanslutningar. En SaaS-leverantör kan förlita sig på flera underbiträden för analys, e-post, observerbarhet, kundsupport och säkerhetskopiering.

DORA artikel 29 riktar fokus mot koncentrationsrisk och underleverantörsrisk. NIS2 artikel 21 kräver också säkerhet i leveranskedjan för direkta leverantörer och tjänsteleverantörer och förväntar sig att entiteter beaktar sårbarheter som är specifika för varje direkt leverantör, övergripande produktkvalitet, leverantörers cybersäkerhetspraxis och rutiner för säker utveckling. För finansiella entiteter som omfattas av DORA fungerar DORA som det sektorsspecifika regelverket för överlappande NIS2-krav på cybersäkerhetsriskhantering och incidentrapportering, men logiken för leveranskedjan är samordnad.

Clarysecs Zenith Blueprint, fasen Controls in Action, steg 23, ger praktisk vägledning:

För varje kritisk leverantör ska ni identifiera om de använder underleverantörer (underbiträden) som kan få åtkomst till era data eller system. Dokumentera hur era informationssäkerhetskrav vidareförs till dessa parter, antingen genom leverantörens avtalsvillkor eller genom era egna direkta klausuler.

Det är här många organisationer behöver åtgärda brister under 2026. Avtal som signerades före DORA-beredskapen kanske inte innehåller transparens om underleverantörer, rätt att begära revisionsunderlag, samarbete med myndigheter, incidentstöd, exitstöd eller åtaganden om plats. Registret bör därför innehålla en status för avtalsåtgärdande, exempelvis slutförd, lucka accepterad, omförhandling pågår eller exitalternativ krävs.

Samordnad regelefterlevnad: DORA, NIS2, GDPR och NIST behöver samma beroendesanning

Ett väl utformat DORA-informationsregister stödjer mer än DORA.

NIS2 artikel 20 gör cybersäkerhet till ett ansvar för ledningsorganet genom godkännande, tillsyn och utbildning. Artikel 21 kräver riskanalys, policyer, incidenthantering, kontinuitet, säkerhet i leveranskedjan, säker anskaffning och säkert underhåll, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och MFA där det är lämpligt. Dessa områden överlappar starkt med ISO/IEC 27001:2022 och registermodellen för underlag.

GDPR lägger till ansvarsskyldighet för dataskydd. Dess territoriella tillämpningsområde kan omfatta organisationer inom och utanför EU som behandlar personuppgifter inom ramen för etableringar i EU, erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende. GDPR:s definitioner av personuppgiftsansvarig, personuppgiftsbiträde, behandling, pseudonymisering och personuppgiftsincident är direkt relevanta för mappning av IKT-leverantörer. Om DORA-registret identifierar IKT-leverantörer och underleverantörer men inte identifierar roller vid behandling av personuppgifter, datakategorier, platser och skyddsåtgärder, kommer det inte att stödja GDPR-underlag.

NIST CSF 2.0 ger ytterligare ett användbart perspektiv. Funktionen GOVERN kräver att organisationer förstår uppdrag, intressentförväntningar, beroenden, rättsliga och avtalsmässiga krav, tjänster som andra är beroende av och tjänster som organisationen är beroende av. Resultaten för leveranskedjan i GV.SC kräver ett program för riskhantering i leveranskedjan, definierade leverantörsroller, integration i organisationens riskhantering, leverantörskritikalitet, avtalskrav, leverantörsgranskning, livscykelövervakning, incidentsamordning och planering efter avslutad relation.

En praktisk vy för samordnad regelefterlevnad ser ut så här.

Poängen är inte att skapa fem arbetsflöden för regelefterlevnad. Poängen är att skapa en underlagsmodell som kan filtreras för respektive ramverk.

Genom revisorns ögon

En DORA-tillsynsmyndighet kommer att fokusera på fullständighet, kritiska eller viktiga funktioner, avtalsarrangemang, underleverantörer, koncentrationsrisk, styrning, rapportering och om registret förvaltas löpande. Myndigheten kan begära ett urval av kritiska leverantörer och förvänta sig att se avtalsklausuler, riskbedömningar, exitstrategier, villkor för incidentstöd och underlag för ledningens tillsyn.

En ISO/IEC 27001:2022-revisor börjar med ISMS-omfattning, intressenter, regulatoriska skyldigheter, riskbedömning, tillämpbarhetsförklaring, operativ styrning och dokumenterad information. Revisorn kommer att testa om leverantörsrelationer och tillgångsförteckningar förvaltas, om externt tillhandahållna processer styrs, om ändringar utlöser omprövning och om underlag stödjer det påstådda genomförandet av kontroller.

En NIST CSF 2.0-bedömare frågar ofta efter aktuella profiler och målprofiler, styrningsförväntningar, beroendekartläggning, leverantörskritikalitet, avtalsintegration, livscykelövervakning och prioriterade förbättringsåtgärder.

En COBIT 2019-inriktad revisor undersöker normalt styrningsägarskap, processansvar, beslutsrättigheter, prestandaövervakning, riskrapportering och säkerhetsförsäkran. Revisorn kommer att fråga om registret är inbäddat i företagsstyrningen, inte bara underhållet av regelefterlevnad.

Zenith Controls hjälper till att översätta dessa perspektiv genom att förankra området i ISO/IEC 27001:2022 bilaga A-kontrollerna A.5.9, A.5.19 och A.5.20 och därefter använda tolkning för samordnad regelefterlevnad för att koppla tillgångar, leverantörsrelationer och leverantörsavtal till regulatoriska förväntningar, styrningsförväntningar och revisionsförväntningar. Det är skillnaden mellan ”vi har ett register” och ”vi kan försvara registret”.

Clarysecs SME-version av Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning – SME hanterar också underlagskvalitet:

Metadata (t.ex. vem som samlade in det, när och från vilket system) ska dokumenteras.

Det kravet är litet men kraftfullt. Vid en underlagsbegäran 2026 är ett kalkylblad utan insamlingsmetadata svagt. En registerexport som visar källsystem, extraktionsdatum, ansvarig ägare, godkännandestatus och granskningsfrekvens är starkare.

Vanliga iakttagelser om DORA-informationsregister under 2026

De vanligaste iakttagelserna är praktiska.

För det första: ofullständigt register. Molntjänster, supportverktyg, övervakningsplattformar, utvecklarverktyg, ärendehanteringssystem och dataanalysplattformar saknas ofta eftersom de inte klassificerades som IKT-tjänster av upphandling.

För det andra: svag kritikalitetslogik. Vissa team markerar leverantörer som kritiska baserat på kostnad, inte verksamhetspåverkan. DORA fokuserar på om IKT-tjänsten stödjer en kritisk eller viktig funktion.

För det tredje: luckor i avtalsunderlag. Äldre leverantörsavtal saknar ofta DORA-anpassade klausuler för revisionsrätt, incidentstöd, underleverantörer, samarbete med myndigheter, tjänsteplatser, återlämning av data, uppsägning och exitstöd.

För det fjärde: svag tillgångskoppling. Register listar leverantörer men länkar inte till applikationer, dataset, API:er, identiteter, loggar, infrastruktur eller verksamhetstjänster. Det gör konsekvensanalys svår vid incidenter och leverantörsstörningar.

För det femte: bristande insyn i underleverantörer. Organisationen känner till huvudleverantören men kan inte förklara vilka underbiträden eller tekniska leverantörer som stödjer tjänsten.

För det sjätte: inga ändringstriggers. En leverantör lägger till ett nytt underbiträde, ändrar driftregion, migrerar arkitektur eller ändrar supportåtkomst, men ingen uppdaterar registret eller omprövar risken.

För det sjunde: ingen fastställd frekvens för underlag. Det finns ingen definierad frekvens för leverantörsgranskning, avtalsgranskning, åtkomstvalidering av tillgångar, avstämning av molnregister eller ledningsrapportering.

Dessa problem går att lösa, men bara om registret har ägare och arbetsflöden.

En praktisk 30-dagars förbättringsplan

Börja med omfattningen. Identifiera alla verksamhetsfunktioner som kan vara kritiska eller viktiga enligt DORA. Lista de IKT-tjänster som varje funktion är beroende av. Börja inte med upphandlingskostnad. Börja med operativt beroende.

Stäm av de centrala datakällorna: leverantörsregister, avtalsarkiv, tillgångsförteckning och register över molntjänster. Lägg till register över personuppgiftsbiträden och incidentresponsberoenden där det är relevant. Målet är inte perfektion dag ett. Målet är en gemensam registerstomme där okända uppgifter markeras tydligt.

Klassificera leverantörer och tjänster med kriterier som stödd funktion, datakänslighet, operativ utbytbarhet, koncentration, underleverantörer, platser, incidentpåverkan, återställningstid och regulatorisk relevans.

Granska avtal för varje kritiskt eller viktigt IKT-arrangemang. Kontrollera om avtalet innehåller tjänstebeskrivningar, villkor för underleverantörer, platser, dataskyddsåtaganden, åtkomst och återställning, servicenivåer, incidentstöd, revisionsrätt, samarbete med myndigheter, uppsägning, deltagande i utbildning och exitstöd.

Mappa ISO-underlag för varje kritiskt arrangemang. Länka till tillgångsposter, riskbedömningsposter, SoA-kontroller, leverantörsgranskning, övervakningsgranskningar, kontinuitetsplaner, incidentåtgärdsplaner och underlag för exitstrategi.

Tilldela frekvens. Kritiska leverantörer kan kräva kvartalsvis granskning, årlig säkerhetsförsäkran, avtalsgranskning före förnyelse och omedelbar omprövning vid väsentlig ändring. Icke-kritiska leverantörer kan granskas årligen eller vid triggerhändelser.

Använd denna checklista för att omvandla registret till en operativ process:

• Utse en ägare och en ersättande ägare för DORA-registret.
• Koppla varje registerrad till ett avtals-ID och en leverantörsägare.
• Koppla varje kritisk eller viktig IKT-tjänst till verksamhetsfunktion och tillgångsposter.
• Lägg till fält för underleverantörer och underbiträden, även om de initialt markeras som okända.
• Lägg till status för avtalsklausuler avseende DORA-kritiska villkor.
• Lägg till ISO/IEC 27001:2022-riskreferenser och SoA-referenser.
• Lägg till GDPR-roll, personuppgifter och platsfält där det är tillämpligt.
• Lägg till granskningsfrekvens och metadata för senast genomförd granskning.
• Skapa eskaleringsregler för saknade klausuler, okända underleverantörer och hög koncentrationsrisk.
• Rapportera kvalitetsmått för registret till ledningen.

Det är här Clarysecs 30-stegsmetod för genomförande, policypaket och Zenith Controls samverkar. Zenith Blueprint ger genomförandevägen, från riskbehandling och SoA-spårbarhet i steg 13 till tillgångsförteckning i steg 22 och leverantörskontroller i steg 23. Policyerna definierar vem som ska underhålla register, vilket avtals- och tillgångsunderlag som ska finnas och hur metadata för regelefterlevnad fångas. Zenith Controls ger kompassen för samordnad regelefterlevnad vid mappning av samma underlag mot revisionsförväntningar enligt DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST och COBIT 19.

Gör registret till underlag innan tillsynsmyndigheten frågar

Om ert DORA-informationsregister fortfarande är ett kalkylblad som är frikopplat från avtal, tillgångar, leverantörer, underleverantörer och ISO 27001-underlag är 2026 året då det ska åtgärdas.

Börja med att använda Zenith Blueprint Zenith Blueprint för att koppla samman riskbehandling, tillgångsförteckning och leverantörsstyrning. Använd Zenith Controls Zenith Controls för att mappa ISO/IEC 27001:2022 bilaga A-kontrollerna A.5.9, A.5.19 och A.5.20 till underlag för samordnad regelefterlevnad. Operationalisera därefter kraven genom Clarysecs policyer för leverantörer, tillgångar, moln, rättslig efterlevnad och revisionsövervakning, inklusive policy för leverantörssäkerhet och tredjepartssäkerhet – SME, Policy för hantering av risker kopplade till leverantörsberoenden, policy för leverantörssäkerhet och tredjepartssäkerhet, policy för tillgångshantering – SME, policy för tillgångshantering, Policy för användning av molntjänster – SME, Policy för rättslig och regulatorisk efterlevnad och Policy för revision och regelefterlevnadsövervakning – SME.

Den bästa tidpunkten att åtgärda registerkvaliteten är före en myndighetsbegäran, internrevision, leverantörsstörning eller avtalsförnyelse. Den näst bästa tidpunkten är nu. Ladda ned relevanta Clarysec-policyer, mappa ert nuvarande register mot underlagsmodellen ovan och boka en DORA-registerbedömning för att omvandla spridda leverantörsdata till underlag på tillsynsnivå.