ISAE 3402- og SOC 2‑erklæringer og logdata

Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen

En ISAE 3402- eller SOC 2-erklæring fortæller, at en revisor har vurderet en leverandørs kontroller i en bestemt periode og mod bestemte kontrolmål. Den fortæller ikke, at de konkrete logs, I får udleveret til en undersøgelse, er fuldstændige, korrekte eller uændrede. Erklæringen kan styrke tilliden til en logkilde, men kun for de kontroller, der var i omfanget, og kun i den periode, der blev testet. Artiklen er skrevet til IT-revisorer og andre, der skal vurdere leverandørdata i en undersøgelse.

Forskellen mellem revisionsbevis og forensisk bevis generelt er beskrevet i fra revisionsbevis til forensisk bevis. Hvornår opgaven hører hjemme hos en IT-revisor, og hvornår hos en IT-sagkyndig, står på digital-bevissikring.dk.

Hvad erklæringerne er

ISAE 3402 er IAASB’s internationale standard for erklæringer med sikkerhed om kontroller hos en serviceorganisation. Den er udformet til at give brugervirksomhedens revisor et grundlag, når revisionen af regnskabet afhænger af en leverandørs systemer. Fokus er derfor kontroller med betydning for den finansielle rapportering.

SOC 2 er en tilsvarende amerikansk erklæringstype fra AICPA, rettet mod kontroller vedrørende sikkerhed, tilgængelighed, behandlingsintegritet, fortrolighed og privatliv. Leverandøren vælger, hvilke af de fem kategorier erklæringen omfatter. Sikkerhed er næsten altid med; de øvrige er det ikke nødvendigvis.

Begge findes i to typer:

Type 1 vurderer beskrivelsen af systemet og om kontrollerne var hensigtsmæssigt udformet og implementeret på et bestemt tidspunkt.
Type 2 vurderer desuden, om kontrollerne har fungeret effektivt i en periode, og indeholder revisors test og eventuelle afvigelser.

Til en undersøgelse er en type 1-erklæring næsten uden værdi for spørgsmålet om logdata, fordi den ikke siger noget om, hvordan kontrollerne faktisk fungerede.

Læs erklæringen som en afgrænsning

Det vigtigste i erklæringen til en undersøgelse er ikke konklusionen, men afgrænsningen. Gennemgå:

Perioden. Dækker type 2-perioden det tidsrum, hændelsen skete i? En erklæring for kalenderåret før siger intet direkte om en hændelse i år.
Systemerne. Hvilke systemer, platforme og lokationer er med? Den log, I har brug for, kan komme fra et system uden for beskrivelsen.
Kontrolmålene. Er der kontroller om logning, beskyttelse af logs, adgang for privilegerede brugere, ændringsstyring og tidssynkronisering? Mangler de, er logintegriteten ikke vurderet.
Underleverandører. Ved carve-out-metoden er underleverandørens kontroller ikke med. Ligger hosting eller logopsamling hos en underleverandør, er netop den del uden for erklæringen.
Komplementære kontroller hos brugervirksomheden. Erklæringen forudsætter typisk, at kunden selv udfører visse kontroller, fx gennemgang af brugere eller opbevaring af egne eksporter. Har kunden ikke gjort det, hviler konklusionen på en forudsætning, der ikke holdt.
Afvigelser. Revisors test kan have fundet afvigelser i fx logovervågning eller adgangsstyring. De står ofte i et bilag og er let at overse.

Når hændelsen ligger mellem to erklæringer

Hændelser sker sjældent pænt inden for en erklæringsperiode. Ligger hændelsen efter den seneste periodes udløb, har leverandøren måske udstedt et såkaldt bridge letter: en erklæring fra ledelsen om, at der ikke er sket væsentlige ændringer i kontrollerne siden perioden. Et bridge letter er ledelsens egen udtalelse og er ikke testet af revisor. Det kan ikke bruges som dokumentation for, at logningen fungerede i hændelsesperioden.

Venter I på den næste erklæring, så notér, at den først kan vurderes, når den foreligger, og at revisors stikprøver måske slet ikke rammer de dage, hændelsen omfatter. En type 2-erklæring beskriver, at kontrollerne fungerede i perioden som helhed efter revisors test. Den siger ikke, at de fungerede hver eneste dag.

Flere leverandører i samme kæde

I moderne opsætninger kan en hændelse involvere flere leverandører, fx en SaaS-applikation, der kører hos en cloududbyder, med login gennem en tredje identitetsudbyder. Hver leverandør kan have sin egen erklæring med sin egen periode og sit eget omfang. Lav en simpel oversigt over kæden: hvilken log kommer fra hvilken leverandør, hvilken erklæring dækker den, og hvor er der huller. Oversigten gør det tydeligt, hvor erklæringerne overlapper, og hvor ingen af dem siger noget.

Fra kontrol til konkret log

Selv en ren type 2-erklæring med relevante kontroller siger noget om processen, ikke om den enkelte fil. Den udleverede log skal derfor vurderes for sig:

Kilde og udtræk. Hvem lavede udtrækket, fra hvilket system, med hvilken forespørgsel eller funktion, og hvornår? En CSV dannet af leverandørens supportmedarbejder er et nyt dokument, ikke den originale log.
Fuldstændighed. Dækker udtrækket hele perioden og alle relevante brugere og hændelsestyper? Er der filtre, maksimalt antal rækker eller sidebegrænsninger i eksportfunktionen?
Felter og tid. Hvilken tidszone bruges, og hvad betyder hvert felt? Leverandørens feltbeskrivelse bør vedlægges.
Integritet. Er der hashværdier, signaturer eller anden beskyttelse, og kan udtrækket gentages med samme resultat?

En kontrol, der beskriver, at logs beskyttes mod ændring, gør det mere sandsynligt, at den underliggende log er intakt. Det overføres ikke automatisk til et udtræk, der er lavet bagefter. Hvordan logintegritet kan vises teknisk, står i logintegritet, og hvilke logs SaaS-leverandører typisk har, står i SaaS-systemer som datakilde.

Når leverandøren selv er part

Erklæringen er bestilt og betalt af leverandøren. Det gør den ikke uvederhæftig, men det betyder, at omfanget er leverandørens valg. Er leverandøren part i tvisten, eller kan leverandørens egne medarbejdere være involveret i hændelsen, bør logdata ikke alene accepteres med henvisning til erklæringen. Bed om rådata frem for sammenfatninger, om beskrivelse af udtræksmetoden, og om mulighed for at gentage udtrækket under observation eller ved en uvildig.

Brug erklæringen som kortlægning

Selvom erklæringen ikke beviser den konkrete log, er den et godt kort. Systembeskrivelsen fortæller, hvilke systemer der findes, hvordan logning er sat op, hvem der har privilegeret adgang, og hvilke værktøjer der bruges til overvågning. Det kan forkorte kortlægningen af datakilder betydeligt og give de rigtige spørgsmål til leverandøren. Beskrivelsen af ændringsstyring kan også pege på, hvor dokumentation af konfigurationsændringer ligger.

Typiske fejlslutninger

“Leverandøren har en ren erklæring, så loggen er korrekt.” Erklæringen dækker kontroller i en periode, ikke det konkrete udtræk.
“SOC 2 dækker alt.” Kun de valgte kategorier og de beskrevne systemer er med.
“Erklæringen er fra i år.” Datoen for afgivelse er ikke det samme som den testede periode.
“Der står ingen afvigelser i konklusionen.” Afvigelser kan stå i testafsnittet uden at ændre konklusionen.

Dokumentation i rapporten

Angiv i rapporten, hvilken erklæring der er gennemgået (type, periode, version og afgivelsesdato), hvilke kontroller der er relevante for undersøgelsen, og hvilke dele af logkilden der ligger uden for erklæringens omfang. Beskriv derefter selvstændigt, hvordan den udleverede log er modtaget, kontrolleret og hashet. Så kan en læser se, hvor meget af tilliden der hviler på erklæringen, og hvor meget på egen kontrol. Spørgsmålet om, hvorvidt jeres egen logning kan bære en undersøgelse, kan testes direkte; se forensic readiness-test.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: NIST CFTT og CFReDS: offentlige værktøjstests og testbilleder · NIST SP 800-101 om mobilforensik

→ Second opinion på en IR- eller forensic-rapport · For IT-revision · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik