At gemme data for evigt er en belastning. Lovene om privatliv kræver, at du sletter data, når du ikke længere har brug for dem. Dette kapitel handler om regler for opbevaring (hvor længe du gemmer data) og om sletning (hvordan du håndterer brugernes anmodninger om sletning og rydder op i systemerne).
Hvorfor regler for opbevaring er vigtige
Et lovkrav
GDPR og lignende love kræver regler for opbevaring af data. Du skal slette data, når du har nået det formål, du har angivet. At gemme data for evigt, bare for en sikkerheds skyld, strider mod princippet om at samle så få data som muligt og kan give bøder.
Fordele i driften
Ældre data er mindre nyttige. En hændelse fra for 2 år siden påvirker sjældent de beslutninger, du tager nu. Når du sletter gamle data, bliver lagerpladsen billigere, sikkerhedskopierne enklere, og du udsætter mindre, hvis der sker et brud (der er færre data at afsløre).
Brugernes forventninger
Brugerne forventer, at du sletter deres data, når de ikke længere er nødvendige. En app til huskelister i skyen bør slette dine opgaver, når du lukker din konto, og ikke gemme dem for evigt. Klare regler for sletning skaber tillid.
Sådan laver du regler for opbevaring
Hvilke data? Hvor længe?
Forskellige typer data har forskellige behov for opbevaring:
Hændelser i analytics: 12 måneder er normalt. Efter et år bliver gamle hændelser sjældent analyseret. Har du brug for længere, er 24 måneder rimeligt. Gem dem ikke for evigt.
Data om kundekonti: Gem dem, så længe kontoen er aktiv. Slet dem 90 dage efter, at kontoen er lukket (så der er tid til at fortryde). Gem dem ikke for evigt.
Supporthenvendelser: Gem dem i 2-3 år (forældelsesfristen for tvister). Slet dem derefter.
Regnskabsdata: Gem dem i 7 år (krav fra skat og lovgivning). Slet dem derefter.
Lister til markedsføring: Gem dem, så længe kunden står på listen. Slet dem 30 dage efter afmelding.
Længere opbevaring i særlige tilfælde
Nogle data kan have brug for længere opbevaring: svindelopdagelse (gem som revisionsspor), juridiske tvister (gem, til sagen er afgjort) og krav fra myndighederne (varierer fra branche til branche). Det er undtagelser. Udgangspunktet bør være: slet, så snart data ikke længere er nyttige.
Skriv reglerne ned
Skriv dine regler for opbevaring ned: hvilke typer data, hvor længe du gemmer hver af dem, og hvilket juridisk grundlag du har. Gør dem tilgængelige for brugerne i din privatlivspolitik. "Vi gemmer dine data i X måneder og sletter dem derefter." Åbenhed skaber tillid.
Indfør automatisk sletning
Planlagte sletninger
Sæt automatiske opgaver op, der kører efter en plan (hver måned eller hvert kvartal) og sletter data, der er ældre end opbevaringsfristen. Eksempel: en opgave, der sletter alle hændelser i analytics, som er ældre end 12 måneder. Lad den køre automatisk, så sletningen ikke er manuel eller bliver glemt.
Sletning udløst af en hændelse
Nogle sletninger udløses af en hændelse: når en bruger lukker sin konto, så slet brugerens data. Når en bruger afmelder sig, så slet e-mailadressen. Sæt automatiske forløb op, der sletter, når bestemte hændelser sker.
Log sletninger
Log, når data bliver slettet (hvilke data, hvornår og hvorfor). Så har du et revisionsspor. Hvis myndighederne spørger, hvorfor visse data mangler, kan du vise, at de er slettet efter reglerne og ikke skjult.
Sådan håndterer du brugernes anmodninger om sletning
Retten til at blive glemt
GDPR giver enkeltpersoner "retten til at blive glemt". Brugere kan bede om at få deres persondata slettet. Du har 30 dage til at følge anmodningen (med undtagelser for juridiske forpligtelser). Det betyder, at du skal kunne slette en brugers data, når de beder om det.
Indfør forløb for sletning
Trin 1: Modtag anmodningen. Brugeren sender en anmodning om sletning via en supportformular eller indstillingerne for kontoen.
Trin 2: Bekræft identiteten. Tjek, at anmodningen kommer fra kontoens ejer (og ikke er falsk).
Trin 3: Find data. Find alle data, der hører til brugeren: konto, hændelser i analytics, supporthenvendelser, e-maillister og sikkerhedskopier.
Trin 4: Slet. Fjern dem fra de live systemer og fra sikkerhedskopier. Bekræft sletningen skriftligt over for brugeren.
Trin 5: Log. Skriv sletningen ned: hvem der bad om den, hvornår, og hvad der blev slettet.
Undtagelser fra sletning
Du behøver ikke slette, hvis du har en juridisk pligt til at gemme data (regnskab og skat, retskendelser), hvis du har brug for dem til et angivet formål, der stadig opfyldes, eller hvis brugeren har givet samtykke til videre behandling efter anmodningen om sletning. Men det er undtagelser. Udgangspunktet er at slette, når nogen beder om det.
Udfordringer i praksis
Data, der er spredt ud
Brugerens data ligger ofte i flere systemer: den live database, sikkerhedskopier, tjenester fra tredjeparter (leverandører af analytics og e-mail) og medarbejdernes bærbare computere. Det er svært at finde alle data, der skal slettes. Løsning: hold en oversigt over data. Vid, hvor brugernes data ligger. Skriv krav om sletning ind i aftalerne med leverandører.
Opbevaring af sikkerhedskopier
Sikkerhedskopier indeholder brugerdata, også efter at de er slettet fra de live systemer. Hvor længe gemmer du sikkerhedskopier? Du kan sandsynligvis ikke dagligt genskabe fra 3 år gamle sikkerhedskopier, men juridiske krav kan betyde, at du skal gemme dem. Gør det klart: sikkerhedskopier kan gemmes længere end live data, men de skal også slettes en dag.
Anonymiserede data
Rigtigt anonymiserede data er ikke omfattet af retten til sletning (de er ikke persondata). Men de fleste "anonymiserede" data er i virkeligheden samlede eller pseudonymiserede (kan føres tilbage). Kan du genkende personen igen, er det persondata, og de skal slettes efter anmodning. Forstå, hvad du faktisk gemmer.
Privacy by Design: sletning i opbygningen
Byg systemer med sletning i tankerne fra start. Brug datastrukturer, der gør sletning effektiv. Bland ikke typer af data, der har forskellige behov for opbevaring. Gør det nemt at finde og slette en brugers data. Når du bygger evnen til at slette ind fra start, bliver det lettere at følge reglerne senere.
Hvor længe er det realistisk at gemme analysedata i forskellige typer virksomheder?
Blog eller indhold: 12 måneder er nok (næsten ingen brug for gamle data). SaaS: 24 måneder (du skal kunne analysere udviklingen). Webshop: 24-36 måneder (analyse af sæsoner og svindelopdagelse). Finans og sundhed: følg reglerne (ofte over 6 år). Gennemgå dine rapporter fra de seneste 6 måneder: hvis du ikke har analyseret data, der er ældre end X måneder, så slet alt ud over det. Ret indstillingerne i dit analyseværktøj, så de sletter automatisk.
Hvordan svarer jeg præcist på en anmodning om sletning inden for lovens frist?
Dag 1: modtag anmodningen, bekræft identiteten og log den i dit system til anmodninger. Dag 2-7: find alle data i alle systemer (database, sikkerhedskopier og tjenester fra tredjeparter). Dag 8-20: slet og tjek sletningen i logs. Dag 28: send brugeren en bekræftelse med, hvad der er slettet. Skriv alt ned. 30 dage er en streng frist, så det er afgørende at gå i gang med det samme.
[wemasy-accordion type="primary" wemasy-accordion title="Hvordan ved jeg, om mine "anonymiserede" data virkelig er anonymiserede eller stadig persondata?"]<p>Ægte anonymisering: det er umuligt at genkende personen (kun samlede tal, som "50 % af brugerne klikkede på knappen"). Pseudonymisering: kan føres tilbage med en nøgle (hashet bruger-id, stadig persondata). Sikker tommelfingerregel: hvis du har en nøgle til opslag eller kan krydstjekke med andre data, er det persondata, og de skal slettes efter anmodning. Er du i tvivl, så behandl det som persondata.</p>[/wemasy-accordion]
Hvor længe skal jeg gemme sikkerhedskopier, og hvordan håndterer jeg anmodninger om sletning i dem?
Sletning af live data: med det samme. Sikkerhedskopier på 0-30 dage: slet fra alle kopier. Sikkerhedskopier på 30-90 dage: kan gemmes, hvis du ikke bruger dem til daglig drift. Sikkerhedskopier på over 90 dage: skal slettes en dag efter GDPR (ingen opbevaring for evigt). Lav en plan for sletning af sikkerhedskopier: gennemgå hvert kvartal og slet sikkerhedskopier, der er ældre end fristen i dine regler. Skriv bekræftelse af sletning ind i dit svar til brugeren.
Hvordan ser et forløb for sletning ud trin for trin, når data er spredt over analytics, e-mail, CRM og værktøjer fra leverandører?
Trin 1: et dokument med en oversigt over data viser, hvor brugerens data ligger (database, GA, e-mailværktøj, CRM og så videre). Trin 2: en automatisk opgave sletter i den primære database. Trin 3: sletning i hånden eller via API i værktøjer fra tredjeparter. Trin 4: aftaler med leverandører kræver bekræftelse af sletning (SLA: 7 dage). Trin 5: saml bekræftelserne og send dem til brugeren inden for 30 dage i alt.
[wemasy-accordion type="primary" wemasy-accordion title="Hvad er forskellen på "forsinkelse i driften" og et brud på fristen på 30 dage?"]<p>Acceptabel forsinkelse: du finder data et uventet sted, eller der er rigtige tekniske problemer (højst 8-10 dage). Uacceptabelt: "Vi tager det en dag", at vente på den månedlige kørsel af en opgave eller forsinkelser i genskabelse af data ud over 15 dage. De 30 dage gælder dit svar og din forklaring og ikke tiden til at gennemføre det. Kan du ikke slette inden for 30 dage, er det et brud. Fortæl om forsinkelser med det samme og skriv ned, hvorfor.</p>[/wemasy-accordion]