En jämförelse av GDPR-programvara är användbar först när alternativen får lösa samma uppgift. Den här guiden ger en jämförbar kravmatris, ett provfall och ett sätt att bedöma resultatet. Den är avsedd för en svensk organisation som redan har en kortlista och behöver välja mellan två eller tre offerter. Om ni fortfarande söker tänkbara kandidater, börja med guiden till bästa GDPR-programvara efter användningsfall. Den som främst behöver räkna på licens och arbetstid hittar en separat kostnadsmodell.
Börja med ett gemensamt scenario
Skriv en kort beskrivning som alla leverantörer får före visningen. Exempel: ett svenskt bolag driver en webbtjänst, använder ett lönebiträde och en molnleverantör, har tre affärsenheter och får en begäran om tillgång. Nästa vecka byts en underleverantör och ett kalkylark med kunduppgifter mejlas fel. Fyll i era faktiska volymer: antal behandlingsaktiviteter, system, användare, juridiska enheter och begäranden per år. Använd fiktiva personuppgifter i första omgången.
Be varje leverantör genomföra fyra förändringar inför er: skapa behandlingen, byta underleverantör, hantera begäran och dokumentera incidenten. Ge samma tid och låt samma personer från dataskydd, IT och verksamhet bedöma. Skärmbilder av ett färdigt exempel visar bara att funktioner kan presenteras; ni behöver se vem som anger fakta, vem som granskar och vad som händer när ett antagande är fel. Lämna inte ut verkliga känsliga data för att få se en demo.
Ange i förväg vad som ger godkänt resultat. ”Registret finns” är för vagt. ”En processägare kan ändra lagringstid; ändringen får en ansvarig granskare och syns i exporten” går att kontrollera. Vikta endast krav som ni faktiskt behöver. En lokal myndighet kan väga arkiv och svenska handlingar högre än en SaaS-leverantör gör; en koncern kan prioritera organisatoriska gränser och återanvändning av uppgifter.
Kravmatris för samma prov
| Område | Vad ni visar i demon | Vad ni begär som bevis |
|---|---|---|
| Register, artikel 30 | Skapa och ändra behandling med ägare | Export med nödvändiga fält och ändringshistorik |
| Biträden, artikel 28 | Byt leverantör och koppla avtal | Synliga instruktioner, underbiträden och godkännande |
| Rättigheter, artiklarna 12–22 | Ta emot tillgångsbegäran för två system | Tidslinje, undantagsbedömning och svar |
| DPIA, artikel 35 | Bedöm ny riskfylld behandling | Skäl, åtgärder, beslutsfattare och omprövning |
| Incident, artiklarna 33–34 | Dokumentera felutskick | Riskbedömning och separata beslut om anmälan/information |
| Säkerhet och överföring | Visa åtkomst och underleverantör | Avtal, rollmatris, dataflöde och överföringsstöd |
| Avslut | Exportera och radera provorganisation | Dokumenterade format och avtalsvillkor |
Alla punkter är inte lagstadgade programvarufunktioner. Tabellen översätter skyldigheter till testbara arbetsuppgifter. Ett verktyg kan hantera vissa delar medan andra utförs i era befintliga system. Om er organisation behöver ett dataskyddsombud, ska ombudets rådgivning och kontroll kunna synas utan att godkännandeansvaret flyttas från verksamheten. Poängen är att identifiera luckan och dess ägare. Dokumentera för varje rad ”visat”, ”endast uppgivet”, ”kräver annan modul”, ”utförs utanför verktyget” eller ”saknas”. Denna femgradiga notering är mer hederlig än en ja/nej-lista byggd på broschyrtext.
Jämför registret på rätt nivå
Artikel 30 skiljer mellan register för personuppgiftsansvariga och för biträden. Om ert bolag har båda rollerna behöver demon hantera båda utan att blanda samman dem. Ett register ska vara aktuellt och kunna göras tillgängligt för tillsynsmyndigheten. Prova därför att lägga till ändamål, kategorier, mottagare, överföringar, gallringskriterier och allmän beskrivning av skyddsåtgärder där de krävs. Se om en tom ruta tydligt markeras och om fel rättas med historik. Vår mall för registerförteckning hjälper er bedöma innehållet separat från programvaran.
Fråga också vem som uppdaterar registret efter ett nytt inköpt system. En plattform som kan föreslå ett första utkast men saknar en ansvarig uppdateringsprocess blir snabbt inaktuell. Om en leverantör beskriver „automatisk upptäckt“, be den visa vilka datakällor som faktiskt ansluts och vilka uppgifter som fortfarande måste anges av en människa. Automatiskt skapade fält är inte automatiskt korrekta rättsliga bedömningar.
Undantaget i artikel 30.5 för färre än 250 anställda ska inte bli ett säljargument i någon riktning. Det är villkorat bland annat av att behandlingen är tillfällig och inte medför risk eller särskilda kategorier. Ni kan också behöva dokumentera behandlingar för att klara andra skyldigheter även när just registerkravet inte gäller en aktivitet. Bedöm därför omfattning per behandling, inte som en generell gräns för att köpa system.
Jämför biträdesrelationen, inte bara avtalslagret
Visa ett avtal där underbiträden får anlitas efter ett visst godkännandeförfarande. Kan verktyget koppla avtalet till de system och behandlingar som biträdet faktiskt hanterar? Kan en ny underleverantör utlösa ett granskningsärende? Finns version, datum och beslutsfattare? En PDF-samling kan räcka för få avtal, men större miljöer behöver veta vilka dokument som påverkas när förhållandena ändras. Artikel 28-guiden om biträdesavtal förklarar vad en klausulgranskning bör kontrollera.
Det är missvisande att jämföra ”AI-granskning: ja/nej” utan exempel. En modell kan hitta relevanta klausuler men ändå missa en instruktion i ett bilagt dokument eller felaktigt godkänna en vag säkerhetsbestämmelse. Testa därför ett anonymiserat avtal med en medvetet oklar underbiträdesklausul. Bedöm om verktyget visar källtext, osäkerhet, ansvarig människa och möjlighet att rätta resultatet. Om granskningen endast finns i ett annat paket ska offerten säga det.
Jämför rättigheter och incidenter i tidslinjen
En begäran om tillgång kan röra data i kundtjänst, fakturering och ett externt CRM. Ett fungerande ärende visar mottagning, identitetskontroll, uppgiftsägare, insamling, eventuella begränsningar och svar. Artikel 12.3 ger i regel en månad från mottagandet, med möjlighet till förlängning när förutsättningarna är uppfyllda och den enskilde informeras. Det räcker inte att ett verktyg skickar en påminnelse; prova om ni kan ta fram ett begripligt, korrekt underlag och visa vad som beslutades. För en organisation med få ärenden kan en tydlig manuell rutin vara fullt tillräcklig.
Vid incidenter måste programvaran hålla isär teknisk händelse, personuppgiftsincident och de två externa besluten. Efter artikel 33 ska ansvarig anmäla till IMY om det inte är osannolikt att incidenten leder till risk för enskildas rättigheter och friheter; anmälan sker utan onödigt dröjsmål och om möjligt inom 72 timmar från vetskap. Varje personuppgiftsincident dokumenteras. Artikel 34 kräver information till berörda när incidenten sannolikt leder till hög risk, med angivna undantag. Använd en fiktiv händelse där risken bedöms låg och en annan där känsliga uppgifter kommit till en okänd mottagare. Se om besluten kan motiveras separat. IMY:s vägledning om incidenthantering är en aktuell primär kontrollpunkt; det interna anmälningsförfarandet har en annan uppgift än leverantörsjämförelsen.
Jämför riskarbetet före start
En konsekvensbedömning enligt artikel 35 ska göras före behandling som sannolikt medför hög risk. IMY:s vägledning om när DPIA behövs ger svensk kontext. Be leverantören visa hur planerad behandling, nödvändighet, proportionalitet, risker och åtgärder dokumenteras. Går det att se vilka uppgifter som saknas? Kan en granskare avvisa förslaget och lämna skäl? Kan ändringar senare utlösa omprövning? En knapp ”DPIA godkänd” utan substans hjälper föga.
Lika viktigt är att inte anta att varje behandling kräver en DPIA. Dokumentera bedömningen av tröskeln och använd organisationens sakkunskap. Om verktyget påstår att det „certifierar“ behandlingen bör ni fråga vilken certifieringsordning och vilken verifierbar tredjepart som avses. Ett internt arbetsflöde är ingen myndighetsstämpel.
Leverantörerna som testobjekt
Den tidigare svenska leverantören DPOrganizer hänvisar numera på sin webbplats till DataGuard. Om namnet DPOrganizer står i en gammal upphandlingsmall, be om ett aktuellt produktblad som kopplar äldre benämning till dagens tjänst. Dastra visar på sin plansida att register och mappning respektive rättighetsärenden, incidenter och avtalsanalys ligger på olika nivåer. En jämförelse måste därför gälla samma paketomfattning, inte bara varumärket.
OneTrust visar ett brett utbud inom integritetsautomation, samtycke och tredjepartshantering. TrustArc beskriver särskilt datakartläggning med koppling mellan system, leverantörer och processer. Vanta beskriver numera uttryckligen ett GDPR-erbjudande tillsammans med säkerhetsramverk; Sprintos exakta erbjudande behöver kontrolleras i aktuell offert. Dessa offentliga beskrivningar är skäl att bjuda in till provet, inte bevis på att en viss funktion, svensk utdata eller viss lagringsregion ingår hos er.
Tekniska och avtalsmässiga frågor i jämförelsen
Ställ samma frågor om dataplacering, tillgång från tredje land, underbiträden, export, radering och incidentnotifiering till alla. Ett europeiskt serverval kan vara relevant men utesluter inte överföring genom supportåtkomst. Be om rättsligt stöd för överföringar enligt kapitel V, inte bara en flagga med EU-symbol. Begär exempel på hur behörigheter begränsar tillgång till känsliga bilagor och hur administratörsåtgärder loggas. Ett verktyg ska inte kräva att alla konsulter ser alla kunders material bara för att det säljs som gemensam plattform.
Fråga hur tjänsten avslutas. Kan ni exportera register, ärenden, bilagor, länkar och historik i ett format som går att använda? Hur länge finns backupkopior och vad händer med data efter avtalsslut? Finns en dokumenterad möjlighet att fortsätta verksamheten om leverantören är otillgänglig? Dessa frågor är särskilt viktiga när systemet blir den enda platsen där beslut och avtal lagras.
Bedömning och beslut
Efter varje demo ger tre roller poäng 0–3 för varje prioriterat prov: processägaren för användbarhet, dataskyddsansvarig för spårbarhet och IT/inköp för säkerhet och avtal. Skriv en mening om observerat bevis. Väg samman först när alla har sett samma scenario. Kriterier som inte provats får „ej verifierat“, inte noll eller full poäng. Håll totalpriset som en egen dimension så att ett lågt pris inte maskerar ett saknat kritiskt steg.
Beslutsunderlaget bör innehålla de två främsta alternativen, skillnaden som faktiskt observerades, ansvarig för eventuell manuell komplettering och en plan för införande. Om båda misslyckas på ett kritiskt prov är nästa steg att justera krav eller bjuda in en tredje kandidat. Ett inköp löser inte datakvalitet: innan import behöver ni rensa duplicerade behandlingar, namnge ägare och skilja rättsliga beslut från tekniska gissningar. Då kan verktyget börja med en begriplig grund.
Dokumentera skillnaden mellan påstående och visning
En jämförelsematris bör ha en kolumn för källa. Skriv till exempel „visades i demomiljö 27 september“, „står i offertbilaga“, „står i produktbeskrivning“ eller „muntligt besked“. Dessa nivåer betyder olika saker. En visad funktion kan höra till en dyrare abonnemangsplan; en avtalsbilaga kan beskriva en tjänst som ännu inte är aktiverad. Be därför leverantören knyta varje kritisk funktion till er offert. Anteckna versionen av underlaget, särskilt om upphandlingen pågår i flera månader.
För funktioner som använder AI behöver ni också veta hur ett fel upptäcks. Prova ett behandlingsändamål som avsiktligt är otydligt. Ett bra arbetsflöde bör visa att frågan behöver klargöras, vilka källor eller uppgifter förslaget bygger på och vem som kan avvisa det. Om systemet fyller i en säker laglig grund trots att fakta saknas kan snabbheten bli en risk. Fråga om kunddata används för att träna modeller, var eventuella underleverantörer finns och hur avtalet reglerar detta. Samma kontroll är relevant även för leverantörer som beskriver sin funktion som „assistent“ snarare än AI.
Om ni också utvecklar eller använder ett AI-system i verksamheten behöver ni bedöma systemets egna krav utifrån er roll och användning. Valet av GDPR-plattform avgör inte i sig om AI-förordningens regler gäller eller hur de ska uppfyllas. För den separata inköpsuppgiften finns vår guide till programvara för AI-förordningen.
Låt sedan två blivande användare genomföra samma vardagsuppgift utan säljarens hjälp. Den ena ska vara kunnig i GDPR, den andra processägare utan juridisk specialisering. Mät inte bara antal klick: se om de hittar rätt behandling, förstår vad som kräver beslut och kan lämna över till granskare. Ett verktyg som fungerar utmärkt för en specialist men inte för dem som måste lämna in fakta kan ge ett vackert men ofullständigt register.
Svenskt språk och nationell kontext
Svensk användartext, svensk support och svenska exportdokument är skilda egenskaper. Be om ett exempel på var och en om de är krav. Maskinöversatta fältnamn kan vara begripliga men en felaktig juridisk term i information till registrerade kan skapa problem. Låt en svenskspråkig användare bedöma en exporterad registerpost, ett ärendesvar och en incidentrapport. Bekräfta samtidigt om mallar följer svensk tillsynsvägledning eller bara återger GDPR:s EU-text. En produkt kan vara fullt användbar utan svensk språkversion om organisationen har rätt resurser; kravet bör därför förankras i det faktiska arbetet.
Svensk kontext betyder inte heller att alla data måste ligga i Sverige. Fråga i stället om verkliga överföringar, åtkomst, underbiträden och rättsligt stöd. En produkt med svenskt bolag kan ha internationella tjänsteleverantörer, och en utländsk leverantör kan erbjuda en relevant lösning. Avtalet och dataflödet avgör frågan. För specifika ärenden bör ni dessutom använda IMY:s aktuella vägledning; en leverantörs inbyggda text kan behöva uppdateras när praxis ändras.
När en jämförelse ska avbrytas
Ibland visar provet att inget verktyg löser huvudproblemet eftersom underlaget saknas. Om ingen vet vilka behandlingar som finns, vem som äger dem eller vilka avtal som gäller, bör ni först göra en begränsad kartläggning. Ett inköp kan fortfarande vara rätt, men då måste datainsamling och ansvar ingå uttryckligen i införandeplanen. Annars jämför ni demonstrationshastighet för snygga exempel i stället för förmågan att ordna er verklighet.
Ett annat stopptecken är oklar avtalsomfattning. Om kritiska moduler, tillgång till data eller exitvillkor inte kan bekräftas skriftligt, är det för tidigt att förklara en kandidat vinnare. Be om en kompletterad offert och samma prov på den faktiska abonnemangsplan som ska köpas. Den disciplinen skyddar både budget och dataskydd och ger en tydlig motivering när beslutet senare granskas.
Vanliga frågor
Kan man jämföra leverantörer enbart i en funktionstabell?
Nej. Tabellen visar vilka frågor som ska provas; den visar inte kvaliteten på genomförandet eller paketets omfattning. Ge alla samma scenario och dokumentera den faktiska demon och avtalsbilagorna.
Ska det billigaste verktyget vinna?
Bara om det klarar era kritiska arbetsuppgifter och villkoren är acceptabla. Ett dyrare verktyg kan spara intern tid, men detta ska mätas med egna data. Se kostnadsguiden för en separat kalkyl.
Kräver GDPR att allt samlas i en plattform?
Nej. Flera fungerande processer kan tillsammans uppfylla skyldigheterna. Säkerställ då att överlämningar, ansvar och dokumentation fungerar också när en person är frånvarande eller en leverantör byts.