Innebygget personvern

Presentasjon om: "Innebygget personvern"— Utskrift av presentasjonen:

1 Innebygget personvern
Dag Wiese Schartum

2 Innebygget personvern (IbP) (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 IbP, men her står en ganske fritt mht hva slags tiltak en skal iverksette Men grensen går vel når Datatilsynet bruker IKT til selv å bli Storebror?!

3 De syv prinsippene for innebygget personvern
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

4 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.

5 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 …

6 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.

7 Mulige designelementer (1)
Architecture design (system components, their properties and relationships) Ha egen modul for forklaring-/brukerstøtte Trygg integrasjon med andre systemer, særlig eksterne systemer Samkjøring av opplysninger for å sikre opplysningskvalitet 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

8 Mulige designelementer (2)
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 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

9 Innebyggingsteknikker
• General information • Notices • Defined routines • Automation Legal automation Supportive automation Information Representation

10 Defined routines Automation Notices General information Architecture Definition of consent module and connected data bases Automatic check of interoperability and consistency between consent module and connected data bases Notice to system administrator is given in case of mal function in main system elements Information on systems architecture of consent module Data Definition of valid data input in consent procedure Automated consistency checks 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 processing of data in consent procedure Automatic blocking and deletion of 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 user-driven procedure in consent module Result of processes are automatically visible to users Notices given to users in case of faulty use of consent process General information of consent is available with links to legislation

11 Hva kan lovgiver gjøre? (jf. «automatiserings-vennlig 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 ”MinSide-lø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.)

12 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 nevnt i bokstav a – f tilgjengelig for enhver. Tilgang skal gis uten at det stilles krav om innlogging eller begjæring om innsyn. § 18. Rett til innsyn Enhver som ber om det, skal få vite hva slags behandling av personopplysninger en behandlingsansvarlig foretar, og kan kreve å få følgende informasjon om en bestemt type behandling: a) navn og adresse på den behandlingsansvarlige og dennes eventuelle representant, b) hvem som har det daglige ansvaret for å oppfylle den behandlingsansvarliges 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 mottaker. To mulige IbP-trategier med gjeldende lovtekst: 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