Personvernkonsekvenser av lover og innebygget personvern Dag Wiese Schartum.

Presentasjon om: "Personvernkonsekvenser av lover og innebygget personvern Dag Wiese Schartum."— Utskrift av presentasjonen:

1 Personvernkonsekvenser av lover og innebygget personvern Dag Wiese Schartum

2 Privacy Impact Assessment (PIA) (anslag av personvernkonsekvenser) Noen definisjoner – New Zealand: "a systematic process for evaluating a proposal in terms of its impact upon privacy" – Canada: "provide a framework to ensure that privacy is considered throughout the design or re-design of a programme...[and to] identify the extent to which it complies with all appropriate statutes". This is done to "mitigate privacy risks and promote fully informed policy" – Australia: "assessment of actual or potential effects on privacy, and how they can be mitigated" Definisjonene varierer men har en felles kjerne PIA er en generell tilnærming som ikke primært er knyttet til offentlige myndigheter FADs veileder til Utredningsinstruksen om vurdering av personvernkonsekvenser er klart inspirert av PIA

3 LovutredningHøringEvaluering Lovutredning: Plikt til bl.a. å utrede personvernmessige konsekvenser. Egen veileder er utarbeidet av FAD for å støtte slike analyser Offentlig høring: Plikt til å sende på offentlig høring/vurdere høringssvar Evaluering: Plikt til å vurdere evalueringsbehov etter Utrednings- instruksen; plikt til å evaluere etter Økonomi- reglementet i staten § 16; og anbefaling om etterkontroll av lover i Lovteknikk-heftet Faser der vurdering av personvernkonse- kvenser av lover er aktuell i norsk forvaltning

4 Noen resultater fra Aronsen og Jensen 2013 Utredningsinstruksens krav til å utrede personvern- konsekvenser blir ikke blir fulgt i alle saker Det er sjelden at det vises til FADs veileder om utredning av slike konsekvenser I høringsrundene er det relativt sjelden at argumentene fra høringsinstansene blir tatt til følge av departementet En betydelig andel av høringsargumentene blir ikke kommentert av departementet Datatilsynets argumenter i høringsrunden har ikke større gjennomslag og blir ikke oftere kommentert enn gjennomsnittet Det er ikke gjennomført evalueringer av personvern- konsekvenser i noen av sakene som Aronsen og Jensen gjennomgikk, til tross for at lover og forskrifter er underlagt evalueringsplikt

5 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 – Vanskelig å realisere hvis ikke personvernlovgivning er 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?!

6 De syv prinsippene for innebygget personvern 1.Proactive not Reactive; Preventative not Remedial 2.Privacy as the Default Setting 3.Privacy Embedded into Design 4.Full Functionality — Positive-Sum, not Zero-Sum 5.End-to-End Security — Full Lifecycle Protection 6.Visibility and Transparency — Keep it Open 7.Respect for User Privacy — Keep it User-Centric Men gir egentlig liten veiledning om hva vi faktisk må gjøre

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

8 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 systemutviklingsverktøy, og systemer for behandling av personopplysninger Kan være i form av – «passive» funksjoner (informasjon), eller – «aktive» funksjoner som griper inn og varsler bruker mv

9 Defined routinesAutomationNotices 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 InterfaceDefinition 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