Compliance › Software

GDPR software: 10 funktioner, I skal teste, før I vælger

GDPR software skal kunne bære det, forordningen faktisk kræver. Se de 10 funktioner koblet til GDPR-artiklerne, et scorecard til jeres demo og de røde flag, I skal kende.

Se video af features

Et dashboard i GDPR-software med ti funktioner og et scorecard til at vurdere dem i en demo

De fleste, der skal vælge GDPR software, får den samme oplevelse. Tre leverandører viser tre pæne dashboards, alle siger "fortegnelse", "risikovurdering" og "leverandørstyring", og efter den sidste demo er det svært at sige, hvad der egentlig var forskellen.

Forskellen ligger sjældent i listen over funktioner. Den ligger i, om funktionen kan bære det, databeskyttelsesforordningen faktisk kræver af jer. En fortegnelse, der ikke kan vise hvilke kategorier af personoplysninger der går til hvilken modtager, lever ikke op til Datatilsynets forventninger. Et brudmodul, der tæller 72 timer fra forkert tidspunkt, er værre end intet modul.

Denne artikel gennemgår de 10 funktioner, GDPR software skal have, og kobler hver af dem til den artikel i forordningen, den understøtter. Til sidst får I et scorecard, I kan tage med i jeres næste demo, et regneeksempel med tre leverandører og en liste over røde flag. Er I endnu ikke sikre på, om I overhovedet har brug for et system, så start med vores artikel om hvornår GDPR compliance software giver mening.

Det korte svar: hvilke funktioner skal GDPR software have?

GDPR software skal hjælpe jer med at dokumentere og vedligeholde fem ting: hvad I behandler (fortegnelsen efter art. 30), hvorfor og hvor længe (grundlag og slettefrister), hvor risikoen er (art. 24, 32 og 35), hvem der behandler på jeres vegne (art. 28) og hvad der sker, når noget går galt eller en registreret henvender sig (art. 33-34 og 12-22). Oven på det skal systemet kunne fordele opgaver, styre roller og vise historik, så I kan påvise overholdelse efter ansvarlighedsprincippet i art. 5, stk. 2.

Test hver funktion med et konkret scenarie i demoen i stedet for at se en rundvisning. Og vær skeptisk over for enhver leverandør, der lover "automatisk compliance". Ingen software træffer de juridiske vurderinger for jer.

Hvad GDPR software er, og hvad det ikke er

Søgninger på "GDPR system" og "bedste GDPR software" blander fire forskellige produktkategorier sammen. De løser forskellige opgaver, og en leverandør i én kategori dækker sjældent de andre godt. Vi har beskrevet kategorierne mere udførligt i vores gennemgang af, hvad GDPR compliance software er. Her er den korte version.

Kategori	Hvad den gør	Typiske GDPR-artikler	Dækket af denne artikel?
Dokumentations- og styringsplatform	Fortegnelse, risikovurderinger, DPIA, databehandlere, opgaver, brud- og rettighedslog	Art. 5, stk. 2, 24, 28, 30, 32-35	Ja, det er hovedemnet
Samtykke- og cookieværktøj (CMP)	Cookiebanner og registrering af samtykke på hjemmesider og apps	Art. 7 og cookiebekendtgørelsen	Kun som afgrænsning
Data discovery og DLP	Skanner systemer for personoplysninger og blokerer uønsket deling	Understøtter art. 32	Kun som afgrænsning
Sikker kommunikation og sletteværktøjer	Krypteret e-mail, automatisk sletning i konkrete systemer	Understøtter art. 5, stk. 1, litra e, og 32	Nej

Resten af artiklen handler om den første kategori, fordi det er den, de fleste compliance-ansvarlige, DPO'er og jurister mener, når de siger GDPR software. Har I brug for cookiesamtykke, er det et separat indkøb. Cookies reguleres i Danmark af cookiebekendtgørelsen og ikke af GDPR alene.

De 10 funktioner koblet til GDPR-artiklerne

Tabellen viser hver funktion, den bestemmelse den understøtter, og hvilket bødeniveau en overtrædelse ligger på efter art. 83. I Danmark udstedes bøder ikke af Datatilsynet selv. Tilsynet politianmelder, og domstolene fastsætter bøden efter databeskyttelseslovens § 41.

Funktion	Understøtter	Bødeniveau (art. 83)
1. Fortegnelse og data mapping	Art. 30, stk. 1-5	Op til 10 mio. EUR / 2 % (stk. 4)
2. Formål, behandlingsgrundlag og slettefrister	Art. 5, stk. 1, litra b og e, art. 6 og 9	Op til 20 mio. EUR / 4 % (stk. 5)
3. Risikovurdering	Art. 24 og 32	Op til 10 mio. EUR / 2 % for art. 32
4. Konsekvensanalyse (DPIA)	Art. 35 og 36	Op til 10 mio. EUR / 2 %
5. Databehandlere og leverandører	Art. 28 og art. 44-46	Art. 28: 10 mio. / 2 %. Overførsler: 20 mio. / 4 %
6. Brudregistrering og anmeldelse	Art. 33 og 34	Op til 10 mio. EUR / 2 %
7. De registreredes rettigheder	Art. 12, stk. 3, og art. 15-22	Op til 20 mio. EUR / 4 %
8. Opgavestyring og årshjul	Art. 24, stk. 1, og art. 32, stk. 1, litra d	Afhænger af den forpligtelse, der forsømmes
9. Roller, adgang og koncernstruktur	Art. 32 og art. 38, stk. 1	Op til 10 mio. EUR / 2 %
10. Historik og rapportering	Art. 5, stk. 2, og art. 30, stk. 4	Afhænger af den forpligtelse, der ikke kan påvises

Ti nummererede funktioner i GDPR software, fra fortegnelse til historik, hver mærket med de GDPR-artikler, den understøtter

1. Fortegnelse og data mapping (art. 30)

Fortegnelsen er rygraden. Art. 30, stk. 1 kræver, at den dataansvarlige for hver behandlingsaktivitet registrerer formål, kategorier af registrerede og personoplysninger, modtagere, tredjelandsoverførsler og, hvis muligt, slettefrister og en generel beskrivelse af sikkerhedsforanstaltningerne. Databehandlere har deres egen, kortere fortegnelse efter stk. 2. Undtagelsen i stk. 5 for virksomheder under 250 ansatte bortfalder, så snart behandlingen ikke er lejlighedsvis, indebærer en risiko eller omfatter særlige kategorier. I praksis gælder den derfor sjældent for en virksomhed med ansatte og kunder.

Datatilsynet går et skridt længere end minimumsteksten. I sin opdaterede vejledning fra august 2020 skriver tilsynet, at fortegnelsen skal vise en tydelig kobling mellem hvilke kategorier af personoplysninger, der behandles om hvilke kategorier af registrerede, og hvilke oplysninger der videregives til hvilke modtagere. Det er præcis dér, et regneark bryder sammen, og hvor en god data mapping-funktion viser sin værdi.

Se efter en struktur, hvor behandlingsaktiviteter, it-systemer og leverandører er selvstændige objekter, der linkes til hinanden. Så opdaterer I et system ét sted, og alle de aktiviteter, der bruger det, følger med. Vores artikel om artikel 30-fortegnelsen gennemgår indholdskravene i detaljer.

2. Formål, behandlingsgrundlag og slettefrister (art. 5, 6 og 9)

Hver behandlingsaktivitet skal have et formål og et grundlag. Samtykke er ét af seks behandlingsgrundlag i art. 6, stk. 1, og langt fra det mest almindelige i en virksomhed med ansatte og kunder. Løn hviler typisk på retlig forpligtelse og kontrakt, helbredsoplysninger i en sundhedssammenhæng typisk på art. 9, stk. 2, litra h. Et system, der kun har et felt til "samtykke", er bygget til en anden brugssituation end jeres.

Slettefristen er den funktion, der oftest mangler. Princippet om opbevaringsbegrænsning i art. 5, stk. 1, litra e, betyder, at hver kategori af oplysninger skal have en defineret frist. EDPB's koordinerede tilsynsaktion om retten til sletning, hvis rapport blev vedtaget 18. februar 2026, fandt netop, at mange dataansvarlige havde svært ved at fastlægge opbevaringsperioder. Softwaren sletter ikke data i jeres systemer, men den skal kunne registrere fristen pr. datakategori og minde ejeren om at kontrollere, at sletningen sker.

3. Risikovurdering (art. 24 og 32)

Art. 32 kræver et sikkerhedsniveau, der passer til risikoen for de registreredes rettigheder og frihedsrettigheder. Kryptering og pseudonymisering nævnes som eksempler, ikke som krav. Det betyder, at I skal kunne vise, hvordan I har vurderet risikoen, før I kan begrunde jeres foranstaltninger.

Et godt risikomodul vurderer konsekvens og sandsynlighed for de registrerede, ikke kun for virksomheden. Det skal kunne vurdere både behandlingsaktiviteter, systemer og leverandører med samme metode, og det skal vise restrisikoen efter foranstaltninger. Vores artikel om risikostyring på tværs af GDPR, NIS2 og ISO 27001 viser, hvordan én metode kan dække flere forpligtelser.

4. Konsekvensanalyse, DPIA (art. 35)

Når en behandling sandsynligvis indebærer en høj risiko, skal der laves en konsekvensanalyse efter art. 35. Stk. 7 kræver fire elementer: en systematisk beskrivelse, en vurdering af nødvendighed og proportionalitet, en vurdering af risiciene og de planlagte foranstaltninger. Datatilsynet har offentliggjort en liste over behandlinger, der altid kræver en konsekvensanalyse, og en skabelon, også i en særlig version til AI.

Test to ting i demoen. For det første: hjælper systemet jer med den indledende vurdering af, om en DPIA er nødvendig, med Datatilsynets liste og EDPB's kriterier som udgangspunkt? For det andet: har skabelonen et selvstændigt afsnit om nødvendighed og proportionalitet? Mange skabeloner springer direkte til en risikomatrix, og så mangler et lovpligtigt element. Viser analysen høj restrisiko, skal I høre Datatilsynet efter art. 36, og det skal kunne registreres. Læs mere i vores guide til konsekvensanalyser.

5. Databehandlere og leverandørstyring (art. 28)

En databehandleraftale kræves kun med databehandlere, altså leverandører, der behandler personoplysninger på jeres vegne og efter jeres instruks. Ikke med alle tredjeparter. Art. 28 kræver, at I kun bruger databehandlere, der giver tilstrækkelige garantier (stk. 1), at underdatabehandlere godkendes (stk. 2 og 4), og at aftalen giver jer ret til revision (stk. 3, litra h).

Tilsynet er den del, der halter. Datatilsynets vejledning om tilsyn med databehandlere fra oktober 2021 bruger en pointmodel, hvor mængden og følsomheden af oplysningerne afgør, hvor tungt tilsynet skal være. EDPB's udtalelse 22/2024 fra oktober 2024 slår fast, at den dataansvarlige skal have oplysninger om identiteten på alle databehandlere og underdatabehandlere i kæden. Et godt leverandørmodul kan derfor registrere underdatabehandlere, tilknytte erklæringer som ISAE 3000, planlægge tilsyn efter risiko og vise tredjelandsoverførsler med overførselsgrundlag. Vores artikel om tredjelandsoverførsler forklarer det sidste.

6. Brudregistrering og anmeldelse (art. 33 og 34)

Datatilsynet modtog 9.849 anmeldelser af brud på persondatasikkerheden i 2025, det højeste antal siden anmeldelsespligten blev indført i maj 2018, ifølge tilsynets årsberetning for 2025. Brudhåndtering er en driftsopgave, ikke en undtagelse.

Art. 33, stk. 1 kræver anmeldelse til Datatilsynet uden unødig forsinkelse og om muligt senest 72 timer efter, at I er blevet bekendt med bruddet, medmindre det er usandsynligt, at det indebærer en risiko. De registrerede skal efter art. 34 underrettes uden unødig forsinkelse, når bruddet sandsynligvis indebærer en høj risiko. De 72 timer gælder altså anmeldelsen til tilsynet, ikke underretningen af de registrerede. Og art. 33, stk. 5 kræver, at alle brud dokumenteres, også dem I ikke anmelder.

Funktionen skal derfor have et felt til tidspunktet, hvor I blev bekendt med bruddet, en risikovurdering der fører til en dokumenteret beslutning om anmeldelse og underretning, og en log over alle brud. Er I også omfattet af den danske NIS2-lov, der trådte i kraft 1. juli 2025, kan samme hændelse udløse varsling efter 24 timer, 72 timer og en måned. Se vores artikel om sikkerhedsbrud.

7. De registreredes rettigheder (art. 12-22)

Fristen er én måned, ikke 30 dage. Art. 12, stk. 3 kræver svar uden unødig forsinkelse og senest en måned efter modtagelsen. Fristen kan forlænges med yderligere to måneder, hvis anmodningerne er komplekse eller mange, men den registrerede skal have besked om forlængelsen inden for den første måned. Et system, der regner med 30 dage, rammer forkert i de fleste måneder.

EDPB's koordinerede tilsynsaktion om indsigtsretten, rapport fra 20. januar 2025 med 30 tilsynsmyndigheder og 1.185 dataansvarlige, pegede på manglende dokumenterede interne procedurer som et af hovedproblemerne. Funktionen skal kunne registrere hver anmodning (indsigt efter art. 15, berigtigelse, sletning, begrænsning, dataportabilitet, indsigelse), identitetskontrollen, fristen og svaret. Den skal ikke nødvendigvis hente data automatisk fra jeres systemer. Det er en anden produktkategori. Vores artikel om indsigtsanmodninger går i dybden.

8. Opgavestyring og årshjul (art. 24)

Art. 24, stk. 1 kræver, at foranstaltningerne om nødvendigt revideres og ajourføres. Art. 32, stk. 1, litra d, kræver en procedure for regelmæssig afprøvning og evaluering. Det er to måder at sige, at compliance er tilbagevendende arbejde, og det kræver en funktion, der planlægger det.

Se efter et årshjul med tilbagevendende opgaver, ansvarlige, frister og påmindelser, og efter muligheden for at vedhæfte dokumentation til den løste opgave. Den vigtigste test er dog, om en kollega uden for compliance-teamet kan løse en opgave uden oplæring.

9. Roller, adgang og koncernstruktur (art. 32 og 38)

Når dokumentationen fordeles ud i organisationen, skal systemet selv leve op til art. 32. Det betyder rollebaseret adgang, så en HR-medarbejder kan redigere HR-aktiviteterne uden at se hele leverandørporteføljen. Databeskyttelsesrådgiveren (DPO) skal efter art. 38, stk. 1 inddrages rettidigt og på passende måde, så DPO'en bør have læseadgang til alt og kunne kommentere. Husk at fortegnelsen er den dataansvarliges pligt, ikke DPO'ens. Rollerne i systemet skal afspejle det.

Har I flere selskaber, så test om dokumentation kan deles på koncernniveau og samtidig holdes adskilt pr. selskab, fordi hvert selskab er selvstændigt dataansvarligt. Koncernstruktur er svær at eftermontere i et system, der ikke er bygget til det.

10. Historik og rapportering (art. 5, stk. 2)

Ansvarlighedsprincippet i art. 5, stk. 2 er et af forordningens syv principper og kræver, at I kan påvise overholdelse. Efter art. 30, stk. 4 skal fortegnelsen stilles til rådighed for Datatilsynet på anmodning. Softwaren skal derfor kunne eksportere fortegnelsen i et læsbart format og vise, hvem der ændrede hvad og hvornår.

Rapportering til ledelsen er den anden halvdel. En status pr. selskab over udestående opgaver, åbne risici og tilsyn gør det muligt for ledelsen at tage det ansvar, art. 24 lægger på den dataansvarlige.

Scorecard: sådan tester I GDPR software i en demo

En demo, som leverandøren styrer, viser det, der virker bedst. Send derfor jeres egne scenarier en uge før, og bed leverandøren om at løse dem live. Brug en skala fra 0 til 3: 0 er ikke understøttet, 1 er muligt med workaround, 2 er understøttet, 3 er understøttet og nemt for en ikke-specialist.

Funktion	Bed leverandøren om at vise	Godkendt, når	Forslag til vægt
1. Fortegnelse	Opret en ny behandlingsaktivitet for rekruttering med to systemer og en leverandør	Datakategorier kobles til kategorier af registrerede og til modtagere, og fortegnelsen kan eksporteres	15
2. Grundlag og slettefrister	Registrér løn med retlig forpligtelse og kontrakt, og helbredsoplysninger med art. 9	Flere grundlag pr. aktivitet, art. 9-grundlag og en slettefrist pr. datakategori	10
3. Risikovurdering	Vurdér et CRM-system og vis restrisiko efter foranstaltninger	Konsekvens for de registrerede, restrisiko og samme metode for systemer og leverandører	10
4. DPIA	Start en DPIA for et nyt AI-værktøj i HR	Indledende screening, afsnit om nødvendighed og proportionalitet, mulighed for at registrere høring efter art. 36	10
5. Databehandlere	Tilføj en cloudleverandør med to underdatabehandlere, én uden for EU/EØS	Underdatabehandlere, overførselsgrundlag, erklæringer og en tilsynsplan efter risiko	15
6. Brud	Registrér en fejlsendt e-mail med CPR-numre fredag kl. 16	Tidspunktet for kendskab, beregnet 72-timersfrist, dokumenteret beslutning og log over ikke-anmeldte brud	10
7. Rettigheder	Registrér en indsigtsanmodning modtaget 31. januar	Fristen beregnes som en måned, forlængelse kan registreres, identitetskontrol logges	5
8. Årshjul	Opsæt en årlig gennemgang af fortegnelsen for HR med påmindelse	Tilbagevendende opgave, ansvarlig, påmindelse og dokumentation på den løste opgave	10
9. Roller og koncern	Giv en HR-medarbejder adgang til HR-aktiviteter i ét selskab	Rollebaseret adgang, læseadgang for DPO og adskillelse pr. selskab	10
10. Historik	Vis hvem der ændrede slettefristen i sidste uge	Ændringslog pr. felt og eksport til ledelsesrapport	5

Vægtene er et udgangspunkt. En virksomhed med mange forbrugerkunder bør vægte rettigheder højere. En virksomhed med 80 databehandlere bør vægte leverandørmodulet højere. Beslut vægtene, før I ser den første demo, ellers ender I med at vægte det, den sidste leverandør var god til.

Sådan kører I processen:

Fastlæg vægtene og eventuelle knockout-kriterier i projektgruppen.
Send de 10 scenarier til leverandørerne mindst en uge før demoen.
Lad en person uden for compliance-teamet prøve mindst to af opgaverne selv.
Scor hver leverandør hver for sig umiddelbart efter demoen.
Sammenlign vægtede scorer og knockout-kriterier, og indhent referencer hos den bedste.

Fem trin til at teste GDPR software i en demo, fra vægte til sammenligning af scorer, med scoringsskalaen 0-3 nederst

Regneeksempel: tre leverandører på scorecardet

Nordvang Logistik A/S og Mette Kjær er fiktive. Vi har opfundet dem til denne artikel, og leverandør A, B og C er ikke rigtige produkter.

Nordvang Logistik har 430 ansatte fordelt på tre danske selskaber og bruger omkring 60 databehandlere, heraf flere med underdatabehandlere i USA. Kunderne er virksomheder, så de modtager få indsigtsanmodninger. Mette Kjær er compliance-ansvarlig og har i dag fortegnelsen i et regneark med 14 faner. Hun bruger vægtene fra tabellen ovenfor og har ét knockout-kriterium: systemet skal kunne registrere underdatabehandlere, fordi Nordvang ellers ikke kan leve op til art. 28, stk. 2 og 4.

Funktion (vægt)	Leverandør A	Leverandør B	Leverandør C
1. Fortegnelse (15)	3	2	3
2. Grundlag og slettefrister (10)	2	1	3
3. Risikovurdering (10)	2	3	1
4. DPIA (10)	2	3	1
5. Databehandlere (15)	3	1	2
6. Brud (10)	2	3	1
7. Rettigheder (5)	1	3	2
8. Årshjul (10)	3	2	1
9. Roller og koncern (10)	3	1	2
10. Historik (5)	2	3	1
Vægtet sum (maks. 300)	245	205	180
Score i procent	81,7 %	68,3 %	60,0 %
Knockout og røde flag	Ingen	Kan ikke registrere underdatabehandlere	Brudmodul uden felt for tidspunkt for kendskab

Scoren beregnes som vægt gange point, lagt sammen og divideret med 3. Leverandør B var den stærkeste i demoen på DPIA, brud og rettigheder, og det var tæt på at vinde Mette over. Men B faldt på knockout-kriteriet, fordi underdatabehandlere kun kunne noteres i et fritekstfelt. For en virksomhed med 60 databehandlere er det ikke en detalje.

Leverandør C havde den bedste fortegnelse, men brudmodulet regnede 72 timer fra registreringen i systemet og ikke fra det tidspunkt, hvor Nordvang blev bekendt med bruddet. Mette valgte A og skrev de to svageste punkter, rettigheder og historik, ind som krav til leverandørens køreplan i kontrakten.

Søjlediagram: fiktiv leverandør A får 81,7 % og vælges, B får 68,3 % og falder på knockout, C får 60,0 % med rødt flag

Røde flag i demoen

Nogle udsagn i en demo fortæller mere om leverandøren end selve skærmbillederne.

Rødt flag	Hvorfor det er et problem
"Systemet gør jer automatisk GDPR-compliant"	Compliance kræver juridiske vurderinger af grundlag, proportionalitet og risiko. Ingen software træffer dem for jer
"Svarfristen på 30 dage"	Art. 12, stk. 3 siger én måned med mulighed for forlængelse på to måneder. Forkerte frister i systemet giver forkerte frister i praksis
"GDPR kræver samtykke, før I behandler data"	Samtykke er ét af seks grundlag i art. 6. En leverandør, der tror noget andet, har bygget sin datamodel forkert
"Vi finder automatisk alle personoplysninger"	Data discovery kræver integrationer og giver falske positiver. Fortegnelsen kræver stadig formål og grundlag, som ingen skanner finder
72-timersfristen regnes fra registreringen	Art. 33 regner fra tidspunktet, hvor I blev bekendt med bruddet
DPIA-skabelonen er kun en risikomatrix	Art. 35, stk. 7, litra b, kræver en vurdering af nødvendighed og proportionalitet
Ingen eksport af fortegnelsen	Art. 30, stk. 4 kræver, at den stilles til rådighed for Datatilsynet. I skal også kunne tage jeres data med, hvis I skifter
Pris pr. bruger, der gør det dyrt at invitere kolleger	Dokumentationen bliver bedre, jo flere systemejere der bidrager. En prismodel, der straffer det, modarbejder funktion 8 og 9
Leverandøren kan ikke svare på, hvor jeres data hostes	Så er leverandøren selv en databehandler, I ikke kan føre tilsyn med

Hvad GDPR software ikke gør for jer

Den bedste GDPR software er stadig et værktøj til dokumentation og styring. Det træffer ikke beslutningen om, hvilket grundlag en behandling hviler på. Det sletter ikke oplysninger i jeres lønsystem, og det opdager ikke et brud i jeres netværk. Det erstatter heller ikke databeskyttelsesrådgiveren eller den juridiske rådgivning.

Software kan også give en falsk tryghed. En fortegnelse med 200 aktiviteter, som ingen har gennemgået i to år, er ikke bedre end et regneark. Det er værre, fordi den ser opdateret ud. Værdien kommer først, når systemet er koblet til et årshjul, og når ejerne af systemer og processer faktisk logger ind. Overvejer I stadig et regneark, så se vores sammenligning af GDPR i Excel eller software.

Hvad kan ændre sig i reglerne?

Kommissionen fremsatte 19. november 2025 forslaget til en digital omnibus, der blandt andet vil hæve tærsklen for anmeldelse af brud til høj risiko, forlænge fristen til 96 timer og indføre ét fælles indberetningspunkt på tværs af GDPR, NIS2 og DORA. I maj 2025 foreslog Kommissionen desuden i den såkaldte Omnibus IV at udvide undtagelsen i art. 30, stk. 5 til virksomheder og organisationer med færre end 750 ansatte, medmindre behandlingen sandsynligvis indebærer en høj risiko. Ingen af ændringerne af GDPR var endeligt vedtaget pr. september 2026.

Samtidig har EDPB 10. juni 2026 vedtaget en fælles skabelon til anmeldelse af brud, der var i høring til 5. august 2026, og Datatilsynet deltager i EDPB's koordinerede tilsyn med oplysningspligten i art. 12-14, der blev skudt i gang 19. marts 2026. For jeres valg af system betyder det én ting: frister, tærskler og felter skal kunne konfigureres, så I ikke er afhængige af en ny version, når reglerne ændrer sig.

Tidslinje maj 2025 til september 2026: Omnibus IV, digital omnibus, EDPB's tilsyn og brudskabelon, ingen ændring vedtaget endnu

Sådan understøtter .legal jeres GDPR-arbejde

.legal er bygget op omkring de samme objekter, som denne artikel beskriver. I GDPR-modulet kortlægger I behandlingsaktiviteter, systemer og leverandører og linker dem til hinanden, så fortegnelsen bygges ud fra jeres data mapping i stedet for at blive vedligeholdt ved siden af. Risikovurderinger laves med en metode for konsekvens og sandsynlighed og kan bruges på både aktiviteter, systemer og leverandører.

Leverandørsiden dækkes af Vendor Management, hvor databehandleraftaler, erklæringer og risikovurderinger ligger samlet, og hvor I kan planlægge tilsyn med databehandlere. Tilbagevendende opgaver planlægges i compliance-årshjulet med ansvarlige og påmindelser, og platformen understøtter koncernstrukturer og rollestyring. Arbejder I også med NIS2 eller ISO 27001, kan dokumentationen genbruges via Frameworks.

Vi foreslår, at I holder .legal op mod det samme scorecard som de andre leverandører. Book en demo, send os jeres scenarier på forhånd, og se priserne på vores prisside.

Ofte stillede spørgsmål om features i GDPR compliance software

Hvad er den bedste GDPR software?

Der findes ikke én bedste løsning for alle. Den bedste GDPR software for jer er den, der klarer jeres egne testscenarier på fortegnelse, databehandlere, brud og rettigheder, og som jeres kolleger faktisk vil bruge. Vægt funktionerne efter jeres risikobillede, før I ser demoer. En virksomhed med mange forbrugerkunder har andre behov end en B2B-virksomhed med mange leverandører.

Hvad er forskellen på et GDPR system og et cookieværktøj?

Et GDPR system dokumenterer og styrer jeres databeskyttelsesarbejde: fortegnelse, risikovurderinger, konsekvensanalyser, databehandlere og brud. Et cookieværktøj, også kaldet en CMP, viser cookiebanneret på jeres hjemmeside og registrerer brugernes valg. Cookies reguleres i Danmark af cookiebekendtgørelsen og GDPR i fællesskab. De fleste organisationer har brug for begge, men det er to forskellige indkøb.

Kan GDPR software lave fortegnelsen automatisk?

Delvist. Softwaren kan generere fortegnelsen ud fra de behandlingsaktiviteter, systemer og leverandører, I har registreret, og holde den opdateret, når et system ændres. Den kan ikke selv fastlægge formål, behandlingsgrundlag eller slettefrister. Det kræver en vurdering fra dem, der kender processen. Værktøjer, der skanner systemer for personoplysninger, supplerer arbejdet, men erstatter det ikke.

Skal virksomheder under 250 ansatte have en fortegnelse?

I de fleste tilfælde ja. Undtagelsen i art. 30, stk. 5 gælder kun, hvis behandlingen er lejlighedsvis, ikke indebærer en risiko og ikke omfatter særlige kategorier eller oplysninger om straffedomme. Løn og personaleadministration er ikke lejlighedsvis. Kommissionen har foreslået at hæve tærsklen til 750 ansatte, men ændringen var ikke endeligt vedtaget pr. september 2026.

Hvor lang tid har man til at svare på en indsigtsanmodning?

Én måned fra modtagelsen efter art. 12, stk. 3. Fristen kan forlænges med yderligere to måneder, hvis anmodningen er kompleks, eller hvis I modtager mange. Den registrerede skal have besked om forlængelsen og begrundelsen inden for den første måned. Fristen er altså ikke 30 dage, og det bør jeres system regne korrekt.

Gælder 72-timersfristen også underretning af de registrerede?

Nej. De 72 timer i art. 33 gælder anmeldelsen til Datatilsynet og regnes fra det tidspunkt, hvor I blev bekendt med bruddet. De registrerede skal efter art. 34 underrettes uden unødig forsinkelse, når bruddet sandsynligvis indebærer en høj risiko for dem. Alle brud skal dokumenteres internt, også dem, der ikke anmeldes.

Skal man have en databehandleraftale med alle leverandører?

Nej, kun med databehandlere, altså leverandører der behandler personoplysninger på jeres vegne og efter jeres instruks. Et lønbureau eller en cloududbyder er typisk databehandler. En revisor eller et rejsebureau, der selv bestemmer formålet, er typisk selvstændigt dataansvarlig. GDPR software bør kunne skelne mellem rollerne, så I ikke indgår aftaler, der ikke passer til forholdet.

Kan GDPR software erstatte en databeskyttelsesrådgiver?

Nej. Er I forpligtet til at udpege en databeskyttelsesrådgiver (DPO) efter art. 37, skal det være en person eller funktion med faglig ekspertise og en uafhængig stilling. Softwaren kan give DPO'en overblik, fordele opgaver og dokumentere rådgivningen. Den kan ikke overvåge overholdelsen eller rådgive ledelsen på DPO'ens vegne.

Hvordan skifter man GDPR software uden at miste dokumentation?

Kræv i kontrakten, at alle data kan eksporteres i et struktureret format, også historik og vedhæftede filer. Eksportér fortegnelse, risikovurderinger og databehandleroversigt, før den gamle aftale udløber, og gennemgå data før import, så forældede aktiviteter ikke flyttes med. Spørg den nye leverandør, om de kan importere fra jeres nuværende format.

Hvad skal en DPIA-skabelon i GDPR software indeholde?

Mindst de fire elementer i art. 35, stk. 7: en systematisk beskrivelse af behandlingen, en vurdering af nødvendighed og proportionalitet, en vurdering af risiciene for de registrerede og de foranstaltninger, der skal håndtere dem. Skabelonen bør også dokumentere DPO'ens rådgivning og give mulighed for at registrere en forudgående høring af Datatilsynet efter art. 36.

Har du fortsat spørgsmål?

Spørg Johannes direkte, han giver de fleste af vores demoer personligt

Book ham her

.legal compliance platform

Få alle 10 GDPR-funktioner i én platform

Dotlegals complianceplatform leverer alle de væsentlige GDPR-funktioner, din organisation har brug for. Fra datakortlægning til brudstyring arbejder alt problemfrit sammen.