Software til fortegnelsen skal gøre det muligt at beskrive virksomhedens behandlingsaktiviteter, forbinde oplysningerne og holde dem ajour. Den afgørende forskel ligger sjældent i, om et system har felter med artikelnumre. Den ligger i, om fagpersoner kan registrere virkeligheden forståeligt, om ændringer bliver opdaget, og om en ansvarlig kan forklare den godkendte version.
ROPA er en engelsk forkortelse for fortegnelse over behandlingsaktiviteter. Denne guide handler om valg og indførelse af et værktøj til fortegnelsen: datamodellen, importen, arbejdsdelingen og den løbende vedligeholdelse. Den erstatter ikke den juridiske afgrænsning af fortegnelsespligten. Den hjælper med at omsætte denne afgrænsning til et system, virksomheden faktisk kan bruge efter den første kortlægning.
Fastlæg pligten og rollen før opsætningen
GDPR artikel 30 har forskellige indholdskrav til dataansvarlige og databehandlere. Virksomheden kan have begge roller for forskellige aktiviteter og bør kunne holde dem adskilt. En leverandør, der behandler kundedata på kunders vegne, har ikke nødvendigvis samme fortegnelsesindhold for den aktivitet som for sin egen personaleadministration. Et system bør gøre rollen synlig og bruge en passende struktur.
Undtagelsen for organisationer med under 250 ansatte i artikel 30, stk. 5, er betinget. Den gælder ikke for behandlinger, der sandsynligvis indebærer risiko for personers rettigheder og frihedsrettigheder, ikke er lejlighedsvise eller omfatter oplysninger efter artikel 9 eller 10. Derfor kan en lille virksomhed være forpligtet til at føre fortegnelse over tilbagevendende behandlinger. Medarbejdertallet alene kan ikke afgøre, om registeret kan undværes.
Brug Datatilsynets vejledning om fortegnelser og gennemgangen af artikel 30 til denne afgrænsning. Herefter kan kravene omsættes til felter, relationer og arbejdsgange. Hvis leverandøren tilbyder en automatisk vurdering af pligten, bør en ansvarlig kunne se og kontrollere dens forudsætninger, før den lægges til grund.
Skeln mellem minimumsfelter og nyttig dokumentation
Den dataansvarliges fortegnelse omfatter blandt andet navn og kontaktoplysninger for relevante parter, formål, kategorier af registrerede og personoplysninger samt kategorier af modtagere. Internationale overførsler skal beskrives med de oplysninger, som artikel 30 kræver. Hvor det er muligt, indgår forventede slettefrister og en generel beskrivelse af tekniske og organisatoriske sikkerhedsforanstaltninger.
Databehandlerens fortegnelse omfatter blandt andet navn og kontaktoplysninger for databehandleren og de dataansvarlige, kategorierne af behandling på hver dataansvarligs vegne, relevante overførsler og, hvor det er muligt, en generel sikkerhedsbeskrivelse. Et produkt, der kun har én generisk skabelon, bør derfor afprøves mod begge roller, hvis de er relevante. En rollemarkering alene ændrer ikke indholdet.
Behandlingsgrundlag, interne ejere, systemnavne og links til aftaler kan være meget nyttige supplerende oplysninger. De er ikke alle selvstændigt opregnet som minimumsfelter i artikel 30. Skeln mellem forordningens udtrykkelige indholdskrav og virksomhedens bredere dokumentationsbehov. Det gør både oplæring og kvalitetskontrol mere præcis og forhindrer, at et produkts egne felter bliver præsenteret som lovens ordlyd.
Vælg et meningsfuldt niveau for behandlingsaktiviteter
En fortegnelse er ikke blot en liste over IT-systemer. Samme system kan understøtte flere formål, og samme aktivitet kan foregå i flere systemer. Hvis CRM-systemet både bruges til kundeadministration og særskilt markedsføring, bør strukturen kunne vise forskellene. Omvendt behøver hvert enkelt datafelt eller hver teknisk overførsel ikke blive en selvstændig aktivitet, hvis det gør overblikket uforståeligt.
Afprøv niveauet med to repræsentative processer. Bed fagansvarlige forklare, hvad de gør, hvem oplysningerne vedrører, og hvorfor oplysningerne bruges. Se derefter, om beskrivelsen kan læses af en person uden specialviden om afdelingen. For brede aktiviteter skjuler væsentlige forskelle; meget små aktiviteter skaber gentagelser og kan gøre vedligeholdelsen uforholdsmæssigt vanskelig. Det rette niveau skal kunne begrundes i jeres behandlinger.
Brug kortlægningen af IT-systemer og afhængigheder som en tilknyttet oversigt. Den kan vise, hvor behandlingerne foregår, hvilke leverandører der indgår, og hvem der vedligeholder systemerne. Hold samtidig formål og behandling adskilt fra den tekniske komponent. Når en applikation skiftes, skal virksomheden kunne se, om formålet er uændret, og hvilke øvrige oplysninger der skal vurderes igen.
Undersøg relationerne mellem oplysningerne
En flad formular med lange tekstfelter kan være enkel at begynde med, men bliver vanskelig at vedligeholde, når de samme leverandører og systemer optræder mange steder. En fælles leverandøroplysning kan mindske dobbeltarbejde, hvis ændringer slår korrekt igennem. Det kræver dog, at relationerne er tydelige, og at en rettelse ikke ændrer historiske beskrivelser uden spor.
Datatilsynet præciserede i sin opdaterede vejledning fra august 2020, at oplysningerne skal kunne forbindes meningsfuldt. Blandt andet skal kategorier af oplysninger kunne knyttes til kategorier af registrerede, og oplysninger om videregivelse skal vise relevante sammenhænge. Det er en væsentlig praktisk kontrol af datamodellen, ikke blot et spørgsmål om at have alle overskrifterne med.
I demonstrationen kan I bruge en rekrutteringsaktivitet med ansøgere og referencer. Bed leverandøren vise, hvilke oplysninger der vedrører hver gruppe, og hvilke oplysninger en ekstern rekrutteringspartner modtager. Hvis systemet kun viser tre uforbundne lister med personer, data og modtagere, kan sammenhængen blive uklar. Den valgte model bør gøre det muligt at beskrive relationerne uden gentagen fri tekst alle steder.
Beskriv sletning og sikkerhed, så oplysningerne kan anvendes
En opbevaringsperiode bør være mere præcis end «så længe det er nødvendigt», når virksomheden kan fastlægge en relevant periode eller et anvendeligt kriterium. Beskriv, hvad der starter perioden, om der er forskellige oplysningsgrupper, og hvilke undtagelser der faktisk kan opstå. Skeln mellem den godkendte regel og de tekniske systemers nuværende evne til at gennemføre den.
Et fortegnelsesværktøj sletter normalt ikke oplysningerne i de underliggende systemer blot ved at ændre et felt. Afprøv derfor, hvordan en uoverensstemmelse mellem beskrevet og faktisk sletning bliver registreret og fulgt op. Retten til sletning er et særskilt spørgsmål, som kan udløse konkrete handlinger. En opbevaringsbeskrivelse er vigtig, men løser ikke automatisk alle anmodninger eller undtagelser.
Sikkerhedsbeskrivelsen skal kunne forstås på et passende niveau uden at sprede unødvendige tekniske hemmeligheder. Knyt gerne til kontrolleret dokumentation om sikkerhedsforanstaltninger efter artikel 32, når det er relevant. Kontroller, hvem der må se bilagene. Et bredt læsebehov for fortegnelsen betyder ikke, at alle brugere skal kunne hente detaljer om sikkerhedsarkitektur eller interne sårbarheder.
Gør importen til en kontrolleret migrering
Før I importerer eksisterende dokumenter, skal I kende kvaliteten. Et regneark kan indeholde dubletter, forskellige navne for samme leverandør og tomme felter, der betyder forskellige ting. Beslut, hvilke oplysninger der skal samles, hvilke der skal undersøges, og hvilke der må bevares som historik. Importen bør ikke gøre usikre oplysninger til godkendte fakta ved at placere dem i et nyt system.
Brug først et lille udsnit med både enkle og vanskelige poster. Bevar en identifikation af kilden, så en importeret oplysning kan spores tilbage. Sammenlign antal aktiviteter, relationer, bilag og tegnsætning, og få fagansvarlige til at læse resultatet. Et korrekt antal rækker er utilstrækkeligt, hvis relationen mellem aktivitet og leverandør er gået tabt eller teksten er blevet afkortet.
Fortegnelsesskabelonen kan give et fælles udgangspunkt for oprydningen. Aftal derefter en skæringsdato og en ansvarlig for ændringer under migreringen. Hvis medarbejdere samtidig retter i gamle filer og i den nye løsning, kan begge versioner hurtigt blive ufuldstændige. Planen skal derfor forklare, hvilken version der er gældende, og hvordan nye oplysninger føres ind.
Fordel ejerskab uden at overlade alt til koordinatoren
Hver aktivitet bør have en faglig ejer, som kender den faktiske behandling, og en tydelig vej til kvalitetssikring. Koordinatoren kan sørge for fælles struktur og opfølgning, men kan sjældent vide, hvordan alle afdelinger bruger oplysninger. Softwaren bør understøtte, at ejeren besvarer relevante spørgsmål, mens juridiske eller tekniske tvivlspunkter sendes til en passende fagperson.
Skeln mellem udkast og godkendt indhold. Et udfyldt felt bør ikke automatisk blive autoritativt, hvis oplysningerne endnu ikke er undersøgt. Lad demonstrationen omfatte en ejer, som ikke kender alle svar, og en reviewer, der beder om præcisering. Se, om usikkerhed, kommentarer og begrundelser kan bevares, uden at de blandes sammen med den endelige beskrivelse.
En databeskyttelsesrådgiver, hvor rollen er relevant, kan rådgive og overvåge, men bliver ikke dermed automatisk ejer af alle behandlinger. Fordelingen bør passe til virksomhedens organisation. Når en procesansvarlig stopper, skal opgaver og adgang kunne overdrages. Afprøv dette konkret, så registeret ikke mister ejerskab, hver gang en medarbejder forlader virksomheden.
Brug ændringer som udløser for opdatering
En kalenderpåmindelse kan hjælpe, men ændringer bør også fanges, når de sker. Ny software, nye formål, ændrede oplysningskategorier og nye modtagere er eksempler på relevante signaler. Knyt fortegnelsesarbejdet til indkøb, projektgodkendelse og ændringsstyring. Det giver bedre mulighed for at opdatere beskrivelsen før eller samtidig med, at behandlingen ændres.
Prøv et scenario, hvor en leverandør tilføjer support fra en ny lokation. Registeret bør kunne vise de berørte aktiviteter og udløse en vurdering af aftaler, adgang og eventuelle overførsler. En databehandleraftale efter artikel 28 er en del af dokumentationen, men fortegnelsen skal også vise selve behandlingen og de relevante modtagere. Et link til en aftale erstatter ikke de øvrige oplysninger.
Bevar historikken med dato og begrundelse for væsentlige ændringer. Virksomheden kan senere få brug for at forklare, hvordan behandlingen så ud på et bestemt tidspunkt. En samlet status «opdateret» siger mindre end en registrering af, hvad der blev vurderet, og hvilke forudsætninger der blev ændret. Afklar, om systemets historik følger med i en eksport og kan forstås uden adgang til produktet.
Forbind fortegnelsen med andre opgaver uden at forveksle dem
Fortegnelsen kan hjælpe med at finde de systemer og ansvarlige, der er relevante for en indsigtsanmodning. Den indeholder normalt ikke alle konkrete oplysninger om ansøgeren. DSAR-software har derfor et andet formål: at styre søgning, gennemgang og svar i en konkret sag. Undersøg, hvordan de to arbejdsgange kan dele grunddata, uden at sagsmateriale bliver spredt unødigt.
En aktivitet med særlige risikoforhold kan også have behov for en konsekvensanalyse. Systemet kan gøre vurderingsbehovet synligt og knytte analysen til den rigtige version af aktiviteten. Det må ikke automatisk konkludere, at alle risici er håndteret, fordi en fil er vedhæftet. Dokumentationens kvalitet og de faktiske foranstaltninger skal stadig vurderes.
Ved overlap med cybersikkerhed kan en fælles systemoversigt være nyttig. NIS2-software vedrører dog også tjenester og driftsrisici, som ikke er identiske med persondatabehandling. Brug den bredere sammenligning af GDPR-software til at vurdere integrationen. Undgå at lade et fælles produktnavn skjule, at registrene beskriver forskellige forhold og har forskellige brugere.
Afprøv adgang, udtræk og tilgængelighed
Fortegnelsen skal foreligge skriftligt, herunder elektronisk, og kunne stilles til rådighed for tilsynsmyndigheden efter anmodning. En brugbar eksport bør derfor kunne vise de nødvendige oplysninger samlet og forståeligt. Der findes ikke ét generelt obligatorisk produktformat. Lad en medarbejder fremstille et udtræk for en bestemt juridisk enhed uden leverandørens hjælp og kontrollere det mod de godkendte oplysninger.
Test adgang på tværs af afdelinger og selskaber. En lokal procesejer kan have behov for at redigere egne aktiviteter og læse fælles beskrivelser, mens en ekstern rådgiver kun skal se et afgrænset område. Kontroller også søgning, vedhæftninger og eksport. Begrænsninger i brugerfladen er ikke tilstrækkelige, hvis de samme oplysninger stadig kan hentes gennem en bred rapport.
Afprøv desuden, hvad virksomheden kan gøre, når tjenesten er utilgængelig eller aftalen afsluttes. Et periodisk kontrolleret udtræk kan støtte kontinuitet, hvis det opbevares sikkert og ikke bliver en konkurrerende redigerbar hovedversion. Beskriv, hvem der må bruge det, og hvordan ændringer håndteres efter genoprettelse. Det gør beredskabet anvendeligt uden at skabe nye ukontrollerede kopier.
Kontroller kvaliteten med stikprøver
Vælg jævnligt enkelte aktiviteter og sammenhold beskrivelsen med fagafdelingens faktiske arbejde. Spørg eksempelvis, om den registrerede leverandør stadig anvendes, om modtagerne er korrekte, og om slettereglen kan gennemføres. Formålet er at finde konkrete afvigelser og rette årsagen, ikke blot at genbekræfte alle felter med et klik.
Skeln i opfølgningen mellem manglende svar og en faktisk konstateret mangel. Begge dele kræver opmærksomhed, men de fortæller noget forskelligt. En kvalitetsrapport bør vise, hvilke aktiviteter der er vurderet, hvilke oplysninger der er usikre, og hvem der følger op. Antallet af grønne poster er kun meningsfuldt, hvis kriterierne for godkendelse er kendte og anvendes konsekvent.
Sammenlign tilbud på datamodellen og driftsarbejdet
Indhent tilbud på samme antal aktiviteter, juridiske enheder, bidragydere og ønskede integrationer. Bed om at få oplyst, om import, rådgivning, tilpasning af felter og oplæring er inkluderet. Prisguiden kan bruges til at strukturere sammenligningen. En pris pr. bruger siger ikke nok, hvis virksomheden også skal betale for eksterne bidragydere eller hver ny registerdel.
Vurder det interne arbejde efter indførelsen. Hvem retter fælles navne, kontrollerer relationer og følger op på ubesvarede spørgsmål? Hvis løsningen kræver omfattende manuel koordinering, bør det indgå i beslutningen. Omvendt kan et enkelt system være tilstrækkeligt, hvis aktiviteterne er få og stabile. Guiden til valg af GDPR-software kan støtte afgrænsningen af produktkategorier.
Et beslutningsnotat bør indeholde resultatet af prøveimporten, vurderingen af datamodellen, arbejdsdelingen og eksportprøven. Angiv også de væsentlige mangler, der skal løses før drift. Den danske databeskyttelsesguide giver den bredere ramme, men den konkrete anskaffelse afgøres af, om virksomhedens faktiske behandlinger kan beskrives, vedligeholdes og forklares i den valgte løsning.
Ofte stillede spørgsmål
Er Excel ulovligt til fortegnelsen?
Nej. Forordningen kræver et bestemt indhold og en skriftlig form, herunder elektronisk, men ikke et bestemt produkt. Et regneark kan fungere, hvis det er tilstrækkeligt, ajourført, sikkert og tilgængeligt. Overvej et andet værktøj, når samarbejde, relationer eller versionsstyring gør det vanskeligt at opretholde den nødvendige kvalitet.
Kan softwaren holde registeret ajour automatisk?
Den kan hente bestemte oplysninger og sende påmindelser, hvis funktionerne findes og er korrekt opsat. Formål, roller og faktisk brug kan ikke uden videre udledes af en teknisk forbindelse. En ansvarlig skal kontrollere ændringer og mangler. Bed leverandøren vise, hvordan fejl eller manglende data bliver synlige, så stilhed ikke forveksles med ajourføring.
Skal alle felter udfyldes for at kunne godkende en aktivitet?
De krævede oplysninger skal være tilstrækkeligt beskrevet, men nogle felter kan være betingede eller supplerende. En god arbejdsgang skelner mellem ikke relevant, endnu ukendt og faktisk udfyldt. Et krav om vilkårlig tekst i alle felter kan skabe falsk sikkerhed; begrundede vurderinger og opfølgning på mangler giver et bedre grundlag.