Et datakort er en enkel oversigt over, hvor sagens data ligger: hvilke systemer, konti og enheder der er relevante, hvem der ejer og administrerer dem, og hvornår data slettes. Det udfyldes i eller lige efter det første møde og bruges derefter til at prioritere sikringen, skrive bevarelsesmeddelelser og formulere editionsbegæringer. Skabelonen er et teknisk udgangspunkt, ikke juridisk rådgivning, og skal tilpasses sagen af advokaten.
Spørgsmålene til selve mødet står i Tjekliste til det første møde med klienten. Datakortet er stedet, hvor svarene samles.
Sådan bruger du skabelonen
- Udfyld det, klienten ved. Resten markeres “ukendt” med en ansvarlig for at finde svaret.
- Én række pr. datakilde. En postkasse, en telefon, et CRM-system. Ikke “IT generelt”.
- Sortér efter slettefrist. Kilden med den korteste frist sikres først.
- Opdater kortet. Når noget er sikret, skrives dato, metode og hvem. Kortet bliver dermed også en log.
Skabelonen
Del 1: Sagen kort
Sag: [kort beskrivelse]
Relevant periode: fra [dato] til [dato]
Nøglepersoner: [navne og roller, hos klienten og modparten]
IT-ansvarlig hos klienten: [navn, intern eller leverandør, kontakt]
Udfyldt af og dato: [navn], [dato]
Del 2: Datakilder
- Datakilde · [fx “Postkasse for sælger A”]
- Type · [mail/fil/chat/telefon/computer/forretningssystem/log/cloud/fysisk medie]
- System eller udbyder · [Microsoft 365/Google Workspace/Salesforce/iPhone/andet]
- Konto eller enhed · [mailadresse, brugernavn, model og serienummer]
- Ejer · [hvem ejer data: klienten, medarbejderen, en leverandør, modparten]
- Administrator · [hvem kan ændre eller slette]
- Hvad kan den vise? · [fx “kontakt til kunder efter fratrædelse”]
- Slettefrist · [automatisk sletning efter x dage/abonnement udløber [dato]/ukendt]
- Status · [i brug/taget ud af brug/nulstillet/lukket/sikret]
- Ændret efter hændelsen? · [nej/ja: hvad, hvornår, af hvem]
- Prioritet · [høj/mellem/lav]
- Næste skridt · [fx “eksport af revisionslog”, “bevarelsesmeddelelse til leverandør”]
- Ansvarlig og frist · [navn, dato]
- Sikret · [dato, metode, af hvem, hashværdi]
Del 3: Data hos andre
- Modparten · Hvad de formentlig har: [mails, chats, systemlogs] · Identifikator: [domæne, konti] · Kendt slettefrist: [ukendt] · Skridt: [bevarelsesmeddelelse/opfordring/edition]
- IT-leverandør · Hvad de formentlig har: [backup, logs] · Identifikator: [kundenr.] · Kendt slettefrist: [x dage] · Skridt: [henvendelse om bevarelse]
- Teleselskab, bank, platform · Hvad de formentlig har: [opkaldsdata, posteringer, kontodata] · Identifikator: [nummer, konto, id] · Kendt slettefrist: [ukendt] · Skridt: [tredjemandsedition]
Del 4: Hvad der ikke må ske
Skriv tre til fem punkter, som klienten får skriftligt efter mødet, fx:
- [Computeren for medarbejder A] må ikke tændes, bruges eller nulstilles.
- [Postkassen for A] må ikke slettes eller konverteres.
- Automatisk sletning i [system] sættes i bero.
- Ingen søger selv i [enhed eller postkasse].
Kategorier, der ofte glemmes
- Revisionslog · Microsoft 365, Google Workspace, forretningssystemer. Har ofte kort opbevaringstid.
- Mobil enhedsstyring · Intune, Jamf og lignende. Kan vise fjernsletning og enhedsstatus.
- Telefonsystem · Opkaldslister i omstillingsanlæg eller Teams-telefoni.
- Adgangskontrol · Nøglebrikker og alarmer. Se Adgangskontrol og nøglebrikker.
- Videoovervågning · Overskrives ofte efter få dage.
- Backup · Hvem har den, og hvor langt tilbage rækker den?
- Private konti brugt til arbejde · Privat mail, privat telefon, private cloudkonti. Ejes ikke af klienten.
Eksempel på en udfyldt række
Eksemplet er konstrueret og viser kun, hvordan felterne kan udfyldes.
- Datakilde: Firmatelefon for sælger A.
- Type og system: Telefon, iPhone, administreret via virksomhedens MDM.
- Ejer og administrator: Virksomheden ejer telefonen. IT-leverandøren administrerer MDM.
- Hvad kan den vise? Beskeder og opkald til kunder i ugerne før fratrædelsen.
- Slettefrist: Ukendt. MDM kan være sat til at nulstille enheder ved fratrædelse.
- Status: Afleveret, slukket, ligger hos kontorchefen.
- Ændret efter hændelsen? Ja: A har selv slettet sin private konto på telefonen ved afleveringen.
- Prioritet: Høj.
- Næste skridt: IT-leverandøren bekræfter skriftligt, at der ikke sendes en nulstilling. Telefonen sikres.
- Ansvarlig og frist: [navn], i morgen.
Eksemplet viser, hvorfor “ukendt” er et vigtigt svar. Det udløser et konkret skridt i stedet for en antagelse.
Spørgsmål, der fylder kortet ud
Klienter tænker sjældent i datakilder. De tænker i personer og hændelser. Disse spørgsmål oversætter det ene til det andet:
- Hvem var involveret, og hvilke enheder og konti brugte de i perioden?
- Hvordan kommunikerede parterne: mail, telefon, chat, møder med referat?
- Hvilke systemer registrerer det, sagen handler om, fx ordrer, leverancer, adgang eller betalinger?
- Hvem kan logge ind som administrator i de systemer, og er det klienten selv eller en leverandør?
- Er der skiftet system, telefon eller leverandør siden hændelsen?
- Er nogen af de involverede stoppet, og hvad skete der med deres konti og udstyr?
Hvert svar bliver til en eller flere rækker i del 2 eller del 3.
Spørg også den IT-ansvarlige, ikke kun ledelsen. Ledelsen ved typisk, hvilke systemer der bruges. Den IT-ansvarlige ved, hvilke logs der er slået til, hvor længe de gemmes, og hvilke automatiske regler der kan slette eller nulstille noget. Det er ofte de oplysninger, der afgør prioriteringen, og de kan sjældent fås fra andre i virksomheden.
Varianter efter sagstype
- Ansættelse og fratrædelse · Postkasse, cloudkonto, firmatelefon, computer og revisionslog for den fratrådte. Se Tjekliste: konkurrenceklausulsag.
- IT-leverance · Ticketsystem, kodedepot, testmiljø, driftslogs og mails mellem projektdeltagere. Se Tjekliste: IT-leverancesag.
- Konkursbo · Alle konti, abonnementer, regnskab og enheder med fokus på slettefrister. Se Tjekliste: kuratorens første uge.
- Familiesag · Klientens telefon, delte konti og familiedeling. Ejer og lovlig adgang skal stå tydeligt. Se Tjekliste: familiesag.
Hvad datakortet ikke viser
Datakortet er et kort over, hvor data formentlig findes. Det er ikke en bekræftelse af, at de findes, eller at de indeholder det, klienten forventer. En række kan pege på en postkasse, der viser sig at være tømt, eller en log, der ikke var slået til. Derfor står feltet “Sikret” for sig, og en kilde er først sikret, når den er hentet og kontrolleret. Kontrollen kan være enkel: Indeholder eksporten den forventede periode, og svarer antallet af elementer nogenlunde til det, kilden viser?
Kortet viser heller ikke, om data må bruges. Om klienten lovligt kan få adgang til en kilde, fx en medarbejders private konto, er en juridisk vurdering, der skal ske, før der handles på rækken.
Sådan bruges datakortet bagefter
- Til bevarelse: Rækkerne med “Data hos andre” er grundlaget for en meddelelse om bevarelse af data.
- Til edition: Identifikatorer og typer kan genbruges i en editionsbegæring eller en begæring om edition fra tredjemand.
- Til den IT-sagkyndige: Kortet giver den sagkyndige overblik på få minutter og kan vedlægges opdraget.
- Til prioritering: Er en kilde markeret “høj” og “ukendt slettefrist”, bør den behandles, som om fristen er kort. Se Beslutningstræ: skal data sikres nu, eller kan det vente?
Typiske fejl
- “Mail” som én kilde. Hver postkasse er sin egen kilde med egen ejer og egne frister.
- Ejer og administrator forveksles. Klienten ejer måske data, men leverandøren kan slette dem.
- Slettefrister gættes. Notér “ukendt” og find svaret frem for at skrive et skøn.
- Kortet udfyldes én gang. Det mister værdi, hvis sikringer og ændringer ikke skrives ind.
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
