{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/privacy-by-design","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/privacy-by-design/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/privacy-by-design/"},"term":{"en":"Privacy by design","da":"Privacy by design"},"aka":{"en":["data protection by design and by default"],"da":["databeskyttelse gennem design og standardindstillinger"]},"domain":["security"],"cluster":"compliance","layer":"data","status":"current","era":2009,"summary":{"en":"The GDPR principle that protection of personal data must be built into systems from the start.","da":"GDPR-princippet om, at beskyttelse af personoplysninger skal bygges ind i systemer fra starten."},"body":{"formal":{"en":"The duty in GDPR Article 25 to build data protection into systems and processes from the design stage - for example by collecting less and hiding identities - and to make the most privacy-friendly setting the default.","da":"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."},"plain":{"en":"Drawing curtains into the plans for a new house, rather than taping newspaper over the windows after moving in.","da":"At tegne gardiner ind i planerne til et nyt hus i stedet for at tape aviser for vinduerne, når man er flyttet ind."},"inPractice":{"en":"Developers building a Danish municipality's booking form for sports halls drop the CPR number field the task does not need and leave the newsletter box unticked by default.","da":"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."},"whyItMatters":{"en":"Data never collected cannot leak, and fixing privacy after launch costs far more than planning it in; it also makes the system easier to defend when Datatilsynet asks.","da":"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."}},"deepDive":{"en":"The concept predates the GDPR. Ann Cavoukian, then Information and Privacy Commissioner of Ontario, formulated it in the 1990s as seven foundational principles: proactive not reactive; privacy as the default setting; privacy embedded into design; full functionality (positive-sum, not zero-sum); end-to-end security across the lifecycle; visibility and transparency; and respect for user privacy. The International Conference of Data Protection and Privacy Commissioners endorsed it by resolution in Jerusalem in 2010, and the GDPR turned it into a legal duty in Article 25.\n\nArticle 25(1) (data protection by design) requires the controller, both when determining the means of processing and during the processing itself, to implement appropriate technical and organisational measures, such as pseudonymisation, designed to implement the data protection principles of Article 5, for example data minimisation, effectively and to integrate the necessary safeguards. What is appropriate depends on the state of the art, the cost of implementation, the nature, scope, context and purposes of processing and the risks to individuals. Article 25(2) (data protection by default) requires that, by default, only personal data necessary for each specific purpose are processed, which applies to the amount collected, the extent of processing, the storage period and accessibility; in particular, data must not by default be made accessible to an indefinite number of people without the individual's intervention. Article 25(3) lets an approved certification mechanism under Article 42 serve as an element in demonstrating compliance, and infringements fall under the lower fine tier of Article 83(4), up to EUR 10 million or 2 % of worldwide turnover.\n\nThe EDPB's Guidelines 4/2019 on Article 25 (version 2.0, adopted in October 2020) stress that the obligation is on the controller, that \"state of the art\" is a moving target, and that effectiveness must be demonstrable, for example through key performance indicators. Processors and product vendors are not directly bound, but recital 78 encourages producers to take data protection into account, and controllers are expected to choose tools that allow them to comply.\n\nEngineering translations include schema reviews that drop fields with no stated purpose, field-level pseudonymisation and tokenisation, retention implemented as automated deletion or TTLs rather than policy text, role-based access scoped to the purpose, aggregation, k-anonymity or differential privacy for analytics, client-side processing where possible, and privacy-protective defaults such as opt-in tracking and private-by-default profiles. Privacy by design differs from a DPIA under Article 35, which is a specific assessment triggered by high-risk processing, and from security by design, which protects all assets against attackers; a system can be well secured and still collect far more personal data than it needs.","da":"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.\n\nArtikel 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.\n\nEDPB'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.\n\nI 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."},"edges":[{"type":"requires","to":"security/confidentiality","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"security/security-by-design","why":{"en":"Security by design protects all systems and data; privacy by design is the GDPR principle focused on people's personal data and collecting less.","da":"Security by design beskytter alle systemer og data; privacy by design er GDPR-princippet med fokus på menneskers personoplysninger og at indsamle mindre."},"confidence":"high","strength":"primary"},{"type":"mitigates","to":"security/data-breach","why":{"en":"Collecting and keeping less personal data shrinks what a breach can expose.","da":"At indsamle og gemme færre personoplysninger mindsker, hvad et brud kan afsløre."},"confidence":"medium","strength":"normal"}],"depth":1,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"Regulation (EU) 2016/679 (GDPR), Article 25","url":"https://eur-lex.europa.eu/eli/reg/2016/679/oj","tier":"standard","publisher":"European Union"}],"draft":true}