DORA 2026-färdplan för IKT-risk, leverantörsstyrning och TLPT

DORA 2026-sökpaniken handlar egentligen inte om reglering, utan om underlag

Klockan är 08.15 en måndagsmorgon och informationssäkerhetschefen på ett medelstort betalningsinstitut har tre webbläsarflikar öppna: ”DORA RTS/ITS-checklista”, ”DORA-mall för IKT-tredjepartsregister” och ”TLPT-krav för finansiella entiteter”.

Regelefterlevnadsansvarig har redan frågat om styrelseunderlaget bör innehålla det senaste arbetsflödet för incidentklassificering. Upphandling vill introducera en ny molnbaserad analysplattform. Den operativa chefen vill ha försäkran om att leverantören av kärnbanks-SaaS inte har dold underleverantörsexponering utanför EU. Internrevision efterfrågar en testkalender. Juridik frågar om tidsfristerna för incidentanmälan enligt GDPR har samordnats med DORA-rapportering av incidenter.

Ingen ställer en teoretisk fråga. De frågar: ”Kan vi styrka detta senast på fredag?”

Det är den verkliga DORA 2026-utmaningen. De flesta finansiella entiteter förstår huvudkraven: IKT-riskhantering, rapportering av IKT-relaterade incidenter, testning av digital operativ resiliens, hantering av IKT-tredjepartsrisk och starkare styrning av kritiska IKT-leverantörer. Det svåra är att omsätta Regulatory Technical Standards, Implementing Technical Standards och skyldigheter på artikelnivå till kontrollerad, repeterbar och granskningsbar praxis.

Digital Operational Resilience Act kräver att finansiella entiteter upprätthåller robust förmåga för IKT-riskhantering, policyer för hantering och rapportering av IKT-relaterade incidenter, testning av IKT-system, kontroller och processer samt strukturerad styrning av IKT-tredjepartsleverantörer. Förordningen förutsätter också proportionalitet. Ett mindre värdepappersbolag och en stor bankkoncern behöver inte identiska underlagsmodeller, men båda måste kunna visa att deras angreppssätt är lämpligt i förhållande till storlek, riskprofil, komplexitet och kritiska funktioner.

DORA-projekt misslyckas vanligtvis av ett av tre skäl. För det första behandlar organisationen DORA som en juridisk mappningsövning i stället för som en operativ modell. För det andra dokumenteras leverantörsrisk som en leverantörslista i stället för som beroenden, utbytbarhet och koncentrationsrisk. För det tredje behandlas testning som ett årligt penetrationstest i stället för som ett resiliensprogram som omfattar sårbarhetsskanning, scenariotestning, incidentövningar och, där det är tillämpligt, hotledd penetrationstestning, ofta sökt som TLPT.

Ett bättre angreppssätt är att bygga ett sammanhållet system för underlag som kopplar samman policyer, register, ägare, risker, incidenter, leverantörer, testning, återhämtning och ledningens genomgång. Det är här Clarysecs Zenith Blueprint, färdiga policyer och Zenith Controls hjälper finansiella entiteter att göra DORA från en tidsfrist till en operativ rytm.

Börja med DORA:s operativa modell, inte med RTS/ITS-kalkylbladet

Många team börjar med ett kalkylblad som listar DORA-artiklar och RTS/ITS-krav. Det är användbart, men inte tillräckligt. Ett kalkylblad kan visa vad som måste finnas. Det tilldelar inte ägare, definierar granskningsfrekvens, bevarar underlag eller visar att en kontroll faktiskt fungerar.

I Zenith Blueprint: En revisors 30-stegs färdplan behandlar Clarysec detta i riskhanteringsfasen, steg 14, policyer för riskbehandling och regulatoriska korsreferenser:

”DORA: För företag i den finansiella sektorn kräver DORA ett ramverk för IKT-riskhantering som ligger mycket nära det vi har gjort: identifiera risker, införa kontroller (och policyer) och testa dem. DORA betonar också incidenthantering och rapportering samt tillsyn över IKT-tredjepartstjänsteleverantörer.”

Det praktiska budskapet är enkelt: bygg inte ”DORA-efterlevnad” som en parallell byråkrati. Bygg ett riskbaserat lager för IKT-styrning som mappar DORA-krav mot policyer, register, kontrollägare, testunderlag, leverantörsunderlag och ledningens genomgång.

En praktisk DORA-operativ modell bör ha fem underlagspelare:

För reglerade finansiella entiteter gör denna struktur RTS/ITS-genomförandet till ett revisionsklart system för underlag. För entiteter med förenklad IKT-riskhantering kan samma modell skalas till färre dokument och enklare register. Kärndisciplinerna är desamma: identifiera, skydda, detektera, hantera, återhämta, testa och styra leverantörer.

IKT-riskhantering: registret är kontrollrummet

DORA:s förväntningar på IKT-riskhantering kräver att finansiella entiteter identifierar, klassificerar och hanterar IKT-risker över system, data, processer, kritiska eller viktiga funktioner och tredjepartsberoenden.

Det vanliga felet är inte avsaknaden av ett riskregister. Det är att registret är frikopplat från leverantörer, tillgångar, incidenter och tester. DORA belönar inte ett snyggt kalkylblad om det inte kan förklara varför en högriskleverantör saknar exitplan, eller varför en kritisk kundbetalningsplattform inte har testats.

Clarysecs SME Riskhanteringspolicy ger mindre finansiella entiteter en tydlig baslinje för underlag:

”Varje riskpost måste omfatta: beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan.”
Från avsnittet ”Styrningskrav”, policyklausul 5.1.2.

För större finansiella entiteter kräver Clarysecs Enterprise Riskhanteringspolicy en mer formell process:

”En formell riskhanteringsprocess ska upprätthållas i enlighet med ISO/IEC 27005 och ISO 31000 och omfatta riskidentifiering, analys, utvärdering, behandling, övervakning och kommunikation.”
Från avsnittet ”Styrningskrav”, policyklausul 5.1.

Denna distinktion är viktig. DORA är proportionell, men proportionalitet betyder inte informellt. Ett mindre betalningsinstitut kan använda ett strömlinjeformat register, medan en bankkoncern kan använda integrerade GRC-verktyg. I båda fallen kommer revisorn ändå att fråga: Vilka är era IKT-risker? Vem äger dem? Vad är riskbehandlingsplanen? Vilket underlag visar framdrift? Hur påverkar leverantörer och kritiska funktioner poängen?

Ett starkt IKT-riskregister för DORA bör omfatta följande fält:

En praktisk övning är att ta en kritisk IKT-tjänst, till exempel en transaktionsövervakningsplattform i molnmiljö, och skapa en riskpost på 20 minuter. Beskriv fel- eller komprometteringsscenariot, poängsätt sannolikhet och konsekvens, tilldela en ägare, identifiera relaterade leverantörer, definiera en riskbehandlingsplan och länka posten till underlag såsom leverantörsgranskning, SLA, incidentklausuler, BIA, resultat från DR-tester, övervakningspaneler och åtkomstgranskning.

Den enskilda posten blir tråden som kopplar samman DORA:s IKT-riskhantering, tredjepartsstyrning, incidentdetektering, kontinuitet och testning. Det är så ett riskregister blir ett kontrollrum, inte ett arkivskåp.

RTS/ITS-beredskap: mappa skyldigheter till policyer, inte löften

Den praktiska söktermen ”DORA RTS/ITS-checklista” betyder oftast ”Vilka dokument kommer tillsynsmyndigheter att förvänta sig?” Finansiella entiteter bör undvika att utlova efterlevnad genom generiska uttalanden. De behöver en mappning som kopplar varje skyldighet till policy, kontroll, ägare och underlag.

Clarysecs SME Policy för rättslig och regulatorisk efterlevnad etablerar ett enkelt styrningsankare:

”VD måste upprätthålla ett enkelt, strukturerat register över regelefterlevnadskrav som listar:”
Från avsnittet ”Styrningskrav”, policyklausul 5.1.1.

För DORA 2026 bör ert register över regelefterlevnadskrav omfatta:

• DORA-skyldighet eller RTS/ITS-kravområde.
• Tillämplighet, inklusive proportionalitetsmotivering.
• Referens till policy eller procedur.
• Kontrollägare.
• Plats för underlag.
• Granskningsfrekvens.
• Öppna luckor och tidsfrist för åtgärdande.
• Status för rapportering till styrelse eller ledning.

Detta ligger i linje med angreppssättet i Zenith Blueprint steg 14: mappa regulatoriska krav till ISMS-kontroller och policyer så att inget faller mellan stolarna. I stället för att fråga ”Är vi DORA-kompatibla?” kan ledningen fråga: ”Vilka DORA-underlag är försenade, vilka kritiska leverantörer saknar exitplaner och vilka testaktiviteter har ännu inte lett till åtgärdsunderlag?”

IKT-tredjepartsrisk: koncentration, utbytbarhet och underleverantörer

DORA har förändrat leverantörsdialogen i finansiella tjänster. Det räcker inte längre att fråga om en leverantör har en säkerhetscertifiering, försäkring eller ett personuppgiftsbiträdesavtal. Finansiella entiteter måste bedöma om en leverantör skapar koncentrationsrisk, om leverantören realistiskt kan ersättas, om flera kritiska tjänster är beroende av en och samma leverantör eller närstående leverantörer samt om underleverantörer medför ytterligare rättslig exponering eller resiliensrisk.

Det är den frågan som håller många informationssäkerhetschefer vakna. Ett företag kan vara beroende av en stor molnleverantör för transaktionsbehandling, dataanalys, kundportaler och intern samverkan. Om den leverantören drabbas av ett långvarigt avbrott, en regulatorisk tvist eller ett underleverantörsfel är frågan inte bara ”Har vi ett avtal?” Frågan är: ”Kan vi fortsätta leverera kritiska tjänster, kommunicera med kunder och visa att vi förstod beroendet innan det fallerade?”

Clarysecs SME policy för leverantörssäkerhet och tredjepartssäkerhet lägger grunden:

”Ett leverantörsregister måste upprätthållas och uppdateras av administrativ kontakt eller upphandlingskontakt. Det måste omfatta:”
Från avsnittet ”Styrningskrav”, policyklausul 5.4.

För program på enterprise-nivå går Clarysecs Policy för hantering av risker kopplade till leverantörsberoenden djupare in i DORA-specifika beroenden och utbytbarhet:

”Register över leverantörsberoenden: leverantörsstyrningsfunktionen ska upprätthålla ett aktuellt register över alla kritiska leverantörer, inklusive uppgifter såsom 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 konsekvensen om leverantören skulle fallera eller komprometteras. Registret ska tydligt identifiera leverantörer med högt beroende (t.ex. sådana där inget snabbt alternativ finns).”
Från avsnittet ”Krav för genomförande”, policyklausul 6.1.

Detta är det leverantörsunderlag som DORA-projekt ofta missar. Ett leverantörsregister säger vem leverantören är. Ett beroenderegister säger vad som händer när leverantören fallerar.

Zenith Blueprint, fasen Controls in Action, steg 23, organisatoriska kontroller, ger ett praktiskt arbetsflöde för leverantörsstyrning. Det rekommenderar att man sammanställer en fullständig leverantörslista, klassificerar leverantörer utifrån åtkomst till system, data eller operativ styrning, verifierar att säkerhetsförväntningar är inbyggda i avtal, hanterar underleverantörer och risker längre ned i leveranskedjan, definierar rutiner för ändring och övervakning samt skapar en process för utvärdering av molntjänster.

I Zenith Controls: guiden för tvärgående efterlevnad mappas ISO/IEC 27002:2022-kontroll 5.21, Hantering av informationssäkerhet i IKT-leveranskedjan, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den är kopplad till säkerhet i leverantörsrelationer och cybersäkerhetskonceptet Identify. Den kopplar till säker utveckling, säker kodning, åtkomstkontroll, säkerhetstestning, bevisinsamling, säker utvecklingslivscykel och outsourcad utveckling.

Det är exakt verkligheten för DORA:s tredjepartsstyrning. Leverantörsrisk är inte bara upphandling. Den berör arkitektur, utveckling, incidenthantering, åtkomstkontroll, verksamhetskontinuitet och juridik.

Ur ett tvärgående efterlevnadsperspektiv mappar Zenith Controls IKT-leveranskedjesäkerhet till GDPR Articles 28 och 32 eftersom personuppgiftsbiträden och underbiträden måste väljas och övervakas med lämpliga tekniska och organisatoriska åtgärder. Det stödjer NIS2-förväntningar på säkerhet i leveranskedjan, inklusive Article 21 om åtgärder för hantering av cybersäkerhetsrisker och Article 22 om samordnade riskbedömningar av leveranskedjan. Det mappar starkt mot DORA Articles 28, 29 och 30, där IKT-tredjepartsrisk, koncentrationsrisk, vidareutkontraktering och avtalsbestämmelser är centrala.

Stödjande standarder stärker underlaget. ISO/IEC 27036-3:2021 stödjer IKT-upphandling och säkerhet vid leverantörsval. ISO/IEC 20243:2018 stödjer integritet hos betrodda teknikprodukter och leveranskedjesäkerhet. ISO/IEC 27001:2022 kopplar detta till riskbehandling och leverantörskontroller i Annex A.

Incidentrapportering: bygg eskaleringskedjan före incidenten

DORA-incidentrapportering handlar inte bara om att lämna in en anmälan. Det handlar om att detektera, klassificera, eskalera, kommunicera och dra lärdom av IKT-relaterade incidenter. Finansiella entiteter måste upprätthålla processer för IKT-incidenthantering och rapportering, med definierade roller, klassificeringskriterier, notifieringsvägar och efterincidentanalys.

Clarysecs SME Policy för incidenthantering kopplar incidenthanteringens tidslinjer till rättsliga krav:

”Tidslinjer för respons, inklusive skyldigheter för dataåterställning och avisering, måste dokumenteras och vara anpassade till rättsliga krav, såsom GDPR-kravet på anmälan av personuppgiftsincident inom 72 timmar.”
Från avsnittet ”Styrningskrav”, policyklausul 5.3.2.

För enterprise-miljöer lägger Clarysecs Policy för incidenthantering till ett eskaleringsperspektiv för reglerade data:

”Om en incident leder till bekräftad eller sannolik exponering av personuppgifter eller andra reglerade data måste juridik och DPO bedöma tillämpligheten av:”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4.1.

Citatet slutar vid utlösningspunkten, vilket är exakt där många incidentprocesser brister. Om utlösaren är oklar diskuterar teamen notifieringsskyldigheter medan klockan redan tickar.

Zenith Blueprint, fasen Controls in Action, steg 16, personalsäkerhetsåtgärder II, betonar personaldriven incidentrapportering. Anställda, uppdragstagare och intressenter behöver veta hur de känner igen och rapporterar potentiella säkerhetsincidenter via enkla kanaler, till exempel en särskild brevlåda, portal eller hotline. Blueprint kopplar detta till GDPR Article 33, NIS2 Article 23 och DORA Article 17 eftersom regulatorisk rapportering börjar med intern medvetenhet och eskalering.

I Zenith Controls mappas ISO/IEC 27002:2022-kontroll 5.24, Planering och förberedelse för hantering av informationssäkerhetsincidenter, som en korrigerande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, i linje med Respond och Recover. Den knyter direkt till händelsebedömning, lärande från incidenter, loggning och övervakning, säkerhet under störning, informationssäkerhetskontinuitet och kontakt med myndigheter. Guiden mappar detta till DORA Articles 17 till 23 för IKT-relaterad incidenthantering, klassificering, rapportering och frivillig cyberhotanmälan, GDPR Articles 33 och 34 för incidentanmälan samt NIS2 Article 23 för incidentanmälan.

En DORA-klar incidentprocess bör omfatta:

• Tydliga kanaler för incidentmottagning.
• Händelsetriage och klassificeringskriterier.
• Arbetsflöde för eskalering av större IKT-relaterad incident.
• Beslutspunkter för juridik, DPO och regulatorisk notifiering.
• Utlösare för leverantörers incidentavisering.
• Krav på bevarande av underlag.
• Kommunikationsregler för verkställande ledning och styrelse.
• Efterincidentgranskning och erfarenhetsåterföring.
• Koppling till uppdateringar av riskregister och åtgärdande av kontroller.

Stödjande standarder ger struktur. ISO/IEC 27035-1:2023 tillhandahåller principer för planering och förberedelse inom incidenthantering. ISO/IEC 27035-2:2023 beskriver incidenthanteringens steg. ISO/IEC 22320:2018 stödjer ledning, styrning och strukturerad kriskommunikation. Detta är viktigt när ett IKT-avbrott blir en kundpåverkande kris och entiteten måste visa att besluten var tidsenliga, samordnade och grundade på underlag.

Testning av digital operativ resiliens och TLPT: låt inte testet bli incidenten

Testning är ett av de mest sökta DORA 2026-ämnena eftersom det är både tekniskt och styrningstungt. Finansiella entiteter behöver testa IKT-system, kontroller och processer. För utsedda entiteter blir avancerad testning, såsom TLPT, ett centralt krav enligt DORA Article 26.

Revisionsfrågan är inte bara ”Har ni testat?” Den är: ”Var testet riskbaserat, godkänt, säkert, oberoende där så krävs, åtgärdat och kopplat till resiliensmål?”

Clarysecs Enterprise Policy för säkerhetstestning och red teaming definierar miniminivån för testprogrammet tydligt:

”Typer av tester: Programmet för säkerhetstestning ska minst omfatta: (a) sårbarhetsskanning, bestående av automatiserade vecko- eller månadsskanningar av nätverk och applikationer för att identifiera kända sårbarheter; (b) penetrationstestning, bestående av manuell djupgående testning av specifika system eller applikationer av kvalificerade testare för att identifiera komplexa svagheter; och (c) red team-övningar, bestående av scenariobaserade simuleringar av verkliga angrepp, inklusive social manipulation och andra taktiker, för att testa organisationens detekterings- och responsförmåga som helhet.”
Från avsnittet ”Krav för genomförande”, policyklausul 6.1.

Detta är bryggan mellan rutinmässig testning och TLPT-mognad. Sårbarhetsskanning hittar kända svagheter. Penetrationstestning validerar exploaterbarhet. Red teaming testar detektering och respons som ett system. TLPT, där det är tillämpligt, bör ligga inom ett styrt testprogram med kontroll av omfattning, säkerhetsregler, hantering av produktionsrisk, insamling av underlag och uppföljning av åtgärdande.

Zenith Blueprint, fasen Controls in Action, steg 21, behandlar skydd av informationssystem under revision och testning. Den varnar för att revisioner, penetrationstester, forensiska granskningar och operativa utvärderingar kan medföra risk eftersom de kan involvera förhöjd åtkomst, intrusiva verktyg eller tillfälliga förändringar i systembeteende. Blueprint mappar denna risk till GDPR Article 32, DORA:s förväntningar på testning av digital operativ resiliens, NIS2:s kontinuitetskrav och COBIT 2019-praxis för säkert genomförande av revisioner och granskningar.

I Zenith Controls mappas ISO/IEC 27002:2022-kontroll 5.35, Oberoende granskning av informationssäkerhet, som förebyggande och korrigerande och som stöd för konfidentialitet, riktighet och tillgänglighet. Den knyter till efterlevnad av policyer, ledningsansvar, lärande från incidenter, skydd av poster, radering av information, loggning och övervakning. För DORA finns de relevanta testskyldigheterna främst i Articles 24 till 27, inklusive Article 26 för TLPT. Detta stödjer även GDPR Article 32(1)(d), som kräver regelbunden testning och utvärdering av tekniska och organisatoriska åtgärder, samt NIS2 Article 21, som kräver åtgärder för hantering av cybersäkerhetsrisker.

Ett beredskapspaket för DORA TLPT bör omfatta:

Den viktigaste DORA-lärdomen är att testunderlag inte får stanna vid rapporten. Revisorer kommer att fråga om iakttagelser riskklassades, tilldelades, åtgärdades och omtestades. De kan också kontrollera om testningen omfattade kritiska eller viktiga funktioner, inte bara internetexponerade tillgångar.

Verksamhetskontinuitet och katastrofåterställning: resiliens måste vara operativ

DORA är en reglering för digital operativ resiliens. Återställning är lika viktig som förebyggande åtgärder. Ett dokumenterat IKT-riskramverk hjälper inte om ett avbrott i betalningsplattformen visar att återställningsmål aldrig har testats, leverantörernas kontaktkedjor är inaktuella och kristeamet inte kan enas om vem som kommunicerar med kunder.

Clarysecs SME Policy för verksamhetskontinuitet och katastrofåterställning sätter en tydlig baslinje:

”Organisationen måste testa både sin BCP och sin DR-förmåga minst årligen. Tester måste omfatta:”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4.1.

Enterprise-versionen Policy för verksamhetskontinuitet och katastrofåterställning börjar med verksamhetspåverkan:

”Business Impact Analysis (BIA) ska genomföras minst årligen för alla kritiska verksamhetsenheter och granskas vid väsentliga ändringar av system, processer eller beroenden. BIA-resultat ska definiera:”
Från avsnittet ”Styrningskrav”, policyklausul 5.2.

För DORA bör BIA kopplas till IKT-tillgångar, leverantörer, incidenthantering och testning. Om BIA identifierar ”kundbetalningar” som en kritisk funktion bör registret över leverantörsberoenden identifiera de processorer, molntjänster och nätverksleverantörer som stödjer den. Riskregistret bör innehålla felscenarier. Testplanen bör omfatta validering av resiliens. Incidenthanteringsplanen bör omfatta eskalering och kommunikation. DR-testet bör producera underlag, inte bara en mötesanteckning.

Denna spårbarhet är det som gör DORA-efterlevnad till ett system för operativ resiliens.

Tvärgående efterlevnad: ett underlag, många revisionsfrågor

Finansiella entiteter möter sällan DORA ensam. De har ofta GDPR-skyldigheter, NIS2-exponering, avtalsmässiga säkerhetsåtaganden, ISO/IEC 27001:2022-mål, internrevisionskrav, kunders leverantörsgranskningar, SOC-förväntningar och styrelsens riskrapportering. Svaret är inte att skapa separata underlagssilor. Svaret är att bygga en tvärgående underlagsmodell för efterlevnad.

Zenith Controls är Clarysecs kompass för tvärgående efterlevnad. Den skapar inte nya skyldigheter. Den mappar officiella standarder och ramverk så att organisationer kan förstå hur ett kontrollområde stödjer flera efterlevnadsutfall.

Detta är viktigt för budget och styrning. En informationssäkerhetschef kan förklara för styrelsen att förbättrad incidentklassificering stödjer DORA-rapportering, GDPR-incidentanmälan, NIS2-incidenthantering och intern resiliens. En upphandlingsansvarig kan motivera kartläggning av leverantörsberoenden eftersom den stödjer DORA-koncentrationsrisk, GDPR-leverantörsgranskning av personuppgiftsbiträden och NIS2-leveranskedjesäkerhet. En testansvarig kan visa att red team-övningar och oberoende granskningar stödjer DORA-testning, GDPR-utvärdering av kontroller och bredare assurance.

Revisionsperspektivet: hur granskare kommer att testa ert DORA-underlag

DORA-beredskap blir verklig när någon begär underlag. Olika revisorer och granskare närmar sig samma ämne från olika vinklar.

En revisor med ISO/IEC 27001:2022-perspektiv börjar med ISMS-logiken: omfattning, riskbedömning, riskbehandling, tillämplighet för Annex A-kontroller, internrevision, ledningens genomgång och underlag som visar att kontrollerna är införda. För IKT-leveranskedjesäkerhet granskar de policyer, leverantörsklassificering, avtalsklausuler, leverantörsgranskning och löpande övervakning. För incidenthantering inspekterar de planen, roller, eskaleringsvägar, verktyg och poster. För testning förväntar de sig planerade intervall, oberoende där det är lämpligt, åtgärdande och underlag till ledningens genomgång.

Ett ISO/IEC 19011:2018-revisionsperspektiv fokuserar på revisionsgenomförande. I Zenith Controls noterar revisionsmetodiken för IKT-leveranskedjesäkerhet att revisorer granskar upphandlingspolicyer, RFP-mallar och processer för leverantörshantering för att verifiera att IKT-specifika säkerhetskrav är inbyggda från anskaffning till avveckling. För incidenthantering granskar revisorer incidenthanteringsplanens fullständighet och anpassning till bästa branschpraxis. För oberoende granskning letar revisorer efter underlag som visar att oberoende revisioner eller granskningar har genomförts.

Ett ISO/IEC 27007:2020-perspektiv är mer specifikt för ISMS-revision. Zenith Controls noterar att revisorer kan intervjua upphandlingsansvariga, IT-säkerhetspersonal och leverantörsansvariga för att bedöma förståelse och genomförande av kontroller för IKT-leveranskedjan. För incidentförberedelser bekräftar de att ett Incident Response Team finns och är operativt. För oberoende granskning verifierar de att internrevisionsprogrammet täcker hela ISMS-omfattningen och har tillräckliga resurser.

En testgranskare som utgår från NIST SP 800-115 fokuserar på metodik för sårbarhetsbedömning och penetrationstestning. De kan granska om testomfattning, spelregler, iakttagelser, allvarlighetsgrader, åtgärdande och omtestning är dokumenterade. För DORA TLPT innebär det att granskaren inte nöjer sig med ett presentationsmaterial från red team. De vill se bevis på styrning, säkerhet, tekniskt djup och stängning.

En COBIT 2019- eller ISACA-inriktad revisor kommer att fråga om styrningsmålen uppfylls: vem äger processen, hur mäts prestanda, hur godkänns undantag och hur får ledningen assurance.

Den praktiska DORA 2026-checklistan för beredskap

Använd denna checklista som arbetsbaslinje för att omvandla DORA-sökningar till åtgärder.

Styrning och RTS/ITS-mappning

• Upprätthåll ett DORA-register över regelefterlevnadskrav med kravområde, tillämplighet, ägare, underlag, granskningsfrekvens och luckstatus.
• Mappa DORA-krav mot policyer, register, kontroller och ledningsrapportering.
• Definiera proportionalitetsmotivering för förenklad eller skalad IKT-riskhantering där det är tillämpligt.
• Tilldela verkställande ansvar för IKT-risk, incidentrapportering, tredjepartsstyrning och testning.
• Inkludera DORA-status i ledningens genomgång och styrelsens riskrapportering.

IKT-riskhantering

• Upprätthåll ett IKT-riskregister med beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan.
• Koppla risker till kritiska eller viktiga funktioner.
• Koppla risker till IKT-tillgångar, leverantörer och processer.
• Granska risker efter större incidenter, leverantörsändringar, teknikändringar eller testresultat.
• Följ upp riskbehandlingsåtgärder till stängning eller formell riskacceptans.

IKT-tredjepartsstyrning

• Upprätthåll ett leverantörsregister och ett register över leverantörsberoenden.
• Identifiera leverantörer som stödjer kritiska eller viktiga funktioner.
• Bedöm leverantörer som är enda källa och deras utbytbarhet.
• Granska underleverantörer och vidareutkontrakteringsarrangemang.
• Bygg in klausuler om säkerhet, åtkomst, incidentrapportering, revision och exit i avtal.
• Övervaka kritiska leverantörer minst årligen eller efter väsentliga ändringar.
• Upprätthåll exit- och beredskapsplaner för leverantörer med högt beroende.

Incidenthantering och rapportering

• Upprätthåll incidenthanteringsrutiner med tydliga roller och eskaleringsvägar.
• Definiera klassificeringskriterier för IKT-incidenter.
• Samordna DORA-rapporteringsutlösare med GDPR, NIS2 och avtalsmässiga notifieringsskyldigheter.
• Utbilda anställda och uppdragstagare i kanaler för incidentrapportering.
• Upprätthåll incidentloggar, beslutsunderlag och bevismaterial.
• Genomför efterincidentgranskningar och uppdatera risker och kontroller.

Testning, red teaming och TLPT

• Upprätthåll en riskbaserad testkalender.
• Genomför sårbarhetsskanning och penetrationstestning med definierade intervall.
• Använd scenariobaserade red team-övningar för att testa detektering och respons.
• För TLPT-beredskap: definiera omfattning, spelregler, säkerhetskontroller och leverantörssamordning.
• Skydda produktionssystem under testning.
• Följ upp iakttagelser, åtgärdande, omtestning och erfarenhetsåterföring.
• Rapportera testresultat till ledningen.

Kontinuitet och återhämtning

• Genomför årlig BIA för kritiska verksamhetsenheter och uppdatera efter väsentliga ändringar.
• Definiera återställningsmål för kritiska funktioner och stödjande IKT-tjänster.
• Testa BCP- och DR-förmåga minst årligen.
• Inkludera scenarier för leverantörsavbrott och cyberincidenter.
• Bevara testunderlag, luckor, avhjälpande åtgärder och resultat från omtest.
• Anpassa kontinuitetsplaner till incidenthantering och kriskommunikation.

Hur Clarysec hjälper finansiella entiteter att gå från sökresultat till revisionsklart underlag

DORA 2026-beredskap uppnås inte genom att ladda ned en checklista och hoppas att organisationen kan fylla luckorna senare. Den kräver en strukturerad operativ modell som kopplar samman risk, leverantörer, incidenter, testning, kontinuitet och revisionsunderlag.

Clarysecs angreppssätt kombinerar tre lager.

För det första ger Zenith Blueprint en färdplan för genomförande. Steg 14 hjälper organisationer att korsreferera regulatoriska krav till riskbehandling och policyer. Steg 16 stärker personaldriven incidentrapportering. Steg 21 säkerställer att revisioner och tester inte äventyrar produktionssystem. Steg 23 gör leverantörsstyrning till ett praktiskt arbetsflöde som täcker klassificering, avtal, underleverantörer, övervakning och molnutvärdering.

För det andra tillhandahåller Clarysec-policyer styrning som är redo att operationaliseras. Riskhanteringspolicy, Policy för rättslig och regulatorisk efterlevnad, policy för leverantörssäkerhet och tredjepartssäkerhet, Policy för hantering av risker kopplade till leverantörsberoenden, Policy för incidenthantering, Policy för säkerhetstestning och red teaming samt Policy för verksamhetskontinuitet och katastrofåterställning ger team konkreta klausuler, ägarskapsmodeller och förväntningar på underlag.

För det tredje ger Zenith Controls den tvärgående efterlevnadskartan. Den visar hur IKT-leveranskedjesäkerhet, planering av incidenthantering och oberoende granskning kopplar till DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 och NIST-testpraxis.

Resultatet är ett DORA-efterlevnadsprogram som är försvarbart vid revision och användbart vid en verklig incident, ett leverantörsfel eller ett resiliensprov.

Nästa steg: bygg ert DORA-underlagspaket före nästa revisionsbegäran

Om ert team fortfarande söker efter ”DORA RTS/ITS-checklista”, ”DORA-mall för IKT-riskhantering”, ”DORA-tredjepartsstyrning” eller ”DORA TLPT-krav” är nästa steg att omvandla dessa sökningar till kontrollerat underlag.

Börja med fyra åtgärder denna vecka:

1. Skapa eller uppdatera ert DORA-register över regelefterlevnadskrav med Clarysecs policymodell.
2. Välj en kritisk funktion och spåra den genom riskregistret, registret över leverantörsberoenden, incidentflödet, BIA och testplanen.
3. Granska era fem viktigaste IKT-leverantörer avseende utbytbarhet, underleverantörer, incidentklausuler och exitmöjligheter.
4. Bygg ett testunderlagspaket med omfattning, godkännande, resultat, åtgärdande och omtestning.

Clarysec kan hjälpa er att genomföra detta med Zenith Blueprint, policymallar och Zenith Controls, så att ert DORA 2026-program blir praktiskt, proportionellt och revisionsklart.