Foto til artiklen Databeskyttelse ved systemvalg: krav til leverandører og behandling
Foto af Markus Winkler på Pexels

Regelefterlevelse

Databeskyttelse ved systemvalg: krav til leverandører og behandling

Den 25. maj 2018 fik databeskyttelsesforordningen virkning. Alle virksomheder skal kunne dokumentere, at de behandler persondata efter reglerne.

Dette er et redaktionelt pseudonym for udgivelsen, ikke en påstand om en uafhængigt verificeret personlig identitet. Oprindelig redaktionel kreditering: Jura- og complianceredaktionen.

Kortlæg behandlingen, før du vælger system

Den 25. maj 2018 fik databeskyttelsesforordningen virkning. Alle virksomheder skal kunne dokumentere, at de behandler persondata efter reglerne.

DI peger på, at manglende dokumentation i værste fald kan udløse store bøder. DI fremhæver, at man skal have styr på, hvilke data man behandler, og hvor de lagres og flyttes.

Kortlægningen er ikke et bilag til systemprojektet, men grundlaget for kravspecifikationen.

Kortlæg pr. proces og system, før funktionskravene skrives. Noter hvilke kategorier af personoplysninger der indgår – almindelige oplysninger, følsomme oplysninger, cpr-numre – og hvilke grupper af registrerede der er tale om – kunder, medarbejdere, ansøgere, børn.

Noter formål, behandlingsgrundlag og modtagere. Noter hvor oplysningerne opstår, hvor de lagres, og hvor længe.

Datatilsynets vejledninger »Hvornår behandler du personoplysninger«, »Grundlæggende principper«, »Behandlingsgrundlag« og »Fortegnelse« er de rette til at kvalificere kortlægningen.

Resultatet skal kunne genbruges direkte.

Fortegnelsen over behandlingsaktiviteter, som Datatilsynet vejleder om, og som DI har skabeloner til, indeholder de samme oplysninger, som leverandøren skal understøtte: Kan systemet udskille de enkelte kategorier, begrænse adgang, slette eller eksportere, og dokumentere, hvem der har gjort hvad?

Viser kortlægningen, at I skal kunne svare på en indsigts- eller sletteanmodning, er det et systemkrav – ikke en manuel opgave bagefter.

Saml kortlægningen pr. system i et dokument med version, dato og en navngiven ejer.

Ændrer kortlægningen sig – nyt modul, ny datakilde, ny integration – skal kravspecifikation og aftaler opdateres tilsvarende. Ellers beskriver dokumentationen en behandling, der ikke længere finder sted.

Rollefordeling før kravspecifikationen

Datatilsynet vejleder om »Dataansvarlig og databehandler« og om »Rollefordeling«.

Afklar tidligt, om din virksomhed er dataansvarlig, om leverandøren er databehandler eller underleverandør, og om leverandøren i nogle tilfælde selv bestemmer formålet.

Den dataansvarlige fastlægger formål og midler, dokumenterer behandlingen og svarer de registrerede. En databehandler behandler kun personoplysninger på instruks og på vegne af den dataansvarlige.

Rollerne skal ligge fast, før kravene formuleres, fordi de afgør, hvem der leverer hvad.

Er leverandøren databehandler, skal kravene formuleres som instrukser og bistandsforpligtelser.

Bruger leverandøren oplysningerne til egne formål – fx egne analyser eller produktudvikling – er det ikke en ren databehandlerrolle, og både aftalegrundlag og kravbillede ændrer sig. Det gælder også ved fælles dataansvar.

Skriv rollefordelingen ind i beslutningsgrundlaget: Hvem håndterer anmodninger om indsigt og sletning? Hvem vurderer og anmelder brud? Hvem må de registrerede kontakte?

Uden den fordeling kan hverken instruksen eller databehandleraftalen beskrive den konkrete behandling præcist.

Tegn samtidig leverandørkæden op: Hvilke underleverandører behandler oplysningerne, hvor sidder de, og hvad bestemmer de selv? Underleverandører skal fremgå af aftalen og af underleverandørlisten, så I til enhver tid kan se, hvor oplysningerne behandles.

Krav til leverandøren ud over funktionalitet

Formuler leverandørkravene som rækker i kravspecifikationen med et svar pr. krav – opfyldt, delvist opfyldt eller ikke opfyldt – og med den dokumentation, der skal leveres.

Kravene bør mindst dække dokumentation, behandlingssikkerhed, bistand ved registreredes rettigheder og håndtering af brud.

Datatilsynets vejledninger omfatter bl.a. »Iagttagelse af de registreredes rettigheder«, »Indsigt«, »Sletning«, »Tidsfrister og krav«, »Behandlingssikkerhed«, »Håndtering af brud på persondatasikkerheden« og »Anmeldelse af brud«.

Under dokumentation: I skal kunne vise, hvilke personoplysninger systemet indeholder, hvor de kommer fra, hvem der har adgang, og hvor de sendes hen.

Spørg, om systemet kan understøtte fortegnelsen, om leverandøren kan give skriftlig dokumentation for sikkerhedsforanstaltningerne, og om ændringer i opsætningen dokumenteres og versioneres.

Under bistand ved registreredes rettigheder: Beskriv, hvordan systemet finder og udleverer alle oplysninger om én person på tværs af moduler, hvordan oplysninger berigtiges eller slettes, og hvordan en sletteanmodning håndteres, når der samtidig findes backup, logfiler eller afledte kopier.

Datatilsynets vejledninger om sletning og om tidsfrister og krav kan bruges til at fastsætte, hvor hurtigt leverandøren skal bistå.

Under brud: Kravet er, at leverandøren uden unødig forsinkelse underretter jer, så I kan foretage den vurdering og anmeldelse, der påhviler den dataansvarlige.

Fastlæg, hvem der kontaktes, gennem hvilken kanal, med hvilke oplysninger – hvad er sket, hvilke data, hvor mange registrerede, hvad er gjort – og hvordan leverandøren dokumenterer hændelsen.

Datatilsynets oversigt »De 10 brud« og vejledning om håndtering af brud kan bruges til opfølgende spørgsmål til leverandørens procedurer.

Tag også exit med som krav: Kan data eksporteres i et maskinlæsbart format, hvad sker der ved aftalens ophør, og hvordan dokumenteres sletning hos leverandør og underleverandører?

Kritiske krav til leverandører i forhold til GDPR

Databehandleraftalen som levende styringsdokument

DI stiller skabeloner til rådighed til bl.a. databehandleraftaler, procesafdækning og dokumentation af databehandlingsaktiviteter.

Brug dem som udgangspunkt, men tilpas indholdet til den behandling, kortlægningen har vist: hvilke kategorier af personoplysninger, hvilke grupper af registrerede, hvilke formål og hvilken varighed aftalen dækker.

Aftalen bør indeholde en instruks om, hvad leverandøren må og ikke må gøre med oplysningerne, herunder forbud mod at bruge dem til egne formål.

Den bør beskrive, hvordan underleverandører godkendes, at listen over underleverandører holdes opdateret, og hvordan I underrettes og kan gøre indsigelse, inden en ny underleverandør tages i brug.

Den bør fastlægge sikkerhedsforanstaltninger, bistandsforpligtelser ved registreredes rettigheder, underretning ved brud, sletning eller tilbagelevering ved ophør og adgang til revision eller kontrol.

Gør aftalen til et styringsdokument ved at hænge den op på konkrete forhold.

Læg behandlingskortlægningen ind som bilag, og skriv aftalens varighed og opsigelsesvilkår sammen med slettefristerne.

Fastlæg, hvem i organisationen der ejer aftalen, hvornår den gennemgås, og hvordan ændringer – nyt modul, ny underleverandør, ændret lagringssted – udløser en opdatering af aftalen og bilagene.

Hvis leverandøren ensidigt kan ændre vilkår, sikkerhedsniveau eller underleverandører, har I reelt ikke den styring, aftalen skal give.

Datatilsynets vejledning om tidsfrister og krav kan bruges til at aftale frister for, hvor hurtigt leverandøren skal bistå og underrette.

Vigtige reguleringskrav efter Datatilsynet

Tidsfrist for indsigt
Maks. 1 måned efter anmodning.
Risiko for høj konsekvens
Konsekvensanalyse kræves før systemindførelse, hvis risikoen er stor.

Behandlingssikkerhed, risikovurdering og konsekvensanalyse

Vælg sikkerhedsforanstaltninger ud fra risiciene i den konkrete behandling – ikke ud fra en generel liste.

Datatilsynets vejledninger »Behandlingssikkerhed« og »Risikovurdering« samt »Katalog over sikkerhedsforanstaltninger« kan bruges til at oversætte risici til krav.

Genvejene på Datatilsynets side omfatter desuden behandlingssikkerhed, sletning, samtykke, »De 10 brud«, risikovurdering og konsekvensanalyse.

Start med de risici, kortlægningen har afdækket: Hvor mange registrerede berøres? Hvor følsomme er oplysningerne? Hvor mange interne og eksterne brugere har adgang?

Hvilke konsekvenser har misbrug, fejl eller tab? Hvor svært er det at genoprette?

Omsæt hver risiko til et krav i kravspecifikationen med en tilhørende test, så sikkerhedsniveauet kan efterprøves i stedet for blot at være erklæret.

Datatilsynet har vejledning om konsekvensanalyse.

Rummer behandlingen en høj risiko for de registreredes rettigheder, bør konsekvensanalysen gennemføres, inden systemet tages i brug og før leverandørvalget er endeligt bundet, så konklusionerne kan påvirke valg af løsning og sikkerhedsforanstaltninger.

Involvér leverandøren i at levere de oplysninger, analysen kræver: dataflow, adgangsroller, logning, slettefunktioner og underleverandørkæde.

Er teknologien cloudbaseret eller indeholder den kunstig intelligens, har Datatilsynet særskilte temaer om netop cloud og kunstig intelligens.

Læs dem som en del af risikovurderingen, fordi teknologivalget ændrer, hvor data ligger, hvem der har adgang, og hvordan oplysninger viderebehandles.

Hvor er data, og hvordan slettes de?

Spørg konkret: I hvilket land ligger datafilerne, hvor ligger backup, hvor ligger logfiler, og hvorfra kan leverandørens personale få adgang til oplysningerne?

Datatilsynet har vejledning om »Overførsel til tredjelande« og et tema om cloud.

De hænger sammen, fordi en cloudopsætning typisk betyder, at lagringssted, supportadgang og underleverandører ikke nødvendigvis er samme sted.

Bed om en liste over underleverandører med behandlingssted og rolle.

Bed også om at få oplyst, hvordan fjernadgang foregår, hvem der kan give sig selv eller andre adgang, og hvordan adgang logges.

Kravet om adgangsstyring skal kobles til de roller, I selv har defineret i kortlægningen: hvem må se hvad, og hvem må rette og slette.

Datatilsynet har en vejledning om sletning.

Aftal, hvad sletning betyder i praksis – om oplysninger slettes eller anonymiseres, om de forbliver i backup og i hvor lang tid, hvordan afledte kopier og logfiler håndteres, og hvordan leverandøren dokumenterer, at sletningen er gennemført.

Sæt konkrete frister for, hvor hurtigt sletning skal ske ved aftalens ophør og ved en anmodning fra en registreret.

Sikr samtidig eksportvejen: Hvilke formater kan data udtrækkes i, kan udtrækket afgrænses til én registreret, og kan det gøres uden leverandørens medvirken, hvis aftalen ophører?

Uden en dokumenteret eksport- og slettefunktion risikerer I at hænge på en leverandør, netop når oplysningerne skal slettes.

Test før go-live, og dokumentér løbende

Test de krav, der ikke kan ses på en funktionsliste: Opret en testbruger med begrænsede rettigheder, og kontrollér, at vedkommende ikke kan se eller rette mere end tilsigtet.

Kontrollér, at administrative rettigheder er knyttet til navngivne personer.

Udfør en sletning, og kontrollér, at oplysningen faktisk forsvinder fra systemet, og hvad der sker i backup og logfiler.

Udfør et udtræk af alle oplysninger om én registreret, og vurdér, om resultatet kan besvare en indsigtsanmodning.

Test også, at en hændelse udløser en underretning til jer, og hvem der modtager den.

Dokumentér testen med dato, udførende, forventet og faktisk resultat. Gem afvigelser med en plan for udbedring.

Afvigelser, der ikke er lukket ved go-live, bør beskrives som en kendt risiko med ejer og frist.

Hold dokumentationen samlet og versionsstyret pr. system: fortegnelse over behandlingsaktiviteter, risikovurderinger, konsekvensanalyser, databehandleraftale med bilag, underleverandørliste, beskrivelse af sikkerhedsforanstaltninger, testresultater og log over hændelser og brud.

DI peger på, at virksomheder skal kunne dokumentere, at de behandler persondata efter reglerne, og at manglende dokumentation i værste fald kan udløse store bøder.

Datatilsynet har vejledning om fortegnelse og om håndtering af brud på persondatasikkerheden samt om databeskyttelsesrådgivere.

Har I en databeskyttelsesrådgiver, bør vedkommende indgå i vurderingen af systemvalg, i gennemgangen af databehandleraftaler og i vurderingen af hændelser, så de samme vurderinger ikke laves to gange med forskelligt resultat.

Mere fra Regelefterlevelse