ISO 27001 som ryggrad för revisionsbevis enligt NIS2 och DORA

Måndagsmorgonens krock mellan efterlevnadskrav

Klockan 08:12 på måndagen får Maria, informationssäkerhetschef hos en europeisk betalningsförmedlare, tre meddelanden som vid första anblick inte hänger ihop.

Internrevisionsansvarig begär underlag som visar att tillämpbarhetsförklaringen enligt ISO 27001:2022 är aktuell. Juridikteamet vidarebefordrar ett frågeformulär från en bankpartner om DORA och tillsyn över IKT-tredjepartsrisker. Driftchefen frågar om samma åtgärdsplan för incidenter kan stödja NIS2:s förväntningar på incidentrapportering för en nyförvärvad affärsenhet inom EU.

Klockan 09:00 är whiteboardtavlan på Marias kontor fylld med akronymer: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Organisationen har kontroller. Den har åtkomsthantering, säkerhetskopiering, leverantörsfrågeformulär, kryptering, incidenthantering, policygodkännanden, ledningens genomgång och register över genomförda utbildningar. Det den saknar är en samlad, revisionsklar bevisryggrad som förklarar varför kontrollerna finns, vilka risker de behandlar, vilka regelverk de stödjer, vem som äger dem och var bevismaterialet finns.

Detta problem blir allt vanligare i Europa. NIS2 driver krav på cybersäkerhetsriskhantering, styrning, incidenthantering och resiliens i leveranskedjan. DORA tillför detaljerade krav på IKT-riskhantering, resiliensprovning, incidentrapportering och tillsyn över IKT-tredjepartsleverantörer för finansiella entiteter. GDPR fortsätter att kräva ansvarsskyldighet, säkerhet i behandlingen, styrning av personuppgiftsbiträden och bedömning av personuppgiftsincidenter.

Fel svar är att bygga tre parallella efterlevnadsprogram. Det skapar dubblerade kontroller, inkonsekvent underlag och utmattade team.

Det starkare svaret är att använda ISO 27001:2022 som kontrollryggrad. Inte som ett certifikat på väggen, utan som ett operativt system för risk, policy, leverantörsstyrning, incidenthantering, efterlevnadsmappning och revisionsbevis.

Clarysecs praktiska modell är enkel: använd ISO 27001:2022-ISMS som det organiserande systemet, använd tillämpbarhetsförklaringen som brygga, använd policyer som bindande operativa regler och använd Zenith Controls: guiden för samordnad efterlevnad som kompass för samordnad efterlevnad. Bygg en gång, mappa noggrant och visa efterlevnad kontinuerligt.

Varför ISO 27001:2022 fungerar som ryggrad för regelefterlevnad

NIS2 och DORA har olika omfattning, rättsliga mekanismer och tillsynsmodeller. NIS2 gäller väsentliga och viktiga entiteter inom olika sektorer. DORA gäller finansiella entiteter och ställer detaljerade krav på digital operativ resiliens. GDPR fokuserar på behandling av personuppgifter och ansvarsskyldighet.

Ändå överlappar de operativa frågorna bakom dessa ramverk:

• Styrs cybersäkerhet av policyer som godkänts av ledningen?
• Identifieras, bedöms och behandlas informationssäkerhetsrisker och IKT-risker?
• Väljs kontroller utifrån risk, verksamhetskontext och rättsliga skyldigheter?
• Styrs leverantörer genom leverantörsgranskning, avtal, övervakning och exit-kontroller?
• Kan personal upptäcka och rapportera säkerhetshändelser i tid?
• Kan incidenter triageras, eskaleras, utredas och bedömas för regulatorisk rapportering?
• Kan organisationen snabbt ta fram bevismaterial vid revision, kundgranskning eller förfrågan från tillsynsmyndighet?

ISO 27001:2022 ger ledningen ett ledningssystem för att besvara dessa frågor konsekvent. ISO/IEC 27007:2022 behandlar tillämpbarhetsförklaringen som en granskningsbar lista över valda informationssäkerhetskontroller, inklusive kontroller från ISO 27001:2022 bilaga A, andra standarder eller organisationsspecifika åtgärder, med dokumenterad motivering för inkludering eller exkludering. ISO/IEC 27006-1:2024 förstärker att SoA och relaterad ISMS-dokumentation utgör en central bevisbas för att visa vilka kontroller som krävs, hur ansvar tilldelas och hur policyer införs och kommuniceras.

Det gör SoA till mycket mer än ett kalkylblad. Den blir kontrollkontraktet mellan risk, regelefterlevnad, drift, juridik, upphandling, revision och styrelsen.

Clarysecs [P01] Informationssäkerhetspolicy förankrar detta styrningskrav:

Organisationen ska införa och upprätthålla ett ledningssystem för informationssäkerhet (ISMS) i enlighet med ISO/IEC 27001:2022 klausulerna 4 till 10.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.1.1.

Detta är viktigt eftersom begäranden om bevismaterial enligt NIS2 och DORA sällan formuleras på ISO-språk. En tillsynsmyndighet, kund eller styrelsekommitté kan begära bevis på cybersäkerhetsriskhantering, IKT-styrning, tillsyn över tredjepartsberoenden, incidenteskalering eller testning av operativ resiliens. ISO 27001:2022-ISMS ger dessa svar en struktur.

SoA är bryggan, inte en pappersövning

I Zenith Blueprint: en 30-stegs färdplan för revisorer, fasen Riskhantering, steg 13, beskriver Clarysec SoA som den centrala spårbarhetsmekanismen mellan riskbehandling och införda kontroller:

SoA är i praktiken ett bryggdokument: den kopplar din riskbedömning/riskbehandling till de faktiska kontroller du har.

Den meningen är kärnan i samordnad efterlevnad. En kontroll utan spårbarhet blir en lös artefakt. En kontroll som är kopplad till risk, rättslig skyldighet, policy, ägare, bevispost och testresultat blir revisionsklar.

Steg 13 rekommenderar också att kontrollreferenser läggs till i riskscenarier, till exempel genom att koppla ett scenario om intrång i en kunddatabas till åtkomstkontroll, kryptografi, sårbarhetshantering, incidenthantering och leverantörskontroller. Det rekommenderar även att det anges när kontroller stödjer externa krav såsom GDPR, NIS2 eller DORA.

Clarysecs [P06] Riskhanteringspolicy gör denna operativa regel uttrycklig:

Kontrollbeslut som följer av riskbehandlingsprocessen ska återspeglas i SoA.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.5.1.

För mindre organisationer använder Riskhanteringspolicy – SME samma logik:

Den säkerställer att riskhantering är en aktiv del av planering, projektgenomförande, leverantörsurval och incidenthantering, i linje med ISO 27001, ISO 31000 och tillämpliga regulatoriska krav.

Från avsnittet “Syfte”, policyklausul 1.2.

Om en DORA-riskbehandling för tredje part, en NIS2-åtgärd för incidenthantering eller ett GDPR-krav på säkerhet hos personuppgiftsbiträde inte återspeglas i SoA eller ett relaterat register över regelefterlevnadskrav kan organisationen fortfarande utföra arbetet. Men den får svårt att visa arbetet på ett sammanhängande sätt.

En praktisk ISO 27001:2022-mappning för NIS2 och DORA

Följande mappning är inte juridisk rådgivning. Den är en praktisk bevismodell för informationssäkerhetschefer, ansvariga för regelefterlevnad, internrevisorer och verksamhetsägare som behöver anpassa ISO 27001:2022-underlag till förväntningar enligt NIS2 och DORA.

ENISA har, tillsammans med Europeiska kommissionen och NIS Cooperation Group, tillhandahållit rådgivande korsreferensvägledning som hjälper till att anpassa EU:s cybersäkerhetskrav till internationella och nationella standarder, inklusive ISO 27001. Vägledningen är inte rättsligt bindande och måste kompletteras med instruktioner från nationella myndigheter, sektorsregler och juridisk granskning. Den stödjer dock ett försvarbart mappningssätt.

Mappningen fungerar eftersom den inte skapar dubbla kontroller för varje regelverk. Den använder ISO 27001:2022 som kontrollryggrad och lägger till regulatoriska taggar, ägarskap och förväntningar på underlag.

Tre ISO 27001:2022-kontroller som låser upp ryggraden

Flera kontroller är viktiga för NIS2 och DORA, men tre ISO/IEC 27002:2022-kontroller blir ofta ryggraden i bevismodellen: 5.1, 5.19 och 5.24. En fjärde kontroll, 6.8, avgör ofta om incidentrapportering fungerar i praktiken.

I Zenith Controls beskrivs ISO/IEC 27002:2022-kontroll 5.1, Policyer för informationssäkerhet, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, med styrning och policyhantering som centrala operativa förmågor. Korsmappningen förklarar att GDPR Articles 5(2), 24 och 32 kräver ansvarsskyldighet, ansvar och säkerhet i behandlingen. Den mappar också samma kontroll till NIS2:s förväntningar på cybersäkerhetsriskhantering och styrning samt till DORA:s krav på IKT-styrning och ramverk för riskhantering.

Därför är informationssäkerhetspolicyn inte bara ännu en policy. En NIS2-bedömare kan läsa den som styrningsunderlag. En DORA-tillsynsfunktion kan läsa den som underlag för IKT-riskramverket. En GDPR-granskare kan läsa den som underlag för ansvarsskyldighet. En ISO 27001:2022-revisor kan läsa den som en del av ISMS-policystrukturen.

Kontroll 5.19, Informationssäkerhet i leverantörsrelationer, är där upphandling, juridik, säkerhet, dataskydd och resiliens möts. Zenith Controls mappar den till GDPR-skyldigheter för personuppgiftsbiträden, NIS2-cybersäkerhet i leveranskedjan och DORA IKT-tredjepartsriskhantering. För DORA blir detta underlag ännu starkare när det stöds av kontrollerna 5.20, Hantering av informationssäkerhet i leverantörsavtal, 5.21, Hantering av informationssäkerhet i IKT-leveranskedjan, och 5.23, Informationssäkerhet vid användning av molntjänster.

Kontroll 5.24, Planering och förberedelse för hantering av informationssäkerhetsincidenter, är den operativa motorn för incidentberedskap. Zenith Controls mappar den till NIS2-incidenthantering och rapportering, GDPR-anmälan av personuppgiftsincidenter samt DORA IKT-relaterad incidenthantering och rapportering. Underlaget består inte bara av en incidenthanteringspolicy. Det omfattar rapporteringskanaler, triageringskriterier, eskaleringsposter, juridiska bedömningar av rapporteringsskyldighet, skrivbordsövningar, incidentärenden och erfarenhetsåterföring.

Kontroll 6.8, Rapportering av informationssäkerhetshändelser, stänger gapet mellan den skriftliga planen och mänskligt beteende. Om personal inte vet hur misstänkt phishing, dataläckage, leverantörsavbrott eller misstänkt systemaktivitet ska rapporteras kan organisationen förlora kritisk tid innan juridiska eller regulatoriska rapporteringsbedömningar ens påbörjas.

En leverantörsincident, en samordnad beviskedja

Föreställ dig att en leverantör av molnbaserad analys, som används av Marias betalningsförmedlare, upptäcker obehörig åtkomst till en supportportal. Leverantören driftar pseudonymiserade användningsdata om kunder och stödjer ett verksamhetskritiskt rapporteringsarbetsflöde. Incidenten kan påverka personuppgifter, reglerad IKT-resiliens och tjänstetillgänglighet.

Ett fragmenterat efterlevnadsprogram öppnar tre separata arbetsströmmar: en GDPR-bedömning av personuppgiftsincident, en DORA-granskning av IKT-incident och ett ISO 27001-leverantörsärende. Varje team begär liknande underlag i olika format. Upphandling letar efter avtalet. Juridik frågar om leverantören är personuppgiftsbiträde. Säkerhet frågar om incidenten uppfyller rapporteringströsklarna. Regelefterlevnadsteamet startar ett nytt kalkylblad.

En mogen ISO 27001:2022-ryggrad öppnar en samordnad beviskedja.

Först loggas händelsen enligt incidenthanteringsprocessen. Rapportören använder en definierad kanal, säkerhetsteamet triagerar händelsen och juridik utvärderar rapporteringsskyldigheter. Clarysecs [P30] Policy för incidenthantering kräver att incidenter som rör reglerade data bedöms av juridik och dataskyddsombudet:

Om en incident leder till bekräftad eller sannolik exponering av personuppgifter eller andra reglerade data ska juridik och dataskyddsombudet bedöma tillämpligheten av:

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.4.1.

För mindre organisationer tilldelar Incidenthanteringspolicy – SME samma praktiska beslutspunkt:

När kunddata berörs ska den verkställande chefen bedöma rättsliga rapporteringsskyldigheter baserat på tillämpligheten av GDPR, NIS2 eller DORA.

Från avsnittet “Riskbehandling och undantag”, policyklausul 7.4.1.

Därefter granskas leverantörsrelationen. Var leverantören klassificerad som kritisk? Innehöll avtalet skyldigheter avseende incidentrapportering, revisionsrätt, ansvar för dataskydd, förväntningar på tjänstekontinuitet och exit-bestämmelser? Clarysecs policy för leverantörs- och tredjepartssäkerhet fastställer den förväntningen:

Inför standardiserade säkerhetskrav i alla leverantörsavtal, inklusive skyldigheter avseende incidentrapportering, revisionsrätt och ansvar för dataskydd.

Från avsnittet “Mål”, policyklausul 3.2.

För små och medelstora företag gör Policy för leverantörs- och tredjepartssäkerhet – SME syftet med samordnad efterlevnad uttryckligt:

Stöd efterlevnad av skyldigheter enligt ISO/IEC 27001:2022, GDPR, NIS2 och DORA som rör leverantörsstyrning.

Från avsnittet “Mål”, policyklausul 3.6.

Därefter uppdateras riskregistret, behandlingsplanen och SoA om incidenten visar på en lucka. Kanske saknar leverantörsavtalet en specifik regulatorisk tidslinje för rapportering. Kanske är övervakningsfrekvensen för leverantörer för låg för en kritisk IKT-leverantör. Kanske skiljer incidenthanteringsplanen inte tillräckligt tydligt mellan kriterier för personuppgiftsincidenter och kriterier för störningar i IKT-tjänster.

Poängen är inte att skapa ett nytt universum för regelefterlevnad. Poängen är att uppdatera en integrerad beviskedja så att samma poster kan besvara flera revisionsfrågor.

Att göra SoA till en beviskarta för NIS2 och DORA

En standardiserad SoA besvarar ofta ISO-frågor väl: vilka kontroller som är tillämpliga, varför de har valts och om de är införda. För att göra den till en praktisk beviskarta för NIS2 och DORA bör den kompletteras med regulatoriska och operativa bevisfält.

Öppna SoA_Builder.xlsx från Audit Ready Toolkit som hänvisas till i Zenith Blueprint, fasen Revision, granskning och förbättring, steg 24. Steg 24 förklarar att revisorer ofta tar stickprov på en kontroll från SoA och frågar varför den infördes. Motiveringskolumnen och den länkade risken eller det länkade kravet bör besvara den frågan.

Lägg till dessa kolumner:

Tillämpa sedan detta på den centrala kontrolluppsättningen.

Kör sedan en exempelspårning. Välj en leverantörsincident från det senaste året och följ den från incidentärendet till leverantörsavtalet, från leverantörsklassificeringen till riskregistret, från riskbehandling till SoA och från SoA till ledningens genomgång.

Om kedjan bryts är det inte ett misslyckande. Det är en precis korrigerande åtgärd innan en revisor, kund, tillsynsmyndighet eller styrelsekommitté hittar luckan.

Centraliserat underlag är den förbisedda acceleratorn

Många organisationer har tillräckliga kontroller men svag förmåga att ta fram underlag. Bevismaterial är utspritt över e-post, ärendehanteringssystem, SharePoint-mappar, avtalsarkiv, HR-plattformar, GRC-verktyg och leverantörsportaler. Under revisionssäsongen ägnar regelefterlevnadsteamet veckor åt att jaga skärmdumpar.

Det är inte revisionsberedskap. Det är revisionsåterhämtning.

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

Allt bevismaterial ska lagras i en central revisionsmapp.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.2.1.

En central revisionsmapp betyder inte en okontrollerad dumpningsplats. Det betyder ett strukturerat arkiv som är anpassat till ISMS, SoA, riskregistret, revisionsplanen och registret över regelefterlevnadskrav.

Clarysecs Policy för rättslig och regulatorisk efterlevnad – SME behandlar mappningsproblemet direkt:

När en reglering gäller flera områden (t.ex. GDPR gäller bevarande, säkerhet och integritet) ska detta tydligt mappas i registret över regelefterlevnadskrav och utbildningsmaterial.

Från avsnittet “Styrningskrav”, policyklausul 5.2.2.

Det är exakt så ISO 27001:2022 blir kontrollryggraden för NIS2 och DORA. Du förlitar dig inte på personbunden kunskap. Du mappar regelverk över processer, policyer, kontroller, underlag och utbildning.

Incidentrapportering börjar med människor, inte portaler

En vanlig revisionssvaghet uppstår när incidenthanteringsplanen ser stark ut, men anställda inte vet när eller hur de ska rapportera. Detta är farligt för NIS2, DORA och GDPR eftersom tidslinjer för regulatoriska bedömningar beror på detektering, eskalering och klassificering.

I Zenith Blueprint, fasen Kontroller i praktiken, steg 16, betonar Clarysec personaldriven incidentrapportering enligt ISO/IEC 27002:2022-kontroll 6.8. Vägledningen anger att incidenthantering börjar med människor. Organisationer bör skapa en tydlig, enkel och tillgänglig rapporteringskanal, till exempel en övervakad e-postadress, intern portal, hotline eller ärendekategori. Den rekommenderar också medvetenhetsutbildning, en rapporteringskultur utan skuldbeläggning, konfidentialitet, låg tröskel för rapportering och periodiska simuleringar.

Effekten på samordnad efterlevnad är direkt. Zenith Blueprint kopplar denna personalbaserade rapporteringsförmåga till GDPR Article 33, NIS2 Article 23 och DORA Article 17. Om anställda tvekar att rapportera misstänkt aktivitet kan organisationen förlora kritisk tid innan juridik-, säkerhets- eller regulatoriska team kan bedöma rapporteringsskyldigheter.

Ett praktiskt kontrolltest är enkelt:

1. Fråga fem anställda hur de rapporterar ett misstänkt phishingmeddelande.
2. Kontrollera om rapporteringskanalen övervakas.
3. Bekräfta om ärendehanteringssystemet har en kategori för säkerhetsincidenter.
4. Granska den senaste simuleringen eller skrivbordsövningen.
5. Verifiera att erfarenhetsåterföring har granskats i ledningens genomgång.

Om något svar är oklart, uppdatera incidentinstruktionen, utbildningsmaterialet, rapporteringskanalen och SoA-referensen till bevismaterial.

Hur olika revisorer granskar samma ryggrad

Bevismaterial för samordnad efterlevnad måste klara olika revisionsperspektiv. Samma kontroll kan testas på olika sätt beroende på granskarens mandat.

Här tillför Zenith Controls värde utöver en enkel mappningstabell. Den hjälper till att översätta ISO/IEC 27002:2022-kontroller till revisionsrelevanta perspektiv, inklusive kontrollattribut, regulatoriska relationer och förväntningar på underlag. För kontroll 5.1 stödjer attributen styrning, policyhantering, ansvarsskyldighet och säkerhetsmål. För kontroll 5.24 stödjer attributen respons- och återhämtningsbegrepp, incidentberedskap och korrigerande åtgärder. För kontroll 5.19 kopplar attributen för leverantörsrelationer samman styrning, ekosystemrisk, skydd och tredjepartstillsyn.

Vad styrelsen bör se

Styrelsen behöver inte varje rad i SoA. Den behöver däremot den berättelse som SoA ger.

Ett starkt styrelsepaket för anpassning mellan ISO 27001:2022, NIS2 och DORA bör omfatta:

• ISMS-omfattning och omfattade verksamhetstjänster.
• De viktigaste informationssäkerhetsriskerna och IKT-riskerna.
• Sammanfattning av tillämpliga kontroller per område.
• Mappningsstatus för NIS2, DORA och GDPR.
• Kritiska leverantörer och koncentrationsrisker.
• Mätetal för incidentrapportering och resultat från skrivbordsövningar.
• Öppna korrigerande åtgärder och försenade riskbehandlingar.
• Beslut som krävs om riskacceptans, budget, ägarskap och resurser.

Detta gör regelefterlevnad till styrningsunderlag. Det ligger också i linje med syftet med kontroll 5.1 i Zenith Controls, där policyer för informationssäkerhet stödjer inriktning på ledningsnivå, ansvarsskyldighet och säkerhetsmål.

Vanliga misstag att undvika

Det första misstaget är att anta att ISO 27001:2022-certifiering automatiskt visar efterlevnad av NIS2 eller DORA. Det gör den inte. ISO 27001:2022 ger ett starkt ledningssystem och en kontrollryggrad, men ni behöver fortfarande regulatorisk avgränsning, juridisk analys, sektorsspecifik tolkning, arbetsflöden för rapportering och kännedom om nationella myndigheters förväntningar.

Det andra misstaget är att behandla SoA som statisk. SoA måste utvecklas när nya leverantörer, system, incidenter, regelverk, tjänster eller risker uppstår. Zenith Blueprint, steg 24, rekommenderar att SoA korsverifieras mot riskregistret och behandlingsplanen, och att varje vald kontroll har en motivering baserad på mappad risk, rättsligt krav eller verksamhetsbehov.

Det tredje misstaget är att mappa på för hög nivå. En presentationsbild som säger ”ISO 27001 mappar till DORA” är inte revisionsbevis. En specifik SoA-post som kopplar säkerhet i leverantörsrelationer till en kritisk IKT-leverantörsrisk, avtalsklausul, granskningspost för leverantör och DORA-förväntan på tredjepartstillsyn är mycket starkare.

Det fjärde misstaget är att inte centralisera underlag. Om ansvarig för regelefterlevnad lägger två veckor på att samla skärmdumpar inför varje revision har organisationen ett problem med att ta fram underlag.

Det femte misstaget är att ignorera personalsäkerhetsåtgärder. Incidentrapportering, leverantörsintroduktion, åtkomstgranskning, policygodkännande och eskalering beror alla på mänskligt beteende. En välpolerad process som ingen följer faller samman vid revisionsstickprov.

Clarysecs operativa modell för samordnad efterlevnad

Clarysecs metod kopplar samman berättelsen om regelefterlevnad från strategi till bevismaterial:

• I Zenith Blueprint, fasen Riskhantering, steg 13, mappar du kontroller till risker och bygger SoA som bryggdokument.
• I Zenith Blueprint, fasen Riskhantering, steg 14, korsrefererar du krav enligt GDPR, NIS2 och DORA mot policyer och kontroller.
• I Zenith Blueprint, fasen Kontroller i praktiken, steg 16, operationaliserar du personaldriven incidentrapportering så att eskalering börjar tidigt.
• I Zenith Blueprint, fasen Revision, granskning och förbättring, steg 24, färdigställer och testar du SoA, korsverifierar den mot riskbehandlingsplanen och förbereder den som ett av de första dokument en revisor kommer att begära.

Metoden stöds av Clarysec-policyer som omsätter principer i operativa regler: styrning av informationssäkerhet, riskbehandling, leverantörssäkerhet, incidenthantering, rättslig och regulatorisk mappning samt lagring av bevismaterial.

Resultatet är inte bara ISO 27001:2022-beredskap. Det är ett återanvändbart bevissystem för regelefterlevnad av NIS2, DORA, GDPR, kundförsäkran, internrevision och styrelsetillsyn.

Nästa steg: bygg en gång, visa många gånger

Om din organisation står inför NIS2, DORA, GDPR, kundrevisioner eller certifieringspress enligt ISO 27001:2022, börja med ryggraden.

1. Granska er SoA och lägg till kolumner för regulatoriska drivkrafter för NIS2, DORA och GDPR.
2. Kontrollera SoA mot ert riskregister och er riskbehandlingsplan.
3. Mappa kritiska leverantörer till kontroller för leverantörssäkerhet, avtalsklausuler och övervakningsunderlag.
4. Testa ert arbetsflöde för incidentrapportering med en skrivbordsövning.
5. Centralisera revisionsbevis efter kontroll, regelverk, ägare och teststatus.
6. Använd Zenith Controls för att översätta ISO/IEC 27002:2022-kontroller till underlag för samordnad efterlevnad.
7. Använd Zenith Blueprint för att gå från riskbehandling till SoA-validering med revisionsberedskap.
8. Inför Clarysecs policyuppsättning, inklusive Informationssäkerhetspolicy, Riskhanteringspolicy, policy för leverantörs- och tredjepartssäkerhet och Policy för incidenthantering, för att påskynda genomförandet.

Den snabbaste vägen är inte fler frikopplade checklistor. Det är ett integrerat ISMS, en spårbar SoA, en centraliserad bevismodell och en operativ rytm för samordnad efterlevnad.

Clarysec kan hjälpa dig att göra ISO 27001:2022 från ett certifieringsprojekt till en praktisk kontrollryggrad för NIS2 och DORA. Ladda ner Zenith Blueprint, utforska Zenith Controls eller boka en Clarysec-bedömning för att bygga en revisionsklar bevismodell innan nästa tillsynsmyndighet, kund eller styrelsekommitté begär bevismaterial.