IKT-riskaptit enligt DORA: guide för styrelsegodkännande 2026

Klockan är 08.15 en tisdag och informationssäkerhetschefen (CISO) på ett medelstort betalningsteknikföretag står utanför styrelserummet med tre dokument öppna på en surfplatta.

Det första är IKT-riskregistret. Det har 137 rader, färgkodade bedömningar och flera höga risker kopplade till molnkoncentration, privilegierad åtkomst, återställning efter ransomware, exponering av kunddata och leverantörers incidenthantering. Det andra är DORA-beredskapsspåraren. Den anger att bolaget har policyer, incidentrutiner, tredjepartsregister och planer för resiliensövningar. Det tredje är styrelseunderlaget inför ett regulatoriskt möte.

Ordföranden har en fråga, och den är inte teknisk:

”Vilken nivå av IKT-risk har vi faktiskt kommit överens om att acceptera?”

Rummet blir tyst eftersom företaget har riskbedömningar, men ingen styrelsegodkänd IKT-riskaptit. Det har konsekvensbedömningar, men inga mätbara toleranströsklar. Det har eskaleringsmöten, men ingen formell trigger som anger när en cyberrisk blir ett beslut för ledningsorganet. Det har accepterade kvarstående risker, men vissa motiveras som ”affärsbeslut” utan tydlig koppling till riskkriterier, proportionalitet enligt GDPR Article 32, DORA:s förväntningar på tolerans eller NIS2:s ledningsansvar.

Den luckan blir allt tydligare under 2026. DORA gäller från den 17 januari 2025 och kräver att finansiella entiteter upprätthåller ett ramverk för styrning och kontroll av IKT-risk, inklusive ledningsorganets ansvar för IKT-riskhanteringsramverket, strategin för digital operativ resiliens och IKT-risktolerans. NIS2 driver ledningsorgan att godkänna åtgärder för hantering av cybersäkerhetsrisker och övervaka genomförandet. GDPR Article 32 kräver lämpliga tekniska och organisatoriska säkerhetsåtgärder baserade på risk. ISO/IEC 27001:2022 ger ledningssystemets mekanik: kontext, intressenter, riskkriterier, riskbehandlingsplaner, dokumenterad information och ledningens genomgång.

Den saknade bryggan är en riskaptit- och risktoleransförklaring för IKT som en styrelse kan förstå, godkänna, utmana och använda.

Den här guiden beskriver hur den bryggan byggs med Clarysecs Zenith Blueprint: En revisors 30-stegs färdplan, Clarysecs Riskhanteringspolicy, Clarysecs Riskhanteringspolicy för små och medelstora företag och Zenith Controls: vägledning för tvärgående regelefterlevnad.

Varför riskregister inte är riskaptit

Många organisationer misstar ett riskregister för riskstyrning. Ett riskregister visar vilka risker som finns, hur de har bedömts, vem som äger dem och vilken behandling som planeras. Det besvarar inte automatiskt de frågor på styrelsenivå som DORA, NIS2, GDPR och ISO/IEC 27001:2022 förväntar sig att ledningen hanterar.

En mogen IKT-riskaptitförklaring besvarar frågor som:

• Vilka IKT-risker är oacceptabla oavsett kostnad?
• Vilket driftstopp kan verksamheten tolerera för en kritisk eller viktig funktion?
• Vilken nivå av dataförlust eller komprometterad dataintegritet ligger utanför riskaptiten?
• Vilken koncentrationsrisk hos tredje part kräver styrelsens uppmärksamhet?
• Vem får acceptera kvarstående IKT-risk, och på vilken nivå?
• När måste en risk eskaleras till högsta ledningen eller ledningsorganet?
• Hur byggs rättsliga, regulatoriska och avtalsmässiga krav in i riskkriterierna?

Enligt DORA är detta inte frivillig styrningspolish. Article 5 kräver att ledningsorganet definierar, godkänner, övervakar och ansvarar för IKT-riskhanteringsramverket, inklusive strategin för digital operativ resiliens och IKT-risktolerans. Article 6 kräver ett dokumenterat IKT-riskhanteringsramverk, årlig granskning för icke-mikroföretag, internrevision, åtgärdande av kritiska revisionsiakttagelser och en strategi för digital operativ resiliens med IKT-mål, risktolerans, konsekvenstolerans, arkitektur, testning och strategi för incidentkommunikation.

NIS2 lägger till en parallell modell för ansvar. Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner åtgärder för hantering av cybersäkerhetsrisker, övervakar genomförandet och får utbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder baserade på ett allriskperspektiv, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, kontrolleffektivitet, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, policy för tillgångshantering och MFA där det är lämpligt.

För finansiella entiteter behandlas DORA som en sektorsspecifik unionsrättsakt där överlappande NIS2-skyldigheter är tillämpliga. I praktiken ersätter DORA i regel överlappande NIS2-krav på riskhantering och incidentrapportering för finansiella entiteter inom sitt tillämpningsområde, medan NIS2 fortsatt är viktigt för samordning och för leverantörer utanför DORA:s direkta skyldigheter för finansiella entiteter. För SaaS-, moln-, hanterade tjänste- och hanterade säkerhetsleverantörer kan NIS2 vara direkt tillämpligt när omfattningsvillkoren är uppfyllda.

Därför är styrelsegodkänd IKT-riskaptit inte längre en artefakt för finansiell risk. Den är en kontroll för cybersäkerhetsstyrning.

Använd ISO/IEC 27001:2022 som operativ modell

DORA och NIS2 anger vad ledningen måste styra. ISO/IEC 27001:2022 ger organisationer en praktisk operativ modell för hur styrningen ska ske.

ISO/IEC 27001:2022 Clauses 4.1 till 4.4 kräver att organisationen definierar kontext, intressenter, krav, ISMS-omfattning och ISMS-processer. Detta är viktigt eftersom DORA, NIS2, GDPR, avtal, tillsynsförväntningar, kunder, molnleverantörer och outsourcingarrangemang alla blir krav som påverkar riskkriterierna.

Clauses 5.1 till 5.3 kräver ledarskapsåtagande, policyanpassning, resurser, ansvar och rapportering av ISMS-prestanda till högsta ledningen. Clauses 6.1.1 till 6.1.3 kräver riskbaserad planering, en dokumenterad riskbedömningsprocess, kriterier för riskacceptans, konsekventa bedömningskriterier, riskägare, jämförelse mot riskkriterier, planering av riskbehandling, en tillämpbarhetsförklaring och godkännande av kvarstående risk.

Detta är grunden för IKT-risktolerans enligt DORA.

I riskhanteringsfasen anger steg 10 i Zenith Blueprint att organisationer ska definiera riskkriterier innan risker bedöms:

”Riskkriterier är de regler och riktmärken som organisationen använder för att bedöma betydelsen av varje risk. Genom att fastställa dessa kriterier i förväg säkerställs att alla använder samma riskspråk.”

Samma steg varnar för att regulatorisk påverkan måste byggas in i riskdefinitionerna:

”Varje risk som kan leda till bristande efterlevnad av tillämpliga lagar (GDPR osv.) är inte acceptabel och måste reduceras.”

Zenith Blueprint ger också praktisk vägledning för konsekvensskalor:

”När konsekvens definieras är det klokt att koppla nivåerna till organisationens specifika verksamhetsskala. Exempel: ’Stor finansiell påverkan = förlust > 100 000 USD’ (anpassa till er kontext). Beakta även regulatorisk påverkan: en personuppgiftsincident kan till exempel automatiskt vara ’Stor’ eller ’Allvarlig’ på grund av GDPR-sanktionsavgifter och anmälningskrav, även om den direkta ekonomiska förlusten är oklar. På motsvarande sätt kan en incident som orsakar tjänsteavbrott vara minst ’Stor’ om ni omfattas av NIS2 (väsentliga tjänster), på grund av rättsliga konsekvenser. Ta med sådana överväganden i era definitioner.”

Den vägledningen förhindrar ett vanligt fel: att bedöma en cyberrisk som medel därför att den omedelbara finansiella förlusten verkar liten, samtidigt som rättslig påverkan, operativ resiliens, påverkan på registrerade eller kundpåverkan förbises.

En styrelseanpassad modell ska separera fyra lager:

Denna struktur gör riskaptit granskningsbar eftersom varje uttalande kan spåras till riskkriterier, kontroller, underlag och beslut.

En styrelseanpassad IKT-riskaptitförklaring enligt DORA

En stark IKT-riskaptitförklaring är tillräckligt kort för att styrelsen ska kunna godkänna den, tillräckligt specifik för att ledningen ska kunna tillämpa den och tillräckligt mätbar för att revisorer ska kunna testa den. Den bör undvika jargong, men får inte vara vag.

En praktisk övergripande formulering kan vara:

”Vårt företag har låg riskaptit för IKT-risker som kan leda till väsentlig skada för kunder, avbrott i kritiska eller viktiga funktioner, obehörigt röjande eller ändring av reglerade data, underlåtenhet att uppfylla rättsliga skyldigheter eller förlorad resiliens i kritiska IKT-tredjepartstjänster.”

Den formuleringen måste därefter kompletteras med mätbara toleranströsklar och eskaleringstriggers.

Denna tabell förändrar samtalet. Styrelsen godkänner inte längre en slogan. Den godkänner operativa gränser för tillgänglighet, konfidentialitet, riktighet, leverantörer, sårbarheter, återställning och efterlevnad.

Clarysecs Riskhanteringspolicy stödjer denna styrningsmodell. Företagspolicyn anger:

”Godkänner riskhanteringsramverket och definierar acceptabel riskaptit och toleranströsklar.”

Clause 6.2.1 gör mätkravet uttryckligt:

”Risker ska bedömas avseende sannolikhet och konsekvens med hjälp av en standardiserad riskmatris med tydligt definierade poängskalor.”

Clause 6.3.4 skapar den acceptansregel som revisorer förväntar sig:

”Risker som accepteras utan behandling ska motiveras skriftligen, kopplas till organisationens riskaptit och godkännas på rätt nivå.”

För små och medelstora företag behåller Riskhanteringspolicy för små och medelstora företag samma styrningsprincip i ett lättare format:

”Säkerställ att ledningen medverkar i godkännande av risktolerans och större riskbehandlingsplaner.”

Den kräver också eskalering av höga risker:

”Höga risker måste eskaleras till den verkställande chefen för beslut.”

Detta är proportionalitet i praktiken. DORA Article 4 kräver att krav tillämpas proportionerligt i förhållande till storlek, riskprofil samt tjänsternas art, omfattning och komplexitet. ISO/IEC 27001:2022 möjliggör samma princip genom omfattning, kontext, riskkriterier och riskbehandlingsbeslut. Styrningsstandarden är inte att varje organisation behöver samma kommittéstruktur. Styrningsstandarden är att riskaptit, tolerans, eskalering och acceptans definieras, godkänns, styrks med underlag och används.

GDPR Article 32 förändrar risksamtalet

GDPR Article 32 behandlas ofta som en teknisk säkerhetsklausul. Ur styrningsperspektiv är den också en riskaptitklausul.

Article 32 kräver att personuppgiftsansvariga och personuppgiftsbiträden genomför lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken. Den riskbaserade ansatsen beaktar den senaste utvecklingen, genomförandekostnader, behandlingens art, omfattning, sammanhang och ändamål samt risker för fysiska personers rättigheter och friheter.

Detta påverkar IKT-riskaptit på tre sätt.

För det första kan påverkan på personuppgifter inte reduceras till ekonomisk förlust. En liten databasexponering kan ha begränsad direkt kostnad men allvarliga konsekvenser för konfidentialitet, identitet, bedrägeri, diskriminering eller enskildas rättigheter. Om särskilda kategorier av personuppgifter berörs, exempelvis hälsodata, biometriska data eller genetiska data, bör riskaptiten vara väsentligt lägre.

För det andra måste behandlingsroller kopplas till riskägarskap. GDPR skiljer mellan personuppgiftsansvariga och personuppgiftsbiträden. DORA skiljer mellan finansiella entiteter och IKT-tredjepartstjänsteleverantörer. NIS2 skiljer mellan väsentliga och viktiga entiteter. ISO/IEC 27001:2022 kräver riskägare. En mogen riskaptitförklaring bör identifiera vem som äger riskbeslut som rör personuppgifter, outsourcad behandling, kritiska tjänster och gränsöverskridande beroenden.

För det tredje bör proportionaliteten i Article 32 vara synlig i urvalet av kontroller. Kryptering, pseudonymisering, åtkomstkontroll, säkerhetskopiering, loggning, övervakning, incidentrespons och resiliens är inte isolerade tekniska uppgifter. De är riskbehandlingsåtgärder som valts därför att en risk överskred riskaptit eller tolerans.

Clarysecs Riskhanteringspolicy gör denna koppling explicit:

”Article 32: Föreskriver en riskbaserad ansats till säkerhetsåtgärder, uppfylld genom konsekvensbaserade riskbedömningar och urval av kontroller.”

Det är den operativa koppling revisorer söker: krav enligt Article 32, riskbedömning, riskklassning, riskbehandlingsplan, urval av kontroller, kvarstående risk och godkännande.

Hur Zenith Controls stödjer tvärgående efterlevnadsunderlag

En styrelsegodkänd riskaptitförklaring blir kraftfull när den mappas till kontroller. Zenith Controls fungerar som Clarysecs vägledning för tvärgående regelefterlevnad och hjälper team att återanvända underlag mellan ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF och COBIT-liknande säkerhetsgranskning.

Tre kontrollområden i ISO/IEC 27002:2022 är särskilt viktiga:

Detta är inte en pappersövning för mappning. Det förändrar hur beslut fattas.

Om en verksamhetsägare vill acceptera en försenad MFA-utrullning för administratörer hjälper Zenith Controls informationssäkerhetschefen att visa varför detta inte bara är en fråga om åtkomstkontroll. Det berör policystyrning, ledningsansvar, rättsliga och regulatoriska krav, GDPR-säkerhet i behandlingen, DORA IKT-riskhantering, NIS2-cybersäkerhetsåtgärder, incidentpåverkan och revisionsbevis.

Om ett produktteam vill lansera på en ny EU-marknad med en ny molntjänst för ISO/IEC 27002:2022 control 5.31 in granskningen av rättsliga och regulatoriska krav i ISMS-omfattningen. ISO/IEC 27001:2022 Clause 4.2 kräver att krav från intressenter identifieras, inklusive rättsliga, regulatoriska och avtalsmässiga skyldigheter. Clause 8.1 kräver operativ planering och styrning, inklusive styrning av externt tillhandahållna processer, produkter eller tjänster som är relevanta för ISMS.

Målet är ett gemensamt riskspråk, inte separata efterlevnadsdialekter.

Godkännandearbetsflöde: vem beslutar vad

En informationssäkerhetschef kan föreslå IKT-riskaptit, men styrelsen eller ledningsorganet måste äga den. Det ägarskapet behöver ett arbetsflöde.

Detta ligger också i linje med NIST CSF 2.0. Funktionen GOVERN, särskilt GV.RM, förväntar sig överenskomna mål för riskhantering, riskaptit- och toleransförklaringar, riskaktiviteter integrerade i organisationens riskhantering, definierade alternativ för riskrespons, kommunikationsvägar och standardiserade metoder för att beräkna, dokumentera, kategorisera och prioritera cybersäkerhetsrisker. GV.RR förväntar sig ledningens ansvar, roller, befogenheter och resurser anpassade till riskstrategin. GV.PO förväntar sig att policyer fastställs, kommuniceras, tillämpas, granskas och uppdateras.

COBIT 19- och ISACA-orienterade specialister inom säkerhetsgranskning kommer att fråga om riskaptit är integrerad i verksamhetsstyrningen av information och teknik, inte bara bifogad som en bilaga till en cyberpolicy.

Bygg ett IKT-riskaptitpaket under en arbetssession

En praktisk workshop om IKT-riskaptit kan flytta en organisation från spridda register till ett styrelseunderlag som kan granskas.

Steg 1: samla rätt underlag

Förbered aktuellt IKT-riskregister, Business Impact Analysis (BIA), återställningsmål, lista över kritiska eller viktiga funktioner, tillgångsförteckning för IKT, tjänsteförteckning för IKT, register över leverantörs- och molnberoenden, kriterier för incidentklassificering, GDPR-behandlingsförteckning, DPIA:er där det är relevant, register över rättsliga skyldigheter, policyer, tillämpbarhetsförklaring och befintlig riskaptitförklaring för organisationen.

Detta ligger i linje med ISO/IEC 27001:2022 Clauses 4, 6 och 8 samt NIST CSF-profilmetoder som utgår från verksamhetsprioriteringar, riskprioriteringar, krav, skyddsåtgärder och roller.

Steg 2: definiera konsekvensskalor som inkluderar reglering

Använd steg 10 i Zenith Blueprint för att definiera sannolikhet och konsekvens på verksamhetsspråk. Inkludera finansiell förlust, driftstörning, kundpåverkan, anseendeskada, rättslig och regulatorisk påverkan, skada för registrerade och påverkan på kritiska funktioner.

Exempelvis kan ”Stor” konsekvens omfatta ett långvarigt avbrott i en kritisk tjänst, bekräftad personuppgiftsincident som kräver anmälan, underlåtenhet att uppfylla en DORA-incidentrapporteringsskyldighet eller leverantörsfel som påverkar en kritisk eller viktig funktion.

Steg 3: skriv riskaptit per område

Skapa inte en generell cyberriskaptit. Definiera områden som tillgänglighet för kritiska tjänster, konfidentialitet för personuppgifter, dataintegritet, privilegierad åtkomst, IKT-beroende av tredje part, molnkoncentration, sårbarhetsexponering, beredskap för incidentrapportering, säkerhetskopiering och återställning samt ändringsrisk i säker utveckling.

För varje område, skriv en riskaptitförklaring, en eller flera toleranströsklar och eskaleringstriggers.

Steg 4: koppla behandling till tillämpbarhetsförklaringen

Steg 13 i Zenith Blueprint instruerar organisationer att välja riskbehandlingsalternativ: reducera, undvika, överföra eller acceptera. Det betonar också ledningens godkännande:

”Riskbehandlingsbeslut och SoA bör granskas och godkännas av högsta ledningen.”

För DORA och NIS2 är detta underlag för att ledningsorganet eller delegerad ledning har granskat nyckelrisker, behandlingar och accepterad kvarstående exponering. För GDPR stödjer det ansvarsskyldighet genom att visa varför valda åtgärder var lämpliga i förhållande till risken.

Steg 5: dokumentera acceptans med utgångsdatum och villkor

Varje accepterad medelhög eller hög kvarstående risk ska omfatta:

• Risk-ID och ägare
• Verksamhetsmässig motivering
• Hänvisning till riskaptitförklaring
• Påverkad toleranströskel
• Rättslig och regulatorisk analys
• Kompenserande kontroller
• Utgångs- eller granskningsdatum
• Godkännare
• Plats för underlag
• Trigger för att öppna beslutet på nytt

Riskhanteringspolicy för små och medelstora företag anger:

”Varje beslut att acceptera eller skjuta upp behandling av en hög eller medelhög risk måste dokumenteras i riskregistret. Denna dokumentation måste omfatta:”

I företagsmiljöer blir detta ett godkännandearbetsflöde och ett paket till riskkommittén. I mindre organisationer kan det vara en strukturerad flik i riskregistret med ledningens godkännande. Poängen är inte byråkrati. Poängen är försvarbarhet.

Incidenttolerans: där riskaptit möter klockan

Riskaptit blir verklig under incidenter.

DORA Article 17 kräver att finansiella entiteter inrättar en IKT-relaterad incidenthanteringsprocess för att detektera, hantera och anmäla incidenter, registrera alla incidenter och betydande cyberhot, identifiera rotorsaker, använda tidiga varningsindikatorer, klassificera incidenter efter prioritet, allvarlighetsgrad och tjänstekritikalitet, tilldela roller, kommunicera med intressenter, eskalera åtminstone större IKT-relaterade incidenter till högsta ledningen och ledningsorganet samt återställa säker drift i rätt tid.

DORA Article 18 klassificerar incidenter med faktorer som berörda kunder, varaktighet, driftstopp, geografisk spridning, dataförluster som påverkar tillgänglighet, autenticitet, riktighet eller konfidentialitet, kritikalitet hos berörda tjänster och ekonomisk påverkan. Article 19 kräver att större IKT-relaterade incidenter rapporteras till behörig myndighet, med information till kunder där deras finansiella intressen påverkas.

NIS2 Article 23 har stegvis rapportering för betydande incidenter, inklusive tidig varning utan onödigt dröjsmål och, där tillämpligt, inom 24 timmar, incidentanmälan utan onödigt dröjsmål och, där tillämpligt, inom 72 timmar, mellanliggande uppdateringar på begäran och en slutrapport senast en månad efter incidentanmälan. Betydande incidenter omfattar sådana som orsakar allvarlig driftstörning, finansiell förlust eller materiell eller immateriell skada för andra.

Riskaptitförklaringen ska definiera eskaleringströsklar innan incidenten inträffar.

Annex A-kontroller för incidentplanering, bedömning av informationssäkerhetshändelser, incidentrespons, erfarenhetsåterföring från incidenter, bevisinsamling, upprätthållande av informationssäkerhet vid störning och IKT-beredskap för verksamhetskontinuitet stödjer alla dessa trösklar. NIST CSF-resultat inom IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER stödjer samma operativa modell, inklusive säkerhetskopiering, övervakning, incidentdeklaration, eskalering, rotorsaksanalys, kommunikation med intressenter och verifiering av återställning.

Leverantörs- och molntolerans som styrelser ofta missar

DORA gör IKT-tredjepartsrisk till en central efterlevnadsskyldighet. Article 28 kräver att finansiella entiteter hanterar IKT-tredjepartsrisk som en del av IKT-riskhanteringsramverket samtidigt som de förblir fullt ansvariga för regelefterlevnad. Den kräver strategi för IKT-tredjepartsrisk, register över avtalsarrangemang för IKT-tjänster, åtskillnad av tjänster som stödjer kritiska eller viktiga funktioner, årlig rapportering, avisering av planerade arrangemang, bedömningar före avtal, leverantörsgranskning, revisions- och inspektionsrättigheter, rätt att säga upp avtalet och dokumenterade exitstrategier.

Article 29 lägger till analys av koncentrationsrisk, inklusive bristande utbytbarhet, flera beroenden av samma eller anslutna leverantörer, underentreprenörsrisker, underentreprenörer i tredjeland, efterlevnad av dataskydd, möjlighet att göra avtalsvillkor gällande och komplexa underentreprenörskedjor. Article 30 kräver skriftliga avtalsenliga rättigheter och skyldigheter, tjänstebeskrivningar, platser, säkerhetsskydd, dataåtkomst och återlämnande, servicenivåer, incidentstöd, samarbete med myndigheter, rätt att säga upp avtalet, testade beredskapsplaner, övervakning och exitarrangemang.

En styrelsegodkänd leverantörstoleransförklaring kan lyda:

”Vi har låg riskaptit för att kritiska eller viktiga funktioner är beroende av en IKT-tredjepartsleverantör där vi saknar avtalsenliga revisionsrättigheter, testade exitarrangemang, skyldigheter för incidentavisering, servicenivåmål, rätt till återlämnande av data eller insyn i väsentliga underentreprenörer.”

Den meningen ger upphandling en praktisk regel. Om avtalet inte uppfyller tröskeln kan risken inte accepteras i det tysta av projektteamet.

Hur revisorer kommer att testa er IKT-riskaptit

En stark riskaptitförklaring utformas med revision i åtanke.

Steg 28 i Zenith Blueprint, i fasen för revision, granskning och förbättring, förstärker lagret för ledningens genomgång. Det instruerar organisationer att samla in underlag såsom förändringar i externa och interna frågor, ISMS-prestanda, revisionsresultat, övervakning och mätning, incidenter, avvikelser, förbättringsmöjligheter och resursbehov. Det anger också att ledningens genomgång måste leda till beslut och åtgärder, inte enbart presentationer.

Minst årligen, och när väsentliga ändringar sker, ska ledningen granska om toleranströsklar fortfarande är anpassade till affärsmodellen, om incidenter har överskridit riskaptiten, om accepterade risker fortsatt ligger inom godkända gränser, om nya krav från DORA, NIS2, GDPR eller avtal har ändrat baslinjen, om leverantörer fortsatt ligger inom koncentrationstoleranserna och om KRI:er orsakar eskalering i rätt tid.

Om svaret är nej måste riskaptitförklaringen ändras, eller kontrollerna göra det.

Vanliga felmönster i beredskapsarbete 2026

I projekt kopplade till DORA, NIS2, GDPR och ISO/IEC 27001:2022 återkommer samma svagheter:

• Riskaptit utan trösklar, där styrelsen godkänner ett uttalande men ingen kan säga när det har överträtts.
• Trösklar utan befogenhet, där allvarlighetsnivåer finns men riskägare kan acceptera undantag utan godkännande från högre ledning.
• Rättslig risk utanför poängmodellen, där GDPR, DORA, NIS2 och avtal listas separat men inte byggs in i konsekvenskriterier.
• Leverantörstolerans saknas i styrelseunderlaget, trots att kritiska IKT-beroenden är kända av upphandling eller IT.
• Ledningens genomgång som teater, där bilder presenteras men beslut, åtgärder, resursbehov och riskacceptanser inte dokumenteras.
• Fragmenterat revisionsunderlag, där policyer, register, KRI:er, incidentrapporter, leverantörsgranskningar och styrelseprotokoll finns på olika platser utan korshänvisning.

Clarysecs metod är utformad för att stänga dessa luckor. Zenith Blueprint ger den fasindelade genomförandevägen. Riskhanteringspolicy och Riskhanteringspolicy för små och medelstora företag ger styrningsklausuler anpassade till både företagsmiljöer och små och medelstora företag. Zenith Controls mappar kontrollstommen över informationssäkerhetspolicy, ledningsansvar och rättsliga eller regulatoriska krav, vilket gör underlag återanvändbart mellan ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF och COBIT-liknande säkerhetsgranskning.

Gör styrelsens avsikt till granskningsbar IKT-riskstyrning

Om er organisation har ett riskregister men inte kan visa en styrelsegodkänd IKT-riskaptit, mätbara toleranströsklar, eskaleringstriggers och formella acceptansregler är luckan inte kosmetisk. Den påverkar DORA-styrning, NIS2-ledningsansvar, försvarbarhet enligt GDPR Article 32 och revisionsberedskap enligt ISO/IEC 27001:2022.

Ett praktiskt nästa steg är att genomföra en fokuserad workshop om IKT-riskaptit med Clarysecs verktygslåda:

1. Använd Zenith Blueprint steg 10 för att definiera riskkriterier och konsekvensskalor.
2. Använd Zenith Blueprint steg 13 för att koppla behandlingsalternativ, kvarstående risk och godkännande av tillämpbarhetsförklaringen.
3. Använd Zenith Blueprint steg 14 för att korshänvisa skyldigheter enligt GDPR, NIS2 och DORA.
4. Använd Zenith Blueprint steg 28 för att föra in riskaptit, KRI:er, accepterade risker och resursbeslut i ledningens genomgång.
5. Tillämpa Riskhanteringspolicy eller Riskhanteringspolicy för små och medelstora företag för att formalisera regler för godkännande och acceptans.
6. Använd Zenith Controls för att mappa styrningskontroller till revisionsbevis och förväntningar på tvärgående regelefterlevnad.

Clarysec kan hjälpa er att omvandla spridda riskartefakter till en styrelsegodkänd, regulatoriskt redo modell för IKT-riskaptit som era team kan använda när nästa molnavbrott, leverantörsfel, sårbarhetsrapportering eller personuppgiftsincident testar organisationens faktiska tolerans.