Informationssäkerhetschefens due diligence-underlag: ISO 27001-underlag för 2026

Klockan är 08:17 en måndagsmorgon. Maria, informationssäkerhetschef hos en snabbväxande fintechleverantör av SaaS, öppnar ett e-postmeddelande från VD:n: ”Begäran från tillsynsmyndighet. Behöver underlag senast fredag som visar att vi eskalerade leverantörsrisken före avbrottet, att styrelsen förstod den kvarstående risken och att vårt beslut om incidentrapportering dokumenterades.”

Sex veckor tidigare drabbades en kritisk molnleverantör av regional degradering. Inga kundmedel gick förlorade. Ingen exfiltration av personuppgifter bekräftades. Men kunder förlorade åtkomst till kontrollpaneler under flera timmar, supportärenden ökade kraftigt, och en företagskund vill nu ha bevis för att bolaget följde NIS2, DORA och säkerhetskraven enligt GDPR Article 32.

Maria vet att teamet agerade ansvarsfullt. De varnade ledningen för koncentrationsrisk. De lyfte ett undantag när testningen av reservregionen för säkerhetskopiering försenades. De klassificerade händelsen, konsulterade juridik, uppdaterade kunder och öppnade korrigerande åtgärder. Men frågan 2026 är inte längre bara om säkerhetsfunktionen agerade ansvarsfullt.

Frågan är om informationssäkerhetschefen med tidsstämplat underlag kan visa att risker identifierades, kommunicerades, följdes upp, accepterades av rätt ägare och slutligen hanterades.

Det beviset är informationssäkerhetschefens due diligence-underlag.

För informationssäkerhetschefer, regelefterlevnadschefer, revisorer och verksamhetsägare är due diligence-underlaget inte en privat dokumentationssilo. Det är det operativa underlagslager som kopplar samman ISO/IEC 27001:2022, ledningens ansvarsskyldighet enligt NIS2, styrning och IKT-riskhantering enligt DORA samt säkerhet i behandlingen enligt GDPR Article 32 till en sammanhängande berättelse. Rätt utfört visar det att säkerhetsansvarig gav tydliga råd, att ledningen fattade informerade beslut och att organisationens kontroller inte bara deklarerades, utan användes, granskades och förbättrades.

Varför due diligence för informationssäkerhetschefen är viktigt 2026

Det regulatoriska landskapet har förskjutits från policyskrivningar till verifierbar ansvarsskyldighet. Allmänna försäkringar räcker inte längre. Tillsynsmyndigheter, styrelser, kunder och försäkringsgivare efterfrågar i allt högre grad underlag för styrning.

NIS2 lägger ett uttryckligt ansvar på ledningsorgan. Article 20 kräver att ledningsorgan hos väsentliga och viktiga entiteter godkänner åtgärder för cybersäkerhetsriskhantering, övervakar genomförandet av dem och genomför utbildning i cybersäkerhet. Article 21 förutsätter därefter lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, åtkomstkontroll, tillgångshantering och autentisering.

För berörda finansiella entiteter höjer DORA ribban ytterligare. Article 5 gör ledningsorganet ytterst ansvarigt för IKT-riskhantering. Article 6 kräver ett robust, heltäckande och väldokumenterat ramverk för IKT-riskhantering. DORA kräver även incidentklassificering och rapportering, testning av digital operativ resiliens, internrevision för företag som inte är mikroföretag, uppföljning av avhjälpande åtgärder och styrning av IKT-tredjepartsrisker. DORA gäller från den 17 januari 2025 och fungerar, för berörda finansiella entiteter, som den sektorsspecifika unionsrättsakten för överlappande skyldigheter enligt NIS2 avseende riskhantering och rapportering.

Den personliga oron för informationssäkerhetschefer är begriplig. Om ledningens ansvarsskyldighet, tillsynsmyndigheters granskning, kunders leverantörsgranskning och exponering i rättsprocesser sammanfaller efter ett avbrott eller en incident räcker inte enbart ett riskregister. Informationssäkerhetschefen behöver ett strukturerat underlag som visar professionellt omdöme, eskaleringar i tid, tydliga rekommendationer, avvikande uppfattningar vid behov, accepterade risker och kontrollsäkring.

Due diligence-underlaget är inte ett skugg-ISMS

Ett vanligt revisionsfel är att behandla informationssäkerhetschefens due diligence-underlag som ett privat arkiv skilt från ISMS. Det skapar två risker. För det första blir underlaget inkonsekvent. För det andra kan det se ut som att informationssäkerhetschefen kände till risker men inte integrerade dem i styrningen.

Clarysecs metod är annorlunda. Informationssäkerhetschefens due diligence-underlag är en kurerad vy över ISMS-underlag som är relevant för ledningens ansvarsskyldighet. Det ersätter inte riskregistret, Statement of Applicability, incidentregistret, leverantörsregistret, revisionsrapporter eller protokoll från ledningens genomgång. Det indexerar dem, länkar dem och gör dem försvarbara.

Zenith Blueprint: En revisors 30-stegs färdplan ger den praktiska grunden. I fasen för ISMS-grund och ledarskap betonar steg 4 att ISMS-ansvarig eller säkerhetsansvarig samordnar införande, revisioner och medvetenhet, och ”måste ha direkt tillgång till högsta ledningen för att eskalera frågor.” Det anger också att riskägare bör utses för större risker och att organisationen bör definiera vem som formellt godkänner beslut om riskbehandling.

Det är den första principen för due diligence för informationssäkerhetschefen: säkerhetsansvarig ger råd och eskalerar, men riskägarskap och riskacceptans ska vara uttryckliga.

I fasen Riskhantering gör steg 13 i Zenith Blueprint detta operativt:

Beslut om riskbehandling och SoA bör granskas och godkännas av högsta ledningen. Det görs ofta i ett möte eller åtminstone genom formellt godkännande. Säkerställ att ledningen informeras om:

✓ De viktigaste riskerna och föreslagna behandlingarna, ✓ Eventuella risker som du föreslår ska accepteras (de ska formellt acceptera dem), ✓ Listan över kontroller som du planerar att införa (SoA-höjdpunkter). Ledningens godkännande visar att organisationen är medveten om och åtar sig nödvändiga åtgärder (detta blir också dokumenterat revisionsbevis).

För en informationssäkerhetschef är den vägledningen inte bara förberedelse inför ISO-revision. Den är arkitekturen för due diligence. Om en hög risk accepteras, skjuts upp eller inte finansieras fullt ut ska underlaget visa risken, rekommendationen, verksamhetsbeslutet, godkännande roll, referens till riskaptit och granskningsdatum.

ISO 27001:2022 är motorn för underlag

ISO 27001 är mer än ett certifieringsmål. Det är en operativ modell för styrning, riskbehandling, säkerhet och ständig förbättring. Avsnitt 0.1 anger att ett ISMS är avsett att integreras i organisationens processer och övergripande ledningsstruktur. Den integreringen är det som gör löpande säkerhetsarbete till en tillförlitlig motor för att generera underlag.

De centrala avsnitten i ISO 27001:2022 som matar informationssäkerhetschefens due diligence-underlag är:

• Avsnitten 4.1 till 4.2, kontext och intressenter, som dokumenterar rättsliga, regulatoriska, avtalsmässiga och intressentrelaterade skyldigheter.
• Avsnitt 4.3, ISMS-omfattning, som definierar de tjänster, platser, system och gränser som omfattas.
• Avsnitt 5.1, ledarskap och åtagande, som kräver att högsta ledningen stödjer ISMS och säkerställer att det uppnår avsedda resultat.
• Avsnitt 5.3, organisatoriska roller, ansvar och befogenheter, som stödjer tydligt riskägarskap och tydliga eskaleringsvägar.
• Avsnitten 6.1.2 och 6.1.3, riskbedömning och riskbehandling inom informationssäkerhet, som kräver konsekventa riskkriterier, godkännande av riskägare, riskbehandlingsplaner, acceptans av kvarstående risk och Statement of Applicability.
• Avsnitt 8.1, operativ planering och styrning, som kräver att organisationen planerar, inför och styr de processer som behövs för att uppfylla ISMS-krav.
• Avsnitten 9.2 och 9.3, internrevision och ledningens genomgång, som genererar oberoende försäkran och underlag för ledningens tillsyn.
• Avsnitt 10.1, ständig förbättring, och avsnitt 10.2, avvikelse och korrigerande åtgärder, som visar uppföljning och genomförande.

Denna systematiska metod säkerställer att det underlag Marias VD behöver inte skapas i panik. Det finns redan, om ISMS har utformats för att producera och bevara beslutsdugliga poster.

Vad som ska ingå i ett due diligence-underlag för informationssäkerhetschefen

Ett bra due diligence-underlag besvarar sju frågor som en revisor, tillsynsmyndighet, styrelseledamot eller kund kan ställa efter en störning:

1. Vad visste informationssäkerhetschefen?
2. När fick personen veta det?
3. Vilket råd gavs?
4. Vem ägde risken?
5. Vad godkände, avslog, sköt upp eller accepterade ledningen?
6. Hur testades eller övervakades kontrollerna?
7. Vad ändrades efter incidenter, revisioner, leverantörsvarningar eller undantag?

Följande struktur fungerar för SaaS-leverantörer, fintechbolag, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, operatörer av digital infrastruktur och teknikleverantörer som stödjer reglerade kunder.

Detta underlag är särskilt viktigt för NIS2-sektorer som molntjänster, datacenter, innehållsleveransnätverk, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, leverantörer av publika kommunikationstjänster och vissa entiteter inom finansiell infrastruktur. NIS2-omfattningen beror på sektor, entitetstyp och storlek, och medlemsstaterna ska upprätta förteckningar över väsentliga och viktiga entiteter. Även organisationer utanför direkt tillämpningsområde kan möta vidareförda avtalskrav från kunder som omfattas.

För DORA bör underlaget skilja på om organisationen är den reglerade finansiella entiteten, en IKT-tredjepartstjänsteleverantör eller båda i olika relationer. Finansiella entiteter ska upprätthålla styrning, IKT-riskhantering, incidentrapportering, resiliensprovning och kontroller för tredjepartsrisk. IKT-leverantörer kommer i allt högre grad att ombes stödja underlag, revisionsrätt, incidentstöd, testning och exitplanering.

Clarysecs policyryggrad för försvarbara poster

Due diligence-underlaget står och faller med kvaliteten på posterna. Clarysecs policyer är skrivna för att göra detta revisionsspår till normal verksamhetspraxis, inte en nödåtgärd efter ett brev från en tillsynsmyndighet.

För små och medelstora företag anger [P02S] Policy för styrningsroller och ansvar – SME i avsnitt 5.5:

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

För större organisationer anger [P02] Policy för styrningsroller och ansvar i avsnitt 6.5:

Alla eskaleringar ska loggas och följas upp, med underlag för lösning eller formell acceptans.

Tillsammans definierar dessa avsnitt underlagsstandarden. En väsentlig sårbarhet, ett leverantörsberoende, en fördröjd kontroll eller ett återkommande undantag ska inte bara finnas i chattmeddelanden eller i minnet. Det ska registreras, tilldelas, följas upp och stängas genom lösning eller formell acceptans.

Riskacceptans kräver samma disciplin. [P06S] Riskhanteringspolicy – SME kräver i avsnitt 5.1.2:

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

Samma SME-policy anger dessutom i avsnitt 7.2.1:

Varje beslut att acceptera eller skjuta upp behandling av en hög eller medelhög risk ska dokumenteras i Riskregistret. Denna dokumentation ska innehålla:

För större organisationer anger [P06] Riskhanteringspolicy i avsnitt 6.3.4:

Risker som accepteras utan behandling ska motiveras skriftligen, kopplas till organisationens riskaptit och godkännas på lämplig nivå.

I ett NIS2- eller DORA-sammanhang är detta viktigt eftersom ledningsorgan förväntas godkänna, utöva tillsyn över och förstå beslut om cybersäkerhets- och IKT-risker. I ett GDPR Article 32-sammanhang hjälper det till att visa att säkerhetsåtgärder valdes, sköts upp eller justerades genom en dokumenterad riskbaserad process.

Incidentunderlag ska vara lika strukturerat. [P30S] Policy för incidenthantering – SME kräver:

Alla incidentutredningar, iakttagelser och korrigerande åtgärder ska registreras i ett incidentregister som upprätthålls av den verkställande chefen.

[P30] Policy för incidenthantering kräver:

Alla incidenter ska registreras i systemet för hantering av säkerhetsincidenter (SIMS), inklusive:

Dessa avsnitt stödjer stegvis rapportering enligt NIS2 och DORA-styrning av IKT-incidenter. NIS2 kräver tidig varning inom 24 timmar för betydande incidenter, anmälan inom 72 timmar och en slutrapport inom en månad efter incidentanmälan. DORA kräver formell IKT-incidenthantering, klassificering efter allvarlighetsgrad och påverkad tjänsts kritikalitet, eskalering till högsta ledningen, medvetenhet hos ledningsorganet, kundkommunikation där så krävs och stegvis rapportering för större IKT-relaterade incidenter.

Revisionsbevis behöver också integritet. [P33S] Policy för revision och övervakning av regelefterlevnad – SME anger:

Metadata (t.ex. vem som samlade in det, när och från vilket system) ska dokumenteras.

[P33] Policy för revision och övervakning av regelefterlevnad anger:

Alla revisionsaktiviteter ska dokumenteras och bevaras i ISMS-arkivet.

Slutligen ger [P01] Informationssäkerhetspolicy ledningsrapporteringen en praktisk hemvist. Avsnitt 4.2.4 anger:

Rapporterar ISMS-status, incidenter, revisionsresultat och mätetal till högsta ledningen.

Det avsnittet stödjer due diligence-principen att incidentstatus, mätetal, revisionsresultat och olösta risker ska nå högsta ledningen i en form som stödjer tillsyn.

Zenith Controls som kompass för korsvis efterlevnad

Clarysecs Zenith Controls: vägledning för korsvis efterlevnad hjälper informationssäkerhetschefer att koppla kontroller i ISO/IEC 27002:2022 till bredare efterlevnadsförväntningar. Det är inte ett separat kontrollramverk. Det är Clarysecs vägledning för korsvis efterlevnad för att förstå hur ISO/IEC 27001:2022 Bilaga A och ISO/IEC 27002:2022-kontroller stödjer andra skyldigheter, revisioner och förfrågningar om underlag.

För informationssäkerhetschefens due diligence-underlag är tre kontrollområden centrala.

ISO/IEC 27002:2022 kontroll 5.4, ledningens ansvar, är en förebyggande styrningskontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Zenith Controls placerar den i funktionen Identify, med styrning som operativ förmåga och styrning samt ekosystem som säkerhetsdomäner. Det praktiska budskapet är tydligt: ledningens ansvarsskyldighet är inte symbolisk. Den kräver tilldelade roller, resurser, policyledning, tillsyn och uppföljning.

Zenith Controls kopplar 5.4 direkt till 5.2 roller och ansvar för informationssäkerhet, 5.1 policyer för informationssäkerhet, 5.35 oberoende granskning av informationssäkerhet, 5.36 efterlevnad av policyer, regler och standarder för informationssäkerhet samt 5.8 informationssäkerhet i projektledning. Ett due diligence-underlag som innehåller eskaleringar men saknar underlag för rolltilldelning, policygodkännande, oberoende granskning eller projektintegrering kommer att framstå som ofullständigt.

Kontroll 5.35, oberoende granskning av informationssäkerhet, är också central. Zenith Controls beskriver den som förebyggande och korrigerande, kopplad till informationssäkerhetsområdet. Den kopplas till 5.36 övervakning av efterlevnad, 5.4 ledningens ansvar, 5.27 lärdomar från informationssäkerhetsincidenter, 5.33 skydd av poster samt tekniskt underlag som 8.15 loggning och 8.16 övervakningsaktiviteter. I due diligence-termer visar oberoende granskning att ledningen inte endast förlitade sig på självintygande från säkerhetsteamet.

Kontroll 5.36, efterlevnad av policyer, regler och standarder för informationssäkerhet, ger tillämpningslagret. Zenith Controls kopplar den till policyer, disciplinär process, oberoende granskning, roller, händelsebedömning, loggning, övervakning, skydd av poster och kontakt med särskilda intressegrupper. För en informationssäkerhetschef betyder det att underlaget inte bara ska visa att en policy finns. Det ska visa övervakning av efterlevnad, rapportering av bristande efterlevnad och korrigerande åtgärder.

Korsvis efterlevnadsmappning: ett underlag, flera perspektiv

Det mest effektiva due diligence-underlaget mappar samma underlag till flera skyldigheter. Detta undviker dubbla efterlevnadsprogram och minskar risken för motsägelsefulla narrativ.

NIST CSF 2.0 är användbart eftersom det ger ett gemensamt språk för styrning, risker i leveranskedjan, operativ resiliens, incidenthantering och återhämtning. Funktionen GOVERN omfattar organisationens kontext, rättsliga och regulatoriska skyldigheter, riskaptit, roller, policy och tillsyn. Metoden CSF Profiles stödjer nulägesbedömning, definition av målläge, gapanalys och prioriterad åtgärdsplanering. Detta ligger naturligt i linje med Clarysecs due diligence-metod: avgränsa underlaget, samla in underlag, mappa skyldigheter, identifiera luckor, genomför åtgärder och uppdatera kontinuerligt.

Ett praktiskt paket för riskeskalering

Tänk dig en SaaS-leverantör vars autentiseringstjänst är beroende av en enda molnbaserad identitetsleverantör. Informationssäkerhetschefen identifierar en risk med hög påverkan på tillgänglighet och åtkomstkontroll: om identitetsleverantören drabbas av ett större avbrott kan kunder inte logga in, arbetsflöden för privilegierad åtkomst kan försenas och incidenthantering kan försämras.

Ett försvarbart paket för riskeskalering bör innehålla fem delar.

För det första, skapa riskposten. Använd kravet i Riskhanteringspolicy – SME att varje riskpost ska innehålla beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan. Posten bör identifiera berörda tillgångar och tjänster, inklusive kundportal, administrativ konsol, supportverktyg och process för nödtillträde. Den bör dokumentera CIA-konsekvens, sannolikhet, konsekvens, riskpoäng, riskägare, föreslagen behandling, kvarstående risk, måldatum och budget.

För det andra, koppla behandlingen till Statement of Applicability. Relevanta kontroller kan omfatta leverantörssäkerhet, hantering av molntjänster, identitets- och åtkomsthantering, privilegierad åtkomst, övervakning, incidentplanering, beredskap för verksamhetskontinuitet, säkerhetskopiering och loggning. Detta följer Zenith Blueprint steg 13, där beslut om riskbehandling och SoA granskas och godkänns av högsta ledningen.

För det tredje, ta fram informationssäkerhetschefens rådgivande PM. PM:et bör besvara vad som kan gå fel, vilka reglerade tjänster eller kundåtaganden som kan påverkas, vilka konsekvenserna enligt NIS2, DORA och GDPR är, vilken behandling som rekommenderas, vad kostnaden och tidsplanen är samt vilken kvarstående risk som finns om ledningen skjuter upp åtgärden.

För det fjärde, registrera ledningens beslut. Om ledningen godkänner behandlingen ska det signerade beslutet, budgetgodkännandet och genomförandeplanen bevaras. Om ledningen skjuter upp åtgärden kräver organisationens Riskhanteringspolicy skriftlig motivering kopplad till riskaptit och godkännande på lämplig nivå. Underlaget ska visa informationssäkerhetschefens rekommendation och ledningens beslut som separata artefakter.

För det femte, lägg till underlag för kontrollsäkring. Inkludera testresultat för break-glass-konton, plan för leverantörens incidentkommunikation, avtalsgranskning, SLA-underlag, tester av övervakningslarm, anteckningar från skrivbordsövning, korrigerande åtgärder och revisionsiakttagelser från internrevision. I Zenith Blueprint steg 23 rekommenderar Clarysec att incidenthanteringsförmågan valideras genom att välja en nyligen inträffad händelse eller genomföra en skrivbordsövning, fånga och logga beslut, roller och kommunikation, uppdatera planen med erfarenhetsåterföring och bekräfta rutiner för bevarande av forensisk bevisning. Det är exakt det underlag som filen ska bevara.

Incidentbeslut: att visa varför ett rapporteringsval gjordes

Efter en cyberhändelse är den mest omstridda frågan ofta inte den tekniska tidslinjen. Det är rapporteringsbeslutet.

Var den betydande enligt NIS2? Var den större enligt DORA? Var den en personuppgiftsincident enligt GDPR? Underrättades kunder eller mottagare? Vem beslutade? Baserat på vilka fakta?

Informationssäkerhetschefens due diligence-underlag bör innehålla en post över incidentbeslut för varje väsentlig händelse, även om slutbeslutet är ”inte rapporteringspliktig.” Den posten bör innehålla:

• Datum och tidpunkt för kännedom.
• Sammanfattning av händelsen och berörda system.
• Initial allvarlighetsgrad och verksamhetspåverkan.
• Känd eller misstänkt skadlig orsak.
• Indikatorer på gränsöverskridande påverkan.
• Bedömning av personuppgifter.
• Påverkan på kund eller tjänstemottagare.
• Analys av kriterier för större incident enligt DORA, om tillämpligt.
• Analys av kriterier för betydande incident enligt NIS2, om tillämpligt.
• Deltagare från juridik, DPO, regelefterlevnad och ledning.
• Beslut, motivering och godkännande.
• Uppföljningsutlösare om fakta ändras.

NIS2 definierar betydande incidenter utifrån allvarlig driftstörning, ekonomisk förlust eller avsevärd materiell eller immateriell skada för andra personer. DORA kräver att finansiella entiteter registrerar IKT-relaterade incidenter och betydande cyberhot, klassificerar incidenter med kriterier som berörda kunder, avbrottstid, geografisk spridning, dataförlust, kritikalitet och ekonomisk påverkan samt eskalerar större incidenter till högsta ledningen samtidigt som ledningsorganet informeras.

Due diligence-underlaget bör bevara både de fakta som var kända vid beslutstidpunkten och motiveringen för åtgärd eller utebliven rapportering. Om fakta senare ändras ska underlaget visa den förnyade bedömningen.

Leverantörsvarningar är där noggrannheten prövas

Underlag för leveranskedjan blir en av de viktigaste delarna av informationssäkerhetschefens fil. NIS2 Article 21 kräver säkerhet i leveranskedjan och förväntar sig att organisationer beaktar leverantörsspecifika sårbarheter, produktkvalitet, cybersäkerhetspraxis och rutiner för säker utveckling. Skälen i direktivet uppmuntrar till åtgärder för cybersäkerhetsriskhantering i avtal med direkta leverantörer och tjänsteleverantörer.

DORA är mer föreskrivande för finansiella entiteter. IKT-tredjepartsrisk ska ingå i IKT-riskramverket. Organisationer ska upprätthålla ett register över avtalsarrangemang, genomföra leverantörsgranskning före avtal, bedöma koncentrationsrisk, beakta underleverantörskedjor och beroenden till tredjeländer, inkludera revisionsrätt och åtkomsträttigheter, definiera incidentstöd, testa exitstrategier och upprätthålla rätt att säga upp avtalet.

För informationssäkerhetschefen ska leverantörsvarningar dokumenteras innan leverantören fallerar. Underlaget bör innehålla:

• Förteckning över kritiska leverantörer och tjänstekartläggning.
• Leverantörsriskklassning och motivering.
• Säkerhetsfrågeformulär och granskning av underlag.
• Gapanalys av avtal som omfattar revisionsrätt, incidentavisering, dataplats, underleverantörer och exit.
• Bedömning av koncentrationsrisk.
• Kända sårbarheter eller offentliga säkerhetsmeddelanden som berör leverantören.
• Informationssäkerhetschefens rekommendationer till juridik, upphandling och ledning.
• Accepterade luckor och kompenserande kontroller.
• Testunderlag för exitstrategi avseende kritiska leverantörer.

Detta ligger nära NIST CSF 2.0 GV.SC, som omfattar strategi för riskhantering i leveranskedjan, leverantörsroller, prioritering efter kritikalitet, avtalskrav, leverantörsgranskning, löpande övervakning, incidentplanering och aktiviteter vid relationens avslut.

Hur revisorer och tillsynsmyndigheter läser underlaget

Olika granskare närmar sig samma underlag från olika perspektiv. Ett starkt due diligence-underlag förutser dessa perspektiv.

En ISO 27001-revisor kommer att vara särskilt uppmärksam på dokumenterad information som stödjer riskbedömnings- och riskbehandlingsprocessen. Avsnitten 6.1.2 och 6.1.3 kräver kriterier för riskacceptans, konsekventa bedömningar, riskägare, risknivåer, prioritering, riskbehandlingsplaner, SoA-jämförelse och acceptans av kvarstående risk. Avsnitten 8.1 till 8.3 kräver operativ styrning, planerad förnyad riskbedömning eller förnyad bedömning efter betydande förändringar samt bevarande av resultat.

En NIS2-myndighet eller kundgranskare kommer att titta på ledningens ansvarsskyldighet och proportionalitet. De kommer att fråga om åtgärderna var lämpliga med hänsyn till riskexponering, storlek, sannolikhet, allvarlighetsgrad, samhällelig eller ekonomisk påverkan, teknikens ståndpunkt och tillämpliga standarder.

En DORA-fokuserad granskare kommer att leta efter styrningsspårbarhet. Fastställde ledningsorganet IKT-risktolerans? Godkände det kontinuitets- och responsplaner? Eskalerades större incidenter? Var resiliensprovningen riskbaserad och åtgärdades resultaten? Hanterades IKT-tredjepartsavtal och koncentrationsrisker?

En GDPR-myndighet kommer att fokusera på ansvarsskyldighet och säkerhet i behandlingen. Den kommer att fråga om personuppgifter klassificerades, om behandlingsroller var förstådda, om lämpliga tekniska och organisatoriska åtgärder infördes och om incidentbeslut var evidensbaserade.

Mätetal som skyddar organisationen och informationssäkerhetschefen

Mätetal är inte dekoration. I ett due diligence-underlag visar de om informationssäkerhetschefen gav ledningen tillräcklig insyn för att agera.

Användbara mätetal är bland annat:

• Höga och medelhöga risker som accepterats, är försenade eller saknar ägare.
• Kritiska sårbarheter utanför SLA.
• Undantag per ålder, affärsenhet och godkännande roll.
• Leverantörsrisker per kritikalitet och olösta avtalsluckor.
• Genomsnittlig tid för incidenter till detektering, respons och återhämtning.
• Bedömningar av rapporteringsplikt som slutförts inom föreskrivna beslutsfönster.
• Framgångsgrad för tester av säkerhetskopiering och återställning.
• Slutförandegrad för åtkomstgranskning och undantag för privilegierad åtkomst.
• Revisionsiakttagelser från internrevision per allvarlighetsgrad och försenade korrigerande åtgärder.
• Slutförd säkerhetsmedvetenhetsutbildning för ledning och personal.

Dessa mätetal stödjer ledningsrapportering enligt ISO 27001, utbildning och tillsyn enligt NIS2, IKT-riskrapportering enligt DORA och ansvarsskyldighet enligt GDPR. De skyddar också informationssäkerhetschefen genom att visa om resursbegränsningar, olösta undantag eller återkommande kontrollbrister var synliga för ledningen.

Due diligence-underlaget bör bevara månatliga eller kvartalsvisa ögonblicksbilder. Skriv inte över gamla kontrollpaneler utan att bevara underlag. Om ledningen såg ett rött mätetal och sköt upp behandlingen hör det beslutet hemma i underlaget.

Från revisionsklart verktygspaket till underlag redo för informationssäkerhetschefen

I fasen Revision, granskning och förbättring rekommenderar steg 30 i Zenith Blueprint att ett revisionsklart verktygspaket sammanställs:

Samla alla centrala ISMS-dokument och poster i ett enda arkiv eller en enda mapp. Det gör det enkelt att under certifieringsrevisionen snabbt hämta det som revisorn begär.

Checklistan omfattar ISMS-omfattningsbeskrivning, policyer, riskbedömningsrapport, riskregister, riskbehandlingsplan, Statement of Applicability, tillgångsförteckning, utbildningsregister, operativa underlag som incidentloggar och åtkomstbegäran, internrevisionsrapporter, protokoll från ledningens genomgång, korrigerande åtgärder och register över krav på regelefterlevnad.

Informationssäkerhetschefens due diligence-underlag är ett specialiserat lager i detta verktygspaket. Det ska inte duplicera allt. Det ska indexera det underlag som är mest relevant för professionellt omdöme och ledningens ansvarsskyldighet.

En praktisk mappstruktur är:

• 00 Läs mig och underlagsindex.
• 01 Roll, befogenhet och rapporteringslinje.
• 02 Krav på regelefterlevnad och omfattning.
• 03 Ledningsrapporter och rådgivning.
• 04 Riskacceptanser och undantag.
• 05 Incidentbeslut och kommunikation.
• 06 Leverantörsvarningar och avtalsrisker.
• 07 Kontrollsäkring och oberoende granskningar.
• 08 Mätetal och olösta frågor.
• 09 Ledningens genomgång och CAPA-uppföljning.
• 10 Juridiskt bevarande, bevisintegritet och metadata.

Varje post bör ha ägare, datum, källsystem, relaterad risk-ID, relaterad kontroll, beslutsstatus och krav på bevarande. Detta genomför Clarysecs underlagsprincip från Policy för revision och övervakning av regelefterlevnad – SME: metadata spelar roll.

Börja före nästa incident

Ett due diligence-underlag för informationssäkerhetschefen är mest värdefullt när det finns före avbrottet, incidenten, revisionen eller brevet från tillsynsmyndigheten. Börja med tre åtgärder den här veckan.

För det första, skapa ett due diligence-index för informationssäkerhetschefens underlag och mappa det mot ert ISO 27001-riskregister, SoA, incidentregister, leverantörsregister och paket för ledningens genomgång.

För det andra, granska era tre senaste höga eller medelhöga risker. Bekräfta att var och en har en ägare, riskbehandlingsplan, beslut om kvarstående risk, referens till riskaptit och underlag för godkännande. Om inte, öppna styrningsposten igen.

För det tredje, genomför en 90-minuters skrivbordsövning kring ett leverantörsavbrott eller en misstänkt personuppgiftsincident. Använd Zenith Blueprint steg 23 för att fånga beslut, roller, kommunikation och erfarenhetsåterföring, och arkivera därefter underlaget i avsnittet för incidentbeslut.

Clarysec kan hjälpa er att operationalisera detta snabbt. Vår 30-stegs metod för införande, policysvit och mappning för korsvis efterlevnad i Zenith Controls ger er en försvarbar, revisionsklar struktur för ISO 27001-underlag, ledningens ansvarsskyldighet enligt NIS2, styrning enligt DORA och ansvarsskyldighet för säkerhet enligt GDPR Article 32.

För att bygga informationssäkerhetschefens due diligence-underlag med trygghet, börja med Zenith Blueprint, anpassa era styrnings- och riskposter till Clarysecs policyer och använd Zenith Controls som er kompass för korsvis efterlevnad.