Kontinuerlig efterlevnadsövervakning för NIS2 och DORA

Fredagseftermiddagsfrågan som varje informationssäkerhetschef nu måste kunna besvara

Klockan 16.40 en fredag får informationssäkerhetschefen för en molnbaserad betalningsplattform tre meddelanden inom tio minuter.

Det första kommer från CFO:n: ”Vår bankpartner vill ha uppdaterat underlag som visar att vi uppfyller DORA-förväntningarna för IKT-tredjepartsrisk och incidentrapportering.”

Det andra kommer från chefsjuristen: ”Vår hanterade säkerhetstjänst kan innebära att vi omfattas av nationellt genomförande av NIS2. Kan vi visa ledningens tillsyn och kontrolleffektivitet?”

Det tredje kommer från utvecklingschefen: ”Vi har patchat den kritiska sårbarheten, men backloggen visar 38 försenade medelallvarliga iakttagelser. Behöver vi eskalera?”

Det är då årlig efterlevnad faller samman.

En policy-PDF, ett riskregister som senast uppdaterades före föregående revision och en mapp med skärmdumpar räcker inte för NIS2 och DORA. Dessa regelverk förutsätter levande styrning, ledningens tillsyn, incidentflöden, leverantörsinsyn, resiliensövningar, korrigerande åtgärder och verifierbar kontrolleffektivitet.

För många informationssäkerhetschefer är trycket inte teoretiskt. Införlivandet av NIS2 i EU:s medlemsstater har flyttat cybersäkerhet från ett tekniskt program till en fråga om ledningens ansvarsskyldighet. DORA gäller från den 17 januari 2025 och ger finansiella entiteter ett sektorspecifikt regelverk för digital operativ resiliens avseende IKT-risk, incidentrapportering, testning och tredjepartsrisk. Moln, SaaS, hanterade tjänster, hanterad säkerhet, datacenter, innehållsleverans, betrodda tjänster och leverantörer av allmänna elektroniska kommunikationstjänster kan också omfattas av direkta eller indirekta skyldigheter beroende på omfattning, storlek, sektor, nationell klassificering och kundavtal.

Den praktiska frågan är inte längre: ”Har vi en kontroll?”

Den är: ”Vem äger kontrollen, vilket mätetal visar att den fungerar, hur ofta samlar vi in underlag och vad händer när mätetalet fallerar?”

Detta är kärnan i kontinuerlig efterlevnadsövervakning för NIS2 och DORA. I Clarysec-införanden använder vi ISO/IEC 27001:2022 som ryggrad för ledningssystemet, ISO/IEC 27002:2022 som kontrollspråk, Zenith Blueprint: revisorns 30-stegsfärdplan som införandesekvens och Zenith Controls: guiden för korsvis efterlevnad som kompass för korsvis efterlevnad som kopplar ISO/IEC 27001:2022-underlag till NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 och revisionsförväntningar.

Varför NIS2 och DORA gör periodisk efterlevnad otillräcklig

NIS2 och DORA skiljer sig åt i rättslig struktur, tillsynsmodell och omfattning, men skapar samma operativa tryck. Cybersäkerhet och IKT-resiliens måste styras kontinuerligt.

NIS2 kräver att väsentliga och viktiga entiteter tillämpar lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder med en allriskansats. Dessa åtgärder omfattar riskanalys, policyer för informationssystemsäkerhet, incidenthantering, verksamhetskontinuitet, krishantering, säkerhet i leveranskedjan, säker anskaffning och utveckling, hantering av sårbarheter, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och flerfaktorsautentisering när det är lämpligt. Ledningsorgan ska godkänna riskhanteringsåtgärder för cybersäkerhet, övervaka genomförandet och genomgå utbildning.

DORA gör detta ännu tydligare för finansiella entiteter. Förordningen kräver interna styrnings- och kontrollarrangemang för IKT-risk, ett dokumenterat ramverk för IKT-riskhantering, ansvar för ledningsorganet, IKT-relaterad incidenthantering och rapportering, testning av digital operativ resiliens, hantering av IKT-tredjepartsrisk, uppföljning av revision, utbildning och kommunikationsarrangemang. DORA klargör också att finansiella entiteter förblir ansvariga för efterlevnad när de använder IKT-tredjepartstjänsteleverantörer.

Detta skapar en ny efterlevnadsverklighet. En informationssäkerhetschef kan inte vänta till revisionsmånaden med att upptäcka att:

• granskningar av privilegierad åtkomst har missats under två kvartal;
• leverantörers exitplaner har dokumenterats men aldrig testats;
• kriterier för incidenters allvarlighetsgrad inte mappar mot tröskelvärden för regulatorisk rapportering;
• säkerhetskopior är konfigurerade men underlag för återställning saknas;
• ledningen aldrig har granskat försenade riskbehandlingar;
• molnavtal saknar revisionsrätt, insyn i underleverantörer eller klausuler om incidentavisering.

Den gamla projektbaserade modellen skapar panikcykler. Teamen stressar inför en revision, samlar in skärmdumpar, uppdaterar policydatum och hoppas att underlaget berättar en sammanhängande historia. NIS2 och DORA är utformade för att få den metoden att fallera. De fokuserar på ansvarsskyldighet, proportionalitet, resiliens och underlag som visar att kontrollerna faktiskt fungerar.

ISO/IEC 27001:2022 tillhandahåller operativsystemet för detta problem. Standardens klausuler kräver att organisationer förstår kontext, intressenter, rättsliga och avtalsmässiga krav, omfattning, ledarskap, roller, riskbedömning, riskbehandling, tillämpbarhetsförklaring, operativ planering, prestandautvärdering, internrevision, ledningens genomgång, hantering av avvikelser och ständig förbättring. Den strukturen är idealisk för att kombinera NIS2, DORA, GDPR, program för kundförsäkran och intern risk i en gemensam modell för kontinuerlig övervakning.

Kontinuerlig efterlevnad handlar inte om fler kontrollpaneler. Det handlar om en styrd frekvens för bevisinsamling.

Bygg efterlevnadsmotorn på ISO/IEC 27001:2022

Många organisationer missförstår ISO/IEC 27001:2022 som enbart ett certifieringsramverk. I praktiken är det ett riskhanteringssystem för att göra säkerhetsstyrning repeterbar, mätbar och möjlig att granska.

Det är viktigt eftersom NIS2 och DORA inte är isolerade checklistor. De kräver en operativ modell som kan fånga upp rättsliga krav, översätta dem till kontroller, tilldela ägarskap, övervaka prestanda och förbättra när luckor identifieras.

De grundläggande ISO/IEC 27001:2022-klausulerna tillhandahåller den modellen:

För en FinTech, SaaS-leverantör, leverantör av hanterade säkerhetstjänster eller IKT-leverantör till finansiella entiteter förhindrar denna struktur dubbla efterlevnadsprojekt. Ett ISMS kan mappa skyldigheter till kontroller en gång och därefter återanvända underlag för NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, ISO/IEC 27001:2022-certifiering och granskningar inom kundförsäkran.

Börja med kontrollägarskap, inte verktyg

Det första felmönstret vid kontinuerlig efterlevnad är verktygsstyrt införande. Ett företag köper en GRC-plattform, importerar hundratals krav, tilldelar allt till ”Security” och kallar det kontinuerlig övervakning. Sex månader senare är kontrollpanelen röd, utvecklingsteamet bestrider sårbarhetsunderlaget, juridik säger att leverantörsdokumenten är ofullständiga och ledningen kan inte se kvarstående risk tydligt.

ISO/IEC 27001:2022 undviker detta genom att kräva att ansvar och befogenheter tilldelas och kommuniceras. NIS2 och DORA förstärker samma förväntan genom ledningens ansvarsskyldighet, definierade roller och tillsyn.

Clarysecs Policy för styrningsroller och ansvar – SME anger:

Varje roll med säkerhetsansvar ska registreras i en central logg och bekräftas skriftligen.

Den klausulen är viktigare än de flesta kontrollpaneler. Om testning av säkerhetskopiering, åtgärdande av sårbarheter, leverantörsgranskning, incidentklassificering och granskning av privilegierad åtkomst saknar namngivna ägare finns ingen tillförlitlig frekvens för bevisinsamling.

Informationssäkerhetspolicyn gör detta operativt för företagsmiljöer:

Samla in och bevara revisionsbevis för revisioner och kontrollgranskningar.

Den kräver också att kontrollägare ska:

Rapportera kontrollprestanda och eventuella luckor eller problem till ISMS-ansvarig.

I Zenith Controls mappar detta område direkt till ISO/IEC 27002:2022-kontroll 5.2 Roller och ansvar för informationssäkerhet, 5.35 Oberoende granskning av informationssäkerhet och 5.36 Efterlevnad av policyer, regler och standarder för informationssäkerhet.

Zenith Blueprint ger en praktisk startpunkt i fasen ISMS Foundation & Leadership, steg 4: Roller och ansvar i ISMS. Den rekommenderar formell utnämning, uppdateringar av befattningsbeskrivningar, anpassning till KPI:er, organisationsövergripande kommunikation och ansvar på avdelningsnivå.

En typisk utnämningspost kan lyda:

”Med omedelbar verkan utses du till informationssäkerhetsansvarig med ansvar för att övervaka och samordna ISMS, inklusive riskhantering, genomförande av kontroller och övervakning av efterlevnad.”

Den utnämningen är inte byråkrati. Den är revisionsbevis för ISO/IEC 27001:2022-ledarskap och rolltilldelning. Den stödjer också ledningens tillsyn enligt NIS2 och DORA-styrning. Tillsynsmyndigheter, certifieringsrevisorer och bankkunder vill se att ansvar inte är underförstått. Det är tilldelat, bekräftat, resurssatt och övervakat.

Ett praktiskt register över kontrollägarskap ska innehålla följande fält:

Detta register blir bryggan mellan policy och bevis.

Definiera KPI:er och KRI:er som visar kontrolleffektivitet

När ägare finns behöver de veta vad ”bra” innebär. Kontinuerlig efterlevnadsövervakning bygger på meningsfulla indikatorer, inte breda ambitioner.

”Förbättra patchning” är inte en KPI. ”Granska leverantörer regelbundet” är inte underlag. ”Upprätthåll resiliens” är inte en mätbar kontroll.

Clarysec skiljer tydligt mellan de två indikatortyperna:

• KPI, Key Performance Indicator, mäter om processen fungerar som förväntat.
• KRI, Key Risk Indicator, signalerar ökande risk eller att ett tröskelvärde har överskridits och kräver eskalering.

Organisationens Riskhanteringspolicy anger:

KRI:er (Key Risk Indicators) och säkerhetsmätetal ska definieras för kritiska risker och övervakas månadsvis.

Den kräver också eskaleringslogik:

Eskaleringsutlösare ska bäddas in i övervakningslogiken, till exempel när kvarstående risk ökar med mer än en nivå eller när tidsfrister för behandling missas.

För mindre organisationer använder Clarysecs Riskhanteringspolicy – SME en proportionerlig ansats:

Framsteg i riskreducering ska granskas kvartalsvis.

Den tillåter också lättviktiga mätetal:

Informella mätetal får följas upp, till exempel antal öppna risker, försenade åtgärder och nya incidenter.

Den proportionaliteten är viktig. En multinationell bank och en FinTech-leverantör med 60 anställda behöver inte identisk telemetri, men båda behöver tilldelat ägarskap, repeterbar mätning, eskaleringströsklar och underlag för korrigerande åtgärder.

En praktisk KPI- och KRI-modell för NIS2 och DORA ser ut så här:

Dessa mätetal stödjer mer än ISO/IEC 27001:2022-certifiering. De stödjer även NIS2:s riskhanteringsåtgärder för cybersäkerhet, beredskap för NIS2-incidentrapportering, DORA:s IKT-riskhantering, DORA:s tredjepartsrisk, GDPR:s ansvarsskyldighet, styrningsresultat enligt NIST CSF 2.0 och COBIT-liknande prestandahantering.

Fastställ frekvensen för bevisinsamling innan revisionen efterfrågar den

Många organisationer samlar in underlag slumpmässigt. En skärmdump hamnar i en Teams-kanal. Ett Jira-ärende länkas i ett e-postmeddelande. Ett leverantörsfrågeformulär lagras hos upphandling. Ett säkerhetskopieringstest beskrivs muntligt. Under revisionsveckan blir ISMS-ansvarig en forensisk utredare.

Kontinuerlig efterlevnad kräver planerad frekvens och god underlagshygien.

Clarysecs Policy för revision och efterlevnadsövervakning – SME anger:

Varje revision ska omfatta definierad omfattning, mål, ansvarig personal och erforderligt underlag.

Den anger också:

Underlag ska bevaras i minst två år, eller längre om certifiering eller kundavtal kräver det.

För större organisationer lägger Policy för revision och efterlevnadsövervakning till förväntningar på automatisering:

Automatiserade verktyg ska införas för att övervaka konfigurationsefterlevnad, hantering av sårbarheter, patchstatus och privilegierad åtkomst.

Automatisering ska vara riktad. Högriskkontroller och högfrekventa kontroller ska inte vara beroende av manuella skärmdumpar. Den bästa bevismodellen kombinerar automatiserad telemetri, attesteringar från ägare, undantagsloggar, ärendeposter, testresultat och protokoll från ledningens genomgång.

En namngivningskonvention är också viktig. Underlag ska vara lätt att ta fram utan heroiska insatser. Exempel:

• veckovis sårbarhetsrapport: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• månadsvis granskning av privilegierad åtkomst: YYYY-MM_IAM-Privileged-Review_Attestation
• kvartalsvis leverantörsgranskning: YYYY-QX_Critical-Supplier-Review
• incidentpaket: INC-YYYY-###_Timeline-Classification-RCA-CAPA

Det är här policy blir operativ. Bevarande av underlag är inte en arkiveringsuppgift. Det är en del av kontrollen.

Mappa ett underlag till många skyldigheter

Kontinuerlig efterlevnad blir kraftfull när ett underlag uppfyller flera ramverk. Därför är Zenith Controls central i Clarysecs ansats för korsvis efterlevnad.

Tänk på incidenthantering. Enligt NIS2 kräver betydande incidenter stegvis rapportering, inklusive tidig varning inom 24 timmar från kännedom, anmälan inom 72 timmar och slutrapport inom en månad, med förbehåll för nationellt genomförande och incidentens fakta. DORA kräver att finansiella entiteter hanterar, klassificerar, eskalerar och rapporterar större IKT-relaterade incidenter med föreskrivna processer och mallar. GDPR kräver att personuppgiftsansvariga bedömer och hanterar personuppgiftsincidenter när personuppgifters konfidentialitet, riktighet eller tillgänglighet påverkas.

Ett enda incidentpaket med underlag kan stödja alla tre om det innehåller:

• incidentens tidslinje och tidpunkt för kännedom;
• klassificeringsmotivering;
• berörda tjänster och jurisdiktioner;
• påverkan på kunder, transaktioner eller användare;
• konsekvensbedömning av personuppgiftsincident;
• rotorsak;
• riskbegränsande åtgärder och återställningsåtgärder;
• kommunikation och aviseringar;
• registrering av ledningseskalering;
• post för korrigerande åtgärd.

Samma logik för korsvis efterlevnad gäller leverantörsrisk. NIS2 kräver säkerhet i leveranskedjan och uppmärksamhet på direkta leverantörs- och tjänsteleverantörsrelationer. DORA kräver strategi för IKT-tredjepartsrisk, register, leverantörsgranskning före avtal, avtalsklausuler, revisionsrätt, servicenivåer, exitstrategier och övervakning av koncentrationsrisk. NIST CSF 2.0 behandlar leveranskedjerisk som en styrningsdisciplin över hela livscykeln. ISO/IEC 27001:2022 kopplar dessa krav till omfattning, intressentkrav, riskbehandling och operativ styrning av externt tillhandahållna processer.

En praktisk bevismatris hjälper kontrollägare att förstå varför underlag är viktigt:

Denna ansats förhindrar dubbelt efterlevnadsarbete. Organisationen samlar in ett starkt underlagspaket och mappar det sedan till flera skyldigheter.

Clarysecs övervakningsmodell, från skyldighet till ägare till bevis

En robust övervakningsmodell följer en enkel sekvens.

Först definieras skyldigheten. DORA kräver till exempel att IKT-tredjepartsrisk hanteras som en del av IKT-riskhanteringen, med register, leverantörsgranskning, avtalskrav, revisionsrätt och exitstrategier för kritiska eller viktiga funktioner. NIS2 kräver säkerhet i leveranskedjan och lämpliga korrigerande åtgärder.

Därefter översätts skyldigheten till ISO/IEC 27001:2022 ISMS-krav. Detta omfattar intressentkrav, omfattning, riskbedömning, riskbehandling, tillämpbarhetsförklaring, operativ styrning, övervakning, internrevision, ledningens genomgång och förbättring.

Därefter väljs operativa kontroller. I Zenith Controls omfattar centrala styrningskontroller för kontinuerlig efterlevnad ISO/IEC 27002:2022-kontrollerna 5.2, 5.35 och 5.36. Stödjande kontroller omfattar ofta 5.19 Informationssäkerhet i leverantörsrelationer, 5.21 Hantering av informationssäkerhet i IKT-leveranskedjan, 5.22 Övervakning, granskning och ändringshantering av leverantörstjänster, 5.23 Informationssäkerhet vid användning av molntjänster, 5.24 Planering och förberedelse för hantering av informationssäkerhetsincidenter, 5.26 Respons på informationssäkerhetsincidenter, 5.30 IKT-beredskap för verksamhetskontinuitet, 5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav, 8.8 Hantering av tekniska sårbarheter, 8.13 Säkerhetskopiering av information, 8.15 Loggning, 8.16 Övervakningsaktiviteter och 8.9 Konfigurationshantering.

Därefter tilldelas ägare och frekvens. Leverantörsrisk kan involvera upphandling, juridik, säkerhet och verksamhetens tjänsteägare, men en ansvarsskyldig ägare måste underhålla registret och rapportera undantag.

Därefter definieras KPI:er, KRI:er och underlag. Leverantörs-KPI:er kan omfatta andel kritiska IKT-leverantörer med slutförd leverantörsgranskning, andel med godkända avtalsklausuler, antal utan testade exitplaner och antal försenade leverantörsgranskningar. KRI:er kan omfatta olösta högriskiakttagelser hos leverantörer, koncentrationsrisk över toleransnivå eller saknade revisionsrätter för en tjänst som stödjer en kritisk eller viktig funktion.

Därefter rapporteras och eskaleras. Månadsvisa ISMS-kontrollpaneler ska inte bara visa grön status. De ska identifiera försenat underlag, riskförändringar, missade behandlingsfrister och ledningsbeslut som krävs.

Slutligen revideras och förbättras. Luckor i underlag blir korrigerande åtgärder, inte ursäkter.

Detta ligger i linje med Zenith Blueprint-fasen Audit, Review & Improvement. Steg 25, Internal Audit Program, rekommenderar att relevanta ISMS-processer och kontroller täcks över revisionscykeln, med en årlig revision av full omfattning och mindre kvartalsvisa stickprovskontroller för högriskområden där det är lämpligt. Steg 28, Management Review, efterfrågar indata såsom ändringar i krav, resultat från övervakning och mätning, revisionsresultat, incidenter, avvikelser, förbättringsmöjligheter och resursbehov. Steg 29, Continual Improvement, använder CAPA-loggen för att fånga problembeskrivning, rotorsak, korrigerande åtgärd, ansvarig ägare, måldatum och status.

Det är kontinuerlig efterlevnad i praktiken.

Ett praktiskt scenario: kritisk sårbarhet i ett publikt API

Klockan 02.15 utlöses ett SIEM-larm. En sårbarhetsskanning har identifierat en kritisk sårbarhet för fjärrkörning av kod i en publik API-gateway som stödjer en reglerad betalningstjänst.

Modellen för kontinuerlig övervakning ska reagera utan att invänta ett möte.

Först klassificerar tillgångsförteckningen gatewayen som kritisk. KPI-klockan för hantering av sårbarheter startar. KRI:n för opatchade kritiska sårbarheter ökar. Om tillgången är internetexponerad och exploiten är aktiv utlöses eskaleringströskeln omedelbart.

Därefter dirigeras ärendet till DevOps-teamet i beredskap. DevOps-chefen, som kontrollägare för hantering av sårbarheter, får en automatiserad avisering. SOC-chefen följer upp om det finns indikatorer på exploatering. ISMS-ansvarig övervakar om incidentkriterierna är uppfyllda.

Därefter samlas underlag in som en biprodukt av arbetsflödet. SIEM-larmet, sårbarhetsskanningen, tillgångsklassificeringen, ärendets tidsstämplar, responschatten, patchposten, valideringsskanningen och stängningsgodkännandet bifogas underlagspaketet.

Därefter bedömer teamet om händelsen endast är en sårbarhet, en säkerhetshändelse eller en incident. Om tjänstepåverkan, indikatorer på kompromettering, kundpåverkan eller exponering av personuppgifter föreligger utlöser incidentflödet bedömningar av rapportering enligt NIS2, DORA, GDPR och avtal.

Slutligen får ledningen en kortfattad rapport. Om sårbarheten åtgärdades inom fyra timmar stödjer underlaget kontrolleffektivitet. Om SLA missades registrerar CAPA-loggen rotorsak, korrigerande åtgärd, ägare, måldatum och status.

Denna enskilda händelse genererar användbart underlag för hantering av sårbarheter, incidentberedskap, övervakning, åtkomst till kritiska tillgångar, ledningens genomgång och ständig förbättring.

Hur revisorer och tillsynsmyndigheter testar samma övervakningsmodell

Ett moget program för kontinuerlig efterlevnad måste tåla olika revisionsperspektiv. Underlaget förändras inte, men frågorna gör det.

För ISO/IEC 27002:2022-kontroll 5.35 Oberoende granskning av informationssäkerhet fokuserar en ISO/IEC 27001:2022-revisor på internrevisionsplan, omfattning, kompetens, iakttagelser och korrigerande åtgärder. En NIS2- eller DORA-tillsynsmyndighet fokuserar på om ledningen förstod iakttagelserna, finansierade åtgärdandet och minskade systemisk risk. En NIST CSF 2.0-bedömare kan mappa granskningen till GOVERN-funktionen, inklusive tillsyn och justering av prestanda.

Samma underlagspaket tjänar dem alla om det är fullständigt, aktuellt och kopplat till ägarskap.

Vanliga fallgropar som försvagar kontinuerlig efterlevnad

Den första fallgropen är att behandla NIS2 och DORA som separata projekt. Det skapar dubbla register, motstridiga mätetal och utmattade kontrollägare. Använd ISO/IEC 27001:2022 som ISMS-ryggrad och mappa skyldigheter via ett gemensamt kontrollbibliotek.

Den andra fallgropen är att tilldela kontroller till team i stället för personer. ”IT äger säkerhetskopior” räcker inte. En namngiven ägare måste attestera, rapportera undantag och eskalera risk.

Den tredje fallgropen är att samla in underlag utan att utvärdera effektivitet. En skärmdump som visar lyckad säkerhetskopiering bevisar inte återställningsförmåga. Ett återställningstest gör det. Ett leverantörsfrågeformulär bevisar inte tredjepartsresiliens. Avtalsklausuler, revisionsrätt, villkor för incidentavisering, prestandarapporter och exitplanering ger starkare underlag.

Den fjärde fallgropen är att mäta aktivitet i stället för risk. Att räkna sårbarheter är användbart. Att följa upp försenade kritiska sårbarheter i internetexponerade system är bättre. Att räkna leverantörer är användbart. Att följa upp kritiska leverantörer utan exitplaner är bättre.

Den femte fallgropen är svag disciplin för korrigerande åtgärder. Zenith Blueprint steg 29 är tydligt med att iakttagelser behöver problembeskrivning, rotorsak, korrigerande åtgärd, ansvarig ägare, måldatum och status. Om CAPA-loggen inte granskas blir kontinuerlig efterlevnad en kontinuerlig ackumulering av kända svagheter.

Vad ledningen bör se varje månad

Ledningsorgan enligt NIS2 och DORA behöver inte råa exportfiler från skannrar. De behöver en beslutsduglig bild av cyber- och IKT-risk.

En månadsvis styrelse- eller ledningspanel bör omfatta:

• de viktigaste cyber- och IKT-riskerna med förändring i kvarstående risk;
• försenade riskbehandlingar och missade tidsfrister;
• betydande incidenter, kandidater till större IKT-relaterade incidenter och erfarenhetsåterföring;
• kritiska undantag avseende leverantörsrisk;
• SLA-prestanda för sårbarheter i kritiska tillgångar;
• status för säkerhetskopierings- och återställningstester;
• undantag vid granskning av privilegierad åtkomst;
• slutförandegrad för efterlevnadsunderlag;
• revisionsiakttagelser och CAPA-status;
• resursbeslut som krävs.

Detta stödjer direkt ISO/IEC 27001:2022 ledningens genomgång och styrningsförväntningarna i NIS2 och DORA. Det ligger också i linje med NIST CSF 2.0, där ledande befattningshavare fastställer prioriteringar, ansvarsskyldighet, resurser och riskaptit medan chefer omsätter dessa prioriteringar i målprofiler och åtgärdsplaner.

Bygg er bevisrytm för NIS2 och DORA denna vecka

Ni behöver inte göra allt på en gång för att komma igång. En användbar första vecka kan vara enkel.

Dag 1: skapa ett register över kontrollägare för fem områden: styrning och riskhantering, incidenthantering och rapportering, hantering av sårbarheter och patchning, leverantörs- och molnrisk samt verksamhetskontinuitet och återställning.

Dag 2: definiera en KPI och en KRI för varje område. Håll dem specifika, mätbara och kopplade till riskaptit.

Dag 3: mappa varje underlag till värde för NIS2, DORA, ISO/IEC 27001:2022, GDPR och kundförsäkran.

Dag 4: fastställ frekvens för bevisinsamling, lagringsplats, namngivningskonvention, bevaranderegel och granskare.

Dag 5: genomför en skrivbordsövning för eskalering. Använd ett molnavbrott eller ett scenario med kritisk sårbarhet. Bekräfta klassificering, bedömning av regulatorisk rapportering, kundkommunikation, lagring av underlag och skapande av CAPA.

Om er organisation fortfarande hanterar NIS2 och DORA med kalkylblad, årliga workshoppar och utspridda underlagsmappar är det dags att gå över till en övervakad operativ rytm.

Börja med tre åtgärder:

1. Bygg ett register över kontrollägare för era högriskområden.
2. Definiera en KPI, en KRI, ett underlag och en frekvens per kontroll.
3. Genomför en 30-minuters granskning av underlag och öppna CAPA-poster för allt som saknas.

Clarysec kan hjälpa er att påskynda skiftet med Zenith Blueprint för införandesekvensering, Zenith Controls för mappning av korsvis efterlevnad och Clarysecs policybibliotek, inklusive Informationssäkerhetspolicyn, Riskhanteringspolicyn, Policy för revision och efterlevnadsövervakning, Policy för styrningsroller och ansvar – SME, Riskhanteringspolicy – SME och Policy för revision och efterlevnadsövervakning – SME.

Målet är inte mer efterlevnadsdokumentation. Målet är att kunna besvara fredagseftermiddagsfrågan med säkerhet:

”Ja, vi vet vem som äger kontrollen, vi känner till KPI:n, vi har underlaget, vi känner till undantagen och ledningen har granskat risken.”

Kontakta Clarysec för att bygga en modell för kontinuerlig efterlevnadsövervakning som är revisionsklar, styrelseklar och tillräckligt resilient för NIS2, DORA och nästa regelverk som följer.