ESDH og dokumentstyring: auditspor, versioner og journalisering

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Et ESDH-system kan typisk vise, hvornår et dokument blev oprettet, hvornår det blev journaliseret på en sag, hvilke versioner der findes, og hvem der har set eller ændret det. Spørgsmålet i en undersøgelse er sjældent, om sporene findes, men hvilke af dem der faktisk er slået til, hvad hvert felt betyder i netop det system, og om udtrækket bevarer dem. Systemerne er forskellige, og meget afhænger af konfigurationen, så denne artikel beskriver det, der går igen, og hvor man skal kigge efter forskellene.

Myndigheden som modpart, og den juridiske betydning af journalisering, er beskrevet på digital-bevissikring.dk. Artiklen her er skrevet til offentlige IT-afdelinger, revisorer og teknisk interesserede advokater.

Tre lag i et ESDH-system

Det hjælper at skelne mellem tre lag, fordi de har hver sin historik:

Journalen: sagens metadata og registreringen af dokumenter på sagen, med journaldato, dokumentdato, afsender, modtager og titel. Det er det, offentlighedsloven kræver af journaliseringen.
Dokumentlageret: selve filerne, ofte med versioner. Lageret kan ligge i systemets egen database, på et filsystem eller i en tilknyttet SharePoint-løsning.
Auditsporet: en log over handlinger, fx oprettelse, ændring af metadata, ny version, visning, udskrift, eksport, ændring af adgang og sletning.

Et dokument kan derfor have én dato i journalen, en anden i filens egne metadata og en tredje i auditsporet. De beskriver forskellige begivenheder og skal ikke forventes at stemme overens.

Datoerne, og hvad de betyder

Journaliseringspligten efter offentlighedsloven indebærer blandt andet, at journalen indeholder dato for dokumentets modtagelse eller afsendelse. Den dato indtastes eller udfyldes automatisk, og den kan ofte rettes. Systemet har derudover typisk:

Registreringstidspunkt: hvornår posten blev oprettet i systemet. Sættes automatisk og kan normalt ikke ændres af brugeren.
Dokumentdato: den dato, brugeren angiver som dokumentets dato. Kan ligge før registreringen.
Ændringstidspunkt: seneste ændring af metadata eller fil.

Når spørgsmålet er, om et dokument er journaliseret rettidigt eller senere, er forskellen mellem dokumentdato og registreringstidspunkt det første, der skal ses på. Auditsporet kan vise, om dokumentdatoen er rettet efterfølgende. Hvordan filens egne tidsstempler og indlejrede metadata fortolkes, er beskrevet i tilbagedaterede dokumenter og metadata i Office-filer.

Versioner

De fleste systemer gemmer en ny version, når et dokument tjekkes ind efter redigering. Men det er ikke sikkert, at hver gemning giver en version. Typiske varianter:

Versionering kun ved bevidst indtjekning, mens løbende gemninger overskriver den aktuelle version.
Kladder, der ikke versioneres, før dokumentet markeres som endeligt.
Automatisk sletning af mellemversioner efter en periode eller ved et maksimalt antal.
Endelige dokumenter, der låses, så nye versioner ikke kan oprettes.

Find systemets versionsindstillinger, før historikken fortolkes. Hvis dokumentlageret er SharePoint, gælder SharePoints versionsregler og auditlog også, som beskrevet i versioner og delingslinks i SharePoint. Her kan administratorer sætte grænser for antal versioner og deres alder, og ifølge Microsoft slettes versioner, der overskrider grænserne, permanent uden om papirkurven. Er dokumenterne omfattet af en opbevaringspolitik eller et eDiscovery-hold, bliver versionerne derimod bevaret. Et manglende mellemled i versionshistorikken kan derfor skyldes en indstilling, ikke en bevidst sletning, og indstillingerne bør dokumenteres sammen med udtrækket.

Auditsporet

Auditsporets indhold varierer mest mellem systemer og installationer. Afklar med leverandøren:

Hvilke handlinger logges? Logges visning og udskrift, eller kun ændringer?
Logges ændringer af metadata med både gammel og ny værdi?
Logges sletning og flytning mellem sager?
Logges administratorers handlinger, fx ændring af adgangsrettigheder?
Hvor længe opbevares sporet, og bliver det ryddet automatisk?
Kan sporet ændres af systemadministratorer, og logges det i så fald?

Mange systemer logger visninger med en anden detaljegrad end ændringer, eller kun når en særlig indstilling er slået til. Fravær af en visningspost betyder derfor ikke nødvendigvis, at dokumentet ikke blev set.

Udtræk

Udtræk fra ESDH foregår typisk på tre måder, og de bevarer forskellige ting:

Brugerens eksport af en sag: giver ofte filerne og en oversigt, men sjældent auditspor og versioner.
Leverandørens rapporter eller API: kan give journal, versioner og auditspor, men skal bestilles specifikt med felter og periode.
Databaseudtræk: giver det mest komplette billede, men kræver kendskab til datamodellen og bør foretages i samarbejde med leverandøren. Se databaser i forensic.

Bestil udtrækket skriftligt med periode, sager, felter, tidszone og format, og bed om en beskrivelse af, hvordan det er dannet. Hash filerne ved modtagelsen, og kontrollér en stikprøve mod systemets brugerflade.

Arkiveringsversioner som kilde

Offentlige myndigheder afleverer data til Rigsarkivet eller et kommunalt arkiv som arkiveringsversioner efter Rigsarkivets bekendtgørelse. En arkiveringsversion indeholder tabeller fra systemets database og dokumenterne i et bevaringsformat, typisk TIFF. Det betyder, at dokumenterne er konverteret, og at filernes oprindelige metadata ikke er bevaret i selve dokumentfilen. Til gengæld kan tabellerne indeholde journal- og registreringsdatoer for en periode, hvor det levende system måske er udskiftet. Er en sag gammel, eller er systemet skiftet, kan arkiveringsversionen være den eneste kilde.

Typiske fejlkilder

Systemskift: ved migrering fra et ESDH-system til et andet kan registreringstidspunkter blive sat til migreringsdatoen, og auditspor fra det gamle system følger ikke altid med.
Tidszone og serverur: auditspor er ofte i servertid uden tidszone. Se servertid og klienttid.
Tekniske brugere: integrationer, fx postmodtagelse fra Digital Post eller automatisk journalisering af mails, kan stå med en systembruger eller med den sagsbehandler, sagen er tildelt.
Flere kopier af samme dokument: samme fil kan være journaliseret på flere sager, og hver kopi kan have sin egen historik.
Konfiguration, der er ændret: logning af visninger kan være slået til eller fra undervejs.
Brugerflade og database er uenige: brugerfladen kan vise en afrundet eller omregnet dato, mens databasen har det præcise tidspunkt i UTC eller servertid. Brug databasens værdi i analysen, og forklar omregningen, når datoen præsenteres i rapporten.

Sikring før ændringer

Når en sag kan ende i en tvist eller en intern undersøgelse, bør auditspor og versioner sikres, før noget ryddes op, migreres eller arkiveres. Bed leverandøren om at bekræfte, at automatisk oprydning i auditsporet er sat i bero for den relevante periode, og notér systemets versionsindstillinger og logkonfiguration på sikringstidspunktet med skærmbilleder eller udtræk. Står et systemskift for døren, er det ofte nødvendigt at tage et fuldt databaseudtræk af det gamle system, fordi auditsporet ellers går tabt ved migreringen.

Hvad sporene kan og ikke kan bevise

Registreringstidspunkt og auditspor kan med god sikkerhed vise, hvornår et dokument kom ind i systemet, og hvornår metadata blev ændret, forudsat at serveruret var korrekt, og at sporet ikke kan redigeres af brugerne. De kan ikke alene vise, hvornår dokumentet blev skrevet, eller om det forelå i en anden form, før det blev journaliseret. Det kræver andre kilder, fx mail, filserver eller dokumentets egne metadata.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Audit trail i e-signaturløsninger

Del af: Analyse og fortolkning

Læs også: Audit trail i e-signaturløsninger · Hvem ændrede tallet? Ændringshistorik i Excel, Google Sheets og delte lister

→ Teknisk undersøgelse af dokumenter og metadata · For offentlige IT-afdelinger · 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