Bevaringsplan for et IT‑projekt i krise

Forside · Gennemgået oktober 2026 · Af John Nielsen

Når et IT-projekt går i stå, og parterne begynder at tale om ophævelse eller erstatning, er det bedste tidspunkt at sikre projektets data allerede passeret. Det næstbedste er nu. En bevaringsplan er en kort, konkret liste over projektets systemer, hvem der ejer dem, hvad der skal sikres, og hvornår data forsvinder af sig selv. Den skal laves, mens begge parter stadig har adgang, og den skal kunne gennemføres uden at stoppe det arbejde, der stadig foregår.

Den ledelsesmæssige side, fx hvordan man dokumenterer en leverandør, der ikke leverer, er beskrevet på bevissikring-digitalt.dk. Denne artikel er den tekniske plan, skrevet til projektledere, udviklingshuse og de IT-folk, der skal udføre den.

Hvorfor en plan og ikke bare en backup

En backup af en database eller et repository bevarer indhold. Den bevarer ikke nødvendigvis historik, auditlog, rettigheder eller sammenhængen mellem systemerne. I en projekttvist er det netop historikken, der skal bruges: hvem ændrede kravet, hvornår blev fejlen omklassificeret, hvilken version var installeret på testmiljøet ved overdragelsen. En plan sikrer, at hvert system sikres med en metode, der bevarer det, sagen sandsynligvis kommer til at handle om.

Trin 1: Kortlæg systemerne

Lav en tabel med én linje pr. system. For hvert system noteres ejer (hvilken part har kontoen), administrator, hvor data ligger, og hvordan adgangen kan ophøre.

Ticketsystem (fx Jira, Azure Boards) · Fejl, prioritering, accepttest, ændringsønsker
Wiki og kravdokumenter · Kravændringer og godkendelser
Git-platform · Hvad der blev leveret og hvornår
CI/CD og testresultater · Om det virkede
Miljøer (test, staging, produktion) · Tilstand ved overdragelse
Timeregistrering · Forbrug og fakturagrundlag
Mail, Teams, Slack · Aftaler, forbehold og varsler
Mødereferater og styregruppemateriale · Beslutninger og eskalering

Glem ikke systemer uden for de to hovedparter: en underleverandørs repository, en konsulents private Jira-instans eller en kundes SharePoint, hvor leverancerne blev uploadet.

Trin 2: Find det, der forsvinder først

Prioritér efter, hvornår data forsvinder, ikke efter, hvor vigtige de virker. Typiske tidsbegrænsninger:

Auditlogs på SaaS-platforme har ofte begrænset opbevaring. GitHubs organisationsauditlog dækker fx de seneste 180 dage på tidspunktet for gennemgangen (oktober 2026). Andre platforme har andre grænser, og de afhænger ofte af licensniveau.
CI/CD-artefakter og logs slettes ofte automatisk efter en fast periode for at spare plads.
Testmiljøer bliver nulstillet, genbrugt eller lukket, når kontrakten ophører.
Konti lukkes, når en part opsiger aftalen eller fjerner den anden parts adgang.
Abonnementer på værktøjer betalt af den ene part kan udløbe.

Det, der har kortest levetid, sikres først. Det er sjældent kildekoden, som de fleste har flere kopier af.

Trin 3: Vælg sikringsmetoden pr. system

Brug metoder, der bevarer historik og metadata:

Ticketsystem: fuld eksport med ændringshistorik pr. sag, plus systemets auditlog. En CSV-eksport af den aktuelle visning er ikke nok. Se ticketsystemer og ændringshistorik.
Wiki: eksport af området med sidehistorik og vedhæftede filer. Se wiki og kravdokumenter.
Git: en komplet klon med alle grene og tags, fx som git bundle, plus platformens auditlog over adgang, kloning og tokens. Se auditlogs på Git-platforme.
CI/CD: byggelogs, testrapporter og artefakter for de builds, der blev leveret eller testet. Se CI/CD-logs og testdokumentation.
Miljøer: snapshots eller images af test- og stagingmiljøer, databaseudtræk og konfiguration. Se leverancens tilstand på overdragelsestidspunktet.
Timeregistrering: udtræk med registreringstidspunkt og eventuelle rettelser, ikke kun de godkendte timer.
Mail og chat: eDiscovery-eksport eller tilsvarende, med de relevante personer og perioden fra kontraktindgåelse.

Trin 4: Aftal adgang og fastfrysning

Mange projektsystemer ejes af den ene part, og den anden part har kun brugeradgang. Det er en god idé at aftale skriftligt, at begge parter bevarer data, og at ingen af parterne sletter, omdøber eller lukker konti, repositories eller miljøer, før sikringen er gennemført. Hvis der ikke kan opnås enighed, kan advokaten overveje juridiske skridt, men den tekniske plan bør være klar, så den kan bruges straks.

Fastfrysning behøver ikke betyde, at arbejdet stopper. Det kan være nok at tage et øjebliksbillede af hvert system på en aftalt dato, og derefter lade udviklingen fortsætte på en ny gren eller i et nyt miljø. Så er der en klar grænse mellem projektet, som det så ud, da striden opstod, og det arbejde, der kom bagefter.

Trin 5: Dokumentér hver sikring

Hver eksport skal kunne efterprøves af den anden part eller en skønsmand. Notér for hver:

System, instans og den konto, der foretog eksporten.
Tidspunkt med tidszone.
Metode og værktøj, inklusive version.
Filnavne, størrelser og hashværdier i et manifest.
Afgrænsninger, fx at vedhæftede filer over en vis størrelse ikke kom med, eller at en bestemt rolle ikke kunne se alle sager.

Gem manifestet adskilt fra eksporterne, og send en kopi til den anden part, hvis det er aftalt. Så kan begge parter senere kontrollere, at de taler om de samme data.

Trin 6: Sammenhængen mellem kilderne

I selve tvisten bliver kilderne holdt op mod hinanden: en fejlrapport i ticketsystemet, en commit, der påstår at rette den, en testkørsel, der bestod eller fejlede, og timer registreret på opgaven. Det kræver, at id’er og tidspunkter kan kobles. Sørg derfor for, at eksporterne indeholder de felter, der forbinder systemerne: ticket-nøgler i commit-beskeder, build-numre i testrapporter og opgave-id i timeregistreringen. Metoden er beskrevet i krydsvalidering af timer, commits og tickets.

Fortrolighed og persondata

Projektdata indeholder ofte mere end projektet. Testmiljøer kan rumme kopier af produktionsdata med kundeoplysninger, repositories kan indeholde adgangsnøgler, og mailudtræk rummer private beskeder. Planen bør derfor angive, hvor eksporterne opbevares, hvem der har adgang, og om de er krypteret. Adgangsnøgler, der findes i kode eller konfiguration, sikres som de er, men bør roteres i drift bagefter, så kopien ikke giver adgang til levende systemer. Hvis den ene parts forretningshemmeligheder indgår, kan det være nødvendigt at aftale, at en uvildig opbevarer kopien, og at den anden part kun får adgang til udvalgte dele. Det er lettere at aftale, før striden er spidset til.

Typiske fejl

Kun den aktuelle tilstand sikres, ikke historikken.
Sikringen foretages med en konto, der ikke kan se alt, uden at det noteres.
Eksporter gemmes på et delt drev, hvor de kan ændres.
Miljøer genbruges til ny test, før de er sikret.
Ingen holder styr på, hvornår auditlogs løber ud.

Hvem gør det

Projektets egne udviklere kender systemerne bedst og kan ofte gennemføre mange af eksporterne. Det giver dog en svaghed, hvis de selv er part i uenigheden om, hvad der blev leveret. Et kompromis er, at en uvildig sagkyndig lægger planen, overvåger eller udfører sikringen af de omstridte systemer og hasher resultatet, mens udviklerne hjælper med adgang og forklaring. Nielco IT påtager sig den rolle og kan ved større projekter tilknytte konsulenter i eget regi.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Konkursboets IT: teknisk overtagelse af tenant og domæner · Fejllister og fejlklassifikation i en projekttvist

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-projekter i tvist · 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