En nyttig sammenligning av GDPR-programvare viser hva kandidatene kan gjøre med de samme opplysningene, hvilke forutsetninger tilbudene bygger på, og hvor mye arbeid virksomheten fortsatt må utføre. En tabell med produktnavn og avkryssede funksjoner er ikke tilstrekkelig når ordene protokoll, KI og integrasjon kan bety ulike ting hos leverandørene.
Denne guiden er for virksomheter som allerede har valgt ut aktuelle kandidater og skal sammenligne tilbudene. Du får en metode for et felles prøvegrunnlag, en begrunnet vurdering og et samlet kostnadsbilde. Hvis dere først må avgjøre hvilken type løsning dere trenger, bruk veiledningen til valg av personvernverktøy. Her er målet en etterprøvbar sammenligning, ikke en universell rangering. Rettskildene er kontrollert 27. september 2026.
Definer samme leveranse for alle kandidater
Skriv en kort beskrivelse av virksomheten, juridiske enheter og oppgavene løsningen skal støtte. Angi hvilke deler som er nødvendige fra oppstart, og hva som kan komme senere. Ikke la én leverandør prise en enkel dokumentdatabase og en annen en full tjeneste med rådgivning, migrering og løpende drift uten at forskjellen blir synlig.
Bruk et felles dokument med krav, prøvehandling, forventet resultat og ansvarlig evaluator. For eksempel kan et krav om versjonshistorikk prøves ved at en behandling godkjennes, endres og eksporteres på nytt. Forventet resultat er at den tidligere godkjente versjonen fortsatt kan vises, og at den nye versjonen ikke fremstår som godkjent av samme beslutning.
Et lite antall presise krav er ofte mer nyttig enn en omfattende funksjonsliste. En kandidat kan ha mange tilleggsfunksjoner og likevel falle igjennom på tilgangsstyring eller eksport. Et annet verktøy kan mangle en praktisk bekvemmelighet, men løse de sentrale oppgavene godt. Gjør denne prioriteringen før demonstrasjonene, slik at presentasjonsteknikk ikke bestemmer vurderingsgrunnlaget.
Skill lovkrav fra egne innkjøpskrav
Personvernforordningen stiller krav til behandlingen av personopplysninger og dokumentasjon, men pålegger ikke generelt kjøp av en bestemt programvare. Datatilsynets veiledning om behandlingsprotokoll tillater ulike verktøy, herunder regneark, når innholdet og tilgjengeligheten oppfyller kravene.
En norsk brukerflate kan være et viktig praktisk krav for ansatte som skal registrere opplysninger. Det er ikke det samme som at GDPR generelt krever alle interne dokumenter på norsk. Formuler språkbehovet konkret: hvem skal forstå hva, og i hvilken arbeidsoppgave? Prøv både registrering, varsler og eksport, ikke bare menyene i produktet.
Det samme gjelder automatisering. Virksomheten kan ønske automatisk varsling ved leverandørendringer, men en slik funksjon fritar ikke den ansvarlige fra å vurdere endringen. Merk hvert kriterium som rettslig krav, virksomhetens sikkerhetskrav eller ønsket effektivisering. Da blir det tydelig hva som er ufravikelig, og hva som kan løses på en annen forsvarlig måte.
Lag et felles prøvegrunnlag
Bruk syntetiske opplysninger som ligner deres faktiske situasjon. Et godt prøvegrunnlag kan bestå av en rekrutteringsprosess, en kundeserviceprosess, to leverandører og et dokument med en bevisst uklarhet. Legg inn en behandling med flere lagringstider og en leverandør som opptrer i forskjellige roller. Det gjør det vanskeligere å skjule svakheter bak en standardmal.
Leverandørene skal få samme informasjon og omtrent samme mulighet til forberedelse. Oppgi hva som er kjent, og hva dere forventer at løsningen skal spørre om. Ikke bed kandidatene om å gjette rettslig grunnlag eller lagringstid ut fra et virksomhetsnavn. Gode systemer gjør mangler synlige; et blankt felt kan være mer ærlig enn et plausibelt, men ubegrunnet svar.
Avtal hvem som utfører oppgavene. Selgerens demonstrasjon viser én type bruk; en intern prosesseier uten spesialopplæring viser noe annet. Begge kan være nyttige. Noter hvor mye hjelp som gis underveis, slik at resultatene kan sammenlignes uten å forveksle leverandørens rådgivningsinnsats med produktets egen funksjon.
Prøve én: protokoll med en reell endring
Opprett først en aktivitet og koble den til system, ansvarlig og relevante mottakere. Endre deretter formålet eller legg til en ny mottaker. Undersøk om systemet viser hvilke vurderinger som må gjennomgås på nytt, og om den ansvarlige kan begrunne at noe forblir uendret. Dette er mer opplysende enn hvor raskt en ferdig mal vises.
Programvare for behandlingsprotokoll bør vurderes på struktur, vedlikehold og eksport. Rettslig grunnlag er nyttig ansvarlighetsinformasjon, men ikke et uttrykkelig felt i artikkel 30 nr. 1. Et produkt som omtaler alle egne felter som direkte lovpålagte, bør forklare skillet mellom protokollkrav og øvrig dokumentasjonsbehov.
Eksporter den godkjente aktiviteten og kontroller om relasjonene er forståelige uten innlogging. Ta også med et avsluttet forhold. En sammenligning som bare undersøker dagens aktive poster, overser om historiske beslutninger forsvinner når en leverandør slettes eller en medarbeider slutter.
Prøve to: avtale og leverandørrolle
Gi kandidatene en kort, syntetisk tjenestebeskrivelse og et avtaleutdrag. Én leverandør skal være databehandler for den aktuelle tjenesten, mens en annen mottar opplysninger som selvstendig behandlingsansvarlig. Løsningen bør kunne registrere forskjellen uten automatisk å kreve en databehandleravtale i begge tilfeller.
Datatilsynets rolleforklaring understreker at vurderingen må bygge på de faktiske oppgavene. Bruk veiledningen om databehandleravtaler til å definere hvilke dokumenter og vurderinger som er relevante. Et avtalearkiv alene viser ikke at bistand, underleverandører og sikkerhet er vurdert.
Dersom produktet analyserer tekst automatisk, legg inn en tvetydig bestemmelse og et manglende bilag. Kontroller om analysen viser kilden og usikkerheten, og om en fagperson kan endre konklusjonen med begrunnelse. Resultatet bør ikke bli mer sikkert enn dokumentasjonen. Sammenlign kvaliteten på forklaringen, ikke bare antall markerte klausuler.
Prøve tre: rettighetsanmodning med avgrensning
Opprett en innsynsanmodning der opplysninger finnes i to systemer og inkluderer informasjon om en annen person. Prøven skal vise mottak, identitetsvurdering, innhenting, eventuell skjerming, godkjenning og svar. Systemet skal støtte vurdering av nødvendighet; det bør ikke automatisk kreve kopi av legitimasjon i alle saker.
Innsynsretten etter artikkel 15 og fristreglene i artikkel 12 er den rettslige rammen. En saksmodul må kunne håndtere frister og begrunnede unntak uten å love at alle opplysninger kan hentes automatisk fra hele virksomheten. Krev dokumentasjon for hvilke systemkoblinger som faktisk inngår i tilbudet.
Prøv også overlevering til en stedfortreder. Hvis saken stopper når én medarbeider er fraværende, er en automatisk påminnelse utilstrekkelig. Den mer spesifikke guiden til verktøy for innsynsbegjæringer kan brukes til detaljer om saksflyt og tilgang. Sammenlign hvem som ser selve personopplysningene, og hvem som bare trenger status.
Prøve fire: avvik uten automatisk anmeldelse
Et syntetisk avvik bør ha ufullstendige opplysninger ved oppstart. Senere tilføyes nye fakta som endrer risikovurderingen. Se om verktøyet skiller hendelsestidspunkt, kjennskapstidspunkt, vurdering og faktisk innsendelse. Et ur som starter først når saken opprettes, kan skjule tiden som allerede har gått.
Avvik etter artikkel 33 og 34 krever konkrete vurderinger. Ikke alle persondatabrudd skal meldes til Datatilsynet, men bruddene skal dokumenteres etter artikkel 33 nr. 5. Underretning av de registrerte har en annen terskel enn anmeldelse. Systemet bør kunne bevare begrunnelsen for hvert valg.
Send ikke en fiktiv anmeldelse til myndigheten under utprøving. Be om et tydelig merket utkast og vis hvordan en reell kvittering senere ville bli knyttet til saken. Dette gjør sammenligningen trygg og praktisk, samtidig som dere undersøker hele arbeidsflyten frem til dokumentert handling.
Prøve fem: personvernkonsekvenser og menneskelig vurdering
Velg et prosjekt som kan innebære høy risiko, og be leverandøren vise vurderingen av om en DPIA er nødvendig. Et spørreskjema bør ikke skjule hvordan konklusjonen oppstår. Virksomheten må kunne se hvilke forhold som er vurdert, hvilke opplysninger som mangler, og hvem som har tatt stilling.
En personvernkonsekvensvurdering etter artikkel 35 omfatter mer enn en samlet risikoscore. Be om å følge ett foreslått tiltak frem til beslutning, gjennomføring og ny vurdering. Dersom risikoen fortsatt er høy, skal systemet ikke automatisk lukke saken fordi alle tekstfeltene er fylt ut.
Prøv en uenighet mellom prosesseier og rådgiver. Dokumentasjonen bør kunne vise begge synspunkter og den ansvarlige beslutningen. Programvare erstatter heller ikke en plikt til å utpeke personvernombud. Ombudets rådgivning og uavhengighet må respekteres selv om systemet tilbyr en godkjenningsknapp.
Sammenlign sikkerheten til selve verktøyet
Personvernverktøyet kan samle kontrakter, hendelser, risikovurderinger og opplysninger om personer i enkeltsaker. Vurder derfor leverandøren som en del av deres eget behandlingsmiljø. Be om opplysninger om tilgang, autentisering, logger, sikkerhetskopiering, underleverandører og bistand ved hendelser. Knytt dokumentasjonen til den tjenesten og versjonen dere faktisk kjøper.
EØS-lagring betyr ikke nødvendigvis at ingen separat mottaker utenfor EØS får tilgang. Datatilsynets overføringsveiledning forklarer blant annet betydningen av fjerntilgang. Kontroller support, dokumentanalyse og andre underleverandørtjenester. Leverandørens nasjonalitet alene avgjør ikke om løsningen er lovlig eller egnet.
Bruk vurderingen av tredjelandsoverføringer til de konkrete dataflytene. I sammenligningen bør et ubesvart spørsmål markeres som ubesvart, ikke som et automatisk nei eller ja. Be om samme dokumentasjon fra alle kandidater, og vurder om begrensninger kan håndteres kontraktsmessig og teknisk.
Gi poeng først etter at beviset er vurdert
En vurderingsmatrise bør skille obligatoriske krav fra kriterier som kan veies mot hverandre. Et obligatorisk krav om å skille to behandlingsansvarliges data bør ikke kunne oppveies av en penere brukerflate. Deretter kan ønskede egenskaper sammenlignes med vekter dere fastsetter på forhånd.
En enkel skala kan for eksempel skille mellom ikke demonstrert, demonstrert med vesentlig manuelt arbeid og demonstrert som avtalt. Tallene er en intern metode, ikke en standard fastsatt av Datatilsynet. Beskriv hvorfor karakteren gis, og lenk til referat, eksport eller avtalevilkår. To like tall kan ellers skjule svært ulike forutsetninger.
Skill dessuten funksjon fra leveringsstatus. Noe kan finnes i standardproduktet, kreve konfigurasjon, forutsette en tredjepart eller bare være planlagt. Et fremtidig løfte skal ikke telles som en levert funksjon. Dersom dere aksepterer en senere leveranse, må avtalen beskrive betydningen av forsinkelse og den midlertidige løsningen.
Pris: sammenlign totalkostnad på samme grunnlag
Be om en prisoversikt med abonnement, etablering, migrering, integrasjoner, opplæring, support og eventuell bistand. Avklar hva som utløser prisendringer: flere brukere, selskaper, dokumenter, behandlinger eller analysevolum. Et lavt grunnabonnement kan ikke sammenlignes direkte med et tilbud som omfatter omfattende tjenester.
Medregn virksomhetens egne timer. Datavask, avklaring av roller, rettslige vurderinger og godkjenning forsvinner ikke nødvendigvis ved kjøp. Bruk faktiske observasjoner fra utprøvingen til å anslå restarbeidet. Ikke legg inn et generelt løfte om en bestemt prosentvis tidsbesparelse uten måling og sammenlignbart utgangspunkt.
Guiden til pris og kostnad kan brukes til budsjettstrukturen. Lag gjerne et scenario med stabil drift og et med flere selskaper eller behandlinger. Hold antakelsene synlige og sammenlign samme periode. Sanksjonsmaksima er ikke et bevis for avkastning på et bestemt produkt.
Migrering og avslutning skal prøves
Importer noen representative poster fra dagens løsning og sammenlign kilden med resultatet. Se etter avkortet tekst, sammenblandede roller, tapte vedlegg og feilaktig kobling av mottakere. Avklar hvem som retter feil, og hvilke opplysninger som aldri må gjøres til standardverdier bare for å få importen gjennomført.
Gjennomfør deretter en eksport. Kan en kollega forstå postene og deres relasjoner uten tilgang til produktet? Er historiske godkjenninger, vedlegg og åpne oppgaver med? En PDF kan være god lesedokumentasjon, men lite egnet for videreføring i et nytt system. Be om både forståelig og praktisk anvendelig utlevering der det er nødvendig.
Bruk rutinen ved avslutning av databehandlerforhold til å vurdere sletting, tilbakelevering og overgang. Disse forholdene bør være avklart før underskrift. En ellers god løsning kan bli kostbar å forlate dersom avtalen ikke beskriver hjelp, frister og tilgjengelige formater.
Undersøk om rangeringen tåler endrede forutsetninger
En samlet poengsum kan være følsom for vektene dere velger. Prøv derfor å endre en sentral antakelse, for eksempel antall juridiske enheter eller hvor stor vekt enkel daglig bruk får. Hvis en liten endring snur resultatet, bør beslutningsnotatet forklare dette. Det kan bety at kandidatene er jevngode, eller at dere ennå ikke har avklart det viktigste behovet.
Vurder også konsekvensen av manglende informasjon. En leverandør som ikke dokumenterer eksport av historikk, bør ikke få samme vurdering som en leverandør som viser en begrensning dere kan håndtere. Usikkerhet kan være akseptabel, men den må være synlig og ha en plan for avklaring. Ikke gi produktet gode poeng basert på hva dere antar at det sannsynligvis kan gjøre.
La de som utførte utprøvingen kontrollere oppsummeringen før beslutningen tas. Innkjøp kan kontrollere prisforutsetninger, sikkerhetsansvarlig kan vurdere tilgang og leverandørforhold, og fagansvarlige kan bekrefte de juridiske arbeidsflytene. Ingen av dem trenger å godkjenne forhold utenfor egen kompetanse. Et samlet valg blir mer etterprøvbart når det fremgår hvem som vurderte hva og hvilke spørsmål som fortsatt er åpne.
Sammenlign de valgte tilbudene
Den dokumenterte leverandørsammenligningen gir ytterligere spørsmål om omfang, demonstrasjon og kommersielle forutsetninger. Bruk et nøytralt referat der hvert utsagn knyttes til det som faktisk er vist eller avtalt. Unngå at et varemerke i seg selv blir en begrunnelse for poeng eller rangering.
Hvis dere også trenger sikkerhetsdokumentasjon, kan en sammenligning av DORA-verktøy eller NIS2-verktøy være relevant etter en egen virkeområdevurdering. En samtykkeløsning for nettsiden har igjen et annet formål; samtykkeplattformer bør vurderes på deres spesifikke arbeidsoppgaver. Ikke anta at én modul dokumenterer etterlevelse på alle områder.
Ofte stilte spørsmål
Trenger små virksomheter GDPR-programvare?
Ikke nødvendigvis. Virksomheten må oppfylle sine plikter, men kan velge et egnet verktøy og en forsvarlig arbeidsmåte. Et godt forvaltet regneark kan fungere ved begrenset kompleksitet. Sammenlign programvare når koordinering, tilgang, historikk eller vedlikehold faktisk skaper problemer.
Kan vi sammenligne uten publiserte priser?
Ja. Be kandidatene prise samme skriftlige omfang og oppgi forutsetninger og tilleggsutgifter. Dersom et tilbud mangler vesentlige poster, marker det som ufullstendig fremfor å gjette. Prisens etterprøvbarhet er selv en del av vurderingen.
Hva bør avgjøre ved lik poengsum?
Se på obligatoriske krav, uløste usikkerheter og arbeidet som blir igjen hos virksomheten. Poengsummen er en støtte for beslutningen, ikke beslutningen selv. Ledelsen bør kunne lese begrunnelsen og forstå hvorfor valgt løsning passer, og hvilke begrensninger den aksepterer.