Skip to content

Privacy-by-Design i praksis: Gør det let at gøre det rigtige

Databeskyttelse gennem design og standardindstillinger er et af de centrale elementer i EU Persondataforordningen (GDPR), men der er stadig udbredt usikkerhed om, hvad det egentlig betyder.

Det er på sin vis forståeligt, fordi det er en anden måde at tænke på, et paradigmeskifte for vores databehandling, i forhold til tidligere. På den anden side vil det være yderst vanskeligt at arbejde med persondata og GDPR uden at forstå og implementere databeskyttelse gennem design.

EU sender klart signal

Hvad betyder databeskyttelse gennem design eller Privacy-by-Design, som det også kaldes?

Det betyder, at du fra starten har tænkt beskyttelse af persondata ind i dine processer og it-systemer. Det er ikke en eftertanke eller lappeløsning, men en faktor fra start. Konsekvensen er, at alle processer kommer til at indeholde beskyttelse af persondata som standard – databeskyttelse gennem standardindstillinger.

Det er ikke tilfældigt, at disse principper spiller en så fremtrædende rolle i GDPR. EU vil sende et klart signal om, at denne lovgivning ikke er nogen engangsforestilling. Kravet om beskyttelse af persondata er kommet for at blive, og virksomhederne bør forholde sig til den virkelighed.

Det er ikke klaret med at skrive en politik

Det er sjældent nok at udarbejde nogle retningslinjer, der skal sikre, at GDPR bliver overholdt. Retningslinjer skal implementeres for at have nogen effekt, og de udgør ofte en omvej for medarbejderen, der skal følge dem. Men hvad er chancerne for, at det kommer til at fungere efter hensigten i virkeligheden?

Lad os tage et lavpraktisk eksempel som CV’er sendt i forbindelse med jobansøgninger. Det er almindelig praksis, at de skal slettes efter seks måneder. Det kan man gøre på to måder:

  1. Udfærdige en politik, der instruerer medarbejderne i at slette alle CV’er ældre end seks måneder i deres mailsystemer, fildrev, harddisk, cloud, etc.
  2. Anvende et it-system, hvor alle CV’er automatisk bliver slettet efter seks måneder. Opbevaringen kan forlænges, hvis det er aftalt med kandidaten. Dette kan automatiseres, så man ikke spilder medarbejdernes tid med oprydning. 

Med metode 2 opnår man to afgørende fordele. For det første en høj grad af efterlevelse af GDPR ved at designe systemet til at håndhæve reglerne. For det andet en mere produktiv proces med et minimum af manuelt arbejde. Sletning af data bidrager ikke til virksomhedens bundlinje og bør derfor foretages så omkostningseffektivt som muligt.

Vores råd er derfor, at hvis dine processer er lange og snørklede, skal du ikke komplicere dem yderligere ved at tilføje krav om databeskyttelse. Du skal i stedet gentænke dine processer, således at de tager hensyn til beskyttelse af persondata – gennem design og standardindstillinger.

Lad teknologien gøre arbejdet

Vi møder stadig virksomheder, der spørger, om det overhovedet er nødvendigt at systemunderstøtte arbejdet med GDPR? Skal det absolut bygges ind i it-systemerne? Vores respons er: Hvad er alternativet? At gøre det manuelt? Det er både dyrt og usikkert at anvende manuelle processer til at sikre efterlevelse af GDPR.

Vi skal huske, at processerne med at leve op til GDPR ikke tilfører virksomheden nogen direkte værdi, men er en grundlæggende forudsætning for tillid. Derfor gælder det om at få udført arbejdet så hurtigt og effektivt som muligt. Det er, hvad vi har it-systemerne til.

Spørgsmålet er så, om virksomhedens eksisterende it-systemer kan løfte opgaven? Det vil nogle systemer kunne, mens andre vil være ganske uegnede. For eksempel vil nogle systemer mangle grundlæggende egenskaber som logning af adgang til data eller detaljeret styring af rettigheder.

Det vil derfor være fornuftigt at foretage en indledende kortlægning af it-systemernes parathed i forhold til at understøtte GDPR. Devoteam gennemførte for nylig en sådan analyse på et stort datacenter med 180 forskellige it-systemer, der alle indeholdt persondata. Resultatet var en kritisk, objektiv vurdering af systemerne på 27 parametre, som bliver grundlag for en risikovurdering og en handlingsplan.

Det er ikke sikkert, at det er nødvendigt at gå så detaljeret til værks, men brug listen herunder som inspiration:

Generelle systemegenskaber

Adgang og rettigheder

Styres adgang til system/data på rolle/rettighedsniveau?

Styring af privilegerede rettigheder

Er der særlig styring/logning på tildeling af privilegerede rettigheder?

Logning af tilgang til data

Logges hvem der tilgår hvilke persondata, hvornår?

Mulighed for sletning af records

Kan persondata (poster) slettes individuelt?

Mulighed for indsigtsanmodning

Kan man få at vide, hvilke persondata, der er registreret?

Mulighed for eksport af data

Kan man få sine persondata eksporteret i et alment anvendeligt format?

Mulighed for dataklassifikation

Er persondata klassificeret i systemet?

Mulighed for kobling til sletteregel

Er der indbyggede sletteregler i systemet?

Mulighed for automatisk sletning

Slettes data automatisk, når sletteregel er opfyldt?

Kryptering af data

Krypterer systemet data?

Applikationssikkerhed

Kontrolleres applikationskoden for sikkerhedsbrister?

Sikker håndtering af flytbare/eksterne medier

Er adgang til/brug af fysiske medier kontrolleret?

Sikker håndtering af uddata, print.

Er adgang til uddata kontrolleret?

Beskyttelse mod datatab/lækage

Er der sikkerhedssystemer, der overvåger læk af data mod eksterne parter?

Infrastruktur systemegenskaber

Perimetersikkerhed

Er der sikkerhedssystemer, der skal forhindre/logge eksterne indbrudsforsøg?

Net-trafikovervågning

Er der sikkerhedssystemer, der overvåger trafik på de forskellige netværk?

Beskyttelse mod datatab/lækage

Er der sikkerhedssystemer, der overvåger læk af data mod eksterne parter?

Datadeling- og udveksling

Anvendes VPN-tuneller, sFTP o.lign ved udveksling af data med eksterne parter?

Sikker e-mail

Findes og bruges sikker e-mail?

Sikker fjernadgang

Er fjernadgang sikret med kryptering/flerfaktor authenticering o.lign?

Krypteret trafik

Krypteres trafik mellem netværk/systemer?

Data at rest/data storage

Kryptering

Krypteres persondata på storage medier?

Anonymisering, pseudonymisering

Anonymiseres eller pseudonymiseres persondata?

Beskyttelse af mobile enheder

Er persondata beskyttet mod tyveri på mobile enheder?

Beskyttelse af shares på netværk og servere

Er persondata på netværksshares beskyttet med adgangskontrol/kryptering?

Sikker håndtering af fysiske medier

Er adgang til fysiske medier kontrolleret?

Arkivering, sletning og kassation

Ødelægges medier, der ikke længere bruges?

 

It-systemernes parathed kan derefter defineres ud fra følgende fire niveauer:

  1. Systemet leverer tilfredsstillende understøttelse af de definerede krav til Privacy-by-Design.
  2. Der er funktioner, systemet ikke udfører i dag, men vi kan foretage de nødvendige ændringer.
  3. Der er funktioner, systemet ikke udfører i dag, og vi kan ikke umiddelbart gøre noget ved det. Vi skal vurdere, om det er rentabelt, eller om en alternativ løsning ville være bedre. Mindre egnet til efterlevelse af GDPR.
  4. Systemet vil ikke på noget tidspunkt være i stand til at levere tilfredsstillende understøttelse. Uegnet til efterlevelse af GDPR.

Når først paratheden er fastlagt, kan virksomheden fokusere på manglerne. Den største udfordring er naturligvis niveau 4, som sikkert vil forekomme. Tag for eksempel fildrev, som bliver brugt i rigtig mange virksomheder i dag. Det bliver aldrig en god teknologi til at beskytte persondata. Det er svært at styre adgang og sletteregler, der mangler metadata, og det er mere end vanskeligt at overskue, hvem der har tilgået et dokument, hvornår. Det er ikke umuligt, men det er en stor opgave.

Her er løsningen at ofte skifte til et andet system, der opfylder det samme behov hos virksomheden og samtidig understøtter efterlevelse af GDPR. Et sådant system er ikke svært at finde. Det kan for eksempel være Microsoft SharePoint eller et af flere dokumentstyringssystemer på markedet.

En anden mulighed med besværlige systemer er at bruge RPA (Robotic Process Automation). Det er en softwarerobot, som efterligner manuel opgaveløsning i it-systemer, som for eksempel fildrev. De mange og besværlige klik til at sikre efterlevelse bliver nu varetaget af en robot. Devoteam har flere kunder, herunder det førnævnte datacenter, som har valgt at bygge egne robotter.

Gør det let at gøre det rigtige

Det var it-systemernes parathed, men hvad med den anden part, medarbejderne? Systemer kan ikke stå alene, de skal stadig betjenes af medarbejdere, og i mange tilfælde er de nødt til at ændre adfærd.

Men it-systemerne kan hjælpe ved at gøre det nemmest muligt for medarbejderen. Adfærdsforskning – og vores egne erfaringer – viser, at den mest afgørende faktor i at ændre menneskers adfærd, er lethed. Den hurtigste, nemmeste løsning. Det er langt vigtigere som motivation, end at det er det rigtige eller rationelle at gøre i den konkrete situation. 

Hvis en medarbejder for eksempel skal klikke 12 gange for at få systemet til at gøre det rigtige, så finder vedkommende ofte en kortere vej. Medarbejderen vil opfatte det som en forhindring, og der er en overhængende risiko for, at adfærden ikke ændres, som ønsket.

Løsningen bør være at fjerne kompleksiteten og gøre det let og naturligt for medarbejderen. Det lader sig bedst gøre, hvis systemet i forvejen er indrettet til at håndtere beskyttelse af persondata. Altså databeskyttelse gennem design. Lad den korteste vej være den rigtige – og gør det let.

Fakta: Privacy-by-Design er langt fra nyt

De fleste forbinder i dag Privacy-by-Design med EU’s nye persondataforordning, men princippet har en betydelig længere historie, og det meste af den foregår uden for Europa. Privacy blev første gang formuleret tilbage i 1890 i amerikanske Harvard Law Review som ”the right to be left alone.”

Den gang handlede det ikke på samme måde om data og processer, men stadig de samme grundlæggende principper: Ligesom borgeren har ret til eje, har borgeren også ret til en privatsfære, hvor virksomheder og regeringer ikke har adgang.

Digital privacy blev for alvor kendt i 1980’erne, hvor digitaliseringen for alvor startede og OECD formulerede de grundlæggende principper for privacy, som GDPR nu bygger på. Privacy-by-Design blev for første gang beskrevet i 1990 og er sidenhen dokumenteret i detaljer. Hvis begrebet er nyt for os i Danmark, er det blot, fordi vi er kommet meget sent i gang.

Vil du vide mere? 

Så er du velkommen til at kontakte Frederik.

Vi stiller gerne op til faglige indlæg og individuelle møder om emnet.