Privacy by design
Også kendt som: databeskyttelse gennem design og standardindstillinger
GDPR-princippet om, at beskyttelse af personoplysninger skal bygges ind i systemer fra starten.
Kladde - dette opslag er endnu ikke gennemgået.
Formelt
Pligten i GDPR artikel 25 til at bygge databeskyttelse ind i systemer og processer, allerede mens de designes - fx ved at indsamle mindre og skjule identiteter - og til at gøre den mest privatlivsvenlige indstilling til standard.
Forklaret enkelt
At tegne gardiner ind i planerne til et nyt hus i stedet for at tape aviser for vinduerne, når man er flyttet ind.
I praksis
Udviklerne, der bygger en dansk kommunes bookingformular til idrætshaller, fjerner feltet til CPR-nummer, som opgaven ikke kræver, og lader feltet til nyhedsbrev være fravalgt som standard.
Hvorfor det betyder noget
Data, der aldrig indsamles, kan ikke lække, og at rette op på privatlivet efter lancering koster langt mere end at planlægge det ind; det gør også systemet lettere at forsvare, når Datatilsynet spørger.
Sådan kommer du i gang
De typiske trin i rækkefølge. Tilpas dem til jeres organisation.
- Lad produktejeren ved starten af hvert nyt system eller hver ny proces opliste formålene og de personoplysninger, hvert formål reelt kræver, og fjern alle felter uden et angivet formål.
- Vurdér risikoen for de personer, hvis data I behandler, og lav en konsekvensanalyse efter GDPR artikel 35, når behandlingen sandsynligvis indebærer en høj risiko.
- Vælg foranstaltninger, der passer til risikoen og det aktuelle tekniske niveau, fx pseudonymisering, kryptering, rollebaseret adgang afgrænset til formålet og aggregerede data til analyse.
- Sæt privatlivsvenlige standardindstillinger (artikel 25, stk. 2) - frivillige felter og tracking slået fra, til brugeren vælger dem til, profiler private og ingen data gjort tilgængelige for et ubegrænset antal personer.
- Byg opbevaringsperioden ind i systemet som automatisk sletning eller TTL ud fra jeres slettefrister i stedet for at stole på en politiktekst.
- Skriv kravene til databeskyttelse ind i kontrakterne med leverandørerne, og vælg værktøjer, der gør det muligt at opfylde dem, for ansvaret bliver hos jer som dataansvarlig.
- Test før lancering, at foranstaltningerne virker, fx at slettede data faktisk er væk, og at standardindstillingerne er som designet, og dokumentér valgene, så I kan vise dem til Datatilsynet.
- Gennemgå designet, når formålet, data eller teknologien ændrer sig, og med faste mellemrum, for det aktuelle tekniske niveau flytter sig.
Typiske faldgruber
- At indsamle data, fordi de måske kan bruges senere, hvilket bryder med dataminimering og øger det, et brud kan afsløre.
- At regne et velsikret system for at overholde reglerne om databeskyttelse, selv om det godt kan være velbeskyttet og alligevel indsamle langt flere personoplysninger end nødvendigt.
- At lave konsekvensanalysen, efter systemet er bygget, når designvalgene ikke længere kan ændres billigt.
- At forudafkrydse samtykkefelter eller gøre deling til standard, hvilket strider mod databeskyttelse gennem standardindstillinger.
Gode vejledninger
- Databeskyttelse gennem design og standardindstillinger(åbner i en ny fane) · Datatilsynet
- Indbygget databeskyttelse (privacy by design)(åbner i en ny fane) · Styrelsen for Samfundssikkerhed
- Guidelines 4/2019 on Article 25 Data Protection by Design and by Default(åbner i en ny fane) · European Data Protection Board (på engelsk)
Teknisk uddybning
Begrebet er ældre end GDPR. Ann Cavoukian, dengang Information and Privacy Commissioner i Ontario, formulerede det i 1990'erne som syv grundprincipper: proaktivt, ikke reaktivt; privatliv som standardindstilling; privatliv indbygget i designet; fuld funktionalitet (plussum, ikke nulsum); sikkerhed fra ende til anden gennem hele livscyklussen; synlighed og gennemsigtighed; og respekt for brugerens privatliv. Den internationale konference for databeskyttelsesmyndigheder tilsluttede sig det ved en resolution i Jerusalem i 2010, og GDPR gjorde det til en retlig pligt i artikel 25.
Artikel 25, stk. 1 (databeskyttelse gennem design), kræver, at den dataansvarlige, både når midlerne til behandlingen fastlægges, og under selve behandlingen, gennemfører passende tekniske og organisatoriske foranstaltninger, fx pseudonymisering, der er designet til effektivt at gennemføre databeskyttelsesprincipperne i artikel 5, fx dataminimering, og til at integrere de nødvendige garantier. Hvad der er passende, afhænger af det aktuelle tekniske niveau, implementeringsomkostningerne, behandlingens karakter, omfang, sammenhæng og formål og risiciene for de registrerede. Artikel 25, stk. 2 (databeskyttelse gennem standardindstillinger), kræver, at der som standard kun behandles personoplysninger, som er nødvendige til hvert specifikt formål, og det gælder mængden af indsamlede oplysninger, omfanget af behandlingen, opbevaringsperioden og tilgængeligheden; især må oplysningerne ikke som standard gøres tilgængelige for et ubegrænset antal personer uden den registreredes medvirken. Artikel 25, stk. 3, lader en godkendt certificeringsmekanisme efter artikel 42 indgå som et element i at påvise overholdelse, og overtrædelser hører under det lavere bødeniveau i artikel 83, stk. 4, på op til 10 mio. euro eller 2 % af den globale omsætning.
EDPB's retningslinjer 4/2019 om artikel 25 (version 2.0, vedtaget i oktober 2020) understreger, at pligten påhviler den dataansvarlige, at "det aktuelle tekniske niveau" er et bevægeligt mål, og at effektiviteten skal kunne påvises, fx gennem nøgletal. Databehandlere og producenter er ikke direkte bundet, men betragtning 78 opfordrer producenter til at tage hensyn til databeskyttelse, og den dataansvarlige forventes at vælge værktøjer, der gør det muligt at overholde reglerne.
I udviklingsarbejdet oversættes princippet til skemagennemgange, der fjerner felter uden et angivet formål, pseudonymisering og tokenisering på feltniveau, opbevaringsperioder implementeret som automatisk sletning eller TTL frem for politiktekst, rollebaseret adgang afgrænset til formålet, aggregering, k-anonymitet eller differential privacy til analyse, behandling på klienten, hvor det er muligt, og privatlivsvenlige standarder som tilvalg af tracking og profiler, der som udgangspunkt er private. Privacy by design adskiller sig fra en konsekvensanalyse efter artikel 35, som er en konkret vurdering, der udløses af behandling med høj risiko, og fra security by design, der beskytter alle aktiver mod angribere; et system kan være velsikret og alligevel indsamle langt flere personoplysninger, end det har brug for.
Hvad du bør lære først
Alt det, dette bygger på - grundlaget først.
- Fortrolighed
- →Privacy by design
Relationer
- Forudsætter
- Fortrolighed
- Forveksl ikke med
- Security by design
- Afbøder
- Databrud
- Krævet af
- GDPR
- Bruges sammen med
- Konsekvensanalyse vedrørende databeskyttelse (DPIA)Personoplysninger
Kilder og videre læsning
Standarder og officielle tekster
- Regulation (EU) 2016/679 (GDPR), Article 25 · European Union
Kursusmateriale
- Cyber Security Fast Track - Ordliste
Hvor dataene kommer fra
Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.
Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON
Test dig selv
Indlæser…