Gå til innhold

KRONIKK: Tre overraskelser og potensielle gevinster som utviklere vil få gjennom GDPR


Anbefalte innlegg

Videoannonse
Annonse

"Et vanlig scenario er at organisasjoner benytter produksjonsdata fra sine kunder for å teste nye versjoner av systemet. Dette kan du glemme nå"

Kan du referere til hvilken tekst du har tolket for å komme frem til dette? Har du undersøkt med jurist?

Lenke til kommentar

"Et vanlig scenario er at organisasjoner benytter produksjonsdata fra sine kunder for å teste nye versjoner av systemet. Dette kan du glemme nå"

Kan du referere til hvilken tekst du har tolket for å komme frem til dette? Har du undersøkt med jurist?

 

Du kan fortsatt bruke produksjondata til testing men da må du ha samtykke av bruker eller kontraktfeste dette. I tillegg må du beskytte test miljøet likt som produksjon med en risikobasert tilnærming.

  • Liker 1
Lenke til kommentar

Veldig bra. Hvordan er det i forhold til bruk av tredjeartssystemer som Google analytics, facebook pixel eller tracking/personalisering systemer? Blir man ansvarlig overfor kunden om man implementerer dette på sin nettside? Altså må man kunne eksportere alle de rådata tredjeparten har samlet inn på ditt nettsted om kunden ønsker det?

  • Liker 1
Lenke til kommentar

"Et vanlig scenario er at organisasjoner benytter produksjonsdata fra sine kunder for å teste nye versjoner av systemet. Dette kan du glemme nå"

Kan du referere til hvilken tekst du har tolket for å komme frem til dette? Har du undersøkt med jurist?

 

Artikkel 5 i EU GDPR som tar for seg formålet for bruk av PII som blant annet regulerer dette. I tillegg har også Datatilsynet kommet fem til samme tolkning. Blant annet gjorde de det veldig klart da de presenterte sine nye veiledere i Dataforeningens regi den 25 august i år. Den seansen ligger ute på nett og nøyaktig 2 timer ut i denne får Datatilsynet et konkret spørsmål rundt dette og hvor de svarer at bruk at PII i test øyemed (les: kopi av produksjon) ikke lengre er mulig.

 

Samtykke er mulig, men som Brodwall sier, begresningene er så store rundt samtykke at administrasjonen av dette vil by på mange utfordringer. Blant annet, samtykke må være spesifikt, ikke generelt, ikke evigvarende, man må få tilgang til tjenesten selvom man ikke gir samtykke, etc. Det enkleste som Brodwall sier er å benytte syntetiske test data som gi deg en høyere kvalitet enn det du er i stand til med produksjonsdata. Eksempel, finner du negative test data i produksjon, sannsynligvis ikke.

  • Liker 2
Lenke til kommentar
Gjest Slettet-GnAistlz

Når utviklere og konsulentselskaper flommer over av begeistring for forretningsmuligheter som følge av GDPR får jeg flashback til tilsvarende begeistring hos revisjonsselskapene når SOX skulle innføres eller forsåvidt Y2K. Nothing sells consulting hours like legislation.

Lenke til kommentar

Dette minner veldig om Cookie-advarsel implementeringen og React lisensen. Utviklere og mellomledere leser en juridisk tekst og overreagerer.

 

At et selskap ikke skal kunne gjøre tester mot produksjonsdata er jo helt klart ikke formålet til denne lovgivningen.

Lenke til kommentar

Når utviklere og konsulentselskaper flommer over av begeistring for forretningsmuligheter som følge av GDPR får jeg flashback til tilsvarende begeistring hos revisjonsselskapene når SOX skulle innføres eller forsåvidt Y2K. Nothing sells consulting hours like legislation.

 

Det du sier er nesten, men ikke helt! feil.

 

Som utvikler, konsulent og først og fremst innbygger er jeg glad for at vi nå har en lovgivning som bedrifter bryr seg om som forklarer hvorfor (og hvordan) vi må gjøre det vi alltid har ment er riktig og sy vi rydde opp i gamle synder.

 

Dersom du tror utviklere lider av for lite å gjøre har du ligget under en stein en stund. Men vi liker å kunne gjøre en bedre jobb!

  • Liker 1
Lenke til kommentar

 

Dette minner veldig om Cookie-advarsel implementeringen og React lisensen. Utviklere og mellomledere leser en juridisk tekst og overreagerer.

 

At et selskap ikke skal kunne gjøre tester mot produksjonsdata er jo helt klart ikke formålet til denne lovgivningen.

 

Har du lest lovteksten?

Kan du svare på mitt første spørsmål? Nøyaktig hvilken tekst tolker du for å komme frem til påstanden din? Og ikke artikkel eller kapittelnivå, men selve teksten.

Ser en annen kommentator refererer til en annen del av direktivet for å backe påstanden din..

 

Jeg sier ikke at du har feil, men du gjør det vanskelig å ettergå påstanden din.

Lenke til kommentar

 

 

Dette minner veldig om Cookie-advarsel implementeringen og React lisensen. Utviklere og mellomledere leser en juridisk tekst og overreagerer.

 

At et selskap ikke skal kunne gjøre tester mot produksjonsdata er jo helt klart ikke formålet til denne lovgivningen.

 

Har du lest lovteksten?

Kan du svare på mitt første spørsmål? Nøyaktig hvilken tekst tolker du for å komme frem til påstanden din? Og ikke artikkel eller kapittelnivå, men selve teksten.

Ser en annen kommentator refererer til en annen del av direktivet for å backe påstanden din..

 

Jeg sier ikke at du har feil, men du gjør det vanskelig å ettergå påstanden din.

Kan vi ikke heller la Datatilsynet som tross alt er tilsynsmyndigheten komme med sin tolkning? Datatilsynet har publisert en del guider og veiledere ifm EU GDPR. I den forbindelse hadde jo også Datatilsynet en gjennomgang av disse i Dataforeningens regi. Dette fant sted den 25 august. Denne seansen ble streamet og dere finner opptaket her: https://youtu.be/e7WmVSaFTfc

Sett ut i fra et testståsted så er nok spørsmålet som ble stilt nøyaktig 2.00.00 (2 timer ut i videoen) det mest interessante. Der ble det nemlig stilt spørsmål om bruk av PII i test og svaret er ganske enkelt at det kan man ikke gjøre og at det finnes en rekke andre metoder som gjør at bruk av PII i test ikke er nødvendig.

 

I linken under vil du også finne en overordnet guide rundt anbefalinger fra Datatilsynet for test:

www.datatilsynet.no/regelverk-og-skjema/veiledere/programvareutvikling-med-innebygd-personvern/?id=7735

 

Som en del av dette har du også en sjekkliste helt mot slutten av linken over, og der vil du finne en PDF og hvor du finne følgende presisering:

• Bruk syntetiske personopplysninger og sjekk riktighet, lovlighet, rettferdighet, formål, nøyaktighet, dataminimalisert, lagring og robusthet.

o Bruk reelle data kun ved kvalitetssikring når programvaren er implementert i produksjonsmiljø og brukere skal ta i bruk programvare. Test på reelle data gjøres av fagpersoner som er autoriserte for opplysningene, eksempelvis superbrukere for barnevernprogram i barnevernssektoren, superbrukere for legejournal på legekontor, superbruker på skolesystem på skolen.

Lenke til kommentar

Kjempebra kronikk! Og en veldig god oppsummering av mange av de viktigste elementene for utviklere, men jeg har lyst å kommentere på det du skriver om data portabilitet.

 

Du skriver at kunden må kunne eksportere data fra leverandør, men dette stemmer ikke helt. Artikkel 20 som regulerer dette sier ikke at kunde skal kunne eksportere, men at kunde skal kunne motta data om seg selv. Det høres kanskje ikke så viktigt ut, men det betyr i bunn og grunn at det ikke er en krav om å ha en selvbrukstjeneste for å få ut data. Med andre ord kan henvendelsen om data for eksempel foregå på Mail og kunden få tilsendt sin data på samme måte. Her er det heller ikke stilt noe krav til hvor raskt utover rimelig tid (som er åpent for tolkning, men et par dager vil være innenfor).

 

Proceedingene sier dog at kunden bør kunne laste ned data og at det bør være mulig å overføre data mellom bedrifter, men dette er ikke krav stilt i forordningen. Husk også at kunder skal kunne få all data og ikke bare fra et system, så her er det viktig å tenke helhetlig i forhold til tjenestene (man ønsker ikke å fragmentere dette for alle systemer man har kundedata).

 

Tenkte bare det var viktig å få fram da dette også betyr at kunder kan få ut data fra konkurrenter på sekunder når forordningen inntrer, det kan ta lenger tid og være mer kronglete.

  • Liker 1
Lenke til kommentar

 

 

At et selskap ikke skal kunne gjøre tester mot produksjonsdata er jo helt klart ikke formålet til denne lovgivningen.

 

Har du lest lovteksten?

Kan du svare på mitt første spørsmål? Nøyaktig hvilken tekst tolker du for å komme frem til påstanden din? Og ikke artikkel eller kapittelnivå, men selve teksten.

Ser en annen kommentator refererer til en annen del av direktivet for å backe påstanden din.

Jeg oppfatter spørsmålet ditt som genuint, så jeg skal forsøke å begrunne påstanden. Jeg forstår deg dit at du ønsker at jeg siterer artikler og ikke bare refererer til dem. Jeg har utelatt deler av lovteksten som jeg tror bare gjør det tyngre å lese i vårt tilfelle (se gjerne originalteksten på f.eks. https://gdpr-info.eu/ for å vurdere om du er enig)

 

Det er to forhold som jeg tar utgangspunkt i: Artikkel 6-7 om samtykke og artikkel 25 og 32 om sikker behandling. Her er de mest relevante delene:

 

Artikkel 6: "Processing shall be lawful only if and to the extent that at least one of the following applies: a. the data subject has given consent to the processing of his or her personal data for one or more specific purposes. (b.-f.) [Årsaker begrunnet i lovmessige forpliktelser]". Selv om det kan være at man henter inn data for å understøtte en lovmessig plikt, vil bruken av denne dataen til testing ikke følge av lovplikten. Da trenger man samtykke (min påstand).

 

Artikkel 7: "3. The data subject shall have the right to withdraw his or her consent at any time. 4. When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract [...] is conditional on consent to the processing of personal data that is not necessary for the performance of that contract." Slik jeg forstår det: Du kan ikke kreve samtykke til bruk for testing for å kunne gi en tjeneste.

 

Artikkel 25: "1. ... the controller shall [...] implement appropriate technical and organisational measures [...] in an effective manner and to integrate the necessary safeguards into the processing".

 

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

 

Artikkel 32: "[...], the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data;

(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; [...]"

 

Altså: Persondata skal kun brukes der det er nødvendig (artikkel 25. paragraf 2) og må sikres i alle tilfeller (artikkel 32, paragraf 1). Dette gjør at man som minimum må ha strenge sikkerhetsregimer i testsystemer som benytter persondata.

 

Sist har jeg lyst til å bringe til torgs en sak som delvis motsier meg selv. På min originale versjon av denne artikkelen på min blog (http://johannesbrodwall.com) kommenterte Emily Bache at at det finnes relevant rettspraksis I SVERIGE på personvernDIREKTIVET (dvs forgjengeren til forordningen): http://www.datainspektionen.se/press/nyheter/2014/fel-av-sj-anvanda-riktiga-personuppgifter-da-it-system-testades/

 

Her brukte SJ (NSB i Sverige, sånn cirka) persondata i testmiljøet. Det ble da slått fast at 1. det hadde de lov til, men det måtte sikres og 2. de hadde ikke sikret det tilstrekkelig.

 

2. viser vanskeligheten av og plikten til å sikre testsystemer tilstrekkelig. Med GDP er dette som før, men strengere vurdering og konsekvenser.

 

Det kan fortsatt diskuteres om samtykke til å behandle data automatisk gir samtykke til å bruke dataene til å forbedre tjenesten (dette var den svenske vurderingen under direktivet). Jeg forstår artikkel 7. 4 til å motsi dette "When assessing whether consent was freely given, uttermost importance is given to whether the performance of a contract is conditional on consent to processing that is not necessary..." (forkortet)

 

Håper du er mer fornøyd med dette svaret. :-)

Lenke til kommentar

 

 

 

At et selskap ikke skal kunne gjøre tester mot produksjonsdata er jo helt klart ikke formålet til denne lovgivningen.

 

Har du lest lovteksten?

Kan du svare på mitt første spørsmål? Nøyaktig hvilken tekst tolker du for å komme frem til påstanden din? Og ikke artikkel eller kapittelnivå, men selve teksten.

Ser en annen kommentator refererer til en annen del av direktivet for å backe påstanden din.

Jeg oppfatter spørsmålet ditt som genuint, så jeg skal forsøke å begrunne påstanden.

...

Håper du er mer fornøyd med dette svaret. :-)

Veldig bra, Johannes. Det er definitivt ikke meningen å kverulere, men dette føler jeg er en gråsone og at din tolkning av direktivet er veldig streng. Etter min mening utgjør produktet alle miljøene som er satt opp; test, staging osv. Da blir det litt rart å si at test er en annen, unødvendig og ulovlig prosessering av data...

 

Unntaket er om produktet gjør noe helt annet med dataene i de andre miljøene, men i tilfellet må jo også nytt samtykke innhentes når denne funksjonaliteten når prod?

Lenke til kommentar

 

...

Håper du er mer fornøyd med dette svaret. :-)

 

Veldig bra, Johannes. Det er definitivt ikke meningen å kverulere, men dette føler jeg er en gråsone og at din tolkning av direktivet er veldig streng. Etter min mening utgjør produktet alle miljøene som er satt opp; test, staging osv. Da blir det litt rart å si at test er en annen, unødvendig og ulovlig prosessering av data...

 

Unntaket er om produktet gjør noe helt annet med dataene i de andre miljøene, men i tilfellet må jo også nytt samtykke innhentes når denne funksjonaliteten når prod?

Jeg tror jeg kanskje burde formulert meg annerledes i den originale teksten. Det største problemet er naturligvis at persondata må sikres like godt uansett hvor det ligger lagret. Man må også passe på at forespørsler om å slette og rette data også sletter data i andre miljøer. Og det er ikke gitt at man bør gi enhver tester og utvikler tilgang til dataene.

 

Det kan hende kravet om behandlingsgrunnlaget er noe mer fleksibelt enn jeg har skrevet. Men sjekk med en advokat og kanskje med Datatilsynet!

 

Uansett: Jeg tror det er veldig mye testaktiviteter man ikke kan gjennomføre med persondata fordi man ikke får sikret det godt nok. Så man må uansett ha en annen strategi for testdata i tillegg.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...