Revisionsbevis från ISO 27001 för NIS2 och DORA
Klockan är 08:17 en tisdag och informationssäkerhetschefen på ett snabbväxande fintech-SaaS-bolag har tre meddelanden som väntar.
Det första kommer från en stor bankkund: ”Skicka er senaste internrevisionsrapport, protokoll från ledningens genomgång, status för korrigerande åtgärder, rutin för incidentrapportering, leverantörsregister och underlag för styrelsens tillsyn.”
Det andra kommer från finanschefen: ”Omfattas vi av NIS2 eller DORA, och vilket underlag har vi redan?”
Det tredje kommer från VD:n: ”Kan vi säga att vi är revisionsberedda?”
Det obekväma svaret i många organisationer är inte att inget händer. Det är värre än så. Säkerhetsarbete pågår överallt, men bevismaterialet finns ingenstans. Det finns kontroller, men inget revisionsspår. Det finns ärenden, men ingen tydlig koppling till risker. Det finns uppdateringar till ledningen, men inga formella utfall från ledningens genomgång. Det finns leverantörsdiskussioner, men inget försvarbart leverantörsregister, ingen avtalsgranskning och ingen exitstrategi.
Det är just i detta gap som ISO/IEC 27001:2022 internrevision och ledningens genomgång blir mer än certifieringsaktiviteter. De blir den operativa rytmen för NIS2, DORA, GDPR, kundförsäkran, cyberförsäkring och styrelsens ansvar.
SaaS-, moln-, MSP-, MSSP- och fintechteam misslyckas sällan för att de saknar säkerhetsaktiviteter. De misslyckas för att aktiviteterna är utspridda över Slack, Jira, kalkylark, leverantörsportaler, SOC-ärenden, upphandlingsfiler och styrelsepresentationer. En tillsynsmyndighet, extern revisor eller företagskund vill inte ha en heroisk förklaring. De vill ha objektiva revisionsbevis.
Den praktiska lösningen är inte att köra separata revisionsprogram för varje ramverk. Lösningen är att använda ISO 27001-ISMS som central bevismotor och sedan märka bevismaterialet mot NIS2, DORA, GDPR och avtalskrav. Rätt utfört kan en internrevision och en cykel för ledningens genomgång besvara många frågor om regelefterlevnad.
Från ramverkströtthet till en samlad ISMS-modell för bevismaterial
Många informationssäkerhetschefer möter en variant av Marias problem. Maria ansvarar för säkerheten i ett B2B-SaaS-bolag med kunder i finanssektorn. Hennes team klarade en ISO/IEC 27001:2022-certifieringsrevision för sex månader sedan. ISMS mognar, policyer följs och kontrollägare förstår sitt ansvar. Sedan vidarebefordrar VD:n två artiklar, en om NIS2-direktivet och en om DORA, med en kort fråga: ”Täcks vi?”
Svaret beror på omfattning, tjänster, kunder och juridiska enheter. Men det operativa svaret är tydligt: om Maria behandlar NIS2 och DORA som separata efterlevnadsprojekt skapar hon dubbelarbete, inkonsekvent bevismaterial och ökande revisionströtthet. Om hon i stället behandlar dem som krav från intressenter inom ISMS kan hon använda ISO 27001 för att fånga upp, testa och visa beredskap.
ISO/IEC 27001:2022 är utformad för detta. Klausul 4 kräver att organisationen förstår sitt sammanhang och krav från intressenter, inklusive rättsliga, regulatoriska, avtalsmässiga och beroendedrivna skyldigheter. Klausul 5 kräver ledarskap och integrering i verksamhetsprocesser. Klausul 6 kräver riskbedömning och riskbehandling. Klausul 9 kräver utvärdering av prestanda genom övervakning, internrevision och ledningens genomgång. Klausul 10 kräver förbättring och korrigerande åtgärder.
NIS2 och DORA passar naturligt in i den strukturen.
NIS2 kräver att väsentliga och viktiga enheter inför lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för hantering av cybersäkerhetsrisker. Direktivet lägger också ansvar på ledningsorgan att godkänna dessa åtgärder, övervaka genomförandet och kunna hållas ansvariga för överträdelser. Minimikraven omfattar riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, sårbarhetshantering, bedömning av effektivitet, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, policy för tillgångshantering och, där så är lämpligt, multifaktorautentisering eller kontinuerlig autentisering.
DORA gäller från den 17 januari 2025 och skapar ett sektorspecifikt regelverk för digital operativ resiliens för finansiella entiteter. Förordningen kräver ansvar hos ledningsorganet för IKT-riskhantering, ett dokumenterat ramverk för IKT-riskhantering, strategi för digital operativ resiliens, IKT-kontinuitets- och återställningsplaner, resiliensprovning, styrning av IKT-incidenter och hantering av IKT-tredjepartsrisk. För SaaS- och molnleverantörer som betjänar finansiella entiteter kan DORA aktualiseras genom avtalsförpliktelser, kundrevisioner och förväntningar på hantering av IKT-tredjepartsrisk, även när leverantören inte själv är en finansiell entitet.
GDPR lägger till ansvarsskyldighetslagret. Där personuppgifter behandlas inom GDPR:s tillämpningsområde måste organisationer kunna visa efterlevnad av dataskyddsprinciper och lämpliga tekniska och organisatoriska åtgärder.
ISO 27001 är inte ett magiskt certifikat för efterlevnad av dessa skyldigheter. Det är ledningssystemet som kan organisera, styrka och förbättra dem.
Omfattningsfrågan: vad ska ni bevisa, och för vem?
Innan ett revisionsklart bevismaterialpaket byggs måste ledningen besvara en grundläggande fråga: vilka skyldigheter omfattas?
För SaaS- och molnverksamheter kan NIS2-omfattningen vara bredare än väntat. NIS2 gäller offentliga eller privata enheter i angivna sektorer som uppfyller storlekströsklar, samt vissa högpåverkande enheter oavsett storlek. Relevanta sektorer kan omfatta digital infrastruktur, tillhandahållare av molntjänster, datacentertjänster, nätverk för leverans av innehåll, betrodda tjänster, allmänt tillgängliga elektroniska kommunikationstjänster och B2B-leverantörer av IKT-tjänstehantering, såsom leverantörer av hanterade tjänster och leverantörer av hanterade säkerhetstjänster. SaaS-leverantörer bör vara särskilt uppmärksamma på hur tjänster levereras, vilka sektorer de stödjer och om de möjliggör administration på begäran och bred fjärråtkomst till skalbara delade datorresurser.
För tjänsteleverantörer inom fintech och finanssektorn måste DORA analyseras separat. DORA omfattar direkt ett brett spektrum av finansiella entiteter, inklusive kreditinstitut, betalningsinstitut, leverantörer av kontoinformationstjänster, institut för elektroniska pengar, värdepappersföretag, leverantörer av kryptotillgångstjänster, handelsplatser, fondförvaltare, försäkrings- och återförsäkringsföretag samt leverantörer av gräsrotsfinansieringstjänster. IKT-tredjepartstjänsteleverantörer är också en del av DORA-ekosystemet eftersom finansiella entiteter måste hantera sina IKT-beroenden, upprätthålla register över avtalsarrangemang och inkludera särskilda avtalsbestämmelser för IKT-tjänster som stödjer kritiska eller viktiga funktioner.
NIS2 och DORA samverkar också. När en sektorspecifik EU-rättsakt ställer likvärdiga krav på hantering av cybersäkerhetsrisker eller incidentanmälan kan motsvarande NIS2-bestämmelser sakna tillämpning för dessa entiteter på dessa områden. DORA är den sektorspecifika ordningen för operativ resiliens för finansiella entiteter. Det gör inte NIS2 irrelevant för alla omgivande leverantörer. Det innebär att bevismodellen måste skilja mellan om organisationen är en finansiell entitet som direkt omfattas av DORA, en IKT-tredjepartstjänsteleverantör som stödjer finansiella entiteter, en SaaS-leverantör inom NIS2:s tillämpningsområde eller en koncern med flera juridiska enheter och tjänstelinjer.
Denna omfattningsanalys hör hemma i ISMS-sammanhanget och intressentregistret. Utan den kommer revisionsplanen att testa fel saker.
Ett revisionsspår, många frågor om regelefterlevnad
Ett vanligt misstag är att skapa separata bevismaterialpaket för ISO 27001, NIS2, DORA, GDPR, cyberförsäkring och kundrevisioner. Det skapar dubbelarbete och motstridiga svar. Ett bättre angreppssätt är en bevismodell med flera granskningsperspektiv.
I centrum finns ISMS. Runt det finns fem bevismaterialfamiljer.
| Bevismaterialfamilj | Vad den styrker | Typiska poster |
|---|---|---|
| Styrningsunderlag | Ledningen har godkänt, resurssatt och granskat ISMS | Informationssäkerhetspolicy, roller, revisionsplan, protokoll från ledningens genomgång, rapportering till styrelsen |
| Riskunderlag | Risker har identifierats, bedömts, ägts och behandlats | Riskkriterier, riskregister, riskbehandlingsplan, tillämpbarhetsförklaring, godkännanden av kvarstående risk |
| Kontrollunderlag | Kontroller fungerar enligt utformningen | Åtkomstgranskning, återställningstester av säkerhetskopior, övervakningslarm, sårbarhetsrapporter, leverantörsgranskning, dokumentation från säker utveckling |
| Säkerhetsförsäkransunderlag | Oberoende eller interna kontroller har identifierat luckor och verifierat överensstämmelse | Internrevisionsplan, revisionschecklista, revisionsrapport, logg över avvikelser, CAPA-logg |
| Förbättringsunderlag | Iakttagelser har lett till korrigering, rotorsaksanalys och ständig förbättring | Planer för korrigerande åtgärder, erfarenhetsåterföring, ledningsbeslut, uppdaterade policyer, register från omtester |
Denna struktur är anpassad till Zenith Blueprint: revisorns 30-stegsfärdplan Zenith Blueprint. I fasen Revision, granskning och förbättring fokuserar steg 25 på internrevisionsprogrammet, steg 26 på revisionsgenomförande, steg 28 på ledningens genomgång och steg 29 på ständig förbättring.
Vägledningen i Blueprint steg 25 är avsiktligt praktisk:
”Ta fram ett schema som anger när revisioner ska genomföras och vad de ska omfatta.”
”Använd mallen för internrevisionsplan om den finns tillgänglig; det kan vara ett enkelt dokument eller kalkylark som listar revisionsdatum, omfattning och tilldelade revisorer.”
Från Zenith Blueprint, fasen Revision, granskning och förbättring, steg 25: internrevisionsprogram Zenith Blueprint
Den enkla revisionsplanen blir kraftfull när den är riskbaserad och märks mot skyldigheter enligt NIS2, DORA och GDPR.
ISO 27001-kontroller som förankrar revisionsberedskap
För revisionsberedskap är tre ISO/IEC 27002:2022-kontroller särskilt viktiga när de tolkas genom Zenith Controls: vägledning för tvärgående efterlevnad Zenith Controls:
- 5.4 Ledningens ansvar
- 5.35 Oberoende granskning av informationssäkerhet
- 5.36 Efterlevnad av policyer, regler och standarder för informationssäkerhet
Detta är inte separata ”Zenith-kontroller”. Det är ISO/IEC 27002:2022-kontroller som Zenith Controls hjälper till att kartlägga, revidera och tolka över olika ramverk.
Kontroll 5.4 frågar om ansvar för informationssäkerhet är tilldelade och förstådda. Kontroll 5.35 frågar om informationssäkerheten granskas oberoende. Kontroll 5.36 frågar om organisationen följer sina policyer, regler och standarder.
Zenith Controls klassificerar kontroll 5.35 ur ett säkerhetsförsäkransperspektiv:
ISO/IEC 27002:2022-kontroll 5.35, ”Oberoende granskning av informationssäkerhet”, behandlas i Zenith Controls som ”förebyggande, korrigerande” och stödjer konfidentialitet, riktighet och tillgänglighet genom cybersäkerhetsbegreppen ”Identifiera” och ”Skydda”, med operativ förmåga inom ”säkerhetsförsäkran för informationssäkerhet”. Zenith Controls
Detta är viktigt eftersom internrevision är både förebyggande och korrigerande. Den förebygger blinda fläckar genom att testa ISMS före extern granskning, och den korrigerar säkerhetssvagheter genom dokumenterade åtgärder.
Den bredare korsreferensen börjar med kraven i NIS2 och DORA och identifierar sedan det ISO 27001-underlag som kan styrka dem.
| Regulatoriskt tema | Bevismaterial enligt ISO/IEC 27001:2022 och ISO/IEC 27002:2022 | Praktiskt revisionsfokus |
|---|---|---|
| Ledningens ansvar | Klausulerna 5 och 9.3 samt kontrollerna 5.2, 5.4, 5.35, 5.36 | Ledningsgodkännanden, granskningsprotokoll, rolltilldelningar, CAPA-beslut |
| Riskanalys och säkerhetspolicyer | Klausulerna 4, 6.1 och 6.2 samt kontrollerna 5.1, 5.7, 5.9, 5.31 | Riskkriterier, riskregister, policygodkännanden, rättsliga och avtalsmässiga krav |
| Incidenthantering | Kontrollerna 5.24, 5.25, 5.26, 5.27, 5.28 | Klassificering, eskalering, responsunderlag, erfarenhetsåterföring, bevarande av bevismaterial |
| Verksamhetskontinuitet och återställning | Kontrollerna 5.29, 5.30, 8.13 | Kontinuitetsplaner, IKT-beredskap, tester av återställning från säkerhetskopior, återställningsmått |
| Leverantörs- och molnrisk | Kontrollerna 5.19, 5.20, 5.21, 5.22, 5.23 | Leverantörsgranskning, avtal, övervakning, exitplaner för molntjänster, koncentrationsrisk |
| Säker utveckling och sårbarheter | Kontrollerna 8.8, 8.25, 8.26, 8.27, 8.28, 8.29 | SLA:er för sårbarheter, dokumentation från säker SDLC, ändringsgodkännanden, säkerhetstestning |
| Åtkomst, HR och utbildning | Kontrollerna 5.15, 5.16, 5.17, 5.18, 6.1, 6.2, 6.3, 6.5, 6.6, 6.7 | Åtkomstgranskning, stickprov på nyanställningar, interna förflyttningar och avgångar, utbildningsregistreringar, kontroller för distansarbete |
| Loggning, övervakning och kryptografi | Kontrollerna 8.15, 8.16, 8.17, 8.24 | Logglagring, granskning av larm, tidssynkronisering, krypteringsstandarder |
| Integritet och efterlevnad av lagkrav | Kontrollerna 5.31, 5.34, 5.36 | Register över rättsliga krav, dataskyddskontroller, underlag för personuppgiftsbiträden, granskningar av regelefterlevnad |
Kontrollkartläggning är användbar endast när bevismaterialet är starkt. Om posten är svag räddar ingen korsreferens den. Om posten är fullständig kan samma bevismaterial besvara frågor enligt ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 och COBIT 2019.
Policyunderlag som Clarysec förväntar sig att organisationer bevarar
Clarysecs policyer omvandlar ISMS-teori till krav på bevismaterial.
För små och medelstora företag kräver Policy för revision och regelefterlevnadsövervakning för små och medelstora företag Policy för revision och regelefterlevnadsövervakning för små och medelstora företag ledningens godkännande och revisionsdisciplin:
”Verkställande chef (GM) måste godkänna en årlig revisionsplan.”
Från Policy för revision och regelefterlevnadsövervakning för små och medelstora företag, styrningskrav, klausul 5.1.1 Policy för revision och regelefterlevnadsövervakning för små och medelstora företag
Den fastställer också en miniminivå för frekvens:
”Internrevisioner eller granskningar av regelefterlevnad måste genomföras minst årligen.”
Från Policy för revision och regelefterlevnadsövervakning för små och medelstora företag, styrningskrav, klausul 5.2.1
Och den kopplar iakttagelser till korrigering och ledningens genomgång:
”GM måste godkänna en plan för korrigerande åtgärder och följa upp dess genomförande.”
Från Policy för revision och regelefterlevnadsövervakning för små och medelstora företag, styrningskrav, klausul 5.4.2
”Revisionsiakttagelser och statusuppdateringar måste ingå i processen för ledningens genomgång av ISMS.”
Från Policy för revision och regelefterlevnadsövervakning för små och medelstora företag, styrningskrav, klausul 5.4.3
Bevarande av bevismaterial är också uttryckligt:
”Bevismaterial måste bevaras i minst två år, eller längre när det krävs enligt certifiering eller kundavtal.”
Från Policy för revision och regelefterlevnadsövervakning för små och medelstora företag, krav för genomförande av policyn, klausul 6.2.4
För större organisationer utvecklar Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning, som i vissa Clarysec-material också benämns P33 Policy för revision och regelefterlevnadsövervakning, strukturen ytterligare:
”En riskbaserad revisionsplan ska tas fram och godkännas årligen, med beaktande av:”
Från Policy för revision och regelefterlevnadsövervakning, styrningskrav, klausul 5.2 Policy för revision och regelefterlevnadsövervakning
”Organisationen ska upprätthålla ett revisionsregister som innehåller:”
Från Policy för revision och regelefterlevnadsövervakning, styrningskrav, klausul 5.4
”Internrevisioner ska följa ett dokumenterat förfarande som omfattar:”
Från Policy för revision och regelefterlevnadsövervakning, krav för genomförande av policyn, klausul 6.1.1
”Alla iakttagelser ska resultera i en dokumenterad CAPA som omfattar:”
Från Policy för revision och regelefterlevnadsövervakning, krav för genomförande av policyn, klausul 6.2.1
Ledningens genomgång är förankrad i Informationssäkerhetspolicy Informationssäkerhetspolicy, som i vissa Clarysec-material också benämns P01 Informationssäkerhetspolicy:
”Aktiviteter för ledningens genomgång (enligt ISO/IEC 27001 Klausul 9.3) ska genomföras minst årligen och ska omfatta:”
Från Informationssäkerhetspolicy, styrningskrav, klausul 5.3 Informationssäkerhetspolicy
Dessa krav skapar den beviskedja som revisorer förväntar sig: godkänd plan, definierat förfarande, revisionsregister, iakttagelser, CAPA, bevarande och ledningens genomgång.
Bygga ett revisionsklart bevismaterialpaket
Ett revisionsklart bevismaterialpaket är inte en jättemapp som skapas två dagar före revisionen. Det är en levande struktur som underhålls under hela året.
| Bevismaterial | Syfte enligt ISO 27001 | Relevans för NIS2 och DORA |
|---|---|---|
| ISMS-omfattning och intressentregister | Visar att rättsliga, avtalsmässiga och beroenderelaterade krav är identifierade | Stödjer NIS2-entitetsomfattning, DORA-rollanalys och GDPR-ansvarsskyldighet |
| Riskkriterier och riskregister | Visar konsekvent riskbedömning och riskägarskap | Stödjer NIS2-åtgärder för riskhantering och DORA:s IKT-riskramverk |
| Tillämpbarhetsförklaring | Visar valda kontroller, motivering och genomförandestatus | Skapar en konsoliderad kontrollbaslinje för tvärgående efterlevnad |
| Årlig internrevisionsplan | Visar planerad säkerhetsförsäkran | Stödjer ledningens tillsyn och DORA:s IKT-revisionsplanering |
| Internrevisionschecklista | Visar revisionskriterier och stickprovsmetod | Visar hur krav enligt NIS2, DORA och GDPR har testats |
| Revisionsrapport och logg över iakttagelser | Visar objektivt bevismaterial och avvikelser | Stödjer bedömning av effektivitet och regulatorisk säkerhetsförsäkran |
| CAPA-logg | Visar rotorsak, ägare, förfallodag och stängning | Stödjer korrigerande åtgärder enligt NIS2 och åtgärdande enligt DORA |
| Paket för ledningens genomgång | Visar ledningens granskning av prestanda, incidenter, risk och resurser | Stödjer styrelsens ansvar enligt NIS2 och DORA |
| Leverantörsregister och avtalsunderlag | Visar kontroll över tredjepartsrisk | Stödjer NIS2-säkerhet i leveranskedjan och DORA:s hantering av IKT-tredjepartsrisk |
| Incidentrapportering och registreringar av erfarenhetsåterföring | Visar respons och förbättring | Stödjer NIS2:s stegvisa rapportering och DORA:s incidentstyrning |
Bevismaterialpaketet bör mappas mot ISO/IEC 27001:2022-klausuler och Annex A-kontroller, men märkas för regulatorisk relevans. Ett leverantörsrevisionsunderlag kan till exempel stödja Annex A-kontroller för leverantörer, NIS2-säkerhet i leveranskedjan och DORA:s hantering av IKT-tredjepartsrisk. Ett protokoll från en incidentövning i form av en skrivbordsövning kan stödja ISO 27001-incidenthantering, NIS2-beredskap för stegvis incidentanmälan och DORA-styrning av större IKT-relaterade incidenter.
Så genomförs den integrerade internrevisionen
Steg 26 i Zenith Blueprint betonar objektivt bevismaterial:
”Genomför revisionen genom att samla in objektivt bevismaterial för varje punkt i checklistan.”
”Intervjua relevant personal.”
”Granska dokumentation.”
”Observera arbetssätt.”
”Ta stickprov och genomför stickprovskontroller.”
Från Zenith Blueprint, fasen Revision, granskning och förbättring, steg 26: revisionsgenomförande Zenith Blueprint
Det är exakt vad beredskap för NIS2 och DORA kräver. Tillsynsmyndigheter och kunder kommer inte att acceptera ”vi tror att detta fungerar”. De kommer att fråga hur ni vet det.
En väl genomförd revision testar fyra dimensioner av bevismaterial.
| Bevisdimension | Exempel på revisionstest | Bra bevismaterial |
|---|---|---|
| Utformning | Definierar policyn eller processen kravet? | Godkänd policy, rutin, standard, arbetsflöde |
| Genomförande | Har processen driftsatts? | Ärenden, konfigurationer, utbildningsregistreringar, leverantörsregister |
| Operativ effektivitet | Fungerade processen över tid? | Stickprov över flera månader, larm, granskningsloggar, testresultat |
| Styrningseskalering | Såg och agerade ledningen på resultaten? | CAPA-godkännande, protokoll från ledningens genomgång, budgetbeslut |
Tänk på en simulerad ransomware-händelse på en stagingserver. Revisorn testar om incidenthanteringsprocessen kan uppfylla ISO 27001-krav, NIS2-förväntningar på stegvis rapportering och DORA-kundförpliktelser.
| Insamlat bevismaterial | Relevans för ISO 27001 | Relevans för NIS2 | Relevans för DORA |
|---|---|---|---|
| Incidentlogg med initial klassificering och tidsstämpel | Kontroll 5.26 respons på informationssäkerhetsincidenter | Fastställer tidpunkten för kännedom för rapporteringstidsfrister | Stödjer identifiering och loggning av IKT-relaterade incidenter |
| Eskalering till CSIRT och juridisk rådgivare | Kontroll 5.25 bedömning och beslut om informationssäkerhetshändelser | Stödjer beslutsfattande för anmälan av betydande incident | Stödjer interna kommunikations- och eskaleringsrutiner |
| Utkast till mall för tidig varning | Kontroll 5.24 planering och förberedelser för incidenthantering | Stödjer förmågan att uppfylla förväntan på tidig varning inom 24 timmar | Kan stödja beredskap för avtalsmässig kommunikation |
| Beslutsunderlag för återställning från säkerhetskopia | Kontrollerna 5.29, 5.30 och 8.13 | Stödjer bevismaterial för verksamhetskontinuitet och katastrofåterställning | Stödjer förväntningar på respons, återställning och återläsning från säkerhetskopia |
| Kundkommunikationsregister | Kontrollerna 5.20 och 5.22 leverantörsavtal och övervakning av leverantörstjänster | Kan stödja avtalsmässig kommunikation och kommunikation i leveranskedjan | Stödjer finansiella kunders skyldigheter avseende tredjepartsrisk |
NIS2 har en stegvis rapporteringsstruktur för betydande incidenter, inklusive tidig varning inom 24 timmar från kännedom, incidentanmälan inom 72 timmar och en slutrapport inom en månad från incidentanmälan. DORA har ett eget klassificerings- och rapporteringsramverk för IKT-relaterade incidenter för finansiella entiteter. Internrevisionen bör verifiera att åtgärdsplaner fångar tidpunkt för kännedom, kriterier för allvarlighetsgrad, berörda tjänster, indikatorer på kompromettering, riskbegränsande åtgärder, rotorsak, skyldigheter att underrätta kunder och slutliga rapporteringsdata.
Omvandla en revisionsiakttagelse till NIS2- och DORA-bevismaterial
En realistisk leverantörsiakttagelse visar hur bevismaterialet bör flöda.
Under internrevisionen tar revisorn stickprov på fem kritiska leverantörer. En leverantör av molnbaserad loggning stödjer bedrägeriövervakning och säkerhetslarmning för fintechplattformen. Leverantören finns i förteckningen, men det finns ingen dokumenterad exitplan, inget underlag för årlig säkerhetsgranskning och ingen bekräftelse på att avtalet innehåller incidentstöd eller revisionsrätt.
Revisorn registrerar en avvikelse mot krav på leverantörssäkerhet och exitkrav för molntjänster. Ett svagt svar skulle vara ”leverantörsgranskning saknas”. Ett starkt svar skapar en beviskedja för tvärgående efterlevnad:
- Registrera iakttagelsen i revisionsrapporten, inklusive stickprovsstorlek, leverantörsnamn, avtalsreferens och saknat bevismaterial.
- Lägg till en CAPA-post med rotorsak, till exempel ”leverantörsonboardingens checklista innehöll inte kritikalitetsklassificering eller trigger för exitplan”.
- Tilldela leverantörsägare och riskägare.
- Uppdatera leverantörsregistret för att markera tjänsten som stöd för en kritisk eller viktig funktion.
- Genomför en riskbedömning som omfattar tjänsteavbrott, dataåtkomst, koncentrationsrisk, beroende för incidentrapportering och avtalsluckor.
- Uppdatera riskbehandlingsplanen och tillämpbarhetsförklaringen där det är relevant.
- Inhämta ett uppdaterat avtalstillägg eller en dokumenterad riskacceptans.
- Skapa eller testa en exitplan.
- Revidera leverantörsunderlaget på nytt efter åtgärdande.
- Rapportera iakttagelsen, risken och resursbehoven i ledningens genomgång.
Denna enda kedja stödjer flera skyldigheter. NIS2 förväntar sig säkerhet i leveranskedjan och beaktande av leverantörers sårbarheter, cybersäkerhetspraxis och rutiner för säker utveckling. DORA kräver att finansiella entiteter hanterar IKT-tredjepartsrisk, upprätthåller register över avtalsarrangemang, bedömer leverantörer före avtalstecknande, inkluderar revisions- och inspektionsrättigheter där så är lämpligt, upprätthåller rätt att säga upp avtalet och dokumenterar exitstrategier för IKT-tjänster som stödjer kritiska eller viktiga funktioner. GDPR kan också vara relevant om leverantören behandlar personuppgifter.
Revisionsunderlaget är inte längre bara underlag för regelefterlevnad. Det är resiliensunderlag.
Ledningens genomgång: där bevismaterial blir ansvar
Internrevisionen hittar sanningen. Ledningens genomgång beslutar vad som ska göras åt den.
Steg 28 i Zenith Blueprint beskriver underlagspaketet för ledningens genomgång:
”ISO 27001 anger flera obligatoriska indata till ledningens genomgång. Förbered en kort rapport eller presentation som täcker dessa punkter.”
Blueprint listar status för tidigare åtgärder, förändringar i externa och interna frågor, ISMS-prestanda och effektivitet, incidenter eller avvikelser, förbättringsmöjligheter och resursbehov.
Från Zenith Blueprint, fasen Revision, granskning och förbättring, steg 28: ledningens genomgång Zenith Blueprint
För NIS2 och DORA är ledningens genomgång den plats där ansvar på styrelsenivå blir synligt. Genomgången bör inte bara säga ”säkerhet diskuterades”. Den bör visa att ledningen granskade:
- Förändringar i NIS2, DORA, GDPR, kundkrav och avtalskrav.
- Förändringar i omfattning, inklusive nya länder, produkter, reglerade kunder eller IKT-beroenden.
- Internrevisionsresultat, inklusive större och mindre avvikelser.
- Status för CAPA:er och försenade åtgärder.
- Säkerhetsmål och mätetal.
- Incidenttrender, nära-händelser och erfarenhetsåterföring.
- Leverantörs- och molnrelaterade koncentrationsrisker.
- Resultat från tester av verksamhetskontinuitet och säkerhetskopiering.
- Prestanda för sårbarhetshantering och patchning.
- Resursbehov, inklusive personal, verktyg, utbildning och budget.
- Kvarstående risker som kräver formell acceptans.
- Förbättringsbeslut och ansvariga ägare.
Det är här Maria kan omvandla en teknisk rapport till strategisk säkerhetsförsäkran. I stället för att säga ”vi hittade en lucka i incidentprocessen” kan hon säga: ”Revisionen identifierade en mindre avvikelse i våra beslutskriterier för NIS2-incidentrapportering. CAPA:n uppdaterar rutinen, lägger till en beslutsmatris och kräver en skrivbordsövning inom 30 dagar. Vi behöver ledningens godkännande för juridisk granskning och utbildningstid.”
Det är den typen av registrering som stödjer styrning, tillsyn och försvarbart beslutsfattande.
Korrigerande åtgärd: skillnaden mellan en iakttagelse och mognad
En internrevision utan korrigerande åtgärd är bara en diagnos.
Steg 29 i Zenith Blueprint uppmanar organisationer att använda en CAPA-logg:
”Fyll den med varje problem: problembeskrivning, rotorsak, korrigerande åtgärd, ansvarig ägare, måldatum för slutförande, status.”
Från Zenith Blueprint, fasen Revision, granskning och förbättring, steg 29: ständig förbättring Zenith Blueprint
Det gör också en viktig åtskillnad:
”I revisionstermer: korrigering åtgärdar symtomet, korrigerande åtgärd åtgärdar orsaken. Båda är viktiga.”
Från Zenith Blueprint, fasen Revision, granskning och förbättring, steg 29: ständig förbättring
Om bevismaterial för återställning från säkerhetskopia saknas kan korrigeringen vara att genomföra och dokumentera ett återställningstest denna vecka. Den korrigerande åtgärden är att ändra rutinen för säkerhetskopiering så att återställningstester schemaläggs kvartalsvis, automatiskt ärendesätts, granskas av tjänsteägaren och inkluderas i mätetal för ledningens genomgång.
Revisorer letar efter den mognaden. En ISO 27001-revisor testar överensstämmelse med ISMS och valda kontroller. En NIS2-granskare frågar om riskhanteringsåtgärderna är effektiva och föremål för tillsyn. En DORA-granskare letar efter integrering av IKT-riskramverk, resiliensprovning, hantering av tredjepartsberoenden och åtgärdande. En bedömare enligt NIST Cybersecurity Framework 2.0 kan fråga om utfall för styrning, identifiering, skydd, detektering, respons och återställning fungerar. En COBIT 2019-revisor kan fokusera på styrningsmål, ägarskap, prestandaindikatorer och säkerhetsförsäkran.
Samma CAPA-post kan uppfylla dessa perspektiv om den omfattar rotorsak, ägare, riskpåverkan, korrigerande åtgärd, förfallodag, underlag för genomförande, effektivitetsgranskning och synlighet för ledningen.
Revisorns flera perspektiv
Olika revisorer läser samma bevismaterial på olika sätt. Zenith Controls hjälper till att förutse dessa frågor genom att fungera som vägledning för tvärgående efterlevnad för ISO/IEC 27002:2022-kontroller och relaterade ramverk.
| Revisionsperspektiv | Vad revisorn sannolikt frågar | Bevismaterial som svarar väl |
|---|---|---|
| ISO 27001-revisor | Är ISMS planerat, infört, utvärderat och förbättrat enligt kraven i ISO/IEC 27001:2022? | Omfattning, riskbedömning, tillämpbarhetsförklaring, internrevisionsplan, revisionsrapport, utfall från ledningens genomgång, CAPA |
| NIS2-granskare | Har ledningen godkänt och övervakat lämpliga riskhanteringsåtgärder, och kan enheten visa effektivitet och korrigerande åtgärder? | Protokoll från styrelse eller ledningens genomgång, riskbehandlingsplan, incidentåtgärdsplaner, leverantörsgranskningar, utbildningsregistreringar, effektivitetsmått |
| DORA-granskare | Är IKT-riskhantering integrerad i styrning, resiliensstrategi, testning, tredjepartsrisk och åtgärdande? | IKT-riskramverk, revisionsplan, bevismaterial från resiliensprovning, tredjepartsregister, kartläggning av kritiska funktioner, åtgärdsregister |
| GDPR-granskare | Kan organisationen visa ansvarsskyldighet för behandling av personuppgifter och säkerhet? | Dataregister, register över rättslig grund, personuppgiftsbiträdesavtal, loggar över personuppgiftsincidenter, åtkomstkontroller, bevarandeunderlag, säkerhetsåtgärder |
| NIST CSF 2.0-bedömare | Fungerar utfallen för styrning, risk, skydd, detektering, respons och återställning effektivt? | Kontrollunderlag mappade till utfall, loggar, övervakning, incidentregister, återställningstester, förbättringsåtgärder |
| COBIT 2019-revisor | Är styrningsmål, ägarskap, prestationsstyrning och säkerhetsförsäkransaktiviteter definierade och övervakade? | RACI, policyer, KPI:er, revisionsregister, ärendehantering, ledningsrapportering, beslutsregister |
Kontroll 5.36 är ett bra exempel. ISO 27001-revisorn kan fokusera på om granskningar av efterlevnad genomförs och förs in i korrigerande åtgärder. NIS2-granskaren kan fråga om dessa granskningar testar rättsliga cybersäkerhetsåtgärder, inte bara interna regler. DORA-granskaren kan fokusera på om granskningar av efterlevnad omfattar kritiska IKT-leverantörer och avtalsmässig tillämpning.
Därför måste bevismaterialet utformas för flera läsare från början.
En praktisk 30-dagars sprint för revisionsberedskap
Om VD:n frågar om organisationen kan bli revisionsberedd på 30 dagar är det ärliga svaret: ni kan bygga en trovärdig bevismaterialbaslinje om ledningen stödjer sprinten och omfattningen är realistisk.
| Dagar | Aktivitet | Utfall |
|---|---|---|
| 1 till 3 | Bekräfta ISMS-omfattning, reglerade tjänster, intressenter och skyldigheter | Omfattningsbeskrivning, tillämplighetsnotering för NIS2, DORA och GDPR |
| 4 till 7 | Uppdatera riskkriterier, riskregister och centrala riskägare | Uppdaterat riskregister och riskbehandlingsprioriteringar |
| 8 till 10 | Bygg en riskbaserad internrevisionsplan | Godkänd revisionsplan och revisionschecklista |
| 11 till 17 | Genomför revisionsintervjuer, stickprov och granskning av bevismaterial | Bevismaterialslogg, iakttagelser, positiva observationer |
| 18 till 20 | Validera iakttagelser med ägare och klassificera allvarlighetsgrad | Revisionsrapport och avvikelseregister |
| 21 till 24 | Skapa CAPA-logg med rotorsaker, ägare och förfallodagar | Godkänd plan för korrigerande åtgärder |
| 25 till 27 | Förbered paket för ledningens genomgång | Granskningspresentation eller rapport med mätetal, risker, incidenter, resurser |
| 28 till 30 | Genomför ledningens genomgång och registrera beslut | Protokoll, åtgärdslogg, riskacceptanser, resursbeslut |
Denna sprint ersätter inte långsiktig mognad. Den skapar en försvarbar operativ baslinje. Det verkliga värdet kommer när organisationen upprepar cykeln kvartalsvis eller halvårsvis, inte bara en gång per år.
Vanliga brister i bevismaterial som Clarysec hittar
Samma svagheter återkommer i revisioner av SaaS-, moln- och fintechmiljöer:
- Revisionsplanen finns, men den är inte riskbaserad.
- Revisionschecklistan testar ISO-klausuler men bortser från NIS2, DORA, GDPR och kundförpliktelser.
- Protokoll från ledningens genomgång finns, men de visar inte beslut, resursfördelning eller riskacceptans.
- CAPA-poster listar åtgärder men ingen rotorsak.
- Iakttagelser stängs utan effektivitetsverifiering.
- Leverantörsgranskningar genomförs, men kritiska leverantörer skiljs inte från leverantörer med låg risk.
- Incidentåtgärdsplaner finns, men ingen kan visa att rapporteringsarbetsflödet inom 24 eller 72 timmar skulle fungera.
- Säkerhetskopieringsjobb är gröna, men återställningstester är inte styrkta med bevismaterial.
- Åtkomstgranskning exporteras, men undantag följs inte till stängning.
- Loggar samlas in, men ingen kan visa övervakning, eskalering eller respons.
- Bevismaterial lagras i personliga mappar i stället för i ett styrt dokumentarkiv.
- Bevarandekrav är oklara eller inkonsekventa med kundavtal.
Dessa brister går att åtgärda. De kräver en strukturerad ISMS-arkitektur för bevismaterial, inte dokumentjakt i sista minuten.
Hur bra ser ut för styrelsen
När informationssäkerhetschefen återkommer till VD:n och finanschefen är det starkaste svaret inte ”vi klarade en revisionschecklista”. Det är:
”Vi har en godkänd revisionsplan. Vi genomförde en riskbaserad internrevision. Vi identifierade iakttagelser med objektivt bevismaterial. Vi godkände CAPA:er med ägare och förfallodagar. Vi eskalerade väsentliga risker, incidenter, leverantörsberoenden och resursbehov till ledningens genomgång. Vi mappade bevismaterialet mot ISO/IEC 27001:2022, NIS2, DORA och GDPR. Vi kan visa revisionsspåret.”
Det svaret förändrar samtalet. Det ger VD:n trygghet gentemot kunder. Det ger finanschefen klarhet om regulatorisk exponering. Det ger styrelsen ett försvarbart tillsynsunderlag. Det ger informationssäkerhetschefen en prioriterad färdplan i stället för en hög med frikopplade förfrågningar.
Framför allt flyttar det organisationen från efterlevnadsteater till operativ resiliens.
Nästa steg med Clarysec
Er nästa revision ska inte vara en panikinsats. Den ska vara ett synligt bevis på att ert ISMS fungerar, att ledningen är engagerad och att organisationen är redo för ISO 27001, NIS2, DORA, GDPR och kundförsäkran.
Clarysec kan hjälpa er att:
- Bygga en riskbaserad internrevisionsplan med Zenith Blueprint: revisorns 30-stegsfärdplan Zenith Blueprint.
- Mappa revisionsbevis genom Zenith Controls: vägledning för tvärgående efterlevnad Zenith Controls.
- Införa revisionsstyrning för små och medelstora företag eller större verksamheter med Policy för revision och regelefterlevnadsövervakning för små och medelstora företag Policy för revision och regelefterlevnadsövervakning för små och medelstora företag eller Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning.
- Förbereda paket för ledningens genomgång i linje med Informationssäkerhetspolicy Informationssäkerhetspolicy och förväntningarna i ISO/IEC 27001:2022 Klausul 9.3.
- Omvandla iakttagelser till CAPA-poster, ledningsbeslut och mätbar förbättring.
Ladda ner Clarysecs verktygspaket, boka en beredskapsbedömning eller begär en demo för att omvandla er nästa internrevision till styrelseklart bevismaterial för ISO 27001, NIS2, DORA och vidare.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
