Sammanfattning: Att en säkerhetskontroll finns beskriven i en policy betyder inte att den fungerar. Assurance handlar om att gå från dokumenterade kontroller till verifierad säkerhet: att skilja på designad, implementerad och operativt effektiv kontroll, testa rätt sak på rätt sätt, bygga evidens in i kontrollen i stället för att jaga den i efterhand – och börja riskbaserat med de kontroller som betyder mest.
De flesta organisationer kan svara ja på frågorna:
- ”Vi har MFA.”
- ”Vi har backup.”
- ”Vi har behörighetsstyrning.”
- ”Vi har en incidentprocess.”
- ”Vi har leverantörskontroller.”
Bra. Men vid en revision, en tillsyn, en kundgranskning eller en incident kommer nästa fråga: Kan ni visa det? Och sedan den ännu svårare: Fungerar kontrollen verkligen – hela tiden, för alla system, för alla användare?
Det är där assurance börjar.
Tre nivåer som ofta blandas ihop
1. Designad kontroll
Kontrollen finns beskriven. Det står i policyn att alla administratörskonton ska ha MFA. Det finns en rutin för behörighetsgranskning. Det finns en backupinstruktion. Det är nödvändigt – men det säger ingenting om verkligheten.
2. Implementerad kontroll
Kontrollen är införd. MFA är aktiverat i identitetsplattformen. Backupjobben är konfigurerade. Behörighetsgranskningen har genomförts en gång. Det är ett steg längre – men fortfarande en ögonblicksbild.
3. Operativt effektiv kontroll
Kontrollen fungerar över tid och gör det den ska. MFA gäller för alla privilegierade konton utan undantag, även de som skapades i förra veckan. Backuperna går igenom, återställning är testad och fungerar inom den tid verksamheten behöver. Behörighetsgranskningen görs varje kvartal och leder faktiskt till att felaktiga behörigheter tas bort.
Det är den tredje nivån som en revisor, tillsynsmyndighet eller större kund vill se bevis för. Det är också den nivån de flesta organisationer har svårast att visa.
Testa rätt sak
Olika kontroller behöver testas på olika sätt. Ett vanligt misstag är att testa alla kontroller med samma metod – ofta genom att fråga någon om kontrollen finns.
- Teknisk kontroll – verifieras mot systemet självt: konfiguration, loggar, exportlistor, automatiska rapporter. Frågan är inte ”har ni MFA?” utan ”visa listan över privilegierade konton och deras MFA-status i dag”.
- Manuell kontroll – verifieras genom stickprov på att den utförts: godkännanden, signerade granskningar, ärenden, mötesprotokoll. Har åtkomstbegäran faktiskt godkänts av rätt person innan behörigheten tilldelades?
- Periodisk kontroll – verifieras genom att kontrollera att den genomförts med rätt frekvens, av rätt roll, och att avvikelser hanterats. En kvartalsgranskning som gjorts två gånger på ett år är inte operativt effektiv.
- Styrande kontroll – verifieras genom att policyer, roller och beslut är aktuella, kommunicerade och beslutade på rätt nivå. Finns ledningens beslut om risktolerans, och följs det?
Ta backup som exempel. Att backupjobbet körs är en implementerad kontroll. Att det körs varje natt utan fel är en delvis verifierad kontroll. Att ni faktiskt har återställt ett kritiskt system från backup, mätt tiden, och konstaterat att data var komplett och användbar – det är operativ effektivitet. Många organisationer har aldrig gjort det sista steget.
Evidens ska stödja kontrollen – inte skapa administration
Ett vanligt scenario inför revision eller tillsyn är evidensjakt. Någon sitter i veckor och letar:
- skärmdumpar från olika system
- gamla e-postgodkännanden
- protokoll från möten som hölls för ett halvår sedan
- exportlistor som ingen sparade
- testrapporter som kanske finns hos leverantören
- loggar som redan roterats bort
Det är dyrt, stressigt och ger sällan ett komplett resultat. Alternativet är att bestämma redan när kontrollen designas hur den ska bevisas. Fem frågor räcker långt:
- Vilken evidens visar att kontrollen fungerar?
- Var uppstår evidensen – i systemet, i ett ärende, i ett protokoll?
- Hur ofta behöver den samlas in?
- Vem ansvarar för att den finns?
- Hur länge ska den bevaras, och var?
När evidensen byggs in i kontrollen blir den en biprodukt av det normala arbetet – inte ett separat projekt varje gång någon frågar.
Uppföljning blir allt viktigare
Kraven på att kunna visa – inte bara påstå – ökar från flera håll samtidigt. Nationellt cybersäkerhetscenter (NCSC) lyfter i sitt metodstöd fram uppföljning och utvärdering av säkerhetsåtgärder som en egen del av ett systematiskt informationssäkerhetsarbete. Det är inte tillräckligt att införa åtgärder; organisationen ska också följa upp att de fungerar och justera dem.
För verksamheter som omfattas av cybersäkerhetslagen blir det konkret genom MCF:s föreskrifter (MCFFS 2026:11 och 2026:12), som tillämpas från den 1 oktober 2026. Där ställs krav på att säkerhetsåtgärderna följs upp, utvärderas och dokumenteras – och att tillsynsmyndigheten på begäran ska kunna få underlag. Liknande krav finns redan i DORA för finanssektorn och i ISO 27001 genom kravet på intern revision och ledningens genomgång.
Gemensamt för dem alla: en policy räcker inte som svar.
Assurance är inte samma sak som gap-analys
Det är lätt att blanda ihop de två. En gap-analys svarar på frågan: Vilka kontroller saknas eller är ofullständiga i förhållande till ett krav? Den jämför nuläge mot ett ramverk och ger en prioriterad lista över vad som behöver byggas.
Assurance ställer andra frågor om de kontroller som redan finns:
- Är kontrollen implementerad som designad?
- Fungerar den konsekvent över tid?
- Täcker den hela omfattningen – alla system, alla användare, alla leverantörer?
- Finns evidens som en oberoende part kan granska?
- Hanteras avvikelser när kontrollen fallerar?
Gap-analysen kommer först och visar vad som ska byggas. Assurance kommer sedan och visar att det som byggts håller. Organisationer som bara gör det första får en fin åtgärdslista men ingen visshet.
Börja riskbaserat
Ingen kan testa alla kontroller hela tiden. Börja därför med de kontroller där ett fel skulle göra störst skada och där ni i dag har minst insyn. För de flesta organisationer handlar det om:
- privilegierad åtkomst och administratörskonton
- backup och faktisk återställningsförmåga
- incidentdetektion – upptäcker ni det som händer?
- kritiska leverantörer och deras kontroller
- skydd av säkerhetskopior mot manipulation och kryptering
- patchning av internetexponerade system
- manuella processer som är beroende av enskilda personer
- regulatorisk rapportering – kan ni rapportera i tid om det händer?
Bygg sedan ut testningen successivt, med en årsplan som styrs av risk – inte av vilken kontroll som råkar vara enklast att testa.
Så kan Kristensson i Skåne stödja
Vi arbetar med assurance och internrevision som en oberoende, praktisk verifiering – inte som en pappersövning. Beroende på behov kan vi bidra med:
- intern revision av informationssäkerhet, mot ISO 27001, cybersäkerhetslagen, DORA eller era egna krav
- kontrolltestning av design, implementation och operativ effektivitet
- evidensgranskning och design av evidensinsamling
- mognadsbedömningar
- revisionsberedskap inför certifiering, tillsyn eller kundgranskning
- stickprov och återkommande kontrollpunkter
- tredjepartsassurance – granskning av kritiska leverantörers kontroller
- uppföljning av åtgärder efter tidigare granskningar
- Assurance-as-a-Service – löpande, planerad kontrolltestning över året
Målet är inte fler dokument. Målet är att ni ska kunna svara ”ja, och här är beviset” – innan någon annan ställer frågan.
Vill ni veta om era kontroller håller? Läs mer om vårt erbjudande inom assurance och internrevision eller kontakta oss för ett förutsättningslöst samtal.
Källor: Nationellt cybersäkerhetscenter (NCSC), metodstöd för systematiskt informationssäkerhetsarbete; Myndigheten för civilt försvar (MCF), föreskrifter MCFFS 2026:11 och 2026:12 med tillämpning från den 1 oktober 2026; ISO/IEC 27001:2022, kapitel 9 om utvärdering av prestanda.
Den här texten är allmän information och utgör inte juridisk rådgivning i ett enskilt ärende.

