EDPB:s harmoniserade DPIA-mall från 2026 är den bästa utgångspunkten för de flesta organisationer. Den här artikeln ger en sektion-för-sektion-genomgång, kopierbara checklistor och en risktabell du kan använda direkt, samt vägledning om samråd och löpande uppföljning så att dokumentet håller vid en faktisk granskning.
Kort sagt:
- De flesta organisationer bör använda EDPBs gemensamma DPIA-mall, eftersom den är EU-harmoniserad och lätt att anpassa till nationella krav.
- En DPIA krävs alltid vid behandlingar som innebär stor risk för individers rättigheter, till exempel storskalig behandling av känsliga data eller allmän platsövervakning.
- Det är avgörande att dokumentera Teknik-, Process- och Riskbedömningar tydligt, samt koppla varje risk till konkreta, verifierbara åtgärder för att stärka dokumentets trovärdighet.
- DPIA-processen ska uppdateras minst årligen och vid förändringar i tekniken, målgruppen eller vid säkerhetsincidenter för att behålla sitt värde.
- Effektiv DPIA-uppföljning kan enkelt stödas av digitala verktyg som möjliggör automatiska påminnelser, ansvarsfördelning och realtidsuppföljning av förbättringar.
Innehållsförteckning
- Vilken dpia-mall ska du använda?
- När krävs en DPIA enligt GDPR?
- Sektion-för-sektion: så fyller du i mallen
- Färdiga byggblock du kan kopiera in direkt
- Så samlar du in rätt information från organisationen
- Varför dpia-processen aldrig är klar
- Jespers reflektion: fallgroparna jag ser om och om igen
- Trustview gör dpia-arbetet till en process, inte ett engångsprojekt
- Källor
Vilken dpia-mall ska du använda?
EDPB antog i april 2026 en gemensam mall för konsekvensbedömningar, med det uttalade syftet att harmonisera hur DPIA-dokument ser ut inom EU. Mallen finns fritt tillgänglig och är tänkt att fungera som ett gemensamt EU-ramverk snarare än ett nationellt påfund, vilket gör den till ett naturligt förstahandsval oavsett var i unionen din organisation verkar.
Strukturen bygger på sex huvuddelar:
- Ett tekniskt informationsblad med version, ägare och datum
- En systematisk beskrivning av behandlingen
- En bedömning av nödvändighet och proportionalitet
- En riskbedömning kopplad till fysiska personers rättigheter
- En åtgärdsplan med konkreta skyddsåtgärder
- Ett formellt beslut med motivering
Mallen är avsiktligt hållen på en generell nivå. EDPB har byggt den som en så kallad meta-mall, det vill säga ett skelett som lämnar utrymme för nationell anpassning snarare än en färdig metodik som ska följas ord för ord, enligt en analys från Reed Smith. Det betyder att du fortfarande behöver komplettera med lokal vägledning.
I Sverige gäller det IMY, som tillhandahåller egna screeningverktyg och exempelmallar anpassade efter svensk tillsynspraxis. En pragmatisk arbetsmetod är att använda EDPB-mallen som grundstruktur och sedan väva in IMY:s formuleringar och riskkriterier där de är mer konkreta än EU-versionen.
Spara alltid dokumentet i både PDF och redigerbart format (till exempel DOCX). PDF fungerar för arkivering och delning med tillsynsmyndigheten, medan ett redigerbart format krävs för det löpande arbetet, eftersom en DPIA aldrig är klar i egentlig mening. Håll också en enkel versionslogg i mallens försättsblad, annars blir det snabbt oklart vilken revision som faktiskt godkändes.
När krävs en DPIA enligt GDPR?
Skyldigheten regleras i artikel 35 i GDPR, och kravet gäller när en behandling sannolikt innebär hög risk för fysiska personers rättigheter och friheter. Lagtexten är medvetet öppen, vilket i praktiken lämnar bedömningen till dig. Tre situationer nämns explicit i artikeln och fungerar som tydliga triggers:
- Systematisk och omfattande profilering som leder till beslut med betydande rättslig eller liknande effekt för den enskilda.
- Storskalig behandling av särskilda kategorier av personuppgifter, som hälsodata, biometri eller uppgifter om lagöverträdelser.
- Systematisk övervakning av en allmän plats i stor skala, till exempel kameraövervakning i ett köpcentrum eller en stadsdel.
Utöver dessa tre huvudtriggers är det värt att screena varje nytt projekt mot en bredare uppsättning riskindikatorer: används ny teknik, kombineras dataset från olika källor, drabbar behandlingen sårbara grupper som barn, eller sker det överföring till tredje land utan adekvat skyddsnivå. IMY rekommenderar en strukturerad, stegvis screeningmetod i tio steg för att avgöra om tröskeln är nådd, snarare än en enkel ja/nej-fråga baserad på magkänsla.
I praktiken pekar “storskalig” mot volym (antal registrerade), geografisk spridning och varaktighet, medan “betydande effekt” handlar om konsekvensen för individen, till exempel om ett automatiserat beslut påverkar en anställning, ett lån eller en vårdinsats. Om du är osäker efter screeningen: gör hellre en lättviktig DPIA än ingen alls. Ett kort, dokumenterat resonemang om varför en full bedömning inte krävs är i sig ett bra skydd om frågan kommer upp senare.
Sektion-för-sektion: så fyller du i mallen
Det här är den del av arbetet där de flesta DPIA:er brister, inte i formuleringen av juridiska slutsatser utan i bristande konkretion. En granskare, intern eller extern, ska kunna läsa dokumentet och förstå exakt vad som behandlas, varför och med vilka skydd, utan att ringa upp den som skrev det.
Försättsblad och teknisk information
Börja med det administrativa skelettet: versionsnummer, datum för senaste uppdatering, dokumentägare (oftast dataskyddsombudet), vilket team eller projekt behandlingen tillhör, samt referenser till relaterade dokument som registerförteckningen eller ett tidigare beslut. Det här avsnittet känns trivialt, men det är ofta det första en tillsynsmyndighet eller intern revisor kontrollerar för att bedöma om dokumentet underhålls aktivt.
Beskrivning av behandlingen
Här beskriver du ändamålet med behandlingen i klartext, vilka kategorier av personuppgifter som samlas in, vilka kategorier av registrerade som berörs och hur data flödar genom systemen, från insamling till radering. Ett flödesdiagram, även ett enkelt, gör det betydligt lättare för en läsare att följa logiken än ett textstycke fullt av systemnamn. Ange också lagringstider och vilka tredje parter (leverantörer, molntjänster, underbiträden) som har åtkomst.
Nödvändighet och proportionalitet
Det här avsnittet är ofta det svagaste i DPIA:er som skrivs snabbt. Kravet är att du visar varför behandlingen är nödvändig för ändamålet, och att du har övervägt mindre integritetskänsliga alternativ. Skriv konkret: vilka andra lösningar diskuterades, och varför valdes de bort? EDPS necessity toolkit ger en strukturerad metod för att resonera kring det här, särskilt när behandlingen bygger på ett berättigat intresse snarare än samtycke.
Riskbedömning
Riskbedömningen bör bygga på en tydlig poängsättningsmodell, vanligen en skala på tre till fem steg för sannolikhet och en motsvarande skala för konsekvens. Varje poäng måste ha en motiveringstext, inte bara en siffra, så att en extern granskare förstår resonemanget bakom bedömningen. En risktabell kan se ut så här:
| Risk | Sannolikhet | Konsekvens | Motivering |
|---|---|---|---|
| Obehörig åtkomst till hälsodata | Medel | Hög | Systemet saknar loggning av åtkomst per användare |
| Felaktig profilering påverkar kreditbeslut | Låg | Hög | Modellen har inte testats för snedvridning mot delgrupper |
| Data kvarhålls längre än nödvändigt | Hög | Medel | Ingen automatiserad raderingsrutin finns implementerad |
Åtgärdsplan och beslut
Varje identifierad risk ska kopplas till en konkret åtgärd, inte en vag avsikt. “Vi ska förbättra säkerheten” är ingen åtgärd som går att följa upp. “Implementera rollbaserad åtkomstkontroll för hälsodatamodulen, ansvarig IT-säkerhetschef, klart senast 30 juni 2026, bevis: konfigurationsrapport från systemet” är det. Malltexter bör alltid kompletteras med konkreta bevis för att en åtgärd faktiskt fungerar, som loggar, testresultat eller signerade konfigurationsprotokoll, annars blir dokumentet svagt vid granskning.
Avsluta med ett formellt beslut: godkänns behandlingen, godkänns den villkorat under att vissa åtgärder genomförs inom en satt tid, eller stoppas den? Ange residualrisken, det vill säga risken som kvarstår efter att åtgärderna är implementerade, och vem som fattat beslutet.
Proffstips: Skriv aldrig en åtgärd utan ett bevisfält. Om du inte kan definiera vad som ska bifogas som bevis för att åtgärden är genomförd, är åtgärden troligen för vag för att gå att följa upp.
Färdiga byggblock du kan kopiera in direkt
En DPIA-checklist är bara så bra som de element du fyller den med. Här är två byggblock som går att klistra in i din egen mall, och ett kort exempel som visar logiken i praktiken.
Åtgärdspost att kopiera
| Fält | Innehåll |
|---|---|
| Åtgärd | Automatiserad radering av loggdata efter 30 dagar |
| Ansvarig | Systemägare, IT-drift |
| Deadline | 2026-06-30 |
| Bevis | Skärmdump av schemalagd raderingsjobb + testkörning |
| Status | Pågående |
Case: kameraövervakning i en butikskedja
Tänk dig en butikskedja som vill installera kameror med ansiktsigenkänning för att motverka stöld. Innan DPIA:n skrevs fanns bara ett kort beslut om att “installera kamerasystem för säkerhet”. Efter en fullständig genomgång enligt mallen framkom att systemet klassificerades som storskalig övervakning av allmän plats, en av de tre huvudtriggrarna i artikel 35. Riskbedömningen identifierade att ansiktsigenkänning innebär behandling av biometriska uppgifter, vilket kräver särskild rättslig grund. Slutresultatet blev ett villkorat godkännande: kamerorna fick installeras, men utan ansiktsigenkänningsfunktionen, och med en ny åtgärd om skyltning och begränsad lagringstid på 30 dagar. Det är precis den typen av omsvängning en ordentlig DPIA-analys exempel ska kunna visa, inte bara bekräfta en redan fattad beslutsplan.
Samma logik gäller för AI-driven profilering, till exempel vid automatiserade kreditbeslut eller riktad marknadsföring, där en strukturerad genomgång av dataskyddsutmaningar vid AI-användning ofta avslöjar risker som inte syntes vid projektstart.
Så samlar du in rätt information från organisationen
En DPIA som bara skrivs av juridik missar ofta operativa risker som bara syns för dem som faktiskt bygger och driver systemet. Att förlita sig enbart på juridisk personal leder ofta till ofullständiga bedömningar som ser bra ut på papper men inte matchar verkligheten.
- Fråga tekniska team konkret: var lagras uppgifterna, vem har åtkomst, hur loggas åtkomsten, och vad händer vid en incident? Generella svar som “det är krypterat” räcker inte, be om specifikationer.
- Låt verksamheten formulera ändamålet i egna ord: juridik kan sedan omsätta det till korrekt terminologi, men den ursprungliga formuleringen avslöjar ofta om syftet är bredare än vad som faktiskt behövs, vilket direkt påverkar proportionalitetsbedömningen.
- Involvera leverantörer tidigt, särskilt om databehandling sker hos ett underbiträde. Be om deras egna säkerhetsdokumentation snarare än att anta att den matchar era krav.
- Dokumentera varje svar med datum och namn på den som lämnat informationen, och sätt en tydlig deadline för uppföljning där svar saknas.
Proffstips: Boka ett kort, fokuserat möte med IT innan du skriver ett enda ord i riskbedömningen. Tio minuter med rätt tekniker sparar ofta timmar av omskrivning senare.
Varför dpia-processen aldrig är klar
En DPIA som skrivs en gång och sedan läggs i en pärm förlorar sitt värde inom några månader. Verksamheten förändras, ny teknik införs, och de risker som fanns vid skrivtillfället kan redan vara inaktuella.
Vanliga triggers för att uppdatera dokumentet:
- Ny teknik introduceras i behandlingen, till exempel en AI-modell som ersätter ett regelbaserat system
- Målgruppen för behandlingen breddas, exempelvis från anställda till även kunder
- En säkerhetsincident inträffar som avslöjar en svaghet i tidigare riskbedömning
- Ett leverantörsbyte sker där den nya parten hanterar uppgifterna på ett annat sätt
En rimlig utgångspunkt är att formellt granska varje DPIA minst en gång per år, samt direkt vid någon av triggrarna ovan. Dokumentera varje revision med datum, vem som granskade och vilka ändringar som gjordes, snarare än att bara skriva över den gamla versionen.
Koppla dessutom dokumentet till er registerförteckning, era rutiner för gallring och er process för incidenthantering. Ett effektivt uppföljningsflöde knyter DPIA:n till ett ärendesystem så att åtgärder automatiskt påminns och markeras som klara först när bevis faktiskt är bifogat, inte bara när någon manuellt bockar av en ruta.
Jespers reflektion: fallgroparna jag ser om och om igen
De DPIA:er som faller igenom vid granskning har sällan fel juridisk slutsats. Problemet ligger nästan alltid i detaljerna: åtgärder skrivna som avsikter istället för mätbara kontroller, riskpoäng utan motivering, och en teknisk beskrivning som är för generell för att gå att verifiera.
Den vanligaste bristen jag stöter på är att teamet som skriver dokumentet aldrig pratade med systemägaren. Resultatet blir ett dataflöde som beskriver hur systemet borde fungera enligt dokumentationen, inte hur det faktiskt fungerar i drift. Den skillnaden är precis där de allvarliga riskerna gömmer sig.
Den andra återkommande svagheten är bristande spårbarhet över tid. En DPIA från för två år sedan som aldrig uppdaterats trots ett systembyte är i praktiken ett dokument utan värde, oavsett hur väl skrivet det en gång var. Här gör en strukturerad plattform skillnad, inte genom att ersätta det juridiska omdömet, utan genom att hålla mallar, ansvarsposter och reviewdatum synkade så att ingen åtgärd tystnar bort i en mapp ingen öppnar igen.
— Jesper
Trustview gör dpia-arbetet till en process, inte ett engångsprojekt
Det finns digitala lösningar som är alternativet till att hantera DPIA-arbetet i lösa Word-dokument och delade mappar. Sådana plattformar kan samla mallar, riskbedömningar, åtgärdsuppföljning och rapportering på samma plats, vilket gör det möjligt att se status på varje pågående bedömning i realtid istället för att jaga svar i mejltrådar.
Istället för att bygga upp en egen struktur från noll varje gång ett nytt projekt kräver en konsekvensbedömning, kan ditt team utgå från färdiga arbetsflöden som automatiskt kopplar risker till ansvariga personer, deadlines och bevisfält, precis den typen av spårbarhet som gör en DPIA hållbar över tid snarare än en engångsinsats. Trustview stödjer flera regelverk parallellt, inklusive GDPR, NIS2 och ISO 27000, vilket är relevant om din organisation redan arbetar med andra ISO-standarder eller planerar för AI-förordningens krav.
Vill du se hur det fungerar i praktiken för en större organisation, ta en titt på ett verkligt exempel från ett statligt bolag. Är du redo att testa själv, boka en genomgång av plattformen och se hur mallarna kan anpassas efter er verksamhet redan denna vecka.
Källor
De officiella källorna nedan är värda att länka till direkt i ditt dokument, både som referens och som bevis på att metodiken följer erkänd praxis.
- Enhancing compliance and consistency: EDPB adopts DPIA template
- Sweden: IMY publishes guidance on DPIAs
- Regulation (EU) 2016/679 (GDPR)
Vill du fördjupa dig ytterligare i hela dokumentationskrav för dpia-processen, finns en mer omfattande genomgång i Trustviews guide till konsekvensbedömning enligt GDPR, liksom en detaljerad beskrivning av rollerna i en dpia-process för organisationer som vill formalisera ansvarsfördelningen ytterligare.
