ISO 27001 SoA til NIS2- og DORA-parathed

Klokken er 08.30 en mandag morgen, og Elena, CISO hos en hurtigt voksende B2B fintech-SaaS-udbyder, åbner en hastemarkeret anmodning fra bestyrelsen. Virksomheden har netop opnået ISO/IEC 27001:2022-certificering, men en stor potentiel EU-bankkunde stiller mere krævende spørgsmål end i det sædvanlige sikkerhedsspørgeskema.

De spørger ikke kun, om virksomheden krypterer data, bruger MFA eller har en rapport fra penetrationstest. De vil vide, om SaaS-platformen understøtter deres DORA-forpligtelser, om udbyderen kan være omfattet af NIS2 som IKT-tjeneste eller som afhængighed i digital infrastruktur, og om ISO 27001 Anvendelseserklæring kan begrunde hver medtaget kontrol, hver udelukket kontrol og hvert stykke bevismateriale.

Bestyrelsen stiller det spørgsmål, som enhver CISO, complianceansvarlig og SaaS-stifter hører oftere og oftere:

Kan vores ISO 27001 SoA dokumentere NIS2- og DORA-parathed?

Elena ved, at det forkerte svar ville være at etablere tre separate efterlevelsesprogrammer: ét for ISO 27001, ét for NIS2 og ét for DORA. Det ville skabe duplikeret bevismateriale, modstridende kontrolansvarlige og en konstant jagt på dokumentation før hver kundevurdering. Det bedre svar er at bruge det eksisterende ISMS som driftsmodel for efterlevelse med Anvendelseserklæringen, eller SoA, som det overordnede sporbarhedsdokument.

SoA er ikke blot et regneark til ISO-certificering. I et EU-miljø for cybersikkerhed og digital operationel robusthed er det dér, en organisation dokumenterer, hvorfor kontroller findes, hvorfor udelukkelser er forsvarlige, hvem der ejer hver kontrol, hvilket bevismateriale der understøtter implementeringen, og hvordan kontrolsættet adresserer NIS2, DORA, GDPR, kundekontrakter og intern risikobehandling.

Clarysecs enterpriseudgave af Informationssikkerhedspolitik Informationssikkerhedspolitik fastsætter:

ISMS skal omfatte definerede omfangsafgrænsninger, en risikovurderingsmetode, målbare målsætninger og dokumenterede kontroller, der er begrundet i Anvendelseserklæringen (SoA).

Dette krav, fra politikklausul 6.1.2 i Informationssikkerhedspolitik, er grundlaget for en revisionsklar tilgang. SoA skal være broen mellem forpligtelser, risici, kontroller, bevismateriale og ledelsesbeslutninger.

Hvorfor NIS2 og DORA ændrede betydningen af “anvendelig”

En traditionel ISO/IEC 27001:2022 SoA starter ofte med et enkelt spørgsmål: “Hvilke Annex A-kontroller gælder for vores risikobehandlingsplan?” Det er stadig korrekt, men det er ikke længere tilstrækkeligt for SaaS-, cloud-, managed services-, fintech- og kritiske leverandører i forsyningskæden.

NIS2 hæver grundniveauet for cybersikkerhedsrisikostyring på tværs af væsentlige og vigtige enheder i EU. Direktivet omfatter sektorer som digital infrastruktur, cloud computing-tjenester, datacentertjenester, indholdsleveringsnetværk, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, bankvirksomhed og finansielle markedsinfrastrukturer. Medlemsstaterne skal identificere væsentlige og vigtige enheder samt udbydere af domænenavnsregistreringstjenester, og mange teknologiudbydere, der tidligere betragtede cybersikkerhedsregulering som et kundespørgsmål, er nu enten direkte omfattet eller eksponeret gennem kontraktlige flow-down-krav.

NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger inden for risikoanalyse, sikkerhedspolitikker, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, vurdering af kontroleffektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring og autentifikation, hvor det er relevant. NIS2 Article 23 tilføjer forventninger til faseopdelt hændelsesrapportering, herunder tidlig varsling, underretning, opdateringer og endelig rapportering for væsentlige hændelser.

DORA, Digital Operational Resilience Act, finder anvendelse fra 17. januar 2025 og fokuserer på finansielle enheder og deres IKT-risikoøkosystem. DORA omfatter styring af IKT-risiko, rapportering af IKT-relaterede hændelser, rapportering af operationelle eller sikkerhedsrelaterede betalingshændelser for visse enheder, test af digital operationel robusthed, deling af information om cybertrusler, styring af IKT-tredjepartsrisici, kontraktlige ordninger og tilsyn med kritiske IKT-tredjepartsudbydere.

For finansielle enheder, der også er væsentlige eller vigtige enheder efter NIS2, fungerer DORA som den sektorspecifikke ordning for tilsvarende forpligtelser vedrørende IKT-risikostyring og hændelsesrapportering. Men for SaaS-udbydere, cloududbydere, MSP’er og MDR-udbydere, der leverer til finansielle kunder, er den praktiske realitet, at DORA-forventninger kommer gennem indkøb, kontrakter, revisionsrettigheder, forpligtelser til hændelsesstøtte, exitplanlægning, transparens om underleverandører og bevismateriale for robusthed.

Det ændrer SoA-dialogen. Spørgsmålet er ikke længere: “Indeholder Annex A denne kontrol?” Det bedre spørgsmål er:

Kan vi dokumentere, at kontroludvælgelsen er risikobaseret, forpligtelsesbevidst, forholdsmæssig, ejet, implementeret, overvåget, underbygget med bevismateriale og godkendt?

ISO 27001 er den universelle oversætter for NIS2 og DORA

ISO/IEC 27001:2022 er værdifuld, fordi den er en standard for ledelsessystemer og ikke en snæver tjekliste. Den kræver, at ISMS integreres i organisationens processer og skaleres efter organisationens behov. Det gør den til en effektiv universel oversætter for overlappende efterlevelseskrav.

Klausul 4.1 til 4.4 kræver, at organisationen forstår sin kontekst, identificerer interessenter, fastlægger relevante krav og definerer ISMS-omfanget. For en fintech-SaaS-udbyder som Elenas virksomhed kan disse interessentkrav omfatte EU-kunder, finansielle kunder berørt af DORA, eksponering mod NIS2-sektorer, GDPR-forpligtelser som dataansvarlig og databehandler, outsourcede cloudafhængigheder, leverandørgrænseflader og bestyrelsens forventninger.

Klausul 6.1.1 til 6.1.3 kræver planlægning for risici og muligheder, en gentagelig proces for informationssikkerhedsrisikovurdering, en risikobehandlingsproces, sammenligning med Annex A og en Anvendelseserklæring, der identificerer medtagne kontroller, implementeringsstatus og begrundelser for udelukkelser.

Her bliver SoA til et beslutningsregister for kontroller. En kontrol kan medtages, fordi den behandler en risiko, opfylder et retligt krav, opfylder en kundekontrakt, understøtter et forretningsmål eller udgør grundlæggende sikkerhedshygiejne. En kontrol må kun udelukkes, når organisationen bevidst har vurderet den, fundet den irrelevant for ISMS-omfanget, dokumenteret begrundelsen og indhentet passende godkendelse.

Clarysecs enterpriseudgave af Politik for risikostyring Politik for risikostyring fastsætter:

En Anvendelseserklæring (SoA) skal afspejle alle behandlingsbeslutninger og skal opdateres, når kontroldækningen ændres.

Dette krav, fra politikklausul 5.4 i Politik for risikostyring, er afgørende for NIS2- og DORA-parathed. En ny reguleret kunde, en ny cloudafhængighed, en ny forpligtelse til hændelsesrapportering eller en ny koncentrationsrisiko hos leverandører kan alle ændre kontrolanvendeligheden.

Start med efterlevelsesregisteret, ikke kontrollisten

En svag SoA starter med Annex A og spørger: “Hvilke kontroller har vi allerede?” En stærk SoA starter med organisationens driftsmæssige virkelighed og spørger: “Hvilke forpligtelser, tjenester, risici, data, leverandører og kunder skal ISMS adressere?”

ISO/IEC 27005:2022 understøtter denne tilgang ved at fremhæve interessentkrav, risikokriterier og behovet for at tage højde for standarder, interne regler, love, reguleringer, kontrakter og eksisterende kontroller. Den understreger også, at ikke-anvendelighed eller manglende efterlevelse skal forklares og begrundes.

Clarysecs SMV-udgave af Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse - SMV beskriver det samme driftsprincip:

GM skal vedligeholde et enkelt, struktureret efterlevelsesregister med følgende oplysninger:

Dette krav kommer fra klausul 5.1.1 i Politik for juridisk og regulatorisk efterlevelse. For en mindre organisation kan registeret være enkelt. For en enterprise-organisation skal det være mere detaljeret. Logikken er den samme: Forpligtelser skal være synlige, før de kan kortlægges.

Clarysecs enterpriseudgave af Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse er eksplicit:

Alle retlige og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).

Det er politikklausul 6.2.1 i Politik for juridisk og regulatorisk efterlevelse. Den udgør styringsrygraden for at bruge en ISO 27001 Anvendelseserklæring til parathed over for NIS2- og DORA-efterlevelse.

Opbyg risikokriterier, der afspejler robusthed, databeskyttelse, leverandører og regulering

Mange SoA-begrundelser fejler, fordi risikoscoringsmodellen er for snæver. Den måler teknisk sandsynlighed og konsekvens, men indfanger ikke regulatorisk eksponering, tjenestekritikalitet, skade for kunder, leverandørafhængighed, påvirkning af databeskyttelse eller systemiske driftsforstyrrelser.

NIS2 handler ikke kun om fortrolighed. Direktivet fokuserer på at forebygge og minimere hændelsers påvirkning af tjenester og modtagere af tjenester. DORA definerer kritiske eller vigtige funktioner ud fra, om en forstyrrelse væsentligt vil forringe finansiel performance, servicekontinuitet eller regulatorisk efterlevelse. GDPR tilføjer ansvarlighed, integritet, fortrolighed, beredskab ved brud på persondatasikkerheden og skade for registrerede.

Clarysecs SMV-udgave af Politik for risikostyring Politik for risikostyring - SMV giver et praktisk minimum:

Hver risikopost skal indeholde: beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan.

Dette er klausul 5.1.2 i Politik for risikostyring. For NIS2- og DORA-parathed udvider Clarysec dette minimum med felter som kilde til forpligtelse, berørt tjeneste, datakategori, leverandørafhængighed, forretningsansvarlig, regulatorisk påvirkning, restrisiko, behandlingsstatus og kilde til bevismateriale.

Bemærk formuleringen. En stærk begrundelse siger ikke kun “implementeret”. Den forklarer, hvorfor kontrollen er anvendelig i organisationens forretningsmæssige, regulatoriske og risikomæssige kontekst.

Kortlæg NIS2- og DORA-domæner til ISO 27001:2022-kontroller

Når efterlevelsesregisteret og risikokriterierne er etableret, består det praktiske arbejde i at kortlægge regulatoriske domæner til Annex A-kontroller. Denne kortlægning dokumenterer ikke i sig selv efterlevelse, men den giver revisorer og kunder et tydeligt indeks til test af bevismateriale.

For Elena ændrede denne kortlægning bestyrelsesdialogen. I stedet for at præsentere NIS2 og DORA som separate projekter kunne hun vise overlapningen: governance, risikostyring, hændelser, kontinuitet, leverandører, test, adgangsstyring og kryptografi.

De tre ISO-kontroller, som enhver NIS2- og DORA-SoA afhænger af

I Zenith Controls: The Cross-Compliance Guide Zenith Controls behandler Clarysec tre ISO/IEC 27002:2022-kontroller som centrale for revisionsklar SoA-styring for NIS2 og DORA. Det er ISO-kontroller, beriget med tværgående efterlevelsesattributter i Zenith Controls-guiden.

Disse kontroller står ikke alene. De er direkte forbundet med leverandørrelationskontrollerne A.5.19 til A.5.23, kontroller for hændelsesstyring A.5.24 til A.5.28, kontinuitetskontrollerne A.5.29 og A.5.30, databeskyttelseskontrollen A.5.34, sårbarhedsstyring A.8.8, konfigurationsstyring A.8.9, backup af information A.8.13, logning A.8.15, overvågningsaktiviteter A.8.16, kryptografi A.8.24, kontroller for sikker udvikling A.8.25 til A.8.29 og ændringsstyring A.8.32.

Værdien af Zenith Controls er, at den hjælper teams med at undgå at behandle SoA som et artefakt for én standard. Kontrol 5.31 understøtter juridisk og kontraktlig kortlægning. Kontrol 5.35 understøtter intern revision, uafhængig gennemgang og ledelsesmæssig sikkerhed. Kontrol 5.36 understøtter operationel efterlevelse af politikker, procedurer, standarder og kontrolkrav.

Brug Zenith Blueprint til at opbygge, teste og forsvare SoA

I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint placerer Clarysec udarbejdelsen af SoA i risikostyringsfasen, trin 13: Planlægning af risikobehandling og Anvendelseserklæring. Blueprintet instruerer organisationer i at bruge SoA-arket i skabelonen “Risk Register and SoA Builder.xlsx”, beslutte om hver af de 93 Annex A-kontroller er anvendelig, og basere beslutningen på risikobehandling, juridiske og kontraktlige krav, relevans for omfanget og organisatorisk kontekst.

Blueprintet fastsætter:

SoA er i praksis et brobyggende dokument: Det kobler jeres risikovurdering/-behandling til de faktiske kontroller, I har.

Denne sætning indfanger driftsmodellen. SoA bygger bro mellem forpligtelser, risici, politikker, kontroller, bevismateriale og revisionskonklusioner.

Zenith Blueprint instruerer også teams i at krydshenvise til reguleringer i SoA-noter, hvor det er relevant. Hvis en kontrol er implementeret for GDPR, NIS2 eller DORA, skal det fremgå af risikoregisteret eller SoA-noterne. Senere, i trin 24, pålægger Blueprintet organisationer at opdatere SoA efter implementering og krydskontrollere den mod risikobehandlingsplanen. I trin 30, certificeringsforberedelse, endelig gennemgang og mock audit, anviser Blueprintet teams at bekræfte, at hver anvendelig Annex A-kontrol har bevismateriale som en politik, procedure, rapport, plan eller implementeringsregistrering.

Denne rækkefølge gør SoA til et levende efterlevelsesinstrument:

1. Trin 13 opbygger den på grundlag af risikobehandling og forpligtelser.
2. Trin 24 tester den mod den faktiske implementering.
3. Trin 30 forsvarer den gennem endelig gennemgang af bevismateriale og mock audit.

Sådan skriver du medtagelsesbegrundelser, som revisorer kan følge

En kontrol skal medtages, når der findes mindst én forsvarlig driver: risikobehandling, retligt krav, kontraktligt krav, relevans for omfanget, grundlæggende sikkerhedshygiejne, kunders forventning om sikkerhedsdokumentation eller et ledelsesgodkendt robusthedsmål.

En nyttig formel er:

Anvendelig, fordi [risiko eller forpligtelse] påvirker [tjeneste, aktiv, data eller proces], og denne kontrol giver [forebyggende, opdagende, korrigerende eller robusthedsrelateret resultat], dokumenteret ved [politik, registrering, test, rapport eller systemoutput].

For en fintech-SaaS-udbyder kan én SoA-række se sådan ud:

Dette er revisionsklart, fordi det kobler kontrollen til kontekst, risiko, forpligtelse, implementering, ejerskab og bevismateriale.

Sådan begrundes udelukkelser uden at skabe revisionseksponering

Udelukkelser er ikke fejl. Dårligt begrundede udelukkelser er fejl.

ISO/IEC 27001:2022 kræver, at SoA begrunder udelukkede Annex A-kontroller. ISO/IEC 27005:2022 understøtter, at ikke-anvendelighed skal forklares og begrundes. Clarysecs enterpriseudgave af Informationssikkerhedspolitik fastsætter:

Baseline kan tilpasses; udelukkelser skal dog dokumenteres med formel godkendelse og begrundelse i SoA.

Dette er klausul 7.2.2 i Informationssikkerhedspolitik.

Clarysecs Informationssikkerhedspolitik - SMV Informationssikkerhedspolitik - SMV fastsætter:

Enhver afvigelse fra denne politik skal dokumenteres med en klar forklaring på, hvorfor afvigelsen er nødvendig, hvilke alternative beskyttelsesforanstaltninger der er etableret, og den dato, der er fastsat for revurdering.

Dette krav kommer fra klausul 7.2.1 i Informationssikkerhedspolitik - SMV.

For NIS2 og DORA kræver udelukkelser særlig omhu. En SaaS-virksomhed bør sjældent udelukke logning, overvågning, backups, hændelsesstyring, adgangsstyring, leverandørsikkerhed eller sårbarhedsstyring. Selv hvor en kontrol ikke er knyttet til én specifik risiko, kan den stadig være nødvendig som grundlæggende sikkerhed, kundedokumentation, kontraktlig forventning eller retlig forpligtelse.

Clarysecs Politik for risikostyring - SMV minder også teams om, hvordan accepteret risiko skal håndteres:

Accepter: Begrund, hvorfor der ikke kræves yderligere handling, og registrér restrisikoen.

Denne klausul, 6.1.1 i Politik for risikostyring - SMV, er præcis den tilgang, der er nødvendig for udelukkelser og beslutninger om restrisiko.

Hændelsesrapportering: dokumentér arbejdsgangen, ikke blot at politikken findes

NIS2 Article 23 kræver faseopdelt rapportering af væsentlige hændelser, herunder tidlig varsling inden for 24 timer efter kendskab, underretning inden for 72 timer, opdateringer hvor det kræves, og en endelig rapport inden for én måned efter 72-timersunderretningen. DORA kræver, at finansielle enheder opdager, håndterer, klassificerer, eskalerer, kommunikerer og rapporterer større IKT-relaterede hændelser, informerer berørte kunder hvor det kræves, udfører rodårsagsanalyse og forbedrer kontroller.

En SaaS-udbyder rapporterer ikke altid direkte til en DORA-myndighed, men kan skulle understøtte finansielle kunders rapporteringsfrister. Det gør hændelseskontroller meget relevante i SoA.

En svag SoA siger: “Politik for hændelseshåndtering findes.”

En stærk SoA siger: “Anvendelig, fordi organisationen skal opdage, vurdere, klassificere, eskalere, kommunikere, bevare bevismateriale, understøtte regulatoriske rapporteringsfrister, underrette berørte kunder hvor det kræves kontraktligt, og lære af hændelser, der påvirker tjenester, data eller regulerede kunder.”

Bevismateriale skal omfatte:

• Hændelseshåndteringsplan og eskalationsmatrix.
• Kriterier for klassificering af alvorlighed.
• Arbejdsgang for kundeunderretning.
• Beslutningstræ for regulatorisk underretning, hvor det er relevant.
• Hændelsestickets og tidslinjer.
• Logfiler og overvågningsalarmer.
• Registreringer fra tabletop-øvelser.
• Efterhændelsesgennemgang og korrigerende handlinger.
• Procedurer for bevaring af bevismateriale.

Clarysecs enterpriseudgave af Politik for revision og overvågning af efterlevelse Politik for revision og overvågning af efterlevelse forklarer, hvorfor dette er vigtigt:

At generere forsvarligt bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller kunders anmodninger om dokumentation.

Dette mål kommer fra klausul 3.4 i Politik for revision og overvågning af efterlevelse.

For mindre organisationer skal opbevaring af bevismateriale også være eksplicit. Clarysecs Politik for revision og overvågning af efterlevelse - SMV Politik for revision og overvågning af efterlevelse - SMV fastsætter:

Bevismateriale skal opbevares i mindst to år eller længere, hvor det kræves af certificering eller kundeaftaler.

Det er klausul 6.2.4 i Politik for revision og overvågning af efterlevelse - SMV.

Én SoA, flere revisionsdialoger

Den bedste SoA duplikerer ikke frameworks. Den skaber en sporbar kontrolfortælling, som forskellige revisorer kan forstå.

En ISO 27001-revisor starter typisk med klausullogikken: omfang, interessenter, risikovurdering, risikobehandling, SoA, målsætninger, intern revision, ledelsens gennemgang og forbedring. En NIS2-orienteret gennemgang fokuserer på proportionalitet, ledelsesansvar, træning, forsyningskæde, hændelsesfrister og påvirkning af tjenester. En DORA-orienteret kundevurdering fokuserer på IKT-risiko, kritiske eller vigtige funktioner, større IKT-hændelser, robusthedstest, kontraktklausuler, revisionsrettigheder, exitplaner, underleverandører og koncentrationsrisiko. En databeskyttelsesgennemgang fokuserer på GDPR-ansvarlighed og beredskab ved brud på persondatasikkerheden. En COBIT 2019- eller ISACA-lignende revisor tester governance, metrikker, ejerskab, assurance og korrigerende handling.

Derfor kan SoA ikke kun vedligeholdes af sikkerhedsteamet. Den kræver ejerskab fra jura, databeskyttelse, indkøb, engineering, drift, HR og topledelsen.

Almindelige SoA-fejl i NIS2- og DORA-parathedsprojekter

Clarysec finder gentagne gange de samme problemer i parathedsprojekter:

1. SoA markerer kontroller som anvendelige, men der er ikke registreret nogen risiko, forpligtelse eller forretningsmæssig begrundelse.
2. NIS2 og DORA nævnes i politikker, men er ikke kortlagt til kontroller, ejere eller bevismateriale.
3. Leverandørkontroller er markeret som implementeret, men der findes ikke et leverandørregister, en kritikalitetsvurdering, en kontraktgennemgang eller en exitplan.
4. Hændelseskontroller findes, men processen understøtter ikke 24-timers-, 72-timers-, kunde- eller slutrapporteringsarbejdsgange.
5. Ledelsesgodkendelse er underforstået, men der findes ingen registrering af risikoaccept, SoA-godkendelse eller beslutning om restrisiko.
6. Udelukkelser er kopieret fra en skabelon og matcher ikke den faktiske cloud-, fjernarbejds-, SaaS- eller fintech-driftsmodel.
7. Bevismateriale findes på tværs af værktøjer, men intet revisionsspor kobler bevismaterialet til SoA.
8. GDPR-behandling af personoplysninger er ikke koblet til sikkerhedskontroller, håndtering af brud, leverandørkontrakter eller opbevaring.
9. Intern revision kontrollerer dokumenter, men tester ikke, om SoA afspejler den faktiske implementering.
10. SoA opdateres kun før certificering, ikke efter nye kunder, leverandører, hændelser, revisionsobservationer eller regulatoriske ændringer.

Det er ikke papirarbejdsproblemer. Det er governance-problemer.

Praktisk tjekliste for en revisionsklar ISO 27001 SoA

Brug denne tjekliste før en ISO 27001-certificeringsrevision, NIS2-parathedsgennemgang, DORA-kundevurdering, bestyrelsesmøde eller investor-due diligence-proces.

Gør SoA til en forsvarlig efterlevelsesbro

Elenas bestyrelsespræsentation lykkedes, fordi hun ikke præsenterede tre løsrevne efterlevelsesprojekter. Hun præsenterede én kontrolleret, bevisbaseret driftsmodel bygget på ISO/IEC 27001:2022, med SoA som bro mellem regulering, risiko, kontrolimplementering, bevismateriale og ledelsestilsyn.

NIS2 og DORA gør ikke ISO 27001 forældet. De gør en velopbygget ISO 27001 Anvendelseserklæring mere værdifuld. SoA kan blive det centrale sted, hvor din organisation forklarer, hvorfor kontroller findes, hvorfor udelukkelser er forsvarlige, hvordan bevismateriale opbevares, hvordan leverandører styres, hvordan hændelser eskaleres, og hvordan ledelsen ved, at ISMS fungerer.

Din umiddelbare handling er enkel:

1. Åbn din nuværende SoA.
2. Vælg fem kontroller markeret som anvendelige, og spørg: “Hvilken risiko, forpligtelse eller kontrakt begrunder dette?”
3. Vælg fem udelukkelser, og spørg: “Ville dette stadig give mening for en NIS2-, DORA-, GDPR- eller ISO/IEC 27001:2022-revisor?”
4. Kontrollér, om hver anvendelig kontrol har aktuelt bevismateriale.
5. Bekræft, at ledelsen har godkendt restrisici og SoA-beslutninger.
6. Opdater efterlevelsesregisteret, risikoregisteret og SoA, når tjenester, leverandører, kunder, reguleringer eller hændelser ændres.

Clarysec hjælper organisationer med dette gennem Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, politikpakker til enterprise og SMV, værktøjer til risikoregister, SoA-skabeloner, revisionsforberedelse og kortlægning på tværs af efterlevelseskrav for NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 og kundedokumentation.

Hvis din SoA ikke kan svare på hvorfor, hvem der ejer det, hvilket bevismateriale der dokumenterer det, og hvilken forpligtelse det understøtter, er den endnu ikke klar. Brug Clarysec til at gøre den til en revisionsklar efterlevelsesbro, før en tilsynsmyndighed, revisor eller kunde stiller de samme spørgsmål først.