Jeg har laget en info-pakke til deg som er arkitekt eller utvikler, og skal jobbe med personopplysninger. - Kort intro til grunnbegrepene i personvern, og hva GDPR medfører av plikter og rettigheter - En gjennomgang av hva de viktigste artiklene i forordningen vil medføre av krav til funksjonalitet - En introduksjon til mekanismene for å anonymisere og pseudonymisere data - Hva slags kompetanse du må ha, og viktige elementer i utviklingsprosessen - Nyttige design- og arkitekturføringer - Hva du bør spørre etter for å kunne jobbe bra med personvern - Noen relevante verktøy som du kan bruke Om du er arkitekt eller utvikler, vil du ha stor nytte av denne introen til GDPR: Lovverket trår i kraft 25.mai 2018, og setter helt absolutte krav til sikkerhet og personvern. Med bøter på opp til 4% av global konsernomsetning, blir vi tvunget til å lage nye systemer helt annerledes, og mange eksisterende må skrives om.

1. Slik kommer du i gang med
GDPR
Simen Sommerfeldt

2. Ingeniør fra University of Surrey
Pappa til tre
Rolle: CTO konsern
Spesialitet: Kunstig intelligens, GDPR, tingenes internett
Grunnlegger av Lær Kidsa Koding!
Grunnlegger av Oslo GDPR Meetup
Simen Sommerfeldt (@sisomm)

3. Skandinavisk konsulentselskap
14 kontorer i Norge og Sverige
1200 ansatte
Notert på Oslo Børs
IT – Kommunikasjon – Virksomhetsstyring

4. Mitt forhold til GDPR
”It’s complicated”

5. “You have ever been a herald
of woe. Troubles follow
you like crows, and ever
the oftener the worse”
- king Theoden to Gandalf

6. Jeg trenger GDPR-
estimat for
nettbutikken innen
i morgen Jeg setter Nico
på sakenFAEN!

7. Java 5 prosjekt vi kjørte
med 10 mann i 2007.
Oracle/Spring/Hibernate/
Struts. De fleste som
jobbet med det har
sluttet. Ingen
dokumentasjon.

8. Vi beholdt kjernen, men frontend ble
erstattet med React.js og iOS/Android

9. Og det er femten slike systemer

10. Og vi har de samme
utfordringene i Machine-
Learning prosjektet vårt

11. Personvern har
ofte vært elefanten
i rommet

12. Vi kan bli venner
med elefanten!

13. Dette er IKKE et foredrag om
GDPR-innføring i bedrifter

14. Hva som er nyttig for deg som
utvikler, basert på vår egen
opplæring i Bouvet
https://diversity.com/blog/wp-content/uploads/2017/02/3043082-poster-1280-fogcreek-women-hire.jpg

15. Det blir mange bulletpoints:
Juss og metode innebærer
mye oppramsing

16. Kort intro til
personvern
...og GDPR

17. Personopplysninger
o Hva som kan knyttes til deg som person: navn, adresse, telefonnummer,
e-postadresse, IP-adresse, bilnummer, bilder, fingeravtrykk, irismønster, hodeform,
fødselsnummer, etc.
o Adferdsmønstre: Hva du handler, hvilke butikker du går i, hvilke tv-serier du ser på,
hvor du beveger deg, og hva du søker etter på nettet
o Sensitive personopplysninger er rasemessig eller etnisk bakgrunn, politisk, filosofisk
eller religiøs oppfatning, at en person har vært mistenkt, siktet, tiltalt eller dømt for
en straffbar handling, helseforhold, seksuelle forhold eller medlemskap i
fagforeninger.
o Behandling av sensitive personopplysninger er underlagt særlig strenge regler.

18. Plikter og rettigheter
o Plikter
o Behandlingsansvarlig er virksomheten som bruker opplysningene
o Databehandler håndterer dataene på vegne av virksomheten
o Underleverandør kan benyttes av Databehandler
o Dette reguleres i Databehandleravtaler
o Rettigheter
o De registrerte
o Et viktig poeng er å finne hjemmel for behandlingen av personopplysningene

19. Når kan man prosessere personopplysninger?
o Når det er nødvendig for å overholde en kontrakt
o Ved samtykke for et spesifikt formål
o For å overholde lovkrav
o For å overholde den registrertes vitale interesser
o Nødvendig for en oppgave i offentlighetens interesse
o Hvis man har legitime grunner (gråsone).

20. Nokia 909

21. ”Dagens europeiske regelverk ble
laget i 1995.
Innholdsleverandører sliter med
inntekter på annonser, så de
selger info om brukerne
Tore Tennøe, 28.1.2016
Teknologirådet

22. ”Vi har fått en politisk
reaksjon på en
overvåkningsøkonomi
Tore Tennøe, 28.1.2016
Teknologirådet

23. ...en av flere grunner
Overvåknings-
økonomi !
Amerikanske myndigheters
Overvåkning !
Datakriminalitet !
Tilby gode
tjenester til forbrukerne
Hensyn til offentlige
interesser
Gjøre Europeisk næringsliv
konkurransedyktig

24. GDPR
o Erstatter personopplysningsloven
o Det kan gis store bøter for overtredelser
o Det gis anledning til massesøksmål
o Ansvar løftes opp i styrerommet
o Vi er i en overgangsfase nå
o Kommer 25. mai 2018
o E-Privacy direktivet er også på trappene.

25. Samtykker..
o Ett samtykke per formål, selv i den samme
applikasjonen
o Eksplisitte samtykker må innhentes for
profilering og deling av data med andre
parter (hvis ikke kontrakten krever det)
o Påkrevet med korte, forståelige samtykke-
tekster.

26. Tips for å lese
forordningen:
Start på
artikkel 5(!)

27. Det er uklart hvordan
Datatilsynet håndterer legacy-
systemer, men du må ha en
plan

28. 8 artikler
- Og hva de krever av
funksjonalitet

29. Article 25 – Data protection by design and default
o Bruker dere minimumsprinsippet for prosessering?
o Kan dere løskoble linken mellom den registrerte og informasjonen?
o Bruk teknikker for anonymisering og pseudonymisering
o Bruk gjerne en DPIA (Personvernkonsekvensutredning) for å sjekke.

30. Article 7: Conditions for consent
o Bedriften må kunne dokumentere at den registrerte har samtykket
o Om et samtykke trekkes tilbake, må det ha umiddelbar virkning

31. Article 15: Right of access by the data subject
o Det kan være behov for en informasjonsportal
o Og da må du ha autentisering
o Dette kan også være et sted for å administrere samtykker.

32. Article 16: Right to rectification
o Om du lager en innsynsportal kan det også være et sted for endring av data
o Men hva med validering, og hvordan påvirker dette forretningsprosessene?
o Trigger det nye statisitikkberegeninger?

33. Article 17: Right to be forgotten
o Sletting – eller anonymisering og pseudonymisering?
o NB! Det kan være forskjellige kriterier per system

34. ... Et eksempel på hvor GDPR involverer andre lover

35. ... Et eksempel på hvor GDPR involverer andre lover

38. Article 19: Notification obligation
o Du må ha funksjonalitet for å orientere tredjepart hvis
o Den registrerte har endrede opplysninger
o Den registrerte skal slettes
o Den registrerte trekker tilbake et samtykke.

39. Article 20: Right to data portability
o Ganske enkelt en eksport av opplysninger

40. o Du trenger passende tekniske (f.eks. IAM) og organisatoriske tiltak
o Sikker programmering, og mekanismer som står i forhold til risikoen
o Skille forskjellige data mest mulig
o Mekanisme for varsling ved brudd?
Article 32-35: Security of processing

41. Anonymisering og
pseudonymisering

42. Personopplysninger Pseudonymiserte
personopplysninger
Anoymiserte
personopplysninger
Tre kategorier

44. Metoder
anbefalt av

45. o Vi bytter ut identifikatorer med nye, random verdier – ”tokens”
o Sammenhengen mellom identifikatoren og tokenet lagres
separat
o Kan brukes til å linke tilbake til den opprinnelige posten.
Tokenization
Pseudonymisering

46. o Identifiserende felter blir gruppert i ”bøtter” etter en formel
o ”bøttene” gjenbrukes
• ”Pelle Hansen” -> ”01”
• ”Magda Paulsen” –> ”02”
• ”Sverre Jensen” -> ”03”
• ”Simen Sommerfeldt -> ”02”
Hashing
Pseudonymisering

47. o Innfører en viss feilmargin til feltene, .feks vekt 72-> vekt 74,6
Noise addition (støy)
Anonymisering

48. o Verdier erstatter med helt andre verdier.
o F.eks kan høyde 172 byttes med ”blå”, postnummer 3200 med
”elefant”
o Kombineres ofte med å tilføre støy
Substitution
Anonymisering

49. o Sørg for å ha minst K forekomster av en verdi i rader som kan
grupperes sammen (tid, sted, etc)
o Blank ut verdier i felter der dette ikke kan oppnås
o 4-anonymity: Det finnes minst 4 rader med samme forekomst
av
verdien på laveste nivå
o En kan også bruke generalisering: Alder: 23 blir til Alder: 20-30.
Aggregering: K-anonymity
Anonymisering

50. o Utvidelse: Der K-anonymity kan angripes med ”interferens-
angrep”
o Sørg for at man har minst L forskjellige varianter i utvalget
Aggregering: L-diversity
Anonymisering

51. o Innfør støy så nærme som mulig innsamlingspunktet
o Støyen har en gitt statistisk distribusjon
o Statistikk-beregningene ”tar vekk” denne distribusjonen
o Brukes av bla. Apple i deres kart- og meldings- apper.
Differential Privacy
Anonymisering

52. WP 29’s betraktninger rundt tilbakesporing
http://www.wsgrdataadvisor.com/2015/09/personal-data-anonymization-and-pseudonymization-in-the-eu/

53. ”Companies should keep
control of anonymized data.
Enough datapoints can lead
to de-anonymization
Heidi Shey, 6th september 2017
SENIOR ANALYST, FORRESTER RESEARCH

54. Kompetanse
og metode
Hva du bør kunne

55. Relevante utdrag av Datatilsynets krav
o Dokumenterte personvernkonsekvens-vurderinger (DPIA) for alle prosjekter som
angår personvern-sensitive data eller medfører betydelig risiko
o Forhåndsdrøftelser med datatilsynet ved høy risiko
o Innebygd personvern
o Bedrifter må ha en grafisk oversikt over flyt av personopplysninger, med tekstlige
beskrivelser og begrunnelser
o Avvikshåndtering. Man skal melde inne mange flere avvik, og innen 72 timer etter at
de er oppdaget og man må lage systemer for å avdekke avvik.
o Dere må forankre alt dette i internkontrollsystemet

56. På organisasjonsnivå

57. o Finnes det bransjenormer?
o Er dere underlagt andre lover og
regler?
o Hva er holdning og avveining til
sletting, logging, etc. På tvers av
systemer?
o Utarbeides med juss, IT drift,
forretning, sikkerhet, utvikling
o Det må gis nok opplæring
Bransje
Systemtype
Andre lover
GDPR
GDPR i en bransje og en organisasjon

58. GDPR og sikkerhet i en bedrift
o Bedriftens GDPR- implementasjon vil peke på
sikkerhets-policy (ofte ISO 27000)
o Begge disse må beskrives i
internkontrollsystemet
o Prosjektenes GDPR-implementasjon baserer
seg på bedriftens GDPR- og Sikkerhets-
opplegg
o Det påkreves av og til å kjøre
personvernkonsekvens-analyser (DPIA) som
inkluderer sikkerhet og personvern
GDPR
Sikkerhet
(ISO 27.000)
Avhengig av
Internkontrollsystemet
SystemA
DPIA
prosjekter
bedriften
GDPR
SystemB
GDPR
DPIA
Avhengigav
Beskrivesi
Beskrivesi

59. En logisk modell med personopplysninger

60. Excel, Archimate, Ardoq..
http://blog.bizzdesign.com/8-steps-enterprise-architects-can-take-to-deal-with-gdpr

61. Hvor de flyter og hvem som håndterer dem – per system
Husk å dokumentere det
rettslige grunnlaget for
behandlingen!

62. Identifisér hjemmel for håndtering i hvert system
Artikkel Regnskap
(Regnskapsloven)
Nettbutikken HR systemet Big Data
4
...
17
..
..

63. På prosjektnivå

64. Hvor disse aktivitetene befinner seg i et GDPR metodeverk
1. Et godt forankret
team
2. Analyse og
opplæring
3. Justere
prosedyrer og
implementere
endringer
4. Et fungerende
internkontrollsystem

65. Personvernkonsekvensutredning (DPIA)
Risikovurdering
o Kartlegging av verdier –
personopplysninger
o Trusselvurdering
o Er verdiene sårbarer for truslene?
o Resultat = toleransenivå?
o Tiltak for å redusere risiko
Ivaretar vi den registrertes rettigheter?
o Artiklene
https://iapp.org/news/a/wp29-proposes-dpia-guidelines-shedding-light-on-high-risk-processing/

66. o Grunninnføring i personvern
o Kjenne til sikkerhets- og personvern-elementene i en
utviklingsprosess
o Kunne tenke systemdesign for personvern
o Kjenne til Personvernkonsekvensutredninger (DPIA)
o Å kunne kode sikkert (OWASP)
o Sikkerhetsarkitektur og mekanismer, infrastruktur
o Interaksjonsdesignere må kjenne til GDPR
o Forstå hvordan en skal håndtere integrasjon riktig.
Kompetanse for utviklere og arkitekter

67. Testdata er strengt regulert og..
o Mange sliter med dette
o Syntetiske testdata er å foretrekke
o Du kan bruke skarpe data så lenge du gir info og får
samtykke
o Men da må du dokumentére begrunnelse, flyt og sletting
o I nødsfall kan en argumentere for at testdata er beslektet
og nødendig for å kunne drive utvikling av tjenesten:
kompatibilitet
o Avtalefestet taushetsplikt er et minimum.

68. Overordnede strategier
• Overførbarhet: Tiltak og teknikker som bidrar til at det er vanskelig og/eller umulig å
overføre eller spre data utover det aksepterte grunnlaget for registering og
behandling av data.
• Transparens: Tiltak og teknikker som gir informasjon om hvilke data og hvordan data
behandles og eventuelt prosesseres i algoritmer
• Intervensjon: Teknikker og tiltak som bidrar til å sikre individers rettigheter, f.eks
rettighetene til utbedring og sletting av data, retten til å trekke tilbake samtykket eller
rett til å inngi et krav, eller for å heve en tvist, for å oppnå riktig behandling av data
79

69. o Hvor lite informasjon kan applikasjonen klare seg med?
o Hva er den minste tiden det må beholdes?
o Hvordan minimerer dere koblingen mellom person og data?
o Kan personlig data krypteres?
o Minimalisér info i hvert system og prosess: “Need to know”
o Tenk pseudonymisering eller anonymisering gjennom hele
kjeden
Design for innebygd personvern

70. o Få kontroll hele stacken mht lekkasjer av personlige data
• Logger i firewall/lastbalanserer
• Logger på appserver
• Logger i database
• Backups
o Lag helhetlig filosofi rundt dataflyten grad for test-,
akseptanse- eller utviklingsmiljø
o Vurdér eventuell infrastruktur- og systemstøtte for å håndtere
sikkerhets-hendelser
Design for innebygd personvern

71. o Forankre utviklingen i bedriftens sikkerhetspolicy
o Om høy risk: En DPIA gir føringene.
Angrepsvektorer kan motvirkes i designet
o Dere er avhengige av god logging for å kunne
oppdage at løsningen er under angrep
o Noen på teamet må kunne sikkerhet godt, alle bør
kunne kode sikkert (owasp, least privilege)
o Tenk 0 trust i infrastrukturen og arkitekturen
o Sikkerhet bør testes i mange dimensjoner (se
Datatilsynets veileder).
Personvern er avhengig av sikkerhet

72. o Hvorfor systemet trenger informasjonen det behandler
o Hvor lenge systemet trenger å beholde persondata
o Hvilke (design)tiltak har blitt gjort for å beskytte dataene
o Avveininger og avgjørelser som tas - spesielt hvis de
kombinerer flere artikler, men tilsynelatende strider mot én
o Hvilke prosesser/rutiner som følges for å ivareta personens
interesser
o Hvilke prosesser/rutiner som følges ved hendelser.
Dokumentér

73. GDPR og Machine Learning/AI
o Deep Learning og andre teknikker kan dra med seg
fordommer (Bias)
o Husk at brukeren skal få mulighet til å se
beslutningsgrunnlaget og algoritmen
o Vurdér også etikken i vurderingene
o Husk å kunnne redegjøre for å hindre tilbakesporoing via
pseudonymisering og anonymisering ift. Working party 29
o Brukeren kan nekte automatiske beslutning hvis utfallet
har store konsekvenser
o Sporing av hvor dataene kommer fra (Data Lineage)

74. Konfigurasjon på tvers
o Fordel å skille orkestrering av GDPR-policy fra systemene
o Spådom: Det vil tvinge seg frem ”GDPR”-API’er i systemer

75. Datatilsynets
metode for
innebygd
personvern

78. Bouvets metodeverk
1. Et godt forankret team
• Tilgang høyt opp
• Riktige deltagere
2. Analyse og opplæring
• Felles juridiske og
sikkerhetsmessige
vurderinger
• Etablering av prosjekt
og dokumentasjon
• Kartlegging av tilstand
per system (inkl. DPIA)
• Opplæringsaktiviteter
• Leverandør- og sky-
vurderinger
• Estimater og planer
for systemporteføljen
3. Justere prosedyrer og
implementere endringer
• Implementere
nødvendige
systemendringer
• Justering av
samtykker
• Justering av
leverandør-avtaler
• Justering av intern-
kontrollsystemet mht.
sikkerhet og GDPR
• Etablering av avviks-
håndtering
• Etablere kontinuerlig
vedlikehold
4. Et fungerende
internkontrollsystem
• Alle roller har riktig
"mindset"
• Alle vet hvilken
kompetanse de skal
ha, hvilke spørsmål de
skal stille, og hvilke
svar de skal gi
• Fungerende
avvikshåndtering
• Prosjekter kjøres iht.
GDPR

79. Verktøy

81. Størrelse og kompleksitet kan tvinge frem automatisering
1. Et godt forankret
team
2. Analyse og
opplæring
3. Justere
prosedyrer og
implementere
endringer
4. Et fungerende
internkontrollsystem

82. Dere vil antagelig ha
behov for et sikkerhets-
overvåkning-system

83. Avslutning

84. http://frifagbevegelse.no/nettverk/her-larer-datatilsynets-direktor-seg-koding-6.158.481862.49be8737ab

85. http://frifagbevegelse.no/nettverk/her-larer-datatilsynets-direktor-seg-koding-6.158.481862.49be8737ab
- Vi var enige om at
micro:bit koden var
GDPR-compliant...

86. Eva Jarbekk og jeg
Holder GDPR-kurs
hos Bouvet
www.bouvet.no/kurs/kategorier/
personvern-og-gdpr

87. Bli med i Oslo
GDPR-meetup!
www.meetup.com/Oslo-GDPR-Meetup/

88. Spørsmål

89. Takk for meg!
Simen.Sommerfeldt@bouvet.no
@sisomm
99 50 77 33

90. Takk til
o Håvard Kristiansen for design-huskelisten
o Kjetil Stallemo for innspill til kompetansebehov
o Axel Borge for hjelp med å peke ut de viktigste artiklene
o Sven Pihl for å dele av lang erfaring med personvern
o Eva Jarbekk for å forsøke å lære meg litt juss

91. Lenker
• https://gdpr-info.eu/
• https://iapp.org/news/a/how-to-navigate-the-software-development-life-cycle-
under-the-gdpr/

92. Lenker
• http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+TA+P8-
TA-2017-0076+0+DOC+PDF+V0//EN
• https://ico.org.uk/media/for-organisations/documents/2013559/big-data-ai-ml-and-
data-protection.pdf
• http://www.datadan.io/hold-your-machine-learning-and-ai-models-accountable/
• https://vision.cloudera.com/general-data-protection-regulation-gdpr-and-data-
science/
• https://ico.org.uk/for-organisations/data-protection-reform/overview-of-the-
gdpr/individuals-rights/rights-related-to-automated-decision-making-and-profiling/
• https://fpf.org/wp-content/uploads/2016/11/M-Hintze-GDPR-Through-the-De-
Identification-Lens-31-Oct-2016-002.pdf