Helt tilbage i 2009 advokerede Artikel 29-gruppen bestående af EU’s dengang 28 datatilsyn (i dag Databeskyttelsesrådet) for at indføre et lovkrav om ”Privacy by Design” i forbindelse med en kommende revision af persondatadirektivet. De lagde bl.a. vægt på den teknologiske udvikling, som har øget risikoen for beskyttelsen af privatliv og personoplysninger, samt et deraf følgende behov for at gøre det lettere for brugere af teknologien at beskytte sine oplysninge, men også at sikre databeskyttelse gennem standardindstillinger.
GDPR blev vedtaget i 2016 og indeholder i artikel 25 et krav om ”Data Protection by Design og Default”. Man valgte bl.a. et andet begreb end ”Privacy by Design” for at signalere, at artikel 25 er udtryk for noget andet og mere end at overveje privatlivsbeskyttelse ved design af digitale løsninger – det er nu et lovkrav at tænke overholdelse af GDPR ind i designfasen og at kunne dokumentere efterlevelsen af (også) dette krav.
Artikel 25 gælder alene for dataansvarlige, men man finder i GDPR’s indledende betragtninger en opfordring til softwarevirksomheder (betragtning nr. 78):
”Når producenter af produkter, tjenester og applikationer udvikler, designer, udvælger og bruger applikationer, tjenester og produkter, der er baseret på behandling af personoplysninger eller behandler personoplysninger, for at udføre deres opgaver, bør de tilskyndes til at tage højde for retten til databeskyttelse i forbindelse med udvikling og design af sådanne produkter, tjenester og applikationer og til under behørig hensyntagen til det aktuelle tekniske niveau at sørge for, at de dataansvarlige og databehandlerne er i stand til at opfylde deres databeskyttelsesforpligtelser. Der bør også tages hensyn til principperne om databeskyttelse gennem design og databeskyttelse gennem standardindstillinger i forbindelse med offentlige udbud.”
Det danske datatilsyn har (modsat andre EU-landes tilsyn) i skrivende stund ikke udgivet en særskilt vejledning om emnet, men alene berørt det kortfattet i vejledningen om behandlingssikkerhed, hvor de bl.a. skriver:
”Begrebet ”databeskyttelse gennem design” er formuleret bredt. Det betyder, at du som dataansvarlig både forventes at tage højde for de tekniske indretninger (såsom it-systemer, infrastruktur og brugergrænseflader) og de forretningsgange, der præger din organisation. Der er med andre ord lagt op til, at du skal anlægge en helhedstænkning i forhold til organisationens samlede databehandlingsmiljø.
[…]
Bestemmelsen er formuleret med udgangspunkt i en risikobaseret og helhedsorienteret tilgang til databeskyttelse. Det betyder dels, at den dataansvarlige overlades en stor grad af fleksibilitet for både vurderingen af, hvordan vægtningen foretages, men også for, hvordan behandlingen rent faktisk understøttes i at overholde hele forordningen. Dette vil kunne være et valgt miks mellem de mulige tekniske og organisatoriske foranstaltninger.”
Alle, inkl. datatilsynene, har siden 2016 haft rigeligt at gøre med at sætte sig ind i de øvrige krav i forordningen, og det danske datatilsyn har i sin håndhævelse og særligt i bødesagerne fokuseret på de krav, som også var gældende før 2018, f.eks. slettepligten, krav til sikkerhed mv.
Siden 2017 har vi dog løbende set andre EU-lande komme med vejledninger om emnet, herunder det norske i 2017, det spanske i 2019 og det franske her i 2020. Alle disse tre vejledninger udmærker sig i øvrigt ved, at de er skrevet i samarbejde med folk fra den målgruppe, som i praksis skal gennemføre kravet, nemlig IT-folk og udviklere.
Sidst men ikke mindst så offentliggjorde Databeskyttelsesrådet (EDPB) i oktober 2020 den endelige udgave af deres vejledning om DPbDD. Dermed er vejen nu banet for, at de enkelte datatilsyn for alvor kan begynde at håndhæve reglerne.
Det er i øvrigt værd at bemærke, at den nye vejledning sætter barren meget højt. Hvor de enkelte nationale vejledninger på visse punkter har lagt en mere pragmatisk linje, er EDPB’s vejledning i en række henseender mere krævende. Et eksempel er, at EDPB indtager et noget andet standpunkt end det danske datatilsyn, og slår fast, at kravet også gælder for ældre legacy systemer:
“Existing legacy systems are under the same DPbDD-obligations as new systems. If legacy systems do not already comply with DPbDD, and changes cannot be made to comply with the obligations, then the legacy system simply does not meet GDPR-obligations and cannot be used to process personal data.”
Det skal for en god ordens skyld nævnes, at EDPB jo ikke afviser, at en økonomisk vurdering af omkostninger kan føre til en beslutning om at beholde det nuværende system (det fremgår da også direkte af artikel 25), men pointen er, at man ifølge EDPB skal kunne dokumentere denne overvejelse. Dette står i kontrast til den danske vejledning, der i stedet lod legacy systemer være underlagt de øvrige krav i GDPR herunder artikel 32:
“Forordningen kræver ikke, at ældre allerede eksisterende systemer skal re-designes […] Hvis det konstateres, at it-systemet ikke opfylder kravene i andre af forordningens bestemmelser – såsom artikel 32 om behandlingssikkerhed eller principperne for behandling af personoplysning i artikel 5 – vil dette kræve, at systemet ændres, eller at yderligere organisatoriske foranstaltninger gennemføres efter den 25. maj 2018.”
Eftersom de 27 EU-datatilsyn nu har tiltrådt den endelige vejledning fra EDPB, må det forventes, at flere af tilsynene begynder at håndhæve kravet. Vi har allerede set enkelte sager fra andre EU-lande, så mon ikke at også det danske datatilsyn kommer på banen.
Parallelt med denne udvikling er det også værd at fremhæve nogle tendenser uden for GDPR, som peger i samme retning:
For det første ser vi i disse år generelt et stigende fokus på cybersikkerhed – ikke kun fordi, det er et krav efter GDPR artikel 32, men fordi alle er enige om, at truslen bliver større og større, og dermed stiger den kommercielle risiko også. Som følge heraf har vi set en række myndigheder skærpe fokus på emnet, eksempelvis med hjemmesiden www.sikkerdigital.dk, som Digitaliseringsstyrelsen og Erhvervsstyrelsen står bag, men som en række andre myndigheder også har bidraget til, herunder Datatilsynet og Center for Cybersikkerhed. Der bliver her lagt stor vægt på vigtigheden af ”Leverandørstyring”, ligesom der foreslås en række spørgsmål, som man kan stille sin IT-leverandør, se her for myndigheder og her for virksomheder.
For det andet, og delvist overlappende med det forrige punkt, har vi særligt i 2020 set et skærpet interesse for at sikre, at den software, der ligger ”i skyen” og typisk leveres helt eller delvist af udenlandske leverandører, også lever op til EU’s krav, herunder kravene i GDPR. Denne tendens er nærmere beskrevet i et blogindlæg med overskriften: ”Er vi på vej mod en EU cloud?”
Databeskyttelse gennem design er en ny øvelse for de fleste og er relevant i mange forskellige sammenhænge. Det kan både være meget komplekst, f.eks. hvordan det offentlige kan udnytte AI under samtidig efterlevelse af GDPR, men det kan også være mere simpelt, f.eks. at slå nogle af de mange privatlivsfremmende funktioner i Office365 til.
Uanset hvad jeres udgangspunkt er, bør databeskyttelse integreres direkte i eksisterende processer, og DPbDD skal så vidt muligt understøttes via de systemer, organisationen i forvejen bruger. For at sikre DPbDD i praksis er det derfor også vigtigt at få ledelsens og organisationens opbakning til at prioritere databeskyttelse, f.eks. ved at formidle GDPR’s krav som en medspiller frem for en modspiller i den digitale transformation.
Og endelig – som med alt andet arbejde med GDPR, skal I også i arbejdet med DPbDD huske at tænke dokumentation af beslutninger og processer ind.
Har du spørgsmål til emnet eller brug for rådgivning, står vores GDPR-team altid klar til at yde kvalificeret rådgivning.
Jesper Løffler Nielsen
Entreprisekontrakter i nybyggeri – hvad skal du som bygherre være opmærksom på?
Nye og opdaterede regler om konkurskarantæne på vej
Ny dom fra Højesteret om 120-dages reglen