Innebygget personvern Dag Wiese Schartum

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?!

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

Hva kan lovgiver gjøre? 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.)

Hva kan behandlingsansvarlig gjøre? Velge «personvernvennlige» standardverdier («default»), dvs kreve aktiv handling for å gjøre valg som ikke fremmer personvern 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 Utarbeide systemer med forklaringsfunksjoner 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

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

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 forklaringsfunksjoner 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

  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

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