{"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://atlas.maintz.dev/)"},"id":"security/privacy-by-design","url":{"en":"https://atlas.maintz.dev/en/terms/security/privacy-by-design/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["At the start of every new system or process, have the product owner list the purposes and the personal data each purpose really needs, and drop every field without a stated purpose.","Assess the risks to the people whose data you process, and carry out a DPIA under GDPR Article 35 when the processing is likely to be high risk.","Choose measures that fit the risk and the state of the art, such as pseudonymisation, encryption, role-based access limited to the purpose and aggregated data for analytics.","Set privacy-friendly defaults (Article 25(2)) - optional fields and tracking off until the user opts in, profiles private, and no data made available to an unlimited number of people.","Build retention into the system as automatic deletion or TTLs based on your deletion deadlines, instead of relying on a policy text.","Write the privacy requirements into supplier contracts and choose tools that let you meet them, since the duty stays with you as controller.","Test before launch that the measures work, fx that deleted data is really gone and that defaults are as designed, and document the choices so you can show them to Datatilsynet.","Review the design when the purpose, the data or the technology changes, and at fixed intervals, since the state of the art moves."],"da":["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."]},"pitfalls":{"en":["Collecting data in case it might be useful later, which breaks data minimisation and increases what a breach can expose.","Treating a well-secured system as privacy-compliant, although it can be well protected and still collect far more personal data than it needs.","Doing the DPIA after the system is built, when the design choices can no longer be changed cheaply.","Pre-ticking consent boxes or making sharing the default, which goes against data protection by default."],"da":["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."]},"guides":[{"title":"Guidelines 4/2019 on Article 25 Data Protection by Design and by Default","url":"https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en","publisher":"European Data Protection Board","tier":"official-doc"},{"title":"Databeskyttelse gennem design og standardindstillinger","url":"https://www.datatilsynet.dk/regler-og-vejledning/behandlingssikkerhed/databeskyttelse-gennem-design-og-standardindstillinger","publisher":"Datatilsynet","tier":"official-doc","lang":"da"},{"title":"Indbygget databeskyttelse (privacy by design)","url":"https://www.sikkerdigital.dk/myndighed/databeskyttelse-og-gdpr/indbygget-databeskyttelse","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"}]},"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}