Vi har i efteråret 2018 afholdt et webinar flere gange. For dem som ikke kunne deltage eller har brug for en opfrisker, kan man herunder tage webinaret i sit eget tempo.
Det er bygget op således at hvert slide har en lydfil (eller video) som forklarer indholdet, under lydfilen vil der til nogle slides følge en forenklet forklaring på hvad der bliver sagt eller ekstra information såsom tips. Vi anbefaler at man under alle omstændigheder lytter til filen.
Man har derfor mulighed for at genopfriske enkelte emner uden at gennemgå hele præsentationen.
God fornøjelse! 🙂
Forenklet:
Nye funktioner:
- Fremover skal man klassificere felter efter hvorvidt data er omfattet af persondataforanordningen.
- Da man ikke må beholde data uden god grund, vil man fremover skulle sætte et udløb hvorefter data bliver slettet eller anonymiseret.
- ESCRM har en funktion som kan sende mails ud vedr. samarbejde og data herunder, for at opfylde oplysningspligten. Man skal altid oplyse om hvilke data man behandler og hvorfor.
Ændringer:
- Hver enhed skal have en DPM (data protection manager) oplyst i systemet. DPM er vores kontaktperson, og vil stå i systemet som kontaktperson hvis en enhed ikke kan slette en kontaktperson grundet et udløb jeres enhed har sat på personen.
- Der vil komme en log, som registrere hver gang skjulte data bliver vist, f.eks. cpr nr.
- Cpr nr vil snart kun være synlige for erhvervshusene (på webinarets tidspunkt, væksthuse), da vi ikke kan stå inde for at alle skal have adgang til det. Cpr nr er ikke personfølsomt data men skal behandles som personfølsomt data. Hvis man har brug for at have et felt med cpr nr, kan man oprette dette.
- Fremover kan man ikke ændre CVR- og P-nummer, således sikre vi kontinuitet.
- Man skal kunne generere en liste over hvilke informationer der udløber hvornår, for at få bedre overblik over hvilke data systemet står til at slette og hvornår.
Forenklet:
Alle felter skal have en klassifikation, alt efter om det er indbefattet af persondataforordningen (GDPR) eller ej.
- Alm. data er data som ikke kan føres tilbage på en person, og som ikke er følsomt for virksomheden, alm. data har intet udløb.
- Enhedsvæsentlig data er data som låser en kontaktperson, det kan f.eks. være status på medlemskab. (se på årsag og positivliste nedenfor)
- Cpr har fået et specielt kodet felt, hvor det før stod som ddmmåå-xxxx kommer til at stå som ddmmåå-****, således at de sidste 4 cifre er skjult og det vil blive logget hvis en person vælger at se cifrene.
- Personhenførbar data er data som kan føres tilbage til en person og det bliver dermed indbefattet af persondataforordningen da man skal have en årsag til at gemme og behandle disse data.
- Følsomme informationer kan både være følsomme for personer og/eller virksomheder, disse data bliver skjult og det vil blive logget hvis en person tilgår disse data, ligesom med cpr nr.
- Positivliste er en liste over hvilke valgmuligheder der skal låse en kontaktperson hvis feltet et et rullegardin (ved tekst/tal-felt vil den altid låse). Så i tilfælde af at feltet hedder medlemskab vil positivlisten være “medlem”. Resterende muligheder f.eks. “udmeldt” vil dermed ikke låse en kontaktperson som har denne valgmulighed i feltet.
- Årsagstype skal vælges ud fra enten “Evaluering”, “Projekt” eller “Andet”.
- Årsag skal defineres, så detaljeret som muligt, da denne tekst skal informere en anden enhed om hvorfor en kontaktperson med denne data ikke kan slettes.
OBS! automatisk udløb er siden blevet ændret til 3 år
Fremover vil kontaktpersoner være afhængige af at der er gemt filer og noter på dem.
Dvs. at hvis man opretter en kontaktperson uden at gemme en note eller fil på (eller en anden indstilling som låser kontaktpersonen), vil den blive slettet efter 3 måneder.
Når en kontaktperson er oprettet og har filer eller noter gemt på sig, vil den være afhængig af deres udløb, dvs. så længe der er en aktiv fil eller note gemt på personen, vil den være berettiget i systemet.
Så snart alle filer og noter er udløbet, vil kontaktpersonen blive anonymiseret. Således beholder vi kun en persons data så længe det er relevant.
En anden måde at beholde en kontaktperson på, er ved at oprette et “enhedsvæsentlig felt” i “felter. Se vores guide i oprettelse af projektnoter for at se hvordan man opretter et enhedvæsensligt felt her (metoden er den samme for felter som for projektnoter). Sørg derefter for at tildele kontaktpersonen den data. Skal mange kontaktpersoner oprettes med den data, f.eks. at de er medlem, kan vi køre en batch opdatering såfremt at kontaktpersonerne kan defineres ud fra andet data, f.eks. en projektnote på virksomheden.
Forenklet:
I venstre side er indstillingerne for filen/noten, skal den slettes og hvornår skal den slettes.
Hvis man ikke mener at filen/noten indenholder følsomme eller personhenførbare oplysninger, kan man vælge “intet udløb” så noten aldrig bliver slettet. TIP: For at kunne bruge denne funktion kan man vælge at skrive “kontaktperson” i stedet for “Hans Jensen” i noten.
Hvis filen/noten indeholder følsom data, såsom en virksomheds produktudvikling, kan man markere “Indeholder følsom data”, hvor det vil blive logget hver gang en bruger tilgår filen/noten og den vil ikke blive delt med KL’s fælles virksomheds kontakt database.
I midten kan man markere hvilke kontaktpersoner filen/noten skal kobles op på.
I højre side er indstillingerne for kontaktpersonerne som er tilknyttet filen/noten.
Man kan vælge enten at låse kontaktpersonen eller beholdekontaktpersonen.
Forskellen på de to muligheder er at kontaktpersonen kan ikke annonyemiseres før valgte dato med “lås indtil”, hvor imod kontaktpersonen kan annonyemiseres før valgte dato med “behold indtil”, men hvis kontaktpersonen ikke bliver anonymiseret manuelt i den periode, vil systemet beholde kontaktpersonen indtil den valgte dato.
Endnu mere forenklet:
Lås indtil: Kontaktperson(er) bliver opretholdt i perioden og kan ikke slettes
Behold indtil: Kontaktperson(er) bliver opretholdt i perioden, men kan slettes manuelt
Med persondataforordningen er der informationspligt, hvilket betyder at alle enheder i escrm er skal informere om alt det listet i vores slide ovenfor her.
Man kan indsamle eller gemme aftaler i escrm, se demo 3.
Man kan oprette sin egen aftale i systemet, altså selv skrive teksten så den er tilpasset hvilke oplysninger i behandler osv.
Der findes i escrm et par koder, i kan bruge i teksten for at brugerdefinere dem, de er følgende:
%fornavn% : indsætter fornavn på kontaktpersonen
%efternavn% : indsætter efternavnet på kontaktpersonen
Så man kan skrive “Kære %fornavn% %efternavn%” for at få systemet til automatisk at skrive “Kære Lars Hansen” hvis aftalen sendes til Lars Hansen.
%email% : indsætter kontaktpersonens email.
Forenklet:
Ved hjælp af den røde bjælke, bliver man gjort opmærksom på om den pågældende kontaktperson har en aftale, hvilket de alle skal.
I den røde bjælke, kan man ved at trykke på “Tilføj kontaktaftale” enten gemme en aftale eller sende en aftale ud, afhængigt af hvad der er defineret på ens enhed.
Forenklet:
På projektnoter har man mulighed for at definere udløb.
Hvis noten ikke indeholder følsomme eller personhenførbare oplysninger, kan man vælge “intet udløb”, hvorefter projektnoten aldrig vil blive slettet (man skal dog stadig tage stilling til kontaktpersonerne)
Hvis noten indeholder følsomme eller personhenførbare oplysninger, skal man vælge om noten skal slettes helt eller blot anonymiseres og hvornår.
Man kan vælge en fast dato hvor alle oprettede projektnoter bliver slettet, dette kan bruges hvis det er en note tilknyttet et projekt som opholder en bestemt dag.
Det er dog mest sandsynligt at man vil bruge en beregnet dato hvor man først vægler et tal og hvilken måleenhed dette tal er i, f.eks. år.
Derefter skal man udfylde kontakt indstillinger.
Hvis det er vigtigt at en kontaktperson ikke bliver anonymiseret indtil en bestemt dato eller i et bestemt interval, kan man udfylde “lås indtil”, på samme måde som ovenover.
Hvis kontaktpersonen skal have mulighed for at blive slettet manuelt, kan man udfylde “behold indtil“, hvor kontaktpersonen bliver gemt indtil den valgte dato eller i det valgte interval (betinget af at noten ikke er slettet/anonymiseret).
Til slut har man mulighed for at vælge “bruger må ændre udløbet“, så indstillingerne bliver “default” hvor konsulenterne har mulighed for at ændre i dem.
Forenklet:
Da interessegrupper i sig selv ikke indeholder følsomme eller personhenførbare data, vil der ikke automatisk være udløb på.
Man har dog som administrator mulighed for at tilføje et udløb.
Udløbet er dog begrænset, således at man ikke har mulighed for at anonymisere eller låse kontaktpersoner.
Man har derimod mulighed for at sætte en bestemt dato hvor interessegruppen skal slettes, samt beholde kontaktpersoner indtil en bestemt dato (betinget af at interessegruppen ikke er slettet inden da).
Derfor skal man manuelt gå ind og ændre udløb hvis man har data liggende hvor det er nødvendigt eller lovpligtigt at beholde i mere end 3 år (OBS ændret fra 5 til 3 år).
Fremover skal man være opmærksom på at sætte et korrekt udløb, når man opretter filer/noter.
Demo 1 – Klassificering af felter i feltdesign
Demo 2 – Klassificering af felter i projektnote + udløb
Demo 3 – Funktion til informationspligt
Demo 4 – Udløb på note + sletning af låst kontaktperson + DPMs funktion
Ekstra demo – enheds-væsentlige felter på virksomheds-niveau
Tip til Generel awareness:
Det anbefales det at man undgår at bruge f.eks. 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.