ISO 27001-SoA för beredskap inför NIS2 och DORA

Klockan är 08.30 en måndagsmorgon när Elena, informationssäkerhetschef hos en snabbväxande B2B FinTech SaaS-leverantör, öppnar en brådskande förfrågan från styrelsen. Företaget har just uppnått ISO/IEC 27001:2022-certifiering, men en större potentiell bankkund inom EU ställer betydligt skarpare frågor än i ett vanligt säkerhetsfrågeformulär.

De frågar inte bara om företaget krypterar data, använder MFA eller har en rapport från penetrationstestning. De vill veta om SaaS-plattformen stöder deras DORA-skyldigheter, om leverantören kan omfattas av NIS2 som IKT-tjänst eller beroende i digital infrastruktur, och om ISO 27001-tillämpbarhetsförklaringen kan motivera varje inkluderad kontroll, varje undantagen kontroll och varje tillhörande underlag.

Styrelsen ställer frågan som varje informationssäkerhetschef, compliancechef och SaaS-grundare hör allt oftare:

Kan vår ISO 27001-SoA visa beredskap inför NIS2 och DORA?

Elena vet att fel svar vore att starta tre separata efterlevnadsprogram: ett för ISO 27001, ett för NIS2 och ett för DORA. Det skulle skapa dubblerat underlag, motstridiga kontrollägare och ständig tidspress inför varje kundgranskning. Det bättre svaret är att använda det befintliga ISMS:et som operativt system för regelefterlevnad, med tillämpbarhetsförklaringen, eller SoA, som huvuddokument för spårbarhet.

SoA är inte bara ett kalkylblad för ISO-certifiering. I en EU-miljö för cybersäkerhet och operativ resiliens är den platsen där en organisation visar varför kontroller finns, varför undantag är försvarbara, vem som äger varje kontroll, vilket underlag som styrker genomförandet och hur kontrolluppsättningen hanterar NIS2, DORA, GDPR, kundavtal och intern riskbehandling.

Clarysecs informationssäkerhetspolicy för större organisationer Informationssäkerhetspolicy anger:

ISMS ska omfatta definierade omfattningsgränser, en riskbedömningsmetodik, mätbara mål och dokumenterade kontroller som motiveras i tillämpbarhetsförklaringen (SoA).

Det kravet, från policyklausul 6.1.2 i informationssäkerhetspolicyn, är grunden för ett revisionsklart arbetssätt. SoA bör bli bryggan mellan skyldigheter, risker, kontroller, underlag och ledningsbeslut.

Varför NIS2 och DORA förändrade vad ”tillämplig” innebär

En traditionell ISO/IEC 27001:2022-SoA börjar ofta med en enkel fråga: ”Vilka kontroller i Bilaga A är tillämpliga på vår riskbehandlingsplan?” Det är fortfarande korrekt, men det räcker inte längre för SaaS-leverantörer, molnleverantörer, leverantörer av hanterade tjänster, fintechbolag, finansiella teknikleverantörer och kritiska leveranskedjeaktörer.

NIS2 höjer basnivån för cybersäkerhetsriskhantering hos väsentliga och viktiga entiteter i EU. Direktivet omfattar sektorer som digital infrastruktur, leverantörer av molntjänster, leverantörer av datacentertjänster, innehållsleveransnätverk, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, bankverksamhet och infrastrukturer för finansmarknaden. Medlemsstaterna ska identifiera väsentliga och viktiga entiteter samt leverantörer av tjänster för domännamnsregistrering, och många teknikleverantörer som tidigare betraktade cybersäkerhetsreglering som en kundfråga omfattas nu antingen direkt eller exponeras genom avtalsmässiga krav som flödar ned i leveranskedjan.

NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder inom riskanalys, säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och utveckling, bedömning av kontrolleffektivitet, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och autentisering där det är lämpligt. NIS2 Article 23 lägger till förväntningar på stegvis incidentrapportering, inklusive tidig varning, anmälan, uppdateringar och slutrapportering för betydande incidenter.

DORA, Digital Operational Resilience Act, gäller från den 17 januari 2025 och fokuserar på finansiella entiteter och deras ekosystem för IKT-risk. Den omfattar IKT-riskhantering, rapportering av IKT-relaterade incidenter, rapportering av operativa incidenter eller säkerhetsincidenter avseende betalningar för vissa entiteter, testning av digital operativ resiliens, delning av information om cyberhot, hantering av IKT-tredjepartsrisker, avtalsarrangemang och tillsyn över kritiska IKT-tredjepartsleverantörer.

För finansiella entiteter som också är väsentliga eller viktiga entiteter enligt NIS2 fungerar DORA som det sektorsspecifika regelverket för motsvarande skyldigheter avseende IKT-riskhantering och incidentrapportering. Men för SaaS-leverantörer, molnleverantörer, MSP:er och MDR-leverantörer som betjänar finansiella kunder är den praktiska verkligheten att DORA-förväntningar kommer genom upphandling, avtal, revisionsrätt, skyldigheter att stödja incidenthantering, exitplanering, transparens kring underleverantörer och underlag för resiliens.

Det förändrar SoA-diskussionen. Frågan är inte längre: ”Innehåller Bilaga A den här kontrollen?” Den bättre frågan är:

Kan vi visa att valet av kontroller är riskbaserat, beaktar skyldigheter, är proportionerligt, har tydliga ägare, är genomfört, övervakas, stöds av underlag och är godkänt?

ISO 27001 är den universella översättaren för NIS2 och DORA

ISO/IEC 27001:2022 är värdefull eftersom den är en standard för ledningssystem, inte en snäv checklista. Den kräver att ISMS integreras i organisationens processer och anpassas till organisationens behov. Det gör den till en effektiv universell översättare för överlappande krav på regelefterlevnad.

Klausulerna 4.1 till 4.4 kräver att organisationen förstår sitt sammanhang, identifierar intressenter, fastställer relevanta krav och definierar ISMS-omfattningen. För en FinTech SaaS-leverantör som Elenas företag kan dessa intressentkrav omfatta EU-kunder, finansiella kunder som påverkas av DORA, sektorexponering enligt NIS2, personuppgiftsansvarigas och personuppgiftsbiträdens skyldigheter enligt GDPR, outsourcade molnberoenden, leverantörsgränssnitt och styrelsens förväntningar.

Klausulerna 6.1.1 till 6.1.3 kräver planering för risker och möjligheter, en repeterbar process för informationssäkerhetsriskbedömning, en riskbehandlingsprocess, jämförelse med Bilaga A och en tillämpbarhetsförklaring som identifierar inkluderade kontroller, införandestatus och motiveringar till undantag.

Det är här SoA blir ett register över kontrollbeslut. En kontroll kan inkluderas eftersom den behandlar en risk, uppfyller ett rättsligt krav, fullgör ett kundavtal, stöder ett verksamhetsmål eller utgör grundläggande säkerhetshygien. En kontroll kan undantas först efter att organisationen medvetet har bedömt den, funnit den irrelevant för ISMS-omfattningen, dokumenterat motiveringen och inhämtat lämpligt godkännande.

Clarysecs riskhanteringspolicy för större organisationer Riskhanteringspolicy anger:

En tillämpbarhetsförklaring (SoA) ska återspegla alla riskbehandlingsbeslut och ska uppdateras när kontrolltäckningen ändras.

Detta krav, från policyklausul 5.4 i riskhanteringspolicyn, är kritiskt för beredskap inför NIS2 och DORA. En ny reglerad kund, ett nytt molnberoende, en ny skyldighet för incidentrapportering eller en ny koncentrationsrisk hos en leverantör kan alla ändra kontrollernas tillämplighet.

Börja med registret över efterlevnadskrav, inte kontrollistan

En svag SoA börjar med Bilaga A och frågar: ”Vilka kontroller har vi redan?” En stark SoA börjar med organisationens operativa verklighet och frågar: ”Vilka skyldigheter, tjänster, risker, data, leverantörer och kunder måste ISMS hantera?”

ISO/IEC 27005:2022 stöder detta arbetssätt genom att betona intressentkrav, riskkriterier och behovet av att beakta standarder, interna regler, lagar, föreskrifter, avtal och befintliga kontroller. Standarden betonar också att icke-tillämplighet eller bristande efterlevnad ska förklaras och motiveras.

Clarysecs policy för rättslig och regulatorisk efterlevnad för små och medelstora företag Policy för rättslig och regulatorisk efterlevnad – SME fångar samma operativa princip:

GM ska upprätthålla ett enkelt, strukturerat register över efterlevnadskrav som listar:

Det kravet kommer från klausul 5.1.1 i policyn för rättslig och regulatorisk efterlevnad för små och medelstora företag. För en mindre organisation kan registret vara enkelt. För en större organisation bör det vara mer detaljerat. Logiken är densamma: skyldigheter måste vara synliga innan de kan mappas.

Clarysecs policy för rättslig och regulatorisk efterlevnad för större organisationer Policy för rättslig och regulatorisk efterlevnad är tydlig:

Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.

Detta är policyklausul 6.2.1 i policyn för rättslig och regulatorisk efterlevnad. Den är styrningsryggraden för att använda en ISO 27001-tillämpbarhetsförklaring för beredskap inför efterlevnad av NIS2 och DORA.

Bygg riskkriterier som speglar resiliens, integritet, leverantörer och reglering

Många SoA-motiveringar brister eftersom riskpoängmodellen är för snäv. Den mäter teknisk sannolikhet och konsekvens, men fångar inte regulatorisk exponering, tjänstekritikalitet, kundskada, leverantörsberoende, påverkan på integritet eller systemisk operativ störning.

NIS2 handlar inte bara om konfidentialitet. Direktivet fokuserar på att förebygga och minimera incidenters påverkan på tjänster och tjänstemottagare. DORA definierar kritiska eller viktiga funktioner utifrån om en störning väsentligt skulle försämra finansiell prestation, tjänstekontinuitet eller regelefterlevnad. GDPR tillför ansvarsskyldighet, riktighet, konfidentialitet, beredskap för incidentanmälan och skada för registrerade.

Clarysecs riskhanteringspolicy för små och medelstora företag Riskhanteringspolicy – SME anger ett praktiskt minimum:

Varje riskpost ska innehålla: beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan.

Detta är klausul 5.1.2 i riskhanteringspolicyn för små och medelstora företag. För beredskap inför NIS2 och DORA utökar Clarysec detta minimum med fält som källa till skyldighet, berörd tjänst, datakategori, leverantörsberoende, verksamhetsägare, regulatorisk påverkan, kvarstående risk, behandlingsstatus och källa till underlag.

Notera språket. En stark motivering säger inte bara ”införd”. Den förklarar varför kontrollen är tillämplig i organisationens verksamhetsmässiga, regulatoriska och riskmässiga sammanhang.

Mappa NIS2- och DORA-domäner till ISO 27001:2022-kontroller

När registret över efterlevnadskrav och riskkriterierna är etablerade är det praktiska arbetet att mappa regulatoriska domäner till kontrollerna i Bilaga A. Denna mappning visar inte efterlevnad i sig, men den ger revisorer och kunder ett tydligt index för att testa underlag.

För Elena förändrade denna mappning styrelsedialogen. I stället för att presentera NIS2 och DORA som separata projekt kunde hon visa överlappningen: styrning, riskhantering, incidenter, kontinuitet, leverantörer, testning, åtkomstkontroll och kryptografi.

De tre ISO-kontroller som varje NIS2- och DORA-SoA är beroende av

I Zenith Controls: The Cross-Compliance Guide Zenith Controls behandlar Clarysec tre ISO/IEC 27002:2022-kontroller som centrala för revisionsklar SoA-styrning för NIS2 och DORA. Dessa är ISO-kontroller, berikade med attribut för korsvis regelefterlevnad i guiden Zenith Controls.

Dessa kontroller är inte isolerade. De kopplar direkt till kontroller för leverantörsrelationer A.5.19 till A.5.23, incidenthanteringskontroller A.5.24 till A.5.28, kontinuitetskontroller A.5.29 och A.5.30, integritetskontroll A.5.34, hantering av sårbarheter A.8.8, konfigurationshantering A.8.9, säkerhetskopiering av information A.8.13, loggning A.8.15, övervakningsaktiviteter A.8.16, kryptografi A.8.24, kontroller för säker utveckling A.8.25 till A.8.29 och ändringshantering A.8.32.

Värdet med Zenith Controls är att guiden hjälper team att undvika att behandla SoA som en artefakt för en enda standard. Kontroll 5.31 stöder rättslig och avtalsmässig mappning. Kontroll 5.35 stöder internrevision, oberoende granskning och ledningens assurance. Kontroll 5.36 stöder operativ efterlevnad av policyer, procedurer, standarder och kontrollkrav.

Använd Zenith Blueprint för att bygga, testa och försvara SoA

I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint placerar Clarysec framtagningen av SoA i riskhanteringsfasen, steg 13: riskbehandlingsplanering och tillämpbarhetsförklaring. Blueprint instruerar organisationer att använda SoA-fliken i mallen “Risk Register and SoA Builder.xlsx”, avgöra om var och en av de 93 kontrollerna i Bilaga A är tillämplig och basera beslutet på riskbehandling, rättsliga och avtalsmässiga krav, relevans för omfattningen och organisationens sammanhang.

Blueprint anger:

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

Den meningen fångar den operativa modellen. SoA bygger en brygga mellan skyldigheter, risker, policyer, kontroller, underlag och revisionsslutsatser.

Zenith Blueprint instruerar också team att korsreferera regelverk i SoA-anteckningarna där det är lämpligt. Om en kontroll är införd för GDPR, NIS2 eller DORA bör detta framgå i riskregistret eller SoA-anteckningarna. Senare, i steg 24, instruerar Blueprint organisationer att uppdatera SoA efter genomförandet och korsverifiera den mot riskbehandlingsplanen. I steg 30, certifieringsförberedelse, slutlig granskning och simulerad revision, uppmanar Blueprint team att bekräfta att varje tillämplig kontroll i Bilaga A har underlag såsom policy, procedur, rapport, plan eller implementeringspost.

Den sekvensen gör SoA till ett levande instrument för regelefterlevnad:

1. Steg 13 bygger den utifrån riskbehandling och skyldigheter.
2. Steg 24 testar den mot verkligt genomförande.
3. Steg 30 försvarar den genom slutlig granskning av underlag och simulerad revision.

Så skriver du inkluderingsmotiveringar som revisorer kan följa

En kontroll bör inkluderas när det finns minst en försvarbar drivkraft: riskbehandling, rättsligt krav, avtalskrav, relevans för omfattningen, grundläggande säkerhetshygien, förväntan på kundassurance eller ett resiliensmål godkänt av ledningen.

En användbar formel är:

Tillämplig eftersom [risk eller skyldighet] påverkar [tjänst, tillgång, data eller process], och denna kontroll ger [förebyggande, upptäckande, korrigerande eller resiliensrelaterat resultat], styrkt av [policy, post, test, rapport eller systemutdata].

För en fintech-SaaS-leverantör kan en SoA-rad se ut så här:

Detta är revisionsklart eftersom det kopplar kontrollen till sammanhang, risk, skyldighet, genomförande, ägarskap och underlag.

Så motiverar du undantag utan att skapa revisionsexponering

Undantag är inte fel. Bristfälligt motiverade undantag är fel.

ISO/IEC 27001:2022 kräver att SoA motiverar undantagna kontroller i Bilaga A. ISO/IEC 27005:2022 förstärker att icke-tillämplighet ska förklaras och motiveras. Clarysecs informationssäkerhetspolicy för större organisationer anger:

Baslinjen får anpassas; undantag ska dock dokumenteras med formellt godkännande och motivering i SoA.

Detta är klausul 7.2.2 i informationssäkerhetspolicyn.

Clarysecs informationssäkerhetspolicy för små och medelstora företag Informationssäkerhetspolicy – SME anger:

Varje avvikelse från denna policy ska dokumenteras och tydligt förklara varför avvikelsen är nödvändig, vilka alternativa skyddsåtgärder som finns på plats och vilket datum som har fastställts för omprövning.

Det kravet kommer från klausul 7.2.1 i informationssäkerhetspolicyn för små och medelstora företag.

För NIS2 och DORA kräver undantag särskild försiktighet. Ett SaaS-företag bör sällan undanta loggning, övervakning, säkerhetskopior, incidenthantering, åtkomstkontroll, leverantörssäkerhet eller hantering av sårbarheter. Även när en kontroll inte är kopplad till en specifik risk kan den ändå vara nödvändig som grundläggande säkerhet, kundassurance, avtalsförväntan eller rättslig skyldighet.

Clarysecs riskhanteringspolicy för små och medelstora företag påminner också team om hur accepterad risk ska hanteras:

Acceptera: Motivera varför ingen ytterligare åtgärd krävs och registrera den kvarstående risken.

Den klausulen, 6.1.1 i riskhanteringspolicyn för små och medelstora företag, är exakt det synsätt som behövs för undantag och beslut om kvarstående risk.

Incidentrapportering: visa arbetsflödet, inte bara att policyn finns

NIS2 Article 23 kräver stegvis rapportering av betydande incidenter, inklusive tidig varning inom 24 timmar från kännedom, anmälan inom 72 timmar, uppdateringar när sådana begärs och en slutrapport inom en månad från 72-timmarsanmälan. DORA kräver att finansiella entiteter upptäcker, hanterar, klassificerar, eskalerar, kommunicerar och rapporterar större IKT-relaterade incidenter, informerar berörda kunder där så krävs, genomför rotorsaksanalys och förbättrar kontroller.

En SaaS-leverantör rapporterar kanske inte alltid direkt till en DORA-myndighet, men kan behöva stödja finansiella kunders rapporteringstidslinjer. Det gör incidentkontroller mycket relevanta i SoA.

En svag SoA säger: ”Incidenthanteringspolicy finns.”

En stark SoA säger: ”Tillämplig eftersom organisationen måste upptäcka, bedöma, klassificera, eskalera, kommunicera, bevara bevismaterial, stödja regulatoriska rapporteringstidslinjer, underrätta berörda kunder där avtal kräver det och dra lärdom av incidenter som påverkar tjänster, data eller reglerade kunder.”

Underlag bör omfatta:

• Incidenthanteringsplan och eskaleringsmatris.
• Kriterier för klassificering av allvarlighetsgrad.
• Arbetsflöde för kundnotifiering.
• Beslutsträd för regulatorisk notifiering där det är tillämpligt.
• Incidentärenden och tidslinjer.
• Loggar och övervakningslarm.
• Register från skrivbordsövningar.
• Efterincidentgranskning och korrigerande åtgärder.
• Rutiner för bevarande av bevismaterial.

Clarysecs policy för revision och efterlevnadsövervakning för större organisationer Policy för revision och efterlevnadsövervakning förklarar varför detta är viktigt:

Att skapa försvarbart underlag och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om assurance från kunder.

Det målet kommer från klausul 3.4 i policyn för revision och efterlevnadsövervakning.

För mindre organisationer måste bevarande av underlag också vara uttryckligt. Clarysecs policy för revision och efterlevnadsövervakning för små och medelstora företag Policy för revision och efterlevnadsövervakning – SME anger:

Underlag ska bevaras i minst två år, eller längre när det krävs enligt certifiering eller kundavtal.

Detta är klausul 6.2.4 i policyn för revision och efterlevnadsövervakning för små och medelstora företag.

En SoA, flera revisionssamtal

Den bästa SoA duplicerar inte ramverk. Den skapar en spårbar kontrollberättelse som olika revisorer kan förstå.

En ISO 27001-revisor börjar vanligtvis med klausullogiken: omfattning, intressenter, riskbedömning, riskbehandling, SoA, mål, internrevision, ledningens genomgång och förbättring. En NIS2-orienterad granskare fokuserar på proportionalitet, ledningens ansvarsskyldighet, utbildning, leveranskedja, incidenttidslinjer och tjänstepåverkan. En DORA-orienterad kundgranskare fokuserar på IKT-risk, kritiska eller viktiga funktioner, större IKT-incidenter, resiliensövningar, avtalsklausuler, revisionsrätt, exitplaner, underleverantörer och koncentrationsrisk. En dataskyddsgranskare fokuserar på GDPR-ansvarsskyldighet och beredskap för incidentanmälan. En COBIT 2019- eller ISACA-inriktad revisor testar styrning, mätetal, ägarskap, assurance och korrigerande åtgärder.

Det är därför SoA inte kan underhållas enbart av säkerhetsteamet. Den behöver ägarskap från juridik, integritet, upphandling, teknik, drift, HR och verkställande ledning.

Vanliga SoA-brister i beredskapsprojekt för NIS2 och DORA

Clarysec ser återkommande samma problem i beredskapsprojekt:

1. SoA markerar kontroller som tillämpliga, men ingen risk, skyldighet eller verksamhetsmässig anledning har dokumenterats.
2. NIS2 och DORA nämns i policyer, men mappas inte till kontroller, ägare eller underlag.
3. Leverantörskontroller markeras som införda, men det finns inget leverantörsregister, ingen kritikalitetsklassning, ingen avtalsgranskning eller ingen exitplan.
4. Incidentkontroller finns, men processen stöder inte arbetsflöden för 24-timmars-, 72-timmars-, kund- eller slutrapportering.
5. Ledningens godkännande förutsätts, men det finns inget register över riskacceptans, SoA-godkännande eller beslut om kvarstående risk.
6. Undantag kopieras från en mall och matchar inte den faktiska operativa modellen för moln, distansarbete, SaaS eller fintech.
7. Underlag finns i olika verktyg, men inget revisionsspår kopplar underlaget till SoA.
8. Behandling av personuppgifter enligt GDPR är inte kopplad till säkerhetskontroller, incidentrespons, leverantörsavtal eller bevarande.
9. Internrevision granskar dokument men testar inte om SoA återspeglar verkligt genomförande.
10. SoA uppdateras endast inför certifiering, inte efter nya kunder, leverantörer, incidenter, revisionsiakttagelser eller regulatoriska ändringar.

Detta är inte dokumentationsproblem. Det är styrningsproblem.

Praktisk checklista för en revisionsklar ISO 27001-SoA

Använd denna checklista inför en ISO 27001-certifieringsrevision, NIS2-beredskapsgranskning, DORA-kundgranskning, ett styrelsemöte eller en investerares leverantörsgranskning.

Gör SoA till en försvarbar brygga för regelefterlevnad

Elenas styrelsepresentation lyckades eftersom hon inte presenterade tre frikopplade efterlevnadsprojekt. Hon presenterade en kontrollerad, evidensbaserad operativ modell byggd på ISO/IEC 27001:2022, med SoA som brygga mellan reglering, risk, kontrollgenomförande, underlag och ledningens tillsyn.

NIS2 och DORA gör inte ISO 27001 obsolet. De gör en väl utformad ISO 27001-tillämpbarhetsförklaring mer värdefull. SoA kan bli den enda plats där organisationen förklarar varför kontroller finns, varför undantag är försvarbara, hur underlag bevaras, hur leverantörer styrs, hur incidenter eskaleras och hur ledningen vet att ISMS fungerar.

Din omedelbara åtgärd är enkel:

1. Öppna er nuvarande SoA.
2. Välj fem kontroller som markerats som tillämpliga och fråga: ”Vilken risk, skyldighet eller vilket avtal motiverar detta?”
3. Välj fem undantag och fråga: ”Skulle detta fortfarande vara rimligt för en NIS2-, DORA-, GDPR- eller ISO/IEC 27001:2022-revisor?”
4. Kontrollera om varje tillämplig kontroll har aktuellt underlag.
5. Bekräfta att ledningen har godkänt kvarstående risker och SoA-beslut.
6. Uppdatera registret över efterlevnadskrav, riskregistret och SoA när tjänster, leverantörer, kunder, regelverk eller incidenter ändras.

Clarysec hjälper organisationer att göra detta genom Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, policyuppsättningar för större organisationer och små och medelstora företag, verktyg för riskregister, SoA-mallar, revisionsförberedelser och mappning för korsvis regelefterlevnad avseende NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 och kundassurance.

Om er SoA inte kan besvara varför, vem som äger kontrollen, vilket underlag som styrker den och vilken skyldighet den stöder, är den inte redo ännu. Använd Clarysec för att göra den till en revisionsklar brygga för regelefterlevnad innan en tillsynsmyndighet, revisor eller kund ställer samma frågor först.