Innebygget personvern Dag Wiese Schartum
Innebygget personvern (Ib. P) (Privacy by Design) • Vil si at personvernregler mv nedfelles i selve systemløsningen slik at – Løsninger som er gunstige for personvern er førstevalg – Utførelse av personvernregler er automatisk eller understøttes av systemet – Innebygget personvernn kan være vanskelig å realisere hvis ikke personvernlovgivning legger til rette for det (f. eks. ved å være automatiseringsvennlig) • Tekniske informasjonssikkerhetstiltak kan ses på som Ib. P, men her står en ganske fritt mht hva slags tiltak en skal iverksette
De syv prinsippene for innebygget personvern 1. 2. 3. 4. 5. 6. 7. Proactive not Reactive; Preventative not Remedial Privacy as the Default Setting Privacy Embedded into Design Full Functionality — Positive-Sum, not Zero-Sum End-to-End Security — Full Lifecycle Protection Visibility and Transparency — Keep it Open Respect for User Privacy — Keep it User-Centric Men gir egentlig liten veiledning om hva vi faktisk må gjøre
Personvernforordningen, artikkel 25: Data protection by design and by default (1) Ikke «Privacy» Er også omtalt i punkt 78 i fortalen 1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
Data-protection principles (jf. art. 25) Article 5 Principles relating to processing of personal data 1. Personal data shall be: (a) processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’); (b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes … (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’); (d) accurate and, where necessary, kept up to date … (e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed … (f) processed in a manner that ensures appropriate security of the personal data …
Personvernforordningen, artikkel 25: Data protection by design and by default (2) • 2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons. • 3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.
Mulige designelementer (1) 1. Architecture design (system components, their properties and relationships) – Ha egen modul forklaring-/brukerstøtte – Trygg integrasjon med andre systemer, særlig eksterne systemer – Samkjøring av opplysninger for å sikre opplysningskvalitet 2. Data design (data elements of the system and their interrelations, cf. data models) – Velge minst mulig sensitive opplysninger – Bruke færrest mulige opplysninger – Velge opplysninger med høyest mulig kvalitet og oppdatering
Mulige designelementer (2) 3. Process design (system code controlling processing of data in the system, cf. process models) – Utforme automatiske funksjoner (hvis loven legger til rette for det; f. eks. sletting etter en viss tid, jf offentlegforskrifta § 6 siste ledd) – Utforme utførende funksjoner for • gi og trekke tilbake samtykke • sletting, retting mv. • plikt for tilrettelegging for automatisert dokumentkontroll 4. Interface design (design of interactions with other systems and with users of the system) – Utarbeide systemer med forklarings- og informasjonsfunksjoner som understøtter etterlevelse av rettslige krav; særlig som del av • Kan være i form av – «passive» funksjoner (informasjon), eller – «aktive» funksjoner som griper inn og varsler bruker mv
Innebyggingsteknikker • General information • Notices • Defined routines • Automation Legal automation Supportive automation Information Representation
Architecture Defined routines Automation Notices General information Definition of consent Automatic check of Notice to system Information on module and interoperability and administrator is systems connected data consistency between given in case of mal architecture of bases consent module and function in main consent module connected data bases system elements Data Definition of valid Automated data input in consent consistency checks procedure connected to authentication of data subjects Notice to system administrator is given if consent statement is older than five years, Information given regarding data definitions and of relevant legal effects of data Processes Definition of valid Automatic blocking processing of data in and deletion of consent procedure appurtenant data triggered by withdrawals of consent Notice to system administrator is given when legal bases change Information given regarding processes and connected relevant legal requirements Interface Definition of userdriven procedure in consent module Notices given to users in case of faulty use of consent process General information of consent is available with links to legislation Result of processes are automatically visible to users
Hva kan lovgiver gjøre? (jf. «automatiseringsvennlig lovgivning» ) • Formulere regler med et annet innhold: – Plikt til å gjøre informasjon allment tilgjengelig i stedet for å gi innsynsrett for enhver (jf § 18 første ledd) – Plikt for visse behandlinger til å inneholde ”Min. Sideløsning” i stedet for (bare) gi rett til innsyn • Gjøre andre lovtekniske valg – Skrive lovtekst med klar vilkårsstruktur, dvs. som klargjør hva en må ta stilling til og i hvilken rekkefølge det må skje – Generelt redusere bruk av skjønn og formulere regler på så klar og konkret måte som mulig (f. eks. sletting 1 år etter publisering av personnavn, jf offentlegforskrifta § 6 i. f. )
Hvorfor kan det være vanskelig å bygge personvern inn i systemene? Alternativ «automatiseringsvennlig» lovtekst: § 18. Rett til innsyn Den behandlingsansvarlige skal på side internettsider gjøre de opplysninger som Enhver som ber om det, skal få vite hva slags behandling av personopplysninger en nevnt i bokstav a – f tilgjengelig for enhver. Tilgang skal gis uten at det stilles krav behandlingsansvarlig foretar, og kan kreve å få følgende informasjon om en bestemt type om innlogging eller begjæring om innsyn. behandling: a) navn og adresse på den behandlingsansvarlige og dennes eventuelle representant, hvem som har det daglige ansvaret for å oppfylle den behandlingsansvarliges b) plikter, c) formålet med behandlingen, d) beskrivelser av hvilke typer personopplysninger som behandles, e) hvor opplysningene er hentet fra, og f) om personopplysningene vil bli utlevert, og eventuelt hvem som er To mulige Ib. P-trategier med gjeldende lovtekst: mottaker. • Generell informasjon om innsyn • Egen innsynsrutine med forklaringsmodul Om mulighetene for å • formulere mest mulig som «systemkrav» og • gjøre maskinell kontroll av hvordan loven etterleves
Скачать презентацию Innebygget personvern Dag Wiese Schartum Innebygget personvern
7fcd520ce402dc5f2321d7b43d68125f.ppt