En brugbar sammenligning af GDPR-software begynder med de samme opgaver og forudsætninger for alle kandidater. Leverandørernes egne demonstrationer kan vise forskellige styrker, men de giver sjældent et ensartet beslutningsgrundlag. Hvis én kandidat demonstrerer en færdig fortegnelse, mens en anden bliver bedt om at importere jeres rodede regneark, sammenligner I ikke samme leverance.
Denne guide viser, hvordan I opstiller krav, gennemfører prøvesager og sammenholder tilbud. Den er ikke en rangliste over navngivne produkter og indeholder ikke udokumenterede markedspriser. Målet er et beslutningsnotat, hvor ledelsen kan se, hvorfor en løsning passer til virksomheden, hvilke forudsætninger valget bygger på, og hvilke opgaver virksomheden stadig selv skal udføre.
Definer anskaffelsen med en konkret grænse
Beskriv først, hvilke processer anskaffelsen skal dække. Fortegnelse, leverandøraftaler, konsekvensanalyser og rettighedssager kan hænge sammen, men kræver forskellige arbejdsgange. En platform kan være god til central dokumentation og mindre egnet til teknisk datasøgning. Skriv derfor både det ønskede resultat og de systemer, som fortsat skal levere oplysninger eller udføre handlinger.
Afklar også organisationsgrænsen. Skal én juridisk enhed bruge løsningen, eller skal et koncernteam støtte flere selskaber med hver deres ansvar? Skal eksterne rådgivere bidrage, og hvilke oplysninger må lokale medarbejdere se? En demonstration med én administrator siger meget lidt om samarbejdet på tværs af enheder. Disse forhold påvirker både adgangsmodel, migrering og pris.
Hvis I endnu ikke ved, hvilke produktkategorier der er relevante, kan guiden til valg af GDPR-software bruges før selve sammenligningen. En mindre virksomhed bør også overveje SMV-perspektivet på drift og ressourcer. Her er opgaven at vurdere konkrete kandidater på ens vilkår, efter at det grundlæggende behov er beskrevet.
Hold lovkrav og ønskede funktioner adskilt
GDPR pålægger virksomheden forpligtelser; forordningen kræver ikke et bestemt softwareprodukt. Fortegnelsen skal eksempelvis opfylde artikel 30, når pligten gælder, men loven kræver ikke en bestemt skærm eller eksportknap. Datatilsynets vejledning om fortegnelser kan bruges til at fastlægge indholdet, før det omsættes til funktionelle krav.
Registrer for hvert vigtigt krav, hvad det bygger på. Et krav kan følge af loven, en intern sikkerhedspolitik, en kontrakt eller et praktisk ønske. Det gør prioriteringen tydeligere. Et internt ønske om en bestemt graf bør ikke få samme status som evnen til at beskytte adgangen til følsomme dokumenter, og en leverandørs anbefaling er ikke automatisk en retlig pligt.
Marker nogle få ufravigelige anskaffelseskrav, som kan afvise en kandidat. Det kan eksempelvis være en nødvendig adskillelse mellem selskaber eller en eksport, som virksomheden skal kunne bruge ved leverandørskifte. Kravene skal være begrundede og realistiske. Hvis alt kaldes ufravigeligt, bliver sammenligningen ufleksibel og skjuler de afvejninger, som ledelsen faktisk skal tage stilling til.
Lav et vurderingsskema før demonstrationerne
Vælg vurderingsområder og deres indbyrdes betydning, før leverandørerne viser produkterne. En mulig opdeling er opgaveløsning, brugbarhed, dokumentation, sikkerhed, integration, indførelse og samlet omkostning. Der findes ingen universel rigtig vægtning. En organisation med mange selvstændige enheder kan have andre prioriteter end en virksomhed, hvor én person håndterer alle databeskyttelsesopgaver.
Beskriv, hvad der skal til for en god vurdering. «Kan eksportere» er for uklart. Et bedre kriterium er, at en medarbejder kan eksportere oplysninger, relationer og relevante bilag i et format, som kan læses uden leverandørens portal. Noter derefter, om funktionen er demonstreret, dokumenteret skriftligt eller kun lovet. De tre typer evidens bør ikke få samme vægt.
Gem også usikkerheder. Hvis en integration ikke kunne vises, bør det stå som en uafklaret forudsætning, ikke som et neutralt gennemsnitligt resultat. Aftal, hvem der skal afklare den, og hvornår. Et enkelt kritisk ubesvaret spørgsmål kan have større betydning end en høj samlet score, især hvis løsningen ellers forudsætter manuelle arbejdsgange, som virksomheden ikke kan bemande.
Prøvesag 1: Opret og ændr en behandling
Giv hver leverandør den samme korte beskrivelse af en fiktiv rekrutteringsproces. Medtag ansøgere, kontaktpersoner, et eksternt system, opbevaringsperioder og et åbent spørgsmål om adgang. Lad en af jeres egne medarbejdere oprette behandlingen. Vurder, om systemet hjælper med at opdage mangler, uden at foreslå faktuelle svar, som brugeren ikke har grundlag for at godkende.
Ændr derefter processen: rekrutteringssystemet får en ny leverandør, og HR ønsker at bruge oplysninger til et nyt formål. Se, hvilke relationer og vurderinger der bliver berørt, hvem der skal godkende ændringen, og om tidligere versioner kan findes. En fortegnelse skal kunne følge virkeligheden. En smuk første registrering er mindre værd, hvis ændringer senere kræver genindtastning på mange sider.
Denne prøvesag afgrænser behovet for software til fortegnelsen. Kontroller indholdet mod artikel 30, men skeln mellem de udtrykkelige fortegnelsesfelter og nyttige supplerende oplysninger. Eksempelvis kan et felt for behandlingsgrundlag støtte virksomhedens samlede dokumentation, selv om det ikke er opregnet som et selvstændigt minimumsfelt i artikel 30.
Prøvesag 2: Følg en leverandøraftale til beslutning
Brug en fiktiv leverandør med en aftale, en liste over underdatabehandlere og en sikkerhedsrapport med et relevant forbehold. Bed kandidaten vise, hvordan oplysningerne knyttes til de berørte behandlinger. Det afgørende er, om den ansvarlige kan se sammenhængen og følge op, ikke hvor mange dokumenter der kan uploades på én gang.
Lad leverandøren derefter varsle en ny underdatabehandler. Kan systemet registrere ændringen, vise hvem der skal vurdere den og bevare begrundelsen for beslutningen? Kan en ufuldstændig oplysning forblive tydeligt uafklaret? Artikel 28 og databehandleraftalen kræver mere end en underskrift. Virksomheden skal kunne arbejde med instrukser, garantier, bistand og opfølgning under samarbejdet.
Afklar samtidig, hvordan rollen bestemmes. Alle leverandører skal ikke automatisk mærkes som databehandlere. En løsning bør kunne dokumentere den faktiske aktivitet og den valgte rollefordeling. Det er især relevant, når en leverandør har flere roller. En simpel ja/nej-kategori kan ellers føre til aftaler, der ikke beskriver behandlingen korrekt.
Prøvesag 3: Behandl en indsigtsanmodning
Giv kandidaterne en anmodning, som kommer til en almindelig mailadresse, og et datasæt med oplysninger fra flere kilder. Medtag en tidligere mailadresse og oplysninger, der også vedrører en anden person. Se, om modtagelsesdato, søgeplan, delopgaver og faglig gennemgang kan holdes samlet. Undersøg også, hvordan en medarbejder overtager sagen ved fravær.
Vurder, om tidsstyringen kan følge den konkrete juridiske vurdering. En måned efter artikel 12 er ikke en generel 30-dagesperiode, og en forlængelse kræver en begrundelse efter de relevante betingelser. Et system bør heller ikke automatisk fjerne enhver oplysning om andre personer. De detaljerede kriterier fremgår af guiden til DSAR-software.
Slut prøvesagen med at åbne udleveringspakken som modtager. Er materialet forståeligt, er maskering reel, og kan filerne hentes i den aftalte periode? Et internt grønt flueben bør ikke være det eneste bevis for en afsluttet sag. Denne prøve viser, om produktet understøtter hele forløbet eller primært registrerer, at nogen har arbejdet på det.
Vurder konsekvensanalyser og specialfunktioner efter behov
Hvis virksomheden udfører behandlinger, som kan indebære høj risiko, skal en relevant konsekvensanalyse efter artikel 35 kunne gennemføres. Se efter støtte til at beskrive behandlingen, vurdere nødvendighed og proportionalitet, analysere risici for personer og følge foranstaltninger. Et risikotal alene gør ikke analysen tilstrækkelig.
Nogle virksomheder har behov for en samtykkeløsning på hjemmesider eller i apps. Det er ikke nødvendigvis samme produkt som den interne GDPR-platform. Brug sammenligningen af samtykkeplatforme til det særskilte behov og undersøg derefter, hvilke oplysninger der bør udveksles mellem løsningerne. Undgå at betale for en funktion, som ikke passer til den konkrete indsamling eller brugeroplevelse.
Tilsvarende bør NIS2-software og DORA-software vurderes ud fra deres egne arbejdsprocesser. Afklar først relevansen gennem NIS2 i Danmark og DORA i Danmark. En fælles leverandør kan give sammenhæng i grunddata, men antallet af regelværkspakker er ikke i sig selv dokumentation for dækning af jeres forpligtelser.
Undersøg sikkerheden i selve GDPR-platformen
Løsningen kan indeholde følsomme oplysninger om behandlinger, risici, medarbejdere og hændelser. Beskriv derfor, hvilke data I faktisk vil lagre, før I vurderer leverandørens sikkerhed. En platform med anonymiserede procesbeskrivelser har ikke nødvendigvis samme risikoprofil som en løsning, der opbevarer komplette indsigtsudtræk eller personalesager. Begræns kopiering til det, der er nødvendigt for formålet.
Bed om at demonstrere adgangsafgrænsning, autentificering, logning og håndtering af fratrådte brugere. Kontroller både skærmbilleder, vedhæftninger og eksport. En ekstern revisor bør eksempelvis kun kunne få den adgang, som opgaven kræver. Sikkerhedsforanstaltninger efter artikel 32 kan strukturere spørgsmålene, men et udfyldt skema skal understøttes af relevant dokumentation.
Undersøg behandlingssteder, underdatabehandlere og supportadgang. EU-hosting er en oplysning, som skal vurderes sammen med de faktiske dataflows, ikke en samlet garanti for lovlighed. Ved tredjelandsoverførsler skal det relevante grundlag og eventuelle supplerende foranstaltninger afklares. En juridisk vurdering bør bygge på den tilbudte konfiguration, ikke kun på leverandørens generelle hjemmeside.
Skeln mellem automatisering og ansvar
Automatisk genbrug af grunddata, påmindelser og versionskontrol kan reducere bestemte manuelle opgaver. Bed leverandøren vise præcis, hvad der automatiseres, og hvad der udløser en menneskelig gennemgang. Hvis en systemforbindelse fejler, skal fejlen være synlig. Ellers kan automatiseringen skabe en falsk forventning om, at fortegnelsen eller leverandørlisten altid er ajour.
Hvis AI anvendes til tekstforslag eller vurderinger, så indlæg bevidst tvetydige oplysninger i prøvesagen. Se, om løsningen markerer usikkerhed, forklarer sit grundlag og gør det let at rette svaret. Afklar desuden, hvilke data der sendes til hvilke tjenester, hvordan de opbevares, og om de bruges til andre formål. En funktion må vurderes både for nytte og for sin egen behandling af oplysninger.
Den ansvarlige medarbejder eller databeskyttelsesrådgiver, hvor denne rolle er relevant, skal kunne forstå og kontrollere resultatet. Et produkt kan ikke overtage virksomhedens juridiske ansvar gennem et automatisk godkendelsesstempel. Vurder derfor kvaliteten af beslutningsstøtten, ikke kun hastigheden i at producere tekst eller lukke opgaver.
Beregn totalomkostningen på ens vilkår
Bed alle kandidater om et tilbud med samme antal brugere, juridiske enheder, processer, rettighedssager og ønskede integrationer. Beskriv også omfanget af eksisterende materiale, der skal importeres. En pris uden disse forudsætninger kan ikke sammenlignes meningsfuldt. Angiv, hvilke poster der er faste, hvilke der afhænger af forbrug, og hvilke der endnu kun er estimater.
Medtag implementering, oprydning, uddannelse og den interne drift. Et system kan kræve en administrator, løbende redaktion af skabeloner eller konsulentbistand ved nye arbejdsgange. Prisguiden for GDPR-software giver en struktur til beregningen. Brug dokumenterede tilbud og egne ressourceforudsætninger frem for generelle besparelsesprocenter eller påståede priser på konkurrenters produkter.
Se også på prisændringer, binding og udtræden. Hvad sker der ved flere enheder, ekstra lagring eller et fald i brugerantal? Kan I eksportere under opsigelsesperioden, og koster hjælp til migrering særskilt? En lav pris ved start kan være mindre attraktiv, hvis en afgørende integration eller en brugbar eksport kræver en senere, uafklaret tillægsaftale.
Kontroller eksporten, før I lægger data ind
En eksport skal vurderes som en konkret leverance. Få en prøve med behandlinger, relationer, aftaler, vedhæftninger og relevante versionsoplysninger. Lad en person, som ikke kender produktet, forsøge at følge en beslutning fra dokumentation til godkendelse. Hvis sammenhængen kun kan forstås i leverandørens portal, er udtræksmuligheden mere begrænset, end en eksportknap antyder.
Skeln mellem en rapport til ledelsen og data til fortsat arbejde. En PDF kan være velegnet til et møde, men utilstrækkelig ved migrering. Strukturerede filer kan være nyttige, men skal have forståelige felter og relationer. Aftal også, hvordan ophør, sletning og sikkerhedskopier håndteres, så afslutningen af leverancen ikke står ubeskrevet.
En sammenligning af to forskellige platformstilgange kan give supplerende spørgsmål om kompleksitet og indførelse. Den konkrete beslutning skal dog hvile på det, jeres kandidater faktisk har vist og tilbudt. Gem derfor demonstrationens resultater, tilbudsforudsætningerne og de aftalte undtagelser sammen, så beslutningen senere kan efterprøves.
Vurder implementeringen som en del af produktet
Bed kandidaten beskrive en indførelse med jeres eksisterende materiale og medarbejdere. Hvilke beslutninger skal virksomheden træffe, hvilke oplysninger skal ryddes op, og hvem kontrollerer importen? Et standardforløb kan være nyttigt, men bør tilpasses faktiske afhængigheder. Hvis leverandøren forudsætter, at alle behandlinger allerede er korrekt dokumenteret, er tilbuddet ikke nødvendigvis en løsning på virksomhedens nuværende kortlægningsproblem.
Aftal kriterier for at acceptere leverancen. Det kan være, at et repræsentativt udvalg af aktiviteter er importeret korrekt, at relevante brugerroller er afprøvet, og at medarbejderne kan udføre de aftalte opgaver. Kriterierne bør beskrive resultater, som kan undersøges, frem for blot at kræve gennemført undervisning. Deltagelse i et kursus dokumenterer ikke alene, at arbejdsdelingen fungerer.
Undersøg, hvordan fejl efter opstart bliver håndteret. Skeln mellem en produktfejl, mangelfuld opsætning og en ny opgave, som ligger uden for tilbuddet. Aftal kontaktvej og ansvar for afklaring, så uenighed ikke efterlader registeret eller sagsbehandlingen uden ejer. Disse driftsvilkår kan have større praktisk betydning end små forskelle i demonstrationens udseende.
Skriv en anbefaling med åbne forudsætninger
Vælg ikke alene ud fra den samlede score. Forklar, hvilke få forhold der afgør anbefalingen, og hvilke svagheder virksomheden accepterer. Hvis en kandidat kræver mere intern administration, skal der være en navngiven funktion og tid til opgaven. Hvis en anden kandidat mangler en integration, skal den alternative arbejdsgang være afprøvet og regnet med.
Gør uafklarede punkter til konkrete vilkår før kontrakt. En funktion på en udviklingsplan er ikke en leveret funktion, og mundtlig støtte er ikke en defineret service. Beslutningsnotatet bør angive, hvilke forhold der skal være afklaret før start, hvilke der kan håndteres under indførelsen, og hvornår valget skal genvurderes. På den måde bliver sammenligningen et redskab til ansvarlig anskaffelse frem for en liste over salgsargumenter.
Er den mest omfattende platform altid bedst?
Nej. Omfang er kun værdifuldt, hvis funktionerne passer til behovet og kan drives med de ressourcer, virksomheden har. Vurder også løsningen med færre funktioner og en tydelig arbejdsdeling. Den afgørende prøve er, om de nødvendige opgaver kan gennemføres korrekt og følges op.
Kan en høj score opveje et manglende minstekrav?
Ikke uden at virksomheden bevidst ændrer sit krav og begrunder det. Et minstekrav er netop udpeget, fordi andre styrker ikke uden videre kompenserer for manglen. Hvis kravet viser sig unødigt strengt, bør ændringen gælde ens for alle kandidater og dokumenteres, før den endelige sammenligning foretages.