GDPR og ansvarsforankring

[Kevin95]

Hallo,

 

Som nevnt i mine tidligere tråder er jeg høyere leder for en stor organisasjon. Som resten av Europa må vi tenke på hvordan vi vil håndtere dette med GDPR. Vi har selvfølgelig løsning på det, men jeg ønsker å få en diskusjon, inspill og perspektiver fra personer utenifra som ikke kjenner organisasjonen.

 

Problemstillingen er som følger:

Både eksterne og interne kan spørre om hva vi har av data på dem, samt å be om at disse dataene skal slettes. Vi som en veldig gammel og stor organisasjon har naturligvis mange systemer, hvor rundt 20 av disse har noe persondata. Her er dermed spørsmålet, hva er gode løsninger på hvordan en henter ut data fra alle disse forskjellige systemene på en god måte? Et annet spørsmål som egentlig er hovedspørsmålet mitt er om folk har meninger eller erfaring som viser til hvor dette ansvaret bør forankres? Burde det være noe for IT-avdelingen eller er det en administrativ sak, eller kanskje begge? Begrunn svaret. Hvordan håndteres dette i andre bedrifter/organisasjoner, eller deres egen?

 

All diskusjon, meninger, forslag, erfaring og lignende er velkommen!

[Dapp47]

Hei,

 

Hvis dere har 20 forskjellige systemer med data ville jeg tatt kontakt med leverandøren for disse systemene og spurt etter dokumentert fremgangsmåte på å fjerne data ifra systemene deres.

 

GDPR er administrativt og har ikke noe med IT å gjøre, men IT kan bidra til gode måter å dokumentere tekniske løsninger på. 

[KalleKanin]

Hallo,

 

Som nevnt i mine tidligere tråder er jeg høyere leder for en stor organisasjon. Som resten av Europa må vi tenke på hvordan vi vil håndtere dette med GDPR. Vi har selvfølgelig løsning på det, men jeg ønsker å få en diskusjon, inspill og perspektiver fra personer utenifra som ikke kjenner organisasjonen.

 

Problemstillingen er som følger:

Både eksterne og interne kan spørre om hva vi har av data på dem, samt å be om at disse dataene skal slettes. Vi som en veldig gammel og stor organisasjon har naturligvis mange systemer, hvor rundt 20 av disse har noe persondata. Her er dermed spørsmålet, hva er gode løsninger på hvordan en henter ut data fra alle disse forskjellige systemene på en god måte? Et annet spørsmål som egentlig er hovedspørsmålet mitt er om folk har meninger eller erfaring som viser til hvor dette ansvaret bør forankres? Burde det være noe for IT-avdelingen eller er det en administrativ sak, eller kanskje begge? Begrunn svaret. Hvordan håndteres dette i andre bedrifter/organisasjoner, eller deres egen?

 

All diskusjon, meninger, forslag, erfaring og lignende er velkommen!

Her har du ett svar

https://www.medier24.no/reklame/gdpr-er-ikke-et-dataprosjekt-du-kan-lempe-pa-it-sjefen-det-er-noe-hele-bedriften-ma-gjore-ikke-minst-du-som-leder/407640

 

Personlig er jeg enig i at det ikke kun involverer IT-avdelingen. De bør kun være verktøyet.

 

IT-avdelingen har ofte ikke full oversikt over hvilke andre krav som gjelder i tillegg til GDPR.

 

F.eks. kan regnskapsloven gjøre at man likevel ikke kan slette fakturainformasjon osv.

 

Litt avhengig av størrelsen på firmaet, bør IT-avdelingen primært hjelpe til med å gi oversikt over dataene, og så er det de interne brukerne av dataene som bør si hva som bør behandles ut i fra andre lovkrav e.l.

De vil også kunne komme med innspill på hvilke data som kan slettes, eller om det finnes data som i stedet for bør anonymiseres for statistikk og trendformål

 

(Men reell anonymisering er ekstremt vanskelig, da det skal være en irreversibel prosess, og ikke mulig å spore seg tilbake via sammenstilling av andre kilder. Dette vil i praksis være tilnæremet umulig....)

Endret 7. juni 2018 av KalleKanin

[papa_m]

Hei,

 

Har dere laget protokoll over alle behandlingsaktivitetene? En tanke er å legge inn hvilke system og hvem som er systemeier/admin under hver behandling slik at dere vet hvem dere skal kontakte ved innsyn/sletting. Vet om flere som har valgt å legge ansvaret til IT, men har vært borti andre som har valgt å gi ansvaret til HR (for de som ikke har eller må ha et personvernombud). Anbefaler uansett å ha en som har det overordnede ansvaret for personvern, som da også fører denne protokollen.

 

GDPR sier lite om hvordan informasjonen skal leveres ut bortsett fra den skal være kortfattet, åpen, forståelig og lett tilgjengelig, og på et klart og enkelt språk (Artikkel 12(1)). Samtidig sier Artikkel 15(3) at om forespørselen kommer elektronisk skal informasjonen gis i en "vanlig elektronisk form". I forordene (63) er det en anbefaling om at "dersom det er mulig bør den behandlingsansvarlige kunne gi fjerntilgang til et sikkert system der den registrerte kan få direkte tilgang til egne personopplysninger". Flere har laget dette, blant annet Facebook.

 

Det er mulig det holder med et skjermdump av hva du har, men husk at du også må oppgi informasjon om formålet, hvem som mottar personopplysningene (databehandlere), når dette skal slettes og mer. Kravene står i Artikkel 15.

 

 

 

[Kevin95]

Takker for alle gode kommentarer! De hjelper veldig mye i min diskusjon for hvordan dette skal bli forankret i organisasjonen. Personlig ser jeg for meg at GDPR gjelder hele organisasjonen som en helhet og ikke kan bli håndtert av en enkelt avdelingen på en god formålstjenelig og overordnet nivå. Dermed blir min anbefaling for min organisasjon å ankre ansvarsområdet i et sentralt team i IT-avdelingen, for håndtering av disse sakene. IT-avdelingen vil ikke gjennomføre alle aktivitetene alene men vil heller virke mer som en distributør til systemeierene som vil ha ansvaret for selve utførelsen av aktivitetene. 

 

Ved å følge dette alternativet ivaretar vi at det overordna ansvaret som ligger utenfor den enkelte enhet. I tillegg får man koordinert og samlet både den konkrete oppfølgingen av hver enkelt sak i tillegg til at teamet vil kunne fange opp forbedringspunkter underveis i arbeidet. Jeg mener også at denne løsningen ivaretar likebehandling og legger til rette for en effektiv og korrekt saksbehandling.  

 

Modellen for behandling:

https://imgur.com/PznZjm8

 

Dere kan gjerne diskutere videre om besluttningen og modellen, jeg vil personlig vertfall følge med på denne tråden videre med stor interesse.

Endret 8. juni 2018 av Kevin95

[xcomiii]

Det er dataeier som er ansvarlig, dvs øverste leder og i noen tilfeller styret som har det juridiske ansvaret. Nå legges det ikke opptil personlige sanksjoner (bøter), men foretaksstraff i form av bøter til selskapet. Og som øverste leder har man jo da et forklaringsproblem til styret om det skulle skje, og styret igjen svarer til aksjonærene. Spørsmålene du stiller, kommer jo lovlig sent og etter min mening har dere ikke tatt dette særlig seriøst hittill med tanke på når GDPR blir sanksjonert.

Du kan gjerne delegere noe praktisk arbeid til IT avdelingen, men det er som sagt øverste leder som er juridisk ansvarlig for dette. De aller fleste store organisasjoner har allerede for lenge siden forberedt IT systemer på uthenting av data om noen ber om det. Når du nå lurer på hvordan det skal foregå, da har du ikke skjønt at det kan ta svært lang tid å etablere det tekniske samt å etablere prosessen internt i organisasjonen. Og ergo har dere ikke tatt dette særlig seriøst før nå.

 

Forøvrig har Datatilsynet god dokumentasjon og veiledere på dette.

[Kevin95]

Det er dataeier som er ansvarlig, dvs øverste leder og i noen tilfeller styret som har det juridiske ansvaret. Nå legges det ikke opptil personlige sanksjoner (bøter), men foretaksstraff i form av bøter til selskapet. Og som øverste leder har man jo da et forklaringsproblem til styret om det skulle skje, og styret igjen svarer til aksjonærene. Spørsmålene du stiller, kommer jo lovlig sent og etter min mening har dere ikke tatt dette særlig seriøst hittill med tanke på når GDPR blir sanksjonert.

Du kan gjerne delegere noe praktisk arbeid til IT avdelingen, men det er som sagt øverste leder som er juridisk ansvarlig for dette. De aller fleste store organisasjoner har allerede for lenge siden forberedt IT systemer på uthenting av data om noen ber om det. Når du nå lurer på hvordan det skal foregå, da har du ikke skjønt at det kan ta svært lang tid å etablere det tekniske samt å etablere prosessen internt i organisasjonen. Og ergo har dere ikke tatt dette særlig seriøst før nå.

 

Forøvrig har Datatilsynet god dokumentasjon og veiledere på dette.

 

Her må du ha missforstått.

 

Selvfølgelig har vi tatt det seriøst. Selvfølgelig har vi jobbet med det i god stund. Selvfølgelig vet vi hvordan vi skal hente ut dataen. Selvfølgelig er det ankret i toppen til syvende og sist. Jeg lurer heller ikke på hvordan det skal foregå, det jeg lurer på er hvordan andre har opplevd det og hva deres tanker og erfaringer rundt det er.

Endret 9. juni 2018 av Kevin95

[arne22]

Et lite innspill fra sidelinjen ettersom jeg ikke jobber med denne typen problemstillinger nå i dag, men jeg har gjort det en gang i tiden tidligere, og jeg har også nå i "moderne tid" brukt litt tid og krefter på å sette meg inn i GDPR, som jeg synes er et "moderne, nødvendig og interessant fenomen".

 

Slik som jeg vil se problemstillingen så representerer GDPR egentlig ikke noe nytt. Det er heller snakk om noen gode og godt innarbeidede prinsipper som får en mer eller mindre ny anvendelse innenfor et nytt anvendelsesområde. 

 

Kvalitetsledelse, risikostyring og GDPR er vel sånn sett bare 2-3 sider av den samme sak. Akkurat som at det fra før av finnes et lovgitt krav om at det må finnes et system for internkontroll som ivaretar de ansattes arbeidsmiljø og sikkerhet på arbeidsplassen, så finnes det nå også et krav om at det skal finnes et system for internkontroll som ivaretar det som går på datasikkerhet.

 

Tar man utgangspunkt i "klassiske systemer for kvalitetsstyring for produksjonsbedrifter, etter ISO 9000 serien", så ser vi at disse systemene egentlig danner noe av de basisprinsipper og "fundament" for de prinsipper som også brukes i forbindelse med internkontroll og arbeidsmiljø. (Formålet er kanskje noe ulikt, men prinsippene for gjennomføring kan kanskje allikevel ha noe til felles.)

 

Slik som kravene og målene for GDPR er formulert så er det etter mitt syn neppe noen annen måte å oppfylle disse kravene på lang sikt og i en større sammenheng enn at "internkontroll for informasjonssikkerhet" og "risikovurdering rundt informasjonssikkerhet er med som en grunnleggende rammefaktor for alle faser rundt utvikling og drift av et informasjonssystem. 

 

På samme måte som man ikke kan produsere en bil eller et annet teknisk produkt, og så føye til "en glimrende kvalitet" i ettertid, så må også "kvalitetsstyring rundt informasjonssikkerhet" være med som en grunnleggende faktor som er med i alle prosjektfaser og på alle ledelsesnivåer.

 

Hvis dette eventuelt skulle være riktig, så vil jo GDPR ikke bare være "en ny detalj" men en "game changer" som gir nye konkurransefortrinn for de som vet å tilpasse seg denne nye endringen hurtig og effektivt.

 

Jeg har ikke lest eller gått gjennom denne standarden, men jeg ser det er en standard serie som heter ISO/IEC 27000. Skulle denne kunne ha noe med saken å gjøre? (Har selv bare vært borte i ISO 9000 serien.)

 

https://www.iso.org/isoiec-27001-information-security.html

 

Slik som jeg tolker GDPR så er det ikke et hovedpoeng å "bokstavtolke" det enkelte detaljkrav eller bestemmelse, men å etablere et totalt system for "produktkvalitet", "tjenestekvalitet", "kvalitet i arbeidsmiljø" og "kvalitet i forhold til datasikkerhet". Det er summen av det hele og alle systematiske tiltak som teller, at man har en god nok produkt og tjenestekvalitet, kvalitet i forhold til datasikkerhet, osv. 

 

Selv om jeg egentlig ikke har greie på disse tingene så synes jeg GDPR gir så mange assosiasjoner til "tradisjonell kvalitetsstyring" at jeg ikke helt kan dy meg.  

Endret 9. juni 2018 av arne22

[arne22]

Hvis man leser og forstår GDPR ut i fra de tilsvarende prinsipper som gjelder når man leser en kvalitetsstandard i ISO 9000 serien, da blir jo GDPR å tolke som noe i retning av "krav til kvalitet i forhold til temaet datasikkerhet".

 

I likhet med all annen kvalitetsstyring så er det ikke det enkelte punkt i standarden som er av stor viktighet, men der i mot "summen av det hele" der man ender opp med en "tilstrekkelig god kvalitet" i forhold til det som går på datasikkerhet.

 

Med en slik tolkning og et slikt utgangspunkt så blir jo forankringen hos toppledelsen og i alle ledd nedover i bedriften. Likt med all annen kvalitetsstyring så omfatter GDPR alle ledd i virksomheten, og det er sånn sett noe som angår alle. (Kvalitetstyring og risikovurdering i forhold til persondata.)

 

"Summen av det hele" blir jo da også noen som man naturlig implementerer gradvis og steg for steg ut i fra en helhetlig vurdering av "hvor skoen trykker mest".

 

Er det noen på dette forumet som er enige i eller uenige i denne måten å se tingene på?

 

Edit, tilføyelse:

 

Jeg har kikket litt på veiledningene hos Datatatilsynet, lovforarbeidene og den engelsspråklige originalteksten.

 

Det som slår meg det er at den norske framstillingen er utrolig "fragmentert" og "tunglest" slik at det er vanskelig å få med seg "det store bildet" og "hva det hele egentlig dreier seg om".

 

Dette står etter mitt syn i et motsetningforhold til den engelskspråklige originalteksten som på et vis er mer "klar og enkel" og som i større grad får med seg en framstilling av "helhet og sammenheng".

 

https://www.datatilsynet.no/regelverk-og-skjema/veiledere/

 

https://www.regjeringen.no/no/dokumenter/prop.-56-ls-20172018/id2594627/

 

https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L:2016:119:FULL

 

Edit 2:

 

Jeg ser ellers at Stripe ser ut til å ha en meget bra og helhetlig beskrivelse av GDPR

 

https://stripe.com/guides/general-data-protection-regulation#legal-basis-for-processing-personal-data-in-the-gdpr

Endret 11. juni 2018 av arne22

[arne22]

Fant en ganske opplysende artikkel i regi av et advokatfirma som jeg synes gir en meget god beskrivelse av en del sentrale problemstillinger. Selv om artikkelen ikke plasserer ansvaret for GDPR eksplisitt så gjør den jo det allikevel ved beskrivelsen av "de typiske feil som forekommer". (Ansvaret følger jo av typen feil som det dreier seg om,)

 

Ellers veldig hyggelig om det er noen som her synspunker, er enige eller uenige i forhold til mine poster.

 

https://transformationtools.no/articles/2017/de-5-vanligste-brudd-pa-gdpr/

Endret 14. juni 2018 av arne22

[arne22]

Her er også en video som ser ut til å gi en meget god "oversikt":

 

 

Edit:

 

Dokumentmaler for internkontrollsystem, som kanskje er litt gamle men som kan oppdateres:

 

https://www.datatilsynet.no/regelverk-og-skjema/verktoy-skjema/skjema-og-maler/maler-til-veileder-i-informasjonssikkerhet-og-internkontroll-i-word-/

Endret 17. juni 2018 av arne22

[Feh]

Nesten samtlige av mine kunder har bedt oss om å bistå med rådgivning rundt systemstøtte til GDPR. Det er veldig forskjellig hvordan de har organisert seg internt, og det er veldig forskjellig hvordan de ønsker å gå frem.

 

For noen så ønsker de kun systemstøtte til SAR (Subject Access Request, slett meg o.l.), mens resterende prosesser (ROPA, DPIA) utføres i Excel, ofte basert på malverk de har fått tilsendt fra advokatfirmaer.

 

De som har dratt det lengst har også bygget systemstøtte for ROPA og DPIA. Her bruker en CMDB for å vedlikeholde totalbildet over hvilke tjenester og infrastruktur som inneholder persondata.

 

En annen kunde har også bygget et skjema for innmelding av potensielle databrudd som er integrert mot datatilsynets "melding om avvik" som ligger i altinn. De (altinn) har faktisk et ganske velutviklet API som tillater virksomheter å melde inn saker fra eget system.

 

Liten digresjon: Jeg jobber med noen av de største bedriftene i norge og det er nesten komisk å se hvor lite innsikt de har i GDPR, både fra IT og forretningssiden, og hvor avslappet de er i forhold til å bli "compliant". Nå ble det riktignok utsatt til høsten, men likevel.

 

Edit:

 

Slik jeg ser det så er det IT sitt ansvar å følge opp SAR forespørsler, og å bygge de nødvendige tjenestene for å tilby dette til ansatte/kunder av bedriften. Dette inkluderer, men er ikke nødvendigvis begrenset til:

- Innsyn i lagrede persondata

- Be om sletting av data

- Innsyn i samtykker

- Trekke tilbake samtykker

 

Hvordan man løser det rent teknisk kommer vel an på bedriftens ambisjoner. Det viktigste er uansett at bedriften faktisk har oversikt over hvor det finnes persondata, og min erfaring er at dette også havner på IT.

 

Det er dog ikke IT sitt ansvar å sørge for at bedriften er "compliant". Dette ansvaret ligger på forretningssiden.

Endret 18. juni 2018 av Feh

[arne22]

Nå vil ikke jeg ikke akkurat påberope meg å være ekspert innenfor disse greiene. Jeg vil tvert i mot påberope meg å ikke være det, men interessert i å lære (disse greiene) 

 

SAR står altså for Subject Access Request eller "Spørsmål om innsyn i eller sletting av data."

DPIA - Data Processing Impact Assessments - "Vurdering av personvernkonsekvenser"

 

ROPA - Det må vel stå for Record of processing activities, eller "loggføring".

 

CMDB - Det er vel formodentlig en "Configuration Management Database".

 

"Oversetter" forkortelsene på grunn av at jeg er usikker på hva de betyr.

 

En av disse må vel nesten være viktigere enn de andre, eller faktisk "viktigst". Det er DPIA eller en vurdering av "personvernkonsekvenser".

 

Hvis de data som kommer ut eller på avveie er de samme som man kan slå opp i 1881.no så er vel "personvernkonsekvensene" ikke så veldig store. Er det snakk om personopplysninger, sanne eller usanne, der det kan være snakk om betydelige "personvernkonsekvenser" så blir problemstillingen en annen.

 

Tenker man på denne måten, så "glir" jo dette med GDPR over mot de samme prinsipper som gjelder for all annen internkontroll og kvalitetsstyring, man må forebygge ulykker, man må forebygge større produksjonsavvik og man må forebygge at persondata kommer på avveie eller at de blir missbrukt.  Der hvor risikoen er størst så setter man inn de første og største tiltakene, og så bygger man opp et system for internkontroll og datasikkerhet, trinn for trinn.

 

Man skal kort sagt tilrettelegge organisasjon og tekniske løsninger for "Privacy by design and by default". 

 

https://www.datatilsynet.no/regelverk-og-skjema/nye-personvernregler/innebygd-personvern-etter-forordningen/

Endret 18. juni 2018 av arne22

[Feh]

ROPA/DPIA er egentlig vel så viktige. ROPA benyttes til å kartlegge hvilke systemer som inneholder hva slags type data, hvem dataene gjelder, hvor datene lagres osv. Uten å ha gjennomført en fullstendig ROPA kartlegging av alle tjenester og infrastruktur har de fleste bedrifter svært lite innsikt i disse tingene. Den største forskjellen er at (manglende) ROPA får flest interne konsekvenser, mens DPIA får flest eksterne. Manglende DPIA kan f.eks resultere i bøter. ROPA understøtter også SAR dersom det blir satt i system (med f.eks hjelp av en CMDB).

 

DPIA benyttes som regel i to steg: Screening og Assessment. I screening fasen bedømmer man om informasjonen som lagres og forvaltes i et system er av en sånn art at man må gjennomføre en fullstendig analyse (impact assessment). I den fullstendige analysen bedømmer man hvilke konsekvenser det får dersom dataene kommer på avveie. DPIA er spesielt aktuelt for nye tjenester og infrastruktur. Formålet er å kartlegge om man har iverksatt de nødvendige tiltakene for å være "compliant" med GDPR.

[papa_m]

Enig i at ROPA (eller "protokoll over behandlingsaktiviteter" som det heter på norsk) er like viktig å ha på plass som DPIA. 

 

Denne SKAL innholde:

- Navn på behandlingsansvarlig og, om det eksisterer, felles behandlingsansvarlig og personvernombud

- Formål 

- Hvilke kategorier av personopplysninger og registrerte

- Mottakere 

- Utlevering til tredjeland

- Tidsfrist for sletting

- En generell beskrivelse av sikkerhetstiltak

 

Ville derimot også lagt inn hvilke system som benyttes i behandlingen (HR, CRM++) og støttende dokumenter som sletterutiner, personvernerklæring osv. Det florerer av Exel-ark som kan benyttes, og det begynner også å komme gode SaaS løsninger som har koblet på DPIA.

 

Artikkel 29-gruppen har en veileder på DPIA her: http://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=611236 . DPIA bør ikke være altfor fremmed om man har vært borte i ISO 29134 

[Feh]

Gode poeng papa_m. Erfaring fra mine kunder er at man må granulere ROPA enda lenger ned. F.eks når det gjelder CRM. En kunde trodde at alt ble håndtert i ett system, men fant etter hvert ut at dette systemet var, via BizTalk, integrert mot en rekke ulike systemer, og at både CRM systemet, alle integrasjonene og systemene de var integrert mot måtte registreres ettersom alle lagret de samme dataene.

[papa_m]

Nå er ikke jeg noe IT-mann, men ser poenget ditt veldig godt. Og det vil igjen være veldig nyttig å ha alle systemer og integrasjoner kartlagt når man får en SAR (for å dra tråden tilbake til det opprinnelige spørsmålet).

 

Av ren nysgjerrighet, bruker dere Excel til å føre ROPA? 

[NikkaYoichi]

[...]

 

Problemstillingen er som følger:

Både eksterne og interne kan spørre om hva vi har av data på dem, samt å be om at disse dataene skal slettes. Vi som en veldig gammel og stor organisasjon har naturligvis mange systemer, hvor rundt 20 av disse har noe persondata. Her er dermed spørsmålet, hva er gode løsninger på hvordan en henter ut data fra alle disse forskjellige systemene på en god måte? Et annet spørsmål som egentlig er hovedspørsmålet mitt er om folk har meninger eller erfaring som viser til hvor dette ansvaret bør forankres? Burde det være noe for IT-avdelingen eller er det en administrativ sak, eller kanskje begge? Begrunn svaret. Hvordan håndteres dette i andre bedrifter/organisasjoner, eller deres egen?

 

All diskusjon, meninger, forslag, erfaring og lignende er velkommen!

Hvis dere ikke allerede har det, så må dere opprette en protokoll. Den skal blant annet fortelle noe om hvem som er registrert, kategorier av opplysninger, om opplysningene overføres til ikke-EU/EØS-land og eventuelt juridisk grunnlag for dette, sletting, sikringstiltak etc.

 

Det er klart at lønnsmottakere har flere opplysninger lagret om seg, enn et mottaker av et nyhetsbrev. Opplysningene om lønnsmottakere har også andre lovverk som sier noe om hvor lenge opplysningene skal lagres. Poenget er at protokollen vil gi en oversikt over alle systemene, både digitale og analoge, hvor personopplysninger er lagret. Det vil derfor danne grunnlaget for hvordan man lager gode rutiner for uthenting av data, hvis/når noen måtte be om det.

 

Først og fremst sø skal det utpekes et personvernombud, som har i oppgave å ta seg av henvendelser som omhandler temaet. Jeg vil si at dette er et administrativt tema, mest fordi det er en ganske tung juridisk greie. Tenker nok at IT-avdelingen mer enn gjerne kan være sterke bidragsytere til tekniske løsninger og rutiner, da en del personopplysninger skal krypteres, slettes på en god måte. Likevel så er dokumentasjonen og håndteringen av utarbeidelse av databehandleravtaler, personvernerklæringer, samtykkeskjema og denslags, heller mat for mer administrative deler av organisasjonen. Samtidig så berører også disse dokumentene tekniske løsninger, så IT må nok være involvert også her. 

[tomjo381]

Jeg er heller ingen IT- eksmpert, men som flere har skrevet tidligere kan en protokol eller checkliste være smart.

 

For eksempel 

• Kartlegg alle behandlinger i foreningen
•  Dokumenter alle behandlinger i en liste
• Lag et synlig personvernsreglement og informer alle foreningens medlemmer
• Inngå databehandleraftaler hvis foreningen bruker andre til å håndtere data
• Utpek en data-kontaktperson i foreningen

 

Kilde: https://www.sportmember.no/nb/artikler/gdpr-i-forening-og-idrettslag 

[oppat]

Hallo,

 

Som nevnt i mine tidligere tråder er jeg høyere leder for en stor organisasjon. Som resten av Europa må vi tenke på hvordan vi vil håndtere dette med GDPR. Vi har selvfølgelig løsning på det, men jeg ønsker å få en diskusjon, inspill og perspektiver fra personer utenifra som ikke kjenner organisasjonen.

 

Problemstillingen er som følger:

Både eksterne og interne kan spørre om hva vi har av data på dem, samt å be om at disse dataene skal slettes. Vi som en veldig gammel og stor organisasjon har naturligvis mange systemer, hvor rundt 20 av disse har noe persondata. Her er dermed spørsmålet, hva er gode løsninger på hvordan en henter ut data fra alle disse forskjellige systemene på en god måte? Et annet spørsmål som egentlig er hovedspørsmålet mitt er om folk har meninger eller erfaring som viser til hvor dette ansvaret bør forankres? Burde det være noe for IT-avdelingen eller er det en administrativ sak, eller kanskje begge? Begrunn svaret. Hvordan håndteres dette i andre bedrifter/organisasjoner, eller deres egen?

 

All diskusjon, meninger, forslag, erfaring og lignende er velkommen!

 

 

GDPR er i prinsippet et ekstra IT-system som alle andre databaser må ha et grensesnitt mot.

 

Når en kunde gjør et GDPR-utdrag eller sletting så må statusen følges i alle underliggende databaser og IT-system.  Hvert system må enten ha en automatisk eller manuell metode for å hente ut, samt slette data og GDPR-systemet må oppdateres med informasjonen.

 

Håndtering av GDPR-forespørsler kan sannsynligvis gjøres med ticket-systemer som Jira med fornuftig tilpassning men for større bedrifter så finnes det egne workflow-systemer for dette.