Livscykelstyrning av policyer för ISO 27001, NIS2 och DORA

E-postmeddelandet landade i informationssäkerhetschefen Maria Petrovas inkorg med ett diskret ljud som ändå kändes som en siren. Det kom från den externa revisorn: en preliminär begäran om underlag inför en kombinerad uppföljningsrevision enligt ISO/IEC 27001:2022 och en beredskapsbedömning mot DORA. Den första punkten såg enkel ut:

”Vänligen tillhandahåll aktuell informationssäkerhetspolicy, fullständig versionshistorik, underlag för ledningens godkännande av varje version samt poster som visar att policyn har kommunicerats till relevant personal under de senaste 24 månaderna.”

Marias organisation, en medelstor fintechplattform, hade policyer. Dussintals. Den hade en informationssäkerhetspolicy, en incidenthanteringsplan, ett frågeformulär för leverantörssäkerhet, ett riskregister, en åtkomstkontrollrutin, en kontinuitetsplan och en mapp full av revisionsbevis. Men filerna låg utspridda över SharePoint-ytor, äldre Confluence-utrymmen, e-posttrådar, ärendebilagor och delade enheter som ägdes av personer som redan hade lämnat organisationen.

Det verkliga problemet blev tydligt när revisorns följdfrågor kom.

Vem godkände den aktuella incidentrutinen? Varför anger leverantörssäkerhetspolicyn i SharePoint version 2.1 medan upphandling använder version 1.8? Vilken policy är mappad till riskhanteringsåtgärderna i NIS2 artikel 21? Var finns posten som visar att personalen informerades om den senaste policyuppdateringen? Varför beviljades ett undantag för privilegierad åtkomst, vem accepterade den kvarstående risken och när löper undantaget ut? Har föråldrade dokument tagits bort från operativ användning? Hur länge bevaras revisionsrapporter? Kan organisationen visa att policybiblioteket granskades efter den senaste större systemförändringen?

Maria hade kontroller, men ingen kontroll över kontrollerna.

Detta är problemet med livscykelstyrning av policyer 2026. Organisationer underkänns inte längre i revisioner enbart för att en brandväggsregel är felaktig eller ett återställningstest saknas. De underkänns för att dokumenterad information är fragmenterad, svår att granska, duplicerad, inaktuell, okontrollerad eller frikopplad från rättsliga skyldigheter. Enligt ISO/IEC 27001:2022 klausul 7.5 är dokumenterad information inte administrativ ordning och reda. Den är ISMS:ets operativa minne. Enligt NIS2 stödjer den ledningsorganets godkännande och tillsyn. Enligt DORA blir den en del av ramverket för IKT-riskhantering och revisionsspåret för resiliens. Enligt GDPR visar den ansvarsskyldighet.

Clarysecs syn är tydlig: ett policybibliotek är inte en dokumentdump. Det är ett styrt system för revisionsunderlag.

Varför livscykelstyrning av policyer nu är en styrelsefråga

Livscykelstyrning av policyer är disciplinen för att skapa, godkänna, publicera, kommunicera, granska, ändra, avveckla, bevara och belägga policyer och relaterade poster. Den besvarar de frågor som revisorer, tillsynsmyndigheter, kunder och styrelser numera rutinmässigt ställer:

1. Vem äger varje policy?
2. Vem godkänner den?
3. Vilka rättsliga, avtalsmässiga och riskbaserade krav uppfyller den?
4. Vilka kontroller och rutiner genomför den?
5. Vilken version är aktuell?
6. Vem har informerats, utbildats eller behövt bekräfta den?
7. Vilka undantag är kopplade till den?
8. Vilka poster visar att den fungerar i praktiken?
9. Vad händer när den blir föråldrad?

ISO/IEC 27001:2022 stödjer denna disciplin genom klausul 7.5 om dokumenterad information, klausul 5 om ledarskap, klausul 6 om planering och riskbehandling, klausul 8 om operativ styrning samt kontroller i bilaga A som omfattar policyer, poster, rättsliga krav, leverantörer, incidenter, kontinuitet, integritetsskydd, loggning, övervakning och ändringshantering.

Det regulatoriska trycket är lika direkt.

NIS2 artikel 20 kräver att ledningsorgan godkänner riskhanteringsåtgärder för cybersäkerhet, övervakar genomförandet och får lämplig utbildning. Artikel 21 kräver riskbaserade tekniska, operativa och organisatoriska åtgärder, däribland säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, effektivitetsbedömning, cyberhygien, kryptografi, personalsäkerhet, åtkomstkontroll, tillgångshantering och autentisering. En policykorpus utan ägarskap, godkännande och granskningsunderlag försvagar berättelsen om ledningens ansvarsskyldighet.

DORA gäller från den 17 januari 2025 och fastställer ett enhetligt EU-ramverk för IKT-riskhantering, incidentrapportering, testning av digital operativ resiliens, IKT-tredjepartsrisker och avtalskrav. För finansiella entiteter som även är väsentliga eller viktiga entiteter enligt NIS2 betraktas DORA som den sektorsspecifika unionsrättsakten för motsvarande cybersäkerhetsskyldigheter. Artikel 5 kräver att ledningsorganet ansvarar för ramverket för IKT-riskhantering, policyer, ansvar, kontinuitetsplaner, revisioner, policyer för IKT-tredjepart, rapporteringskanaler och utbildning. Artikel 6 kräver ett väl dokumenterat ramverk för IKT-riskhantering, som för finansiella entiteter som inte är mikroföretag granskas minst årligen och förbättras utifrån erfarenhetsåterföring.

GDPR tillför kravet på ansvarsskyldighet. Artikel 5 kräver att personuppgifter behandlas lagligt, korrekt och öppet, för specificerade ändamål, med uppgiftsminimering, korrekthet, lagringsminimering och säkerhet. Artikel 5(2) gör den personuppgiftsansvarige ansvarig för att kunna visa efterlevnad. Denna bevisföring bygger på kontrollerade poster: beslut om rättslig grund, bevarandescheman, DPIA:er där tillämpligt, leverantörsgranskning av personuppgiftsbiträden, incidentregister, åtkomstgranskningar, utbildningsloggar och policygodkännanden.

Den gemensamma nämnaren är revisionsunderlag. En revisor frågar inte bara om en policy finns. Revisorn begär dess födelseattest, versionshistorik, godkännandespår, kommunikationspost, relaterade rutiner och operativa poster som visar att den fungerar.

Ryggraden för dokumenterad information i ISO/IEC 27001:2022

Ryggraden i försvarbar dokumentation är ISO/IEC 27001:2022 klausul 7.5, Dokumenterad information. Den kräver att organisationer skapar, uppdaterar och styr den dokumenterade information som behövs för ISMS och som krävs av standarden.

Ett praktiskt sätt att förstå detta är att dela upp dokumenterad information i tre lager:

Clarysecs Zenith Blueprint: en revisors 30-stegs färdplan behandlar detta uttryckligen i fasen för ISMS-grund och ledarskap, steg 6: Dokumenterad information och uppbyggnad av ISMS-biblioteket. Den förklarar att klausul 7.5 omfattar dokumentation i stort, skapande och uppdatering samt styrning av dokumenterad information.

Zenith Blueprint omsätter detta i praktisk vägledning för införande:

”Dokument ska ha korrekt identifiering, såsom titel, eventuellt dokumentnummer eller unik identifierare och författare, ett lämpligt format … samt granskas och godkännas avseende lämplighet före användning.”

Den anger också den operativa regel som många organisationer missar:

”Säkerställ att endast den aktuella versionen är lätt att hitta; arkivera föråldrade versioner eller märk dem tydligt som ersatta.”

Det är här många ISMS-införanden tyst går sönder. En policy kan ha godkänts en gång, men om gamla versioner fortfarande är tillgängliga, personalen använder föråldrade rutiner eller revisorer inte kan spåra ändringar är dokumentet inte längre styrt på ett meningsfullt sätt.

Zenith Blueprint rekommenderar att ett ”ISMS-dokumentbibliotek” etableras med mappar för policyer och rutiner, riskbedömning och SoA, utbildnings- och medvetenhetsunderlag, revision och granskning, incidentregister, tillgångar och förteckningar samt ett kontrollbibliotek för bilaga A. Den anger även att lagringsplatsen ska vara ”tillgänglig men säker”, där policyer kan läsas av anställda medan konfidentiella mappar, såsom riskbedömningar och incidentregister, är begränsade.

Detta är inte bara en arkiveringsmodell. Det är en styrningsarkitektur.

Clarysecs modell för policyers livscykel

Clarysec strukturerar livscykelstyrning av policyer enligt ISO 27001 kring en sluten loop: krav, ägare, dokument, godkännande, publicering, kommunikation, underlag, granskning, ändring, bevarande och avveckling. Den loopen förhindrar det klassiska revisionsmisslyckandet där ett företag har dokument men inte kan visa befogenhet, aktualitet eller kontroll.

Denna livscykel är starkare än ett engångsgodkännande eftersom den kopplar dokument till kontroller, ägare och underlag. Den stödjer även tvärgående regelefterlevnad. En enda incidenthanteringspolicy kan mappas till incidentkontroller i ISO/IEC 27001:2022 bilaga A, beredskap för rapportering enligt NIS2 artikel 23, DORA:s processer för incidentklassificering och rapportering, hantering av personuppgiftsincidenter enligt GDPR, Respond-utfall i NIST CSF 2.0 och styrningsförväntningar i COBIT 2019.

Vad Clarysec-policyer kräver för granskning, versionshantering och underlag

Clarysecs policybibliotek är utformat så att kraven på policyers livscykel inte lämnas åt tolkning.

För små och medelstora företag anger Information Security Policy-sme - SME en tydlig granskningsutlösare:

”Denna policy ska granskas av vd minst årligen för att säkerställa fortsatt efterlevnad av ISO/IEC 27001-certifieringskrav, regulatoriska förändringar såsom GDPR, NIS2 och DORA samt förändrade verksamhetsbehov.”

Den kräver även dokumenterade ändringsposter:

”Alla policygranskningar och ändringar ska dokumenteras formellt, med tydlig angivelse av datum, ändringarnas art och vd:s godkännande.”

Och den bevarar historisk spårbarhet:

”En historisk post över policyversioner ska underhållas säkert för att visa policyns utveckling och efterlevnad vid revisioner.”

Dessa tre klausuler löser ett vanligt problem för små och medelstora företag. Organisationen kanske inte har en stor styrningsfunktion, men den behöver ändå bevis för granskning, godkännande och versionshistorik.

SME-versionen av Governance Roles and Responsibilities Policy-sme - SME lägger till kravet på spårbarhet för styrningsbeslut:

”Alla betydande säkerhetsbeslut, undantag och eskaleringar ska registreras och vara spårbara.”

Den klausulen är kritisk för policyundantag. En tillfällig avvikelse från MFA, en försenad leverantörsgranskning eller en akut ändring av bevarandetiden för loggar ska inte bara finnas i e-posttrådar. Den ska kopplas till relevant policy, kontroll, riskägare, beslut om kvarstående risk och utgångsdatum.

För centralisering av underlag anger SME-versionen av Audit and Compliance Monitoring Policy-sme - SME:

”Alla underlag ska lagras i en centraliserad revisionsmapp.”

I större organisationer kräver Clarysecs Informationssäkerhetspolicy att policyer ska:

”Vara versionshanterade och dokumenterade”

och:

”Kommuniceras till alla berörda parter via officiella kommunikationskanaler”

Den koncerninriktade Governance Roles and Responsibilities Policy inför begreppet:

”Policyägare och godkännare”

Den koncerninriktade Audit and Compliance Monitoring Policy lägger till förväntningar på bevarande:

”Rapporter ska bevaras i minst sex år, eller längre när det krävs enligt lag, lagras säkert och omfattas av versionshantering enligt Document and Records Management Policy (P6).”

Slutligen kopplar den koncerninriktade Legal and Regulatory Compliance Policy rättsliga skyldigheter till ISMS:

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

Detta krav är bryggan mellan livscykelstyrning av policyer och underlag för NIS2, DORA och GDPR. Utan mappning av skyldigheter kan ett företag ha dokument, men kan inte visa att dokumenten uppfyller specifika rättsliga, avtalsmässiga eller riskbaserade krav.

Kontrolltriangeln: policyer, poster och driftrutiner

Clarysecs Zenith Controls: guiden för tvärgående regelefterlevnad ger kompassen för tvärgående regelefterlevnad inom detta område. För ISO/IEC 27002:2022 kontroll 5.1, Policyer för informationssäkerhet, identifierar Zenith Controls den som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, är anpassad till styrning och cybersäkerhetskonceptet identifiera, och är kopplad till operativa förmågor inom styrning och policyhantering.

Det är viktigt eftersom policystyrning inte bara är en efterlevnadsartefakt. Den är förebyggande. En tydligt ägd och kommunicerad åtkomstkontrollpolicy minskar risken för obehörig åtkomst innan incidenter inträffar. En korrekt godkänd leverantörspolicy förhindrar ohanterad outsourcingrisk. En kontrollerad incidentrutin förbättrar konsekvensen i responsen innan den första regulatoriska rapporteringsfristen börjar löpa.

Zenith Controls lyfter också fram ISO/IEC 27002:2022 kontroll 5.33, Skydd av register, som förebyggande och anpassad till juridik och regelefterlevnad, tillgångshantering och informationsskydd. Detta är centralt för revisionsbevis. Zenith Blueprint utvecklar samma koncept i fasen Controls in Action, steg 23:

”Poster är inte bara kvarlevor från tidigare beslut. De är underlag för efterlevnad, åtgärder och ansvarsskyldighet.”

Den fortsätter:

”Poster skyddas på lämpligt sätt mot förlust, obehörig åtkomst, manipulation och förtida förstöring”

ISO/IEC 27002:2022 kontroll 5.37, Dokumenterade driftrutiner, är också relevant. Zenith Controls klassificerar den som förebyggande och korrigerande, med stöd för skydd och återställning. För DORA och NIS2 är dokumenterade driftrutiner det som gör policy till repeterbar handling: incidenttriage, återställning från säkerhetskopior, leverantörsintroduktion, sårbarhetshantering, säker utveckling, ändringshantering, bevisinsamling och kriskommunikation.

Tillsammans skapar 5.1, 5.33 och 5.37 kontrolltriangeln för policyers livscykel:

Ett moget ISMS behöver alla tre. Policyer utan poster är deklarationer. Poster utan rutiner blir inkonsekventa. Rutiner utan policyinriktning blir lokala vanor snarare än styrda kontroller.

Tvärgående mappning för ISO 27001, NIS2, DORA, GDPR, NIST och COBIT

Att hantera policyer separat för ISO 27001, NIS2, DORA och GDPR skapar duplicering, motsägelser och underlagströtthet. En bättre modell är att underhålla ett enda kontrollerat ISMS-bibliotek med mappningsmetadata. Då kan en och samma underlagskorpus uppfylla flera försäkransintressenters behov.

NIST CSF 2.0 är särskilt användbart som kommunikationslager. Dess GOVERN Function förväntar sig att rättsliga, regulatoriska och avtalsmässiga skyldigheter förstås, att riskhanteringsmål och ansvar definieras, att policyer etableras och uppdateras samt att utfall utvärderas. Metoden Organizational Profile ger också en praktisk process: avgränsa profilen, samla in underlag såsom policyer, riskprioriteringar och krav, skapa nuläges- och målprofiler, analysera gap och genomföra en prioriterad åtgärdsplan.

Detta ligger nära Clarysecs arbetssätt: bygg en enda underlagsbaserad operativ modell och mappa den sedan utåt mot NIS2, DORA, GDPR, NIST och COBIT i stället för att underhålla separata efterlevnadssilor.

En veckas sprint för att bygga ett kontrollpaket för policyunderlag

En fullständig omställning av policystyrningen tar tid, men en fokuserad veckosprint kan synliggöra luckor och skapa en försvarbar grund.

Dag 1: Skapa dokumentregistret

Börja med ett kalkylblad, ett GRC-system eller en strukturerad SharePoint-lista. Dokumentregistret är indexet som hjälper revisorer att navigera i underlagskorpusen.

Komplicera inte i onödan. Om registret tillförlitligt visar ägare, godkännare, version, granskningsdatum, mappning och underlagets plats löser det redan många problem med att hitta revisionsunderlag.

Dag 2: Etablera dokumentarkivet

Följ strukturen i Zenith Blueprint steg 6: policyer och rutiner, riskbedömning och SoA, utbildnings- och medvetenhetsposter, revision och granskning, incidentregister, tillgångar och förteckningar samt kontrollbibliotek.

Tillämpa åtkomstregler. Policyer ska kunna läsas av alla anställda. Riskbedömningsposter bör begränsas till ISMS-teamet och ledningen. Incidentregister bör följa behovsprincipen. Leverantörsavtal bör begränsas till upphandling, juridik, ekonomi och säkerhet. Föråldrade dokument bör vara otillgängliga för daglig användning men bevaras för spårbarhet vid revision.

Dag 3: Standardisera sidhuvuden och ändringsloggar

Varje policy bör innehålla dokumentnamn, ägare, godkännare, version, ikraftträdandedatum, nästa granskningsdatum, klassificering, relaterade kontroller, relaterade rättsliga skyldigheter och ändringshistorik.

Detta stödjer styrning av dokumenterad information enligt ISO/IEC 27001:2022, ledningens tillsyn enligt NIS2, granskningsförväntningar enligt DORA och ansvarsskyldighet enligt GDPR.

Dag 4: Koppla undantag till policyer

Skapa ett undantagsregister med undantags-ID, berörd policy, berörd kontroll, verksamhetsmässig motivering, kompenserande kontroller, riskägare, godkännande, utgångsdatum och granskningsstatus.

Exempel: ett äldre system kan inte stödja MFA under 60 dagar. Undantaget kopplas till åtkomstkontrollpolicy, tillgångsförteckning, riskregister och avhjälpande plan. Riskägaren godkänner kvarstående risk, och undantaget löper ut automatiskt om det inte förnyas. Detta genomför Clarysecs SME-krav på styrning: att betydande beslut, undantag och eskaleringar ska registreras och vara spårbara.

Dag 5: Bygg revisionsunderlagspaketet

För varje policy på högsta nivå skapar du en undermapp för underlag som innehåller godkänd aktuell version, föregående version och ändringslogg, godkännandeunderlag, kommunikationsunderlag, utbildnings- eller bekräftelsepost, relaterad rutin, relaterad operativ post, undantag, senaste granskningspost, nästa granskningsdatum samt mappning till rättsliga skyldigheter och kontroller.

För incidentrespons bör du inkludera poster från skrivbordsövningar, kriterier för incidentklassificering, kontaktlistor, mallar för efterincidentgranskning och poster över beslut om rapportering. Detta stödjer beredskap för stegvis rapportering enligt NIS2 artikel 23, incidentklassificering enligt DORA och ansvarsskyldighet för incidenter enligt GDPR.

Dag 6: Testa åtkomst till underlag

Be en internrevisor eller regelefterlevnadschef att hämta underlag för tre frågor:

1. Visa att informationssäkerhetspolicyn har godkänts, kommunicerats och granskats.
2. Visa att skyldigheter avseende leverantörssäkerhet mappas till krav i DORA och NIS2.
3. Visa att underlag för ansvarsskyldighet enligt GDPR bevaras och skyddas.

Om det tar mer än 30 minuter per fråga att hitta underlaget behöver dokumentarkivet förbättras.

Dag 7: Presentera för ledningen

Sammanfatta status för policyers livscykel i ledningens genomgång:

• Policyer som är aktuella, försenade eller förfaller inom 90 dagar
• Öppna och utgångna undantag
• Underlagsluckor
• Uppdateringar av regulatorisk mappning
• Revisionsiakttagelser
• Korrigerande åtgärder
• Resursbehov

Detta sluter loopen med ledarskapsförväntningar i ISO/IEC 27001:2022, styrelsens ansvarsskyldighet enligt NIS2 och ledningsorganets tillsyn enligt DORA.

Hur revisorer granskar policyers livscykel

Olika revisorer betraktar samma underlag genom olika perspektiv.

En ISO/IEC 27001:2022-revisor börjar med styrning av dokumenterad information. Revisorn kontrollerar om nödvändiga dokument finns, om de godkänns före användning, om versioner styrs, om dokumenten är tillgängliga där de behövs, om konfidentiella poster skyddas och om föråldrade dokument förhindras från oavsiktlig användning. Revisorn kopplar policyernas livscykel till ledarskap, riskbehandling, operativ styrning, internrevision och ledningens genomgång.

En DORA-inriktad granskare har ett resiliensperspektiv. Granskaren undersöker om ramverket för IKT-riskhantering är väl dokumenterat, godkänt av ledningen, granskat minst årligen där det är tillämpligt, reviderat regelbundet, förbättrat utifrån erfarenhetsåterföring och kopplat till incidentrapportering, testning, tredjepartsrisker, kontinuitet och återställning.

En NIS2-tillsynsmyndighet vill se en obruten beviskedja från riskidentifiering till riskhanteringsåtgärder för cybersäkerhet, ledningsorganets godkännande, genomförande och övervakning. Varje brott i den kedjan kan framstå som bristande omsorgsplikt.

En GDPR-revisor eller integritetsgranskare frågar om poster för styrning av personuppgifter visar ansvarsskyldighet: behandlingsändamål, rättslig grund, bevarande, tekniska och organisatoriska åtgärder, biträdeskontroller, incidentregister och underlag för efterlevnad av policyn.

En COBIT 2019- eller ISACA-inriktad revisor fokuserar på styrningssystemets komponenter: processer, organisationsstrukturer, informationsflöden, policyer, roller, kultur, kompetens och tjänster. Revisorn frågar om ägarskap är definierat, om ledningen övervakar prestanda, om undantag eskaleras och om underlaget stödjer kontrolldrift och ledningens tillsyn.

Samma kontrollerade underlagsarkiv kan tillgodose dem alla, men bara om dokumenten är mappade, aktuella, skyddade och spårbara.

Vanliga livscykelbrister att åtgärda innan revisorn kommer

De flesta brister i policyers livscykel är grundläggande styrningssvagheter som upprepas i olika miljöer:

• Policyer finns men saknar namngiven ägare.
• Godkännare är otydliga, inaktuella eller för juniora i förhållande till risken.
• Policyer är godkända men inte kommunicerade.
• Granskningsdatum missas utan eskalering.
• Föråldrade versioner finns kvar i delade mappar.
• Rutiner strider mot policyer.
• Undantag godkänns informellt via e-post.
• Rättsliga skyldigheter mappas till ramverk men inte till faktiska kontroller eller ägare.
• Revisionsbevis är utspridda över personliga enheter, ärendehanteringsverktyg och chattmeddelanden.
• Bevarandetider är odefinierade eller tillämpas inkonsekvent.
• Poster bevaras men skyddas inte mot obehörig ändring.
• Leverantörspolicyer kopplas inte till avtalsregister, leverantörsgranskning eller exitplaner.
• Incidentrutiner är inte anpassade till beslutspunkter för rapportering enligt NIS2, DORA eller GDPR.

Dessa problem skapar friktion vid revision eftersom de undergräver förtroendet. Om en revisor inte kan lita på policykorpusen kommer revisorn att gå djupare in i kontrolldriften.

Marias åtgärdsplan var inte att skriva ännu en policy. Den var att skapa en enda källa till sanning. Hon utsåg ett officiellt ISMS-dokumentbibliotek, migrerade aktuella policyer dit, arkiverade okontrollerade platser, standardiserade fält för ägare och godkännare, byggde arbetsflöden för godkännande, mappade policyer till skyldigheter enligt NIS2 och DORA samt gav revisorerna skrivskyddad åtkomst till strukturerade underlag. Det som hade varit en källa till oro blev en demonstration av kontroll.

Clarysecs väg framåt

Livscykelstyrning av policyer är inte byråkratisk overhead. Det är den operativa disciplin som gör dokumenterad information enligt ISO 27001, ledningens ansvarsskyldighet enligt NIS2, IKT-riskstyrning enligt DORA och ansvarsskyldighet enligt GDPR försvarbara.

Använd Zenith Blueprint: en revisors 30-stegs färdplan för att bygga ISMS-biblioteket i rätt fas och ordning, särskilt steg 6 för dokumenterad information och steg 22 för policystyrning. Använd Clarysecs SME- och koncernpolicyer för att definiera krav på granskning, godkännande, versionshantering, kommunikation, spårbarhet, centralisering av underlag och bevarande. Använd Zenith Controls: guiden för tvärgående regelefterlevnad för att mappa ISO/IEC 27002:2022-kontroller såsom 5.1, 5.33 och 5.37 till förväntningar på tvärgående regelefterlevnad, kontrollattribut och revisionsperspektiv.

Innan du köper ännu ett verktyg eller skriver ännu en policy, besvara en fråga:

Kan du visa att varje viktig policy är ägd, godkänd, aktuell, kommunicerad, mappad, belagd med underlag, granskad, skyddad och korrekt avvecklad?

Om svaret ännu är nej kan Clarysec hjälpa dig att bygga det revisionsklara ISMS-bibliotek, arbetsflöde för policyers livscykel och mappning för tvärgående regelefterlevnad som revisorer, styrelser och kunder förväntar sig under 2026. Ladda ned Zenith Blueprint, utforska Clarysecs policypaket för SME och större organisationer, eller boka en beredskapsbedömning för att omvandla ditt policybibliotek till en försvarbar tillgång för regelefterlevnad.