Kontrollsjälvutvärdering för ISO 27001-underlag

Revisionsproblemet 2026 är inte avsaknad av kontroller, utan svagt underlag
Videosamtalet började 09:10 en måndagsmorgon. Sarah, CISO på ett snabbväxande FinTech SaaS-bolag, såg tre stressade ansikten på skärmen: GRC-chefen, dataskyddsombudet och chefen för IT-drift.
Företaget stod inför en uppföljande revision enligt ISO/IEC 27001:2022. Styrelsen ville ha en genomgång av beredskapen för NIS2 senast fredag. En kund inom finansiella tjänster hade lagt till DORA-liknande frågor om IKT-leverantörer i en avtalsförnyelse. Dataskyddsombudet förberedde underlag för att visa ansvarsskyldighet enligt GDPR.
På papperet såg organisationen mogen ut. Det fanns ett riskregister, en tillämplighetsförklaring (SoA), rutiner för åtkomstkontroll, åtgärdsplaner för incidenthantering, policyer för säkerhetskopiering, formulär för leverantörsgranskning och register över genomförda utbildningar.
Sedan började granskningen av underlaget.
Kalkylbladet för åtkomstgranskning saknade namngiven granskare. En rapport från sårbarhetsskanning var aktuell, men ingen kunde visa om kritiska iakttagelser hade åtgärdats, accepterats eller fortfarande var öppna. Leverantörsgranskning fanns, men den var äldre än en större ändring i molnarkitekturen. Skärmdumpar från säkerhetskopieringstester låg begravda i en chattråd. Anteckningar från en skrivbordsövning för incidenter var användbara, men inte hänförbara. Ingenjörer vidarebefordrade skärmdumpar av konfiguration utan sammanhang. Kontrollägare markerade kvartalsvisa kontroller som ”klara”, men underlaget var inkonsekvent och svårt att återanvända.
Sarah visste att problemet inte var avsaknad av kontroller. Det var avsaknad av försvarbart och repeterbart underlag.
Det är 2026 års gap inom kontrollsjälvutvärdering.
Organisationer har dokumenterade kontroller, kontrollpaneler och ibland verktyg för kontinuerlig övervakning. Men de kan ofta inte visa att kontrollägare testar kontroller konsekvent, att underlaget är fullständigt och aktuellt, och att undantag leder vidare till korrigerande åtgärder, ledningens genomgång och regulatorisk rapportering.
Kontrollsjälvutvärdering, eller CSA, löser detta operativa gap. Rätt genomförd skapar CSA ett disciplinerat arbetsflöde där kontrollägare regelbundet testar kontrollernas utformning och operativa effektivitet, bifogar underlag som uppfyller kriterier för revisionskvalitet, registrerar undantag, tilldelar korrigerande åtgärder och ger ledningen en tillförlitlig bild av kontrollernas hälsoläge.
På Clarysec behandlas CSA som bryggan mellan ISMS, rättsliga skyldigheter och revisionsunderlag. Zenith Blueprint: en revisors 30-stegsfärdplan placerar denna disciplin i fasen revision, granskning och förbättring. Steg 26, genomförande av revision, anger att insamling av underlag ska omfatta intervjuer, dokumentationsgranskning, observation, urval och stickprovskontroller:
✓ Intervjua relevant personal: Be personer som ansvarar för processer att förklara hur de uppfyller kraven.
✓ Granska dokumentation: Kontrollera att dokument och poster finns och är aktuella.
✓ Observera arbetssätt: Gör om möjligt en direkt observation.
✓ Gör urval och stickprovskontroller: Du kan inte kontrollera allt, så använd urval.
Detta arbetssätt ska inte vänta till den formella internrevisionen. CSA flyttar arbetet uppströms, till kontrollägarna, så att organisationen varje månad eller kvartal kan visa att kontrollerna inte bara är dokumenterade utan också fungerar.
Varför manuella kontrollsjälvutvärderingar fallerar under NIS2, DORA och GDPR
Den gamla modellen med kalkylblad och e-post för kontrollsjälvutvärdering är trasig eftersom den belönar slutförande i stället för underlagets kvalitet.
En kontrollägare laddar upp en skärmdump. En annan skriver ”bekräftat enligt policy”. En tredje bifogar en loggexport utan förklaring av systemet, perioden, granskaren eller slutsatsen. GRC-teamet lägger dagar på att återskapa berättelsen för revisorer, kunder och tillsynsmyndigheter.
Detta skapar fyra återkommande brister:
- Inkonsekvent underlag, där varje ägare har en egen uppfattning om vad som är giltigt revisionsbevis.
- Svag hänförbarhet, där filer inte visar vem som samlade in underlaget, när och från vilken källa.
- Formella avbockningar utan testning, där överbelastade team intygar att en kontroll fungerar utan att testa den.
- Ingen återanvändbarhet, där underlag som samlats in för ISO/IEC 27001:2022 inte enkelt kan stödja NIS2, DORA eller GDPR utan manuell omtolkning.
Modern reglering är oförlåtande mot den modellen.
NIS2 Article 20 gör cybersäkerhetsriskhantering till ett ansvar för ledningsorganet. Ledningen ska godkänna åtgärder, övervaka införandet och genomgå utbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, driftskontinuitet, säkerhet i leveranskedjan, sårbarhetshantering, effektivitetsbedömning, cyberhygien, åtkomstkontroll, policy för tillgångshantering och autentisering.
Uttrycket ”effektivitetsbedömning” är där CSA blir avgörande. En NIS2-entitet kan inte trovärdigt säga till ledningen att cybersäkerhetsåtgärder är effektiva om kontrollägare inte testar dem och dokumenterar resultaten.
DORA har höjt ribban för finansiella entiteter sedan den 17 januari 2025. Förordningen skapar ett regelverk för digital operativ motståndskraft som omfattar IKT-riskhantering, incidentrapportering, resiliensprovning, informationsdelning och IKT-tredjepartsrisk. DORA Article 5 kräver ansvar hos ledningsorganet för IKT-riskarrangemang, policyer, roller, strategi, kontinuitetsplaner, revisionsplaner, tredjepartspolicyer och korrigerande åtgärder. Article 6 kräver ett dokumenterat ramverk för IKT-riskhantering, regelbunden granskning, internrevision för icke-mikroföretag och åtgärdande av kritiska IKT-revisionsiakttagelser. Articles 24 till 26 gör resiliensprovning till ett återkommande valideringsprogram, inklusive lämpligt oberoende och, för vissa entiteter, hotbildsstyrd penetrationstestning.
CSA ersätter inte DORA-testning. Det är kontrollägarlagret som gör DORA-testning hållbar.
GDPR lägger till ett närliggande tryck på ansvarsskyldighet. Article 5(2) kräver att personuppgiftsansvariga kan visa efterlevnad av dataskyddsprinciperna. Article 32 kräver lämplig säkerhet i behandlingen, inklusive konfidentialitet, riktighet, tillgänglighet, resiliens, återställning samt regelbunden testning eller utvärdering där det är lämpligt. För ett dataskyddsombud är CSA-underlag ett praktiskt sätt att visa att åtkomstgranskningar, kryptering, loggning, databevarande, leverantörstillsyn och incidenthantering faktiskt fungerar kring personuppgifter.
Clarysecs CSA-modell, från policy till bevis
Ett försvarbart CSA-program börjar med tre frågor:
- Är kontrollen korrekt utformad för risken och skyldigheten?
- Fungerade kontrollen under bedömningsperioden?
- Är underlaget fullständigt, aktuellt, hänförbart och återanvändbart?
Clarysec förankrar denna modell i policyer, revisionsarbetsflöde och kontrollmappning.
Informationssäkerhetspolicy anger förväntan i klausul 6.6.1:
Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade rutiner och bevarat underlag som visar att de fungerar.
Klausul 6.6.2 tillägger:
Kontrollägare ska upprätthålla testresultat, loggar och granskningsprotokoll som stöd för periodiska revisioner.
Det gör kontroller från statiska formuleringar till aktiva, mätbara processer.
Policy för revision och regelefterlevnadsövervakning – små och medelstora företag etablerar granskningsdisciplinen:
Denna policy fastställer organisationens arbetssätt för att genomföra internrevision, granskningar av säkerhetskontroller och övervakning av efterlevnad. Den säkerställer att alla kontroller, policyer, system och tjänsteleverantörer omfattas av regelbunden och strukturerad granskning.
Klausul 5.2.3 kräver struktur:
Varje revision ska omfatta en definierad omfattning, mål, ansvarig personal och nödvändigt underlag.
För CSA gäller samma logik på kontrollägarnivå. Varje självutvärdering ska ha omfattning, mål, ansvarig person, period, underlag och slutsats.
Zenith Controls: guiden för korsvis regelefterlevnad ger därefter mappningsperspektivet. För CSA omfattar de viktigaste kontrollreferenserna i ISO/IEC 27001:2022 Annex A 5.2, roller och ansvar för informationssäkerhet, 5.35, oberoende granskning av informationssäkerhet, och 5.36, efterlevnad av policyer, regler och standarder för informationssäkerhet.
Tillsammans berättar dessa kontroller CSA-historien. Någon måste äga kontrollen. Organisationen måste kontrollera om policyer och standarder följs. Oberoende granskning måste utmana systemet. CSA ligger mellan ägarskap och oberoende granskning. Det är inte internrevision, men det förbereder underlaget som gör internrevision snabbare och mer tillförlitlig.
Test av utformning jämfört med test av operativ effektivitet
Ett vanligt CSA-misstag är att fråga kontrollägare: ”Fungerar den här kontrollen?” utan att definiera vad ”fungerar” betyder.
Varje trovärdig bedömning ska skilja mellan test av utformning och test av operativ effektivitet.
Ett test av utformning frågar om kontrollen, om den utförs enligt beskrivningen, skulle hantera risken eller kravet. För en åtkomstgranskning kontrollerar utformningstestet om rutinen definierar omfattning, granskarroll, frekvens, system som omfattas, undantagshantering, bevarande av underlag och eskalering.
Ett test av operativ effektivitet frågar om kontrollen faktiskt fungerade under perioden. För samma åtkomstgranskning kontrollerar det operativa testet om granskningen genomfördes, vem som utförde den, om alla system inom omfattningen ingick, om undantag löstes och om poster visar att granskningen slutfördes.
Båda testerna är viktiga. En välskriven policy för säkerhetskopiering är svag om inga återställningstester genomförts. En sårbarhetsskanning som körs varje vecka är ofullständig om kritiska iakttagelser inte leder till åtgärdande eller formell riskacceptans. En leverantörsgranskning som genomfördes en gång är inte längre tillförlitlig om leverantören nu stödjer en kritisk process och har bytt underleverantörer.
| CSA-fråga | Test av utformning | Test av operativ effektivitet | Exempel på underlag |
|---|---|---|---|
| Åtkomstgranskning | Rutinen definierar omfattning, frekvens, granskare, godkännande och regler för undantag | Granskningar i urvalet genomfördes i tid och undantag löstes | Granskningsprotokoll, exporterade användarlistor, godkännandeloggar, poster om stängda ärenden |
| Hantering av sårbarheter | Policyn definierar skanningsomfattning, regler för allvarlighetsgrad, SLA:er och process för riskacceptans | Skanningar kördes, iakttagelser triagerades och korrigeringar eller riskacceptanser dokumenterades | Skanningsrapporter, ärenden, ändringsposter, godkännanden av riskacceptans |
| Säkerhetskopiering och återställning | Standard för säkerhetskopiering definierar system, frekvens, bevarande och testning av återställning | Säkerhetskopior slutfördes och återställningstester lyckades för system i urvalet | Loggar för säkerhetskopieringsjobb, rapporter från återställningstester, ärenden för åtgärdande av fel |
| Leverantörssäkerhet | Processen för leverantörsgranskning och övervakning omfattar kritikalitet och avtalsmässiga skyddsåtgärder | Kritiska leverantörer bedömdes, granskades och övervakades under perioden | Leverantörsregister, formulär för leverantörsgranskning, avtalsklausuler, SLA-rapporter |
| Incidenthantering | Åtgärdsplan definierar klassificering, eskalering, rapportering och hantering av bevisning | Incidenter eller övningar följde processen och erfarenheter följdes upp | Incidentregister, tidslinje, kommunikation, rotorsaksanalys (RCA), CAPA-poster |
| Oberoende granskning | Internrevisionsprogrammet definierar omfattning, kompetens, opartiskhet och rapportering | Granskningar genomfördes, iakttagelser rapporterades och korrigerande åtgärder följdes upp | Internrevisionsplan, revisionsrapport, mötesprotokoll från ledningens genomgång, CAPA-logg |
Denna åtskillnad stödjer direkt ISO/IEC 27001:2022 klausuler 8.1 om operativ planering och styrning, 9.1 om övervakning, mätning, analys och utvärdering, 9.2 om internrevision, 9.3 om ledningens genomgång och 10.2 om avvikelse och korrigerande åtgärder.
Kvalitetskriterier för revisionsunderlag 2026
Underlag är inte revisionsbart bara för att det finns. Underlag måste vara användbart.
För CSA bör underlag bedömas mot sju kriterier.
| Kriterium för underlag | Vad det innebär | Typiskt fel |
|---|---|---|
| Fullständigt | Täcker hela kontrollens omfattning och bedömningsperiod | Skärmdumpen visar ett system, men kontrollen omfattar fem system |
| Aktuellt | Speglar den period som bedöms | Leverantörsgranskningen är två år gammal |
| Hänförbart | Visar vem som utförde, godkände eller samlade in det | Kalkylbladet saknar ägare eller tidsstämpel |
| Autentiskt | Kommer från ett tillförlitligt källsystem eller ett kontrollerat dokumentarkiv | Manuellt redigerad skärmdump utan källa |
| Relevant | Bevisar kontrollmålet direkt | Utbildningsmaterial finns, men närvaro saknas |
| Bevarat | Lagras enligt krav på bevarande och åtkomst | Underlag lagras i personliga inkorgar |
| Återanvändbart | Mappas till flera skyldigheter utan omtolkning | Åtkomstunderlag måste byggas om separat för ISO, GDPR och DORA |
SME-policyn förstärker metadatadisciplinen:
Metadata (t.ex. vem som samlade in det, när och från vilket system) ska dokumenteras.
För utredningar och digital bevisning med högre integritetskrav är Policy för bevisinsamling och forensik – små och medelstora företag mer precis:
Varje digitalt bevis ska loggas med:
5.2.1.1. Insamlarens namn
5.2.1.2. Källsystem/-enhet
5.2.1.3. Tidsstämpel för insamling
5.2.1.4. Lagringsplats
5.2.1.5. Åtkomsthistorik (vem som visade eller kopierade det)
En rutinmässig CSA-post behöver inte alltid behandlas enligt forensisk beviskedja. Men varje underlagspost ska vara tillräckligt spårbar för att en revisor ska kunna förstå vem som tog fram den, när, varifrån och varför den bevisar kontrollen.
Policy för rättslig och regulatorisk efterlevnad lägger till kravet på korsvis regelefterlevnad genom att efterfråga:
Nödvändiga artefakter eller poster för att visa efterlevnad (t.ex. revisionsloggar, krypteringsinställningar, samtyckesdokumentation)
Det är nyckeln till återanvändbart underlag. En export av krypteringskonfiguration kan stödja ISO/IEC 27001:2022 riskbehandling, NIS2 Article 21 säkerhetsåtgärder, DORA-skydd av IKT-tillgångar och GDPR Article 32 säkerhet i behandlingen, om posten är fullständig, hänförbar och mappad.
| Dåligt underlag | Bra underlag |
|---|---|
| En fil med namnet audit_report.pdf i en delad mapp | En GRC-post som länkar till Internal_Audit_Report_H1_2026.pdf med insamlare, datum, källa, period, ägare och kontrollmappning |
| Ett e-postmeddelande som säger att ledningen såg rapporten | Mötesprotokoll från ledningens genomgång som visar internrevisionsresultat som indata enligt ISO/IEC 27001:2022 klausul 9.3 |
| En skärmdump av ärenden | CAPA-export som visar avvikelse, rotorsak, korrigerande åtgärd, ägare, måldatum, status och verifieringsmetod |
| En PDF från sårbarhetsskanning | Skanningsrapport kopplad till berörda tillgångar, regler för allvarlighetsgrad, åtgärdsärenden, riskacceptanser och stängningsunderlag |
| Ett leverantörsfrågeformulär | Leverantörspost kopplad till kritikalitet, avtalsklausuler, övervakningsresultat, underleverantörsstatus och granskningsdatum |
Ett praktiskt CSA-arbetsflöde med Clarysecs verktygslåda
En kontrollägare ska kunna genomföra en meningsfull CSA-session på ett strukturerat och repeterbart sätt. Arbetsflödet nedan kan tillämpas på privilegierad åtkomst, återställning från säkerhetskopior, leverantörsövervakning, incidentberedskap, hantering av sårbarheter eller oberoende granskning.
Steg 1, välj kontroll och mappning mot skyldigheter
Börja med tillämplighetsförklaringen (SoA), riskbehandlingsplanen och registret över rättsliga skyldigheter. Välj en kontroll, till exempel granskning av privilegierad åtkomst till produktionssystem.
Mappa den till relevanta ISO/IEC 27001:2022 Annex A-kontroller, såsom 5.15 åtkomstkontroll, 5.16 identitetshantering och 5.18 åtkomsträttigheter. I Zenith Controls kopplas den till 5.2 för roller och ansvar samt 5.36 för efterlevnad av policyer, regler och standarder, eftersom granskningen visar att åtkomstpolicyn följs.
Om organisationen omfattas av NIS2 ska underlaget mappas till Article 21-åtgärder för åtkomstkontroll, policy för tillgångshantering, personalsäkerhet och autentisering. Om den är en finansiell entitet enligt DORA ska det mappas till IKT-riskstyrning, skydd, övervakning och tredjepartskrav där det är relevant. Om personuppgifter berörs ska det mappas till GDPR Article 5 om riktighet och konfidentialitet samt Article 32 om säkerhet i behandlingen.
Steg 2, definiera test av utformning
Ställ praktiska utformningsfrågor:
- Identifierar rutinen alla system inom omfattningen?
- Omfattar den privilegierade konton, tjänstekonton och nödåtkomst?
- Är granskaren oberoende från den dagliga åtkomsttilldelningen där det är praktiskt möjligt?
- Är frekvens, eskalering och undantagsregler definierade?
- Är bevarande av underlag definierat?
- Ingår GDPR, DORA, NIS2 eller kundspecifika skyldigheter där det är relevant?
Om svaret är nej, registrera ett utformningsundantag.
Steg 3, genomför test av operativ effektivitet
Välj ett urval och testa faktisk drift. För en kvartalsvis granskning av privilegierad åtkomst, välj den senaste slutförda granskningen och högriskanvändare i kritiska system. Om miljön är liten, testa alla privilegierade konton. Om den är stor, använd riskbaserat urval med högre täckning för administratörer, produktionssystem, system med personuppgifter och externt exponerade plattformar.
Den organisationsövergripande Policy för revision och regelefterlevnadsövervakning stödjer:
Insamling av underlag genom intervjuer, genomgångar och urval
Den kräver också:
Dokumentation av urvalsstrategi, revisionsomfattning och begränsningar
Bifoga inte bara underlag. Dokumentera varför urvalet valdes, vilken population det representerar och vad som undantogs.
En stark urvalsbeskrivning kan lyda:
”Population: 42 privilegierade produktionskonton i molnkonsol, CI/CD-plattform och databasadministration. Urval: samtliga 7 break-glass-konton, samtliga 5 administratörskonton för produktionsdatabaser och 10 slumpmässigt valda privilegierade ingenjörskonton. Period: Q1 2026. Undantag: brandväggskonton som hanteras av tredje part bedöms inom CSA-TPR-04 för granskning av leverantörsåtkomst.”
Den meningen ger revisorn population, risklogik, period och begränsning.
Steg 4, utvärdera underlagets kvalitet
För varje underlagspost ska följande fångas:
- Underlags-ID
- Kontroll-ID och kontrollägare
- Bedömningsperiod
- Källsystem
- Insamlingsdatum
- Insamlare
- Granskare eller godkännare
- Kopplad skyldighet
- Lagringsplats
- Bevarandetid
- Identifierade undantag
- Åtgärdsärende eller CAPA-referens
Detta omvandlar CSA från ett subjektivt frågeformulär till ett evidensbaserat kontrolltest.
Steg 5, registrera undantag och korrigerande åtgärder
Om två privilegierade konton saknar dokumenterad verksamhetsmässig motivering ska frågan inte döljas i anteckningar. Skapa en iakttagelse, tilldela en riskklassning, definiera en åtgärd, utse en ägare och enas om ett måldatum.
SME-policyn kräver:
Alla revisionsiakttagelser ska dokumenteras med riskklassning och föreslagna åtgärder.
Tillämpa därefter Zenith Blueprint Steg 27, revisionsiakttagelser. Blueprint rekommenderar kategorierna större avvikelse, mindre avvikelse eller observation, följt av rotorsaksanalys. Om tjänstekonton missades eftersom identitetsförteckningen inte omfattar dem är rotorsaken inte ”granskarfel”. Den är ofullständig åtkomstförteckning eller otydlig omfattning i rutinen.
Steg 6, stäng genom CAPA och verifiera effektivitet
Zenith Blueprint Steg 29 rekommenderar användning av en CAPA-logg med problembeskrivning, rotorsak, korrigerande åtgärd, ansvarig ägare, måldatum och status. Den betonar också att effektiviteten ska verifieras efter slutförande.
Om den korrigerande åtgärden är ”uppdatera rutinen för åtkomstgranskning så att tjänstekonton ingår” ska verifieringsmetoden vara praktisk: granska nästa åtkomstcykel och bekräfta att tjänstekonton ingår, undantag är lösta och underlag bevaras.
Det är så CSA blir ständig förbättring i stället för efterlevnadsteater.
Korsvis efterlevnadsmappning utan fyra separata kontrollprogram
Den största effektivitetsvinsten är ”testa en gång, mappa många”.
Att bygga separata testprocesser för ISO/IEC 27001:2022, NIS2, DORA och GDPR skapar dubblerat underlag, inkonsekventa svar och utmattade kontrollägare. Ett bättre arbetssätt är att använda ISO/IEC 27001:2022 som ledningssystem, CSA som testarbetsflöde och Zenith Controls som guide för korsvis regelefterlevnad.
| CSA-underlagsområde | Användning för ISO/IEC 27001:2022 | Användning för NIS2 | Användning för DORA | Användning för GDPR | Anpassning till NIST CSF 2.0 |
|---|---|---|---|---|---|
| Ledningsgodkänd riskbehandling och kontrollägarskap | Klausuler 5.3, 6.1, 6.2 och Annex A 5.2 | Article 20-styrning och Article 21-åtgärder | Article 5 ansvar för ledningsorganet och Article 6 IKT-riskramverk | Ansvarsskyldighet för tekniska och organisatoriska åtgärder | GOVERN-resultat för roller, riskstrategi och tillsyn |
| Underlag från åtkomstgranskning | Annex A 5.15, 5.16 och 5.18 | Åtkomstkontroll, policy för tillgångshantering och autentiseringsåtgärder | IKT-skydd och riskkontroller | Riktighet, konfidentialitet och åtkomstbegränsning | PR.AA-resultat för identitet, autentisering och principen om minsta privilegium |
| Incidentövning och incidentregister | Annex A 5.24, 5.25, 5.26 och 5.27 | Article 21 incidenthantering och Article 23 rapporteringsberedskap | Klassificering, rapportering och rotorsak för IKT-relaterade incidenter | Detektering och hantering av personuppgiftsincidenter | RESPOND- och RECOVER-resultat |
| Poster från leverantörsövervakning | Annex A 5.19, 5.20, 5.21 och 5.22 | Säkerhet i leveranskedjan enligt Article 21 | IKT-tredjepartsrisk, register, avtal och exit | Tillsyn över personuppgiftsbiträden och skyddsåtgärder för dataskydd | GV.SC-resultat för leveranskedjan |
| Test av återställning från säkerhetskopia | Annex A 8.13 och kontinuitetskontroller | Driftskontinuitet, säkerhetskopiering, katastrofåterställning och krishantering | Kontinuitet, återställning och resiliensprovning | Tillgänglighet och resiliens i behandlingen | PR.DS- och RC.RP-resultat för säkerhetskopiering och återställning |
| Åtgärdande av sårbarheter | Annex A 8.8 | Sårbarhetshantering och säkert underhåll | IKT-riskskydd, detektering och åtgärdande | Säkerhet i behandlingen och riskreducering | IDENTIFY-, PROTECT- och DETECT-resultat |
NIST Cybersecurity Framework 2.0 är användbart som integrationslager. Dess GOVERN-funktion behandlar rättsliga, regulatoriska och avtalsmässiga krav, riskaptit, ledningens ansvarsskyldighet, policystyrning och tillsyn. Dess organisatoriska profiler hjälper organisationer att definiera nuvarande och önskade cybersäkerhetsresultat, analysera gap och omvandla dem till prioriterade åtgärdsplaner.
COBIT 2019 och ISACA-liknande säkerhetsförsäkran ger ytterligare ett användbart perspektiv. De fokuserar på styrningsmål, processförmåga, ansvarsskyldighet, mätetal och ledningens tillsyn. En COBIT-orienterad granskare kommer att fråga om processen är definierad, mätt och förbättrad, inte bara om en artefakt finns.
Hur olika revisorer kommer att granska ditt CSA-underlag
Samma CSA-post kommer att tolkas olika beroende på revisorns bakgrund. Att utforma underlag för dessa perspektiv gör programmet mer resilient.
| Revisorsperspektiv | Vad revisorn fokuserar på | Vad starkt CSA-underlag visar |
|---|---|---|
| ISO/IEC 27001:2022-revisor | ISMS-omfattning, riskbehandling, tillämplighetsförklaring (SoA), övervakning, internrevision, ledningens genomgång och korrigerande åtgärd | Kontrollen är kopplad till risk, ägare, rutin, underlag, övervakningsresultat, undantag och korrigerande åtgärd |
| NIST-orienterad bedömare | Nuvarande och önskade resultat, styrning, riskprioritering, identitet, övervakning, respons och återställning | CSA mappas till CSF-resultat, visar nuvarande prestation och identifierar gap mot målbilden |
| DORA-granskare | Ledningsorganets tillsyn, IKT-riskramverk, resiliensprovning, incidentlivscykel, tredjepartsrisk och åtgärdande | IKT-kontrollunderlag är aktuellt, riskbaserat, testat, eskalerat och rapporterat till ledningen där det är relevant |
| GDPR-granskare | Ansvarsskyldighet, dataskyddsprinciper, säkerhet i behandlingen, beredskap för incidentanmälningar och tillsyn över personuppgiftsbiträden | Underlag kopplar tekniska kontroller till behandling av personuppgifter, rättsliga roller, databevarande och säkerhetsåtgärder |
| COBIT 2019- eller ISACA-liknande revisor | Styrningsmål, processägarskap, förmåga, mätetal, ärendehantering och oberoende i säkerhetsförsäkran | CSA visar definierad process, ansvarig ägare, mätbar prestation, undantag och ledningsrapportering |
Vid oberoende granskning kommer en ISO/IEC 27001:2022-revisor att leta efter internrevisionsprogrammet enligt klausul 9.2, indata till ledningens genomgång enligt klausul 9.3 och korrigerande åtgärd enligt klausul 10.2. En DORA-granskare kommer att leta efter riskbaserad testning, oberoende, åtgärdande och ledningens tillsyn. En NIS2-tillsynsmyndighet kommer att fokusera på om ledningen kan visa cybersäkerhetsåtgärdernas effektivitet. En GDPR-granskare kommer att fråga om underlaget visar lämpliga tekniska och organisatoriska åtgärder kring faktiska behandlingsaktiviteter.
Poängen är inte att skriva om underlaget för varje målgrupp. Poängen är att samla in det en gång med tillräckligt sammanhang för att uppfylla flera perspektiv.
Ledningsrapportering som skapar åtgärd, inte brus
CSA-resultat ska inte stanna i kontrollägarnas kalkylblad. De ska flöda in i ledningens genomgång.
I Steg 28, ledningens genomgång, rekommenderar Zenith Blueprint indata om förändringar i interna och externa frågor, förändringar i intressentkrav, ISMS-prestanda, revisionsresultat, övervakning och mätning, incidenter, avvikelser, förbättringsmöjligheter och resursbehov.
Det är precis där CSA hör hemma.
En användbar CSA-kontrollpanel för ledande befattningshavare bör omfatta:
- Kontrolltäckning per område och kritisk process.
- Andel kontroller som testats enligt schema.
- Kvalitetspoäng för underlag per kontrollägare.
- Öppna undantag per riskklassning.
- Försenade korrigerande åtgärder.
- Återkommande iakttagelser och rotorsaker.
- Högriskmappningar för NIS2, DORA, GDPR och kundförpliktelser.
- Leverantörsrelaterade kontrollundantag.
- Iakttagelser från incident-, säkerhetskopierings- och resiliensprovning.
- Resursbeslut som krävs från ledningen.
Ledningen behöver inte varje skärmdump. Den behöver veta om kontrollmiljön är tillförlitlig, var risken ökar, om skyldigheter täcks och var beslut krävs.
Detta stödjer NIS2 Article 20 ledningsansvar och DORA Article 5 tillsyn från ledningsorganet. För GDPR hjälper det den personuppgiftsansvarige att visa att ansvarsskyldighet inte är ett engångsdokument, utan en levande styrningsprocess.
Vanliga CSA-fallgropar och hur de undviks
Den första fallgropen är CSA som enbart bygger på frågeformulär. Ett ja- eller nej-svar utan underlag skapar trygghetskänsla, inte försäkran. Varje väsentligt påstående ska stödjas av underlag.
Den andra fallgropen är underlag utan kontrollsammanhang. En loggexport är meningslös om den inte är kopplad till ett kontrollmål, en period, en källa, en ägare och en slutsats.
Den tredje fallgropen är svag undantagsdisciplin. Om iakttagelser saknar riskklassning, ägare, måldatum och verifieringsmetoder blir CSA en lagringsövning. Zenith Blueprint Steg 29 förebygger detta genom att koppla avvikelser till rotorsak, korrigerande åtgärd, ägare, måldatum och verifiering av effektivitet.
Den fjärde fallgropen är att ignorera externt tillhandahållna tjänster. ISO/IEC 27001:2022 kräver kontroll över externt tillhandahållna processer, produkter eller tjänster som är relevanta för ISMS. NIS2 omfattar säkerhet i leveranskedjan. DORA kräver hantering av IKT-tredjepartsrisker, register, leverantörsgranskning, avtalsmässiga skyddsåtgärder, bedömning av koncentrationsrisk, revisionsrätt och exitplaner. NIST CSF 2.0 GV.SC-resultat omfattar på liknande sätt leverantörsroller, leverantörsgranskning, avtal, övervakning, incidentplanering och avveckling. CSA måste omfatta leverantörsunderlag, inte bara internt IT-underlag.
Den femte fallgropen är att behandla GDPR som en juridisk bilaga. Om personuppgifter behandlas i ett system ska CSA testa om säkerhetskontroller stödjer riktighet, konfidentialitet, tillgänglighet, databevarande, åtkomstbegränsning och beredskap för incidentanmälan.
Kontrollägarens checklista för 2026
Innan ett CSA-resultat lämnas in ska varje kontrollägare kunna bekräfta följande:
- Jag känner till kontrollmålet och kopplade risker.
- Jag vet vilka ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR- eller avtalsmässiga skyldigheter kontrollen stödjer.
- Jag har testat utformning och operativ effektivitet separat.
- Jag har dokumenterat populationen och urvalsmetoden.
- Jag har bifogat underlag som är fullständigt, aktuellt, hänförbart, autentiskt, relevant, bevarat och återanvändbart.
- Jag har registrerat metadata för vem som samlade in underlaget, när och från vilket system.
- Jag har dokumenterat undantag med riskklassning och föreslagna åtgärder.
- Jag har identifierat rotorsak för väsentliga undantag.
- Jag har skapat eller uppdaterat CAPA-poster med ägare, förfallodatum och verifieringsmetod.
- Jag har eskalerat väsentliga frågor till ledningens genomgång.
Om en kontrollägare inte kan slutföra denna checklista är problemet inte bara en CSA-svaghet. Det kan vara en svaghet i ISMS-övervakning, ett gap i NIS2-bedömning av effektivitet, en fråga om IKT-riskstyrning enligt DORA eller en svaghet i ansvarsskyldighet enligt GDPR.
Gör CSA till en del av er operativa modell för säkerhetsförsäkran
Kontrollsjälvutvärdering ersätter inte internrevision, penetrationstestning, DORA-resiliensprovning eller juridisk granskning enligt GDPR. Det är det operativa lagret som gör alla dessa mer tillförlitliga.
År 2026 kommer de organisationer som klarar revisioner med mindre störningar inte att vara de som har flest policyer. Det kommer att vara de vars kontrollägare kan visa, med underlag av hög kvalitet, att kontroller är utformade, fungerar, övervakas, korrigeras och rapporteras.
Clarysec hjälper organisationer att bygga denna förmåga med Zenith Blueprint, policymallar såsom Informationssäkerhetspolicy, Policy för revision och regelefterlevnadsövervakning, Policy för revision och regelefterlevnadsövervakning – små och medelstora företag, Policy för bevisinsamling och forensik – små och medelstora företag, Policy för rättslig och regulatorisk efterlevnad och den korsvisa mappningskraften i Zenith Controls.
Om era ISO/IEC 27001:2022-kontroller är dokumenterade men underlaget är utspritt, inkonsekvent eller inte återanvändbart för NIS2, DORA och GDPR, börja med ett högriskområde den här veckan. Genomför CSA för privilegierad åtkomst, leverantörssäkerhet, incidentberedskap, åtgärdande av sårbarheter eller återställning från säkerhetskopior. Testa utformning, testa operativ effektivitet, bedöm underlagets kvalitet, logga undantag och för in resultatet i ledningens genomgång.
Redo att omvandla kontrollsjälvutvärdering till revisionsbar säkerhetsförsäkran? Ladda ned Zenith Blueprint, utforska Zenith Controls eller begär en Clarysec-bedömning av underlagsberedskap för att se var ert kontrollunderlag håller och var det behöver förbättras.
Bli PECB ISO/IEC 27001 Lead Implementer eller Lead Auditor
- ✓ Officiellt PECB-kursmaterial och två provförsök
- ✓ Certifieringsavgift och första årets AMF ingår, där det är tillämpligt
- ✓ Självstudier eller live online · kursen tilldelas inom 1 arbetsdag
Om författaren

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council