Dataforordning og ESCRM
Formål og intro
Formålet med dette dokument er at beskrive områder hvor der er sammenhæng og sammenstød mellem forordningen og ESCRM, herunder hvorledes vi imødegår disse udfordringer.
Den 25.maj 2018 træder der en ny persondata-beskyttelseslov i kraft, og navnet er The General Data Protection Regulation (GDPR).
Den giver borgerne i EU større kontrol over deres egne personlige data og sikrer, at deres information håndteres sikkert og beskyttet i hele Europa, uanset om databehandlingen sker i EU eller ej.
Som CRM-ansvarlige er vi naturligvis mest optaget af, hvordan vores system kan hjælpe dig med at leve op til GDPR. Det er vores ansvar at sætte rammerne for, at alle brugere har mulighed for, lettest muligt, at leve op til GDPR’s regelsæt.
Det er samtidigt brugernes eget ansvar i de forskellige juridiske roller de har, at sørge for overensstemmelse med gældende lovgivning. Mere om det under afsnit 2 vedrørende roller.
I ESCRM indsamler vi ikke personfølsomdata til noget formål, hvilket overskueliggør processen i at sikre overensstemmelse med lovgivningen. Der er dog punkter, vi skal overholde – hvilket vi gør via udvikling af systemet, og nye procedurer. Konkrete specifikationer på personfølsomdata:
· Oplysninger om helbredsforhold (undtaget hvis den viden er nødvendigt for at opfylde lovkrav)
· Fagforening (undtaget hvis den viden er nødvendig med henblik på kontingenttræk)
· Straffeattest og andre tilsvarende rent private forhold
· Personlighedstest m.v.
· Racemæssig eller etnisk baggrund
· Politisk, religiøs eller filosofisk overbevisning
· Seksuelle forhold
Det er vores helt klare fokus i ESCRM administrationen at lette byrden for vore brugere, således mange punkter, der sikrer overensstemmelse med lovgivningen enten bliver automatiseret, eller klaret via enkelt procedure.
I jeres forberedelse til klargøring af forordningen vil der muligvis være interne procedurer i skal ændre på.
1. Nøglebegreber
Der er rigtigt mange punkter i den nye forordning – betydningen af de enkelte punkter afhænger af formålet med datasystemet og brugen heraf. Vi vil her kort skitsere de vigtigste punkter i den nye forordning, og hvilken indflydelse de har på vores ESCRM system:
· Samtykke (Hjemmel)
· Retten til indsigt (Aktindsigt)
· Retten til at blive glemt
· Retten til at blive underrettet (Databrud)
· Udløbstid på data (Dataminimering, proportionalitet)
· Anonymisering (Sletning)
· CPR-nummer
Der vil i de følgende afsnit nævnes processer og værktøjer, hvoraf nogle endnu ikke er udviklet endnu, med det formål at sikre overensstemmelse med forordningen. Vi vil ikke komme mere specifikt ind på de specifikke udviklingspunkter og processer i denne skrivelse – der kommer opdateringer i dette dokument, der beskriver de specifikke tiltag mere præcist, efterhånden som de implementeres.
Der vil ligeledes være tiltag, der vil blive løst via processer. Disse processer vil ligeledes blive overordnet beskrevet i dette dokument.
1.1 Samtykke
Når man arbejder med persondata i ESCRM er det vigtigt at sikre sig, at man har tilladelse til at foretage registreringen. Der kan være forskellige måder at opnå dette, den måde vi anbefaler er et skriftligt samtykke. En af årsagerne er at det er jeres ansvar at kunne dokumentere, at I har tilladelse til registreringen fremadrettet, det gøres nemt med et skriftligt samtykke.
Et samtykke skal indeholde oplysninger om hvilke data der registreres, hvorfor, hvor længe data opbevares, hvem data deles med og eventuelle indskrænkninger i de gængse rettigheder. F.eks. er Erhvervshusene forpligtiget til overfor opgavestiller (Erhvervsstyrelsen), at registrere hvem der modtager en ydelse for offentlige midler. Derfor er det et meget vigtigt forhold, at når der indgås forløb med en kunde, skal de gøres bevidste om, at vi logger deres data i systemet i mindst 3 år, og hvad formål mm. er.
Det bør fremgå af et samtykke at data som bliver logget i ESCRM, benyttes til effektmåling af offentlig erhvervsfremme i Danmark. Ligeledes deles overordnede oplysninger omkring en kontakt med blandt andre jobcentre, kommuner og andre systemer der som ESCRM, er tilsluttet KL’s fælles virksomhedsdatabase.
Kravet om skriftligt samtykke, til at oprette enkeltpersoner i systemet, kan dog omgås, hvis den pågældende enhed udfører databehandlingen som led i deres arbejde, der er i samfundets interesse. Hvorvidt dette er aktuelt for den enkelte enhed beror på en konkret vurdering og det kan derfor være forskelligt fra enhed til enhed. Dette bliver behandlet længere nede i afsnit 3. Dog vil et skriftligt samtykke altid være at foretrække, da det minimerer retlige problemer for enheden, der kan opstå i denne forbindelse.
Et stærkt udgangspunkt vil være et skriftligt samtykke fra den registrerede, og et udtrykkeligt samtykke, hvis registreringen involverer CPR-nr.
1.2 Retten til indsigt
Enkeltpersoner der er oprettet i ESCRM har retten til indsigt i vores oplysninger om dem. En aktindsigt går oftest på et konkret forløb og alle data i forbindelse med forløbet skal udleveres. Dog kan der afhængigt af datamængden bedes om en total indsigt, det er forventeligt at ESCRM’s brugere vil skulle efterleve en total indsigtsbegæring.
Det vil sige de på ethvert tidspunkt kan kontakte en tilknyttet enhed (”Enhed A”), og bede om aktindsigt i, hvad der står registreret på deres person f.eks. i forhold til et projekt.
Det betyder at man er forpligtiget til at udlevere data andre enheder har delt med Enhed A, vedrørende det forløb der er bedt om aktindsigt i.
Derudover har de også retten til at få samtlige data på deres person leveret i letlæseligt format af Enhed A.
Til slut har enkeltpersoner ret i at få rettet (forkerte) data, der står registreret. Disse punkter i forordningen er vi fuldt ud underlagt.
Til hjælp for enhederne, vil der blive lavet en skabelon, kaldet ”Indsigtsoversigt”, der kan fungere som hjælp til at identificere data man skal/vil medtage i tilfælde af aktindsigtsanmodning der omfatter ESCRM. Ligeledes kan det fungere som et overordnet arkiv over forløb der registreres i ESCRM.
1.3 Retten til at blive glemt
Enkeltpersoner oprettet i IT-systemer har under GDPR retten til at blive ”glemt”, dvs. slettet, hvor de figurerer. Dette er ikke nødvendigvis tilfældet i ESCRM:
Vi har en forpligtigelse til, som offentlige, at kunne dokumentere, hvad offentlige midler har af effekt på erhvervsfremme i Danmark – og hvad midlerne går til. Det er derfor et krav at for at kunne indgå i et offentligt erhvervsfremmende samarbejde, at enkeltpersoner ikke uden videre kan slettes. Der kan dog i nogle tilfælde anonymiseres, hvilket juridisk er det samme som en sletning.
Nogle data vil derfor være stemplet med en ”må tidligst slettes/anonymiseres dato”, for de data der har en særlig status. Dette sættes ved oprettelse af aktiviteten.
Dette er som led i, at vores data er til formål for en offentlig myndighed – hvorfor der gælder særregler, i forhold til kommercielle IT-systemer.
1.4 Retten til at blive underrettet
Ved læk af data eksempelvis ifm. hacking, har vi pligt til at underrette dem, som det er gået ud over.
Hvis for eksempel en kommune er blevet hacket, og er ESCRM i den forbindelse kompromitteret, har vi ansvar for at finde ud af, hvor stort omfanget af lækket er, hvor mange, og hvem det er gået ud over – med henblik på at underrette disse personer om lækket af data.
Denne proces vil der blive udarbejdet procedure for:
Bruger man eksempelvis projektnoter i sit arbejde, skal man have en procedure for, hvad der skal ske, hvis disse projektnoter falder i forkerte hænder.
Enhederne har selv ansvar for at udarbejde en ansvarlig datalæksprocedure for deres data. Vi vil, formegentligt, udarbejde nogle skabeloner, man kan bruge – men det er dog stadig de enkelte enheders ansvar at sørge for, at alle medarbejdere er bekendte med disse procedurer.
1.5 Udløbstid på data
Med forordningen kommer der udløbstid på data. Det vil sige, at man ikke bare kan lave data om enkeltpersoner og gemme det i tid og evighed, med det formål, at man tænker man måske kan bruge det en dag. Dette er bl.a. i led med at bekæmpe de nye big-data tendenser og understøtte proportionalitetsprincippet, datamængden skal stå mål med behovet.
Den umiddelbare udløbstid er 3 år fra oprettelsen til sletning af aktiviteter. En person udløber 3 måneder efter oprettelse. En person hvor der er gemt aktiviteter eller stamdata der forhindre udløb, vil først udløbe når der ikke er flere data der hindre dette. På den måde sikre vi at personer der er aktive forløb med ikke slettes, mens personer der ikke har været aktiviteter omkring i længere tid udløber.
Vi har i ESCRM intet godt argument for at gemme detaljeret data i mere end 3 år, hvorfor der skal udvikles et system-værktøj der automatisk sletter forældede data. Denne funktion vil blive automatiseret, således det ikke er en arbejdsbyrde for vore brugere. Brugerne vil dog ved oprettelse af aktiviteter kunne angive en anden udløbsdato, som betyder enten kortere eller længere opbevaring end standarden.
Eksempelvis er der projekter i ledtog med EU, hvor EU kræver at dokumentation gemmes meget længere. Denne undtagelse vil værktøjet også kunne imødekomme.
Når man opretter data I ESCRM, bliver man bedt om at angive en udløbsdato. Som udgangspunkt står der 3 år – så man skal aktivt lave en ændring. Man vil have muligheden for at sige en specifik dato, 5 år – 25 år – aldrig.
Brugeren har selv ansvaret for at udløbsdatoen på data er i overensstemmelse med lovgivningen. Angiver man at data ikke udløber så skal brugeren bekræfte at der ikke er persondata i registreringen.
1.6 Anonymisering
I forlængelse af udløbstiden på data vil vi nu introducere et nyt aspekt, af ESCRM: Anonymisering.
Et eksempel: Lad os sige, at Peter Jensen har en note der er oprettet for 4 år og 364 dage siden og udløber i morgen. I dag kan alt data på Peter Jensen ses i portalen. I morgen vil noten blive slettet og Peter Jensen blive anonymiseret – dvs. alt data, der kan lede os hen til at Peter Jensen har været i systemet, vil blive slettet/ryddet – men data, der ikke er personhenførbart, vil blive tilbage, f.eks. postnummer og by. Dette er i fuld overensstemmelse med forordningen, og sikrer at vi stadig kan lave effektmålinger der kører mange år tilbage. Eksempelvis, hvis Peter Jensen har været i et givent vækstforløb, vil der stå tilbage at der engang har været en – nu anonymiseret person – i dette forløb – alt data og øvrige kommentarer om forløbet står stadig tilbage – bare intet om Peter Jensens person.
For at kunne gøre dette skal data klassificeres, det sker på feltniveau i Projektnoter og på feltdesign. Andre steder er det hele registreringen, f.eks. noter og dokumenter. Felter kan klassificeres som Generelle data, CPR-nummer, Personhenførbar eller følsom. Ved anonymisering ryddes indholdet i felter markeret med CPR, Personhenførbar og følsom.
Af denne årsag, anbefales det at man undgår at bruge Peter Jensens navn i noter osv. vedr. vigtige forløb. Vi anbefaler at man i stedet skriver “vi har snakket med kontaktpersonen og har fået tilbagemelding…”. På denne måde undgår man at skulle definere noten som personhenførbar og den vil dermed ikke blive slettet sammen med Peter Jensen.
1.7 CPR-nummer
I tilfælde hvor der arbejdes med Iværksættere i ESCRM vil der blive registreret et CPR-nummer. CPR-nummeret er ikke at betragte som personfølsomdata, men skal behandles på samme måde. Derfor er der i ESCRM følgende særskilte tiltag vedrørende CPR
· CPR-nummeret bliver maskeret, dvs. de sidste fire tegn vises ikke, medmindre en bruger specifikt ønsker det.
· Når en bruger får vist hele CPR-nummeret logges det i systemet og vil være registreret indtil den registrerede anonymiseres
· CPR-numre kan ikke trækkes ud automatisk via Webservice eller API, dertil kræves en specifik tilladelse.
2. Roller
I dette dokument redegøres der for forskellige roller man kan have i forhold til brug og/eller dataejerskab i ESCRM. Politik, lov og ”Best practice” er alt sammen forskellige for hver enkelt rolle. Ofte vil man via brug af ESCRM påtage sig flere juridiske roller på én gang. Disse roller defineres nedenfor, og til følge kommer en beskrivelse af, hvad de forskellige roller indebærer, og hvad man skal have in mente juridisk.
· Administrator i ESCRM
· DPO (Data Protection Officer)
· Bruger
· Databehandler
· Dataansvarlig
Efter gennemgang af dette dokument, er det meningen du burde kunne vurdere, hvilke roller du påtager dig jævnfør din brug af ESCRM, og hvilken lovgivning du skal være opmærksom på er pålagt dig. I forhold til personligt ansvar vil vi gerne understrege følgende:
Tildeles man adgang til systemet af en dataansvarlig, og arbejder man med data, påtager man sig automatisk rollen som databehandler. Det er meget vigtigt at understrege, at det er den person, som er oprettet (som bruger), der har det juridiske ansvar ved brud på loven. Det er derfor mod vore regler, som b.la. beskrevet i samarbejdsaftalen, at flere personer tilgår samme systemkonto (bruger). Man skal altså have en licens per bruger, og ikke bare en fælles licens i en enhed.
Ligeledes er det ikke tilladt at ændre en brugers oplysninger til at være en ny person. Man skal deaktivere brugeren og oprette en ny, f.eks. i tilfælde hvor der er ansat en ny i stillingen med adgang til escrm (man bliver faktureret pr. aktive bruger og ikke pr. oprettede bruger).
Formålet med denne skrivelse er ikke at udpensle og tolke på de forskellige artikler i dataforordningen, men snarere redegøre for, de forskellige roller i forhold til ESCRM.
De fleste spørgsmål ifm. lovgivning, som man kunne tænke sig at have efter gennemlæsning af dette dokument besvares her: http://www.eugdpr.org/gdpr-faqs.html
2.1 Administrator i ESCRM
En administrator i ESCRM er en bruger, der har adgang til særlige funktioner i forhold til almindelige brugere, f.eks. rette i kanvas, stamdata-felter, oprette og nedlægge brugere og designe projekter-noter.
Hvis en administrator laver en projektnote til brug i enheden, hvor brugerne skal indsamle data på en række virksomheder, har administratoren sådan set ikke ejerskab over den pågældende data. Administratoren muliggør blot at den pågældende data kan logges. Det er brugerne, der udfylder data i rammerne, der har ansvaret for at det data der udfyldes er korrekte og DPO’en har ansvaret for at registreringen af de pågældende data er i overensstemmelse med gældende lov. Administratoren vil tit enten selv have rollen som DPO, eller sparre med enhedens DPO for at sørge herfor.
I mange tilfælde vil en administrator også selv have en funktion, hvor der behandles og oprettes data – i det tilfælde vil vedkommende påtage sig flere roller, og have adskillige juridiske rammer, som skal alle overholdes.
2.2 Data Protection Officer (DPO)
Ifølge dataforordningen er en DPO, en som referer direkte til øverste ledelse (har generelt karakter af stabsfunktion). DPO’en har til opgave at rådgive hhv. de dataansvarlige og databehandlerne om forpligtelser i henhold til forordningen, overvåge gennemførelsen og anvendelsen af den dataansvarlige- og behandlerens regler om beskyttelse af personoplysninger – både fra EU og nationalt, herunder uddanne medarbejdere. Den dataansvarlige og databehandlerne sikrer, at DPO inddrages i alle spørgsmål vedr. beskyttelsen af personoplysninger. https://ec.europa.eu/info/departments/data-protection-officer_en
En DPO skal være opmærksom på eventuelle ændringer i lovgivningen, og sikre at enheden konstant er i overensstemmelse hermed.
I ESCRM vil vi fremover arbejde med en rolle vi kalder DPM (data protection manager). Det er vigtigt at understrege at der ikke (nødvendigvis) er tale om en formelt udpeget DPO efter dataforordningens definitioner og bestemmelser. Langt de fleste enheder der benytter ESCRM vil ikke have en formel DPO.
Alle enheder skal registrere en person der har en DPO-lignende rolle, dvs. den person vi har dialog med vedrørende DPO-relevante informationer. Det vil også være DPM’en der kommunikeres med i tilfælde af databrud. Praktisk er det en god ide hvis enhedens DPM også er dens ESCRM-administrator, eller i hvert fald har en tæt tilknytning hertil, da der er betydeligt overlap af ansvarsområder.
2.3 Databehandler
I persondatalovens § 3, nr. 5, defineres en ”databehandler”, som den der behandler oplysninger på den dataansvarliges vegne. Databehandleren behandler aldrig personoplysninger til egne formål og må kun bruge de oplysninger som aftalt med den dataansvarlige.
Kort sagt anses databehandler som en almen bruger med tilgang til systemet, der læser og trækker data herfra. En databehandler er forpligtiget til at overholde de regler, som den dataansvarlige og DPO nedskriver – i overensstemmelse med dataforordningen.
Som sagt i afsnit 1., så har vi i ESCRM i udgangspunktet ikke personfølsomt data. Derfor er det vigtigt, at være opmærksom på at der, i forhold til systemet, intet er til hinder for rent teknisk, at man kan lave en note på en enkeltperson, hvori man kortlægger vedkommendes religiøse overbevisning. Det er helt og aldeles ens eget ansvar, at sådan data ikke figurer i systemet, eller hvis det gør, at det er i overensstemmelse med loven.
2.4 Dataansvarlig
I persondatalovens § 3, nr. 4, defineres “den dataansvarlige” som den der afgør, til hvilket formål og hvordan der må foretages behandling af oplysninger
Den dataansvarlige er den person, juridiske organ, offentlige myndighed, institution eller andet, der alene eller sammen med andre afgør, til hvilke formål og med hvilke hjælpemidler, der må foretages behandling af personoplysninger.
Med andre er den dataansvarlige den, som afgør hvad der skal registreres, hvor der registres og til hvilke formål.
Med forordningen afskaffes den nuværende forpligtelse til at anmelde visse behandlinger af personoplysninger til Datatilsynet. I stedet skal dataansvarlige føre en intern fortegnelse over alle behandlingsaktiviteter, som foretages i deres organisation. Fortegnelsen skal indeholde specifikke detaljer om hver behandlingsaktivitet, herunder bl.a. information om:
· formålene med behandling af persondata
· kategorier af persondata, registrerede og modtagere af data
· eventuelle overførsler af persondata til tredjelande
· perioden, hvor data opbevares, og
· de tekniske og organisatoriske foranstaltninger, som er implementeret af den dataansvarlige.
De data man registrerer i ESCRM bør altså indgå i fortegnelserne der udarbejdes lokalt. Med valget af ESCRM som platform er en del af de tekniske foranstaltninger givet. De er bygget ind i ESCRM med udløbsmekanismer og sikre behørig anonymisering og sletning. Husk at stamdata deles automatisk med alle, men aktiviteter aktivt skal deles (kan ske via standarddeling af f.eks. projektnote)
I ESCRM er der adskillige dataansvarlige. Generelt er der en dataansvarlig for hvert af de forløb der registreres i systemet. Nogen har besluttet at disse data skulle registreres med et specifikt formål, eksempelvis forløb, projekter, timeregistrering mm.
Det er let at tilegne sig rollen som dataansvarlig. Man skal huske man selv har ansvaret for at overholde lovgivningen.
Du kan læse mere om den dataansvarlige her:
http://ec.europa.eu/justice/data-protection/data-collection/obligations/index_en.htm
3. Det retlige grundlag
Det er vigtigt at afklare hvad det retlige grundlag er, for den enkelte enhed, i forhold til brugen af ESCRM og databehandling.
Udfører enheden opgaver i samfundets interesse, så kan persondatalovens § 6, stk.1 potentielt være gældende, og hvor samtykke fra den registrerede endda kan undlades hvis: ”behandlingen er nødvendig af hensyn til udførelsen af en opgave i samfundets interesse” eller ”behandlingen er nødvendig af hensyn til udførelsen af en opgave, der henhører under offentlig myndighedsudøvelse, som den dataansvarlige eller en tredjemand, til hvem oplysningerne videregives, har fået pålagt”. Dog er det juridisk tilrådeligt at indhente samtykke uanset hvad, så hjemmel til databehandling findes i den registreredes samtykke og subsidiært i persondatalovens § 6, stk.1.
Hvis enheden ikke udfører arbejde, der kan kategoriseres som tilhørende § 6, findes der et større krav om at der indhentes samtykke fra den registrerede, og udtrykkeligt samtykke, hvis der er tale om registrering af CPR-nummer. Et udtrykkeligt samtykke er forskelligt fra et almindeligt samtykke ved, at samtykket er adskilt fra andre oplysninger og betingelser, dvs. der skal være en særskilt samtykkeerklæring, der kun omhandler den registreredes samtykke til behandling af oplysninger.
4. Klagevejledning
Når man behandler data omkring personer er man fremover forpligtiget til at give en klagevejledning til de personer man registrerer. Det kan eventuelt indskrives i samtykkeerklæring.
I tilfælde af at den registrerede vil klage over den pågældende enheds behandling af dennes data, kan den registrerede rette henvendelse til enheden, med henblik på afklaring af grundlaget for klagen. Hvis den registrerede ikke vurderer, at dennes klage bliver behandlet tilfredsstillende, kan
vedkommende herefter gå videre med klagen til Datatilsynet. Datatilsynet vil i en sådan situation fungere som en uafhængig tredjepart.
Eksempel:
I tilfælde af klager over Væksthusets behandling af jeres data, bør der i første omgang rettes henvendelse til Væksthuset, med henblik på afklaring af grundlaget for klagen. Hvis du/I ikke vurderer, at jeres klage bliver behandlet tilfredsstillende, kan I herefter gå videre med klagen til Datatilsynet. Datatilsynets klagevejledning kan findes her – https://www.datatilsynet.dk/borger/klage-til-datatilsynet/
5. Løbende uddannelse af brugere
Vi skal sikre at brugerne løbende trænes i at håndtere data korrekt, derfor skal vi jævnligt orientere omkring deres forpligtigelser. Dette gøres på tre niveauer
1. DPO
2. Administratorer
3. Almindelige brugere
Dette håndteres vha. procedure for de to første og via ”reminders” i forbindelse med skift af kodeord for brugerne (hver 3. måned)
5.1 DPO-orientering
Der vil halvårligt udsendes et opdateret informationsark til alle der er registreret som DPO for aktive enheder i ESCRM.
Der udtrækkes en liste med modtagere (DPO’erne) og en mail sendes til alle. Efterfølgende skal der foretages opfølgning på de DPO’er hvor vi modtager en mailadressen findes ikke, dvs. Den angive DPO i en given enhed har ikke længere adgang til den pågældende mailadresse. Dette afstedkommer en kontakt fra ESCRM til kontaktpersonen ved enheden. Her skal vi oplyses om den nye DPO og dennes mailadresse.
Der sendes en ”Velkommen som DPO”-mail til vedkommende med oplysningsarket samt link til bloggen mm.
5.2 Admin-orientering
Der skal halvårligt orienteres til admins omkring deres forpligtigelser.
Dette sker via et særligt velkomstbillede til admins seks måneder efter det blev vist sidste gang. Dette billede skal vi sikre læses, f.eks. ved at det har været synlig on-top i x minutter før det kan klikkes væk, ellers kommer det igen ved næste login
5.3 Almindelige brugere
For almindelige brugere vil der være reminders i form af bullets i den form hvor de skifter kodeord, her vil enkelte regler blive fremhævet på skift. Derudover er det en del af DPO’ens forpligtigelser at sikre at brugerne i de enkelte enheder er bekendt med reglerne og registreringer i ESCRM.
6. Sikkerhed
Der indføres en række tiltag for at sikre overholdelse af vores forpligtigelser
1. Logning
2. Dataklassifikation
3. Anonymisering og sletning
4. Datascanner (måske)
6.1 Logning
Der indføres en logning i ESCRM på flere niveauer
Adgangslog
· Der registreres når en bruger logger ind (Succes)
· Ved forkert brugernavn/kodeord (Fejl)
Den enkelte log opbevares 6 måneder
Log af adgang til følsomme data
· Alle visninger af CPR-numre logges med brugernavn, ip-adresse og tidstempel
· Alle visninger af følsomme data logges med brugernavn, ip-adresse og tidstempel
· Ligeledes logges alle rapportudtræk af CPR-nummer og følsomdata for alle kontaktpersoner. Her promptes bruger for en årsag til udtrækket samt mulighed for at angive eventuelle modtagere af rapportens data.
Disse log informationer opbevares så længe den registrerede findes i systemet.
6.2 Dataklassifikation
For at vi kan lave anonymiseringen automatiseret er det nødvendigt at kunne klassificere data i systemet i forskellige kategorier.
I feltdesignerne i ESCRM vil alle felter kunne klassificeres som en af nedenstående:
1. Almindeligt data
2. Enhedsvæsentlig
3. CPR
4. Personhenførbar
5. Følsom
På baggrund af disse dataklassifikationer kan der foretages en automatisk anonymisering.
6.3 Anonymisering og sletning
Der er i systemet forskellige former for data og dermed forskellige måder at håndtere anonymisering.
Som nævnt i punkt 1.5 udløbstid på data, skal der allerede ved oprettelse tages stilling til en udløbsdato på alle aktiviteter, aktiviteter kan forlænge udløbstiden på kontakten.
Når en aktivitet, der ikke benytter dynamiske felter (felt designer) når sin udløbsdato skal den slettes, vi kan ikke anonymisere i fritekster og dokumenter. Aktiviteter markeret som ikke indeholdende persondata kan forblive i systemet, og har ikke nødvendigvis en udløbsdato. Alle aktiviteter med udløbsdato slettes når datoen overskrides.
Alle kontaktpersoner har en udløbsdato, denne opdateres løbende under aktive forløb. Efter en periode uden aktivitet vil udløbsdatoen overskrides og det medfører en anonymisering af personen. Anonymisering sker i henhold til dataklassifikation og den for hvert felt angivne anonymiseringsværdi.
Feltdesigneren
For felter med dataklassifikation 3+ skal der kunne angives en anonymiseringsværdi. Værdien angives for felter der gemmer en tekst eller en dato, øvrige berørte felter bliver nulstillet.
Tekster kan angives en fasttekst enten ”Anonymiseret”, ”Feltnavn”, ”” eller ”xxxx”. Datofelter vil vi kunne angive en fast dato baseret på data f.eks. ”start år”, ”start halvår” eller ”start kvartal”. Har man registreret 23. august 2014, da vil en anonymisering give ”1. januar 2014” ved ”start år” og en anonymisering ”start halvår” give ”1. juli 2014”, på den måde overholder vi datatype/integritet og man kan fortsat trække retvisende statistikker.
Anonymisering
Anonymiseringen er en proces der afvikles særskilt på serveren og der leveres en rapport til systemadministrator med id’er på kontakter der er anonymiseret. Der skal mindst halvårlig tages stikprøver blandt de der er anonymiseret i den seneste periode. Dette gøres enten ved udtræk fra dem der hoster løsningen med alt data for specifikke id’er. Eller i et specielt udviklet værktøj til formålet. Der skal laves dokumentation af denne kontrol.