Inbyggt dataskydd (privacy by design) betyder att skyddet för personuppgifter ska byggas in i system, tjänster och processer redan när de utformas – inte läggas till i efterhand. Artikel 25 i dataskyddsförordningen ställer två krav: dels inbyggt dataskydd (data protection by design), som innebär att tekniska och organisatoriska åtgärder ska integreras i behandlingen från början, dels dataskydd som standard (data protection by default), som innebär att systemets grundinställningar ska vara de mest integritetsvänliga. För svenska organisationer är detta framför allt en fråga om hur ni utvecklar och upphandlar IT.
Viktigaste punkterna
- Artikel 25 kräver att dataskydd byggs in vid utformningen av en behandling och att grundinställningarna är integritetsvänliga.
- Dataskydd som standard innebär att endast de personuppgifter som är nödvändiga för varje specifikt ändamål behandlas per automatik – inte att användaren måsta stänga av delning i efterhand.
- Kravet gäller den personuppgiftsansvarige, men får störst praktisk betydelse vid systemutveckling och upphandling av externa tjänster.
- Konkreta åtgärder är dataminimering, pseudonymisering, åtkomstbegränsning och korta gallringsfrister som förval.
- EDPB:s riktlinjer 4/2019 är den centrala vägledningen för hur artikel 25 ska tolkas.
De två kraven i artikel 25
Artikel 25 delas i två delar som ofta blandas ihop.
Inbyggt dataskydd (25.1) kräver att den ansvarige, både när medlen för behandlingen bestäms och under själva behandlingen, vidtar lämpliga tekniska och organisatoriska åtgärder – som pseudonymisering – utformade för att genomföra dataskyddsprinciperna på ett effektivt sätt. Det ska ske “med beaktande av den senaste utvecklingen, genomförandekostnaderna och behandlingens art, omfattning, sammanhang och ändamål”.
Dataskydd som standard (25.2) kräver att den ansvarige säkerställer att endast de personuppgifter som är nödvändiga för varje specifikt ändamål behandlas som förval. Det gäller uppgifternas mängd, behandlingens omfattning, lagringstiden och tillgängligheten. Ett tydligt exempel: en profil i en ny tjänst ska inte vara publik som standard, utan privat – användaren ska aktivt behöva öppna upp, inte aktivt behöva stänga.
Vad det innebär vid utveckling
I praktiken översätts artikel 25 till konkreta designval. De viktigaste principerna att bygga in är:
| Princip | Konkret åtgärd i systemet |
|---|---|
| Dataminimering | Samla bara in de fält som ändamålet kräver – inga “kan vara bra att ha”-uppgifter |
| Åtkomstbegränsning | Rollbaserad behörighet; inre sekretess så att bara de som behöver ser uppgifterna |
| Pseudonymisering | Separera identifierande uppgifter från behandlingsdata där det går |
| Lagringsminimering | Automatisk gallring efter definierad frist som förval |
| Transparens | Tydlig information om behandlingen inbyggd i gränssnittet |
| Säkerhet som förval | Kryptering, loggning och säkra grundinställningar från start |
Att bygga in dessa åtgärder tidigt är billigare och effektivare än att rätta till dem efter driftsättning. En behandling som är dataminimerad från början genererar dessutom mindre risk i alla efterföljande led – mindre att skydda, mindre att gallra, mindre att exponera vid en incident.
Varför upphandling är den kritiska punkten
De flesta svenska organisationer bygger inte sina egna system utan köper dem. Då förskjuts artikel 25 till upphandlingen: ni måste ställa krav på att leverantörens produkt lever upp till inbyggt dataskydd. Ansvaret enligt artikel 25 ligger kvar hos er som personuppgiftsansvarig även när tekniken byggs av någon annan.
Praktiskt betyder det att en säkerhets- och dataskyddskravställning ska ingå i kravspecifikationen: hur hanterar systemet åtkomst, gallring, loggning, pseudonymisering och grundinställningar? Detta hänger ihop med personuppgiftsbiträdesavtalet och med kontrollen av var uppgifterna behandlas. För en behandling med hög risk ska bedömningen av inbyggt dataskydd dessutom vägas in i en konsekvensbedömning innan systemet driftsätts.
Ett vanligt misstag är att dataskyddsfrågan ställs först efter att systemet valts, när kravspecifikationen redan är låst. Då blir det svårt eller dyrt att kräva ändringar, och organisationen tvingas acceptera leverantörens grundinställningar oavsett om de är integritetsvänliga eller inte. Rätt läge att ställa kraven är i upphandlingens tidiga fas, gärna med en checklista som utvärderar hur varje anbud hanterar åtkomst, gallring, kryptering och datalokalisering. På så sätt blir inbyggt dataskydd ett urvalskriterium i stället för en efterhandskorrigering.
Ett exempel: inbyggt dataskydd i praktiken
Ta ett konkret fall: en kommun ska införa ett nytt system för att hantera synpunkter och klagomål från medborgare. Utan inbyggt dataskydd byggs systemet så att alla handläggare ser alla ärenden, fritextfält frestar till att skriva in mer än nödvändigt, ingen automatisk gallring finns och all data lagras hos en underleverantör utanför EU. Varje val ökar risken.
Med inbyggt dataskydd ser samma projekt annorlunda ut från start:
- Dataminimering: formuläret ber bara om de uppgifter ärendet kräver, och känsliga fält undviks eller motiveras särskilt.
- Åtkomst som standard: en handläggare ser bara sina egna ärenden; utökad behörighet kräver ett aktivt beslut.
- Gallring som förval: ärenden raderas automatiskt en bestämd tid efter avslut, med undantag för det som ska arkiveras enligt arkivlagstiftning.
- Transparens: medborgaren informeras direkt i formuläret om hur uppgifterna behandlas.
- Säkerhet: kryptering, loggning och EU-baserad lagring är grundinställningar, inte tillval.
Poängen är att alla dessa åtgärder är billigast och mest effektiva att införa vid utformningen. Att lägga till åtkomstbegränsning eller gallring i ett system som redan är i drift kräver ofta ombyggnad, migrering och nya avtal. Artikel 25 flyttar därför tyngdpunkten i dataskyddsarbetet till projektets tidiga faser – till kravställning, systemval och design – i stället för till en efterhandskontroll när skadan redan kan vara skedd. Den som samlar in för mycket från början tvingas dessutom hantera mer i varje efterföljande led, från gallring till incidenthantering.
Kopplingen till de övriga principerna
Inbyggt dataskydd är inte en fristående regel utan mekanismen som gör de andra principerna verkliga. Dataminimering enligt artikel 5.1 c blir bara efterlevd om systemet inte frestar till överinsamling. Lagringsminimering blir efterlevd om gallring är en förvald funktion. Rätt rättslig grund och tydlig information blir enklare att uppfylla om behandlingen är genomtänkt från start. Artikel 25 är alltså den strukturella garantin bakom hela regelverket.
För organisationer som hanterar många system blir utmaningen att hålla ordning på vilka behandlingar som lever upp till kraven. Att koppla varje behandling i registerförteckningen till en dokumenterad bedömning av inbyggt dataskydd ger den överblicken – ett arbete som en plattform som Legiscope kan strukturera. Poängen är inte verktyget i sig, utan att bedömningen dokumenteras och kan visas vid en tillsyn.
Vanliga frågor
Vad är skillnaden mellan inbyggt dataskydd och dataskydd som standard?
Inbyggt dataskydd (art. 25.1) handlar om att bygga in skyddsåtgärder när behandlingen utformas. Dataskydd som standard (art. 25.2) handlar om att systemets grundinställningar ska vara de mest integritetsvänliga, så att bara nödvändiga uppgifter behandlas utan att användaren behöver ändra något.
Gäller artikel 25 även om vi köper ett färdigt system?
Ja. Ansvaret ligger kvar hos er som personuppgiftsansvarig. I praktiken uppfyller ni artikel 25 genom att ställa krav på inbyggt dataskydd i upphandlingen och i biträdesavtalet med leverantören.
Är privacy by design obligatoriskt eller en rekommendation?
Det är en obligation. Artikel 25 är en rättsligt bindande skyldighet, inte en rekommendation. IMY kan förelägga om åtgärder och besluta om sanktionsavgift vid brister. EDPB:s riktlinjer 4/2019 preciserar hur kravet ska uppfyllas i praktiken.
Hur visar vi att vi uppfyllt artikel 25?
Genom dokumentation. Ansvarsskyldigheten i artikel 5.2 innebär att ni ska kunna visa vilka dataskyddsval som gjorts vid utformningen och varför. I praktiken görs det genom kravspecifikationer, designbeslut och – för behandlingar med hög risk – en konsekvensbedömning. Koppla bedömningen till respektive behandling i registerförteckningen.
Slutsats
Inbyggt dataskydd innebär att skyddet för personuppgifter byggs in i tekniken från start och att grundinställningarna är integritetsvänliga. För svenska organisationer avgörs efterlevnaden oftast vid utveckling och upphandling: ställ dataskyddskrav i kravspecifikationen, minimera insamlingen, sätt gallring och åtkomstbegränsning som förval och dokumentera bedömningen. Grunden finns i artikel 25 i dataskyddsförordningen och i EDPB:s riktlinjer, och IMY väger in inbyggt dataskydd i sin bedömning av om en behandling är laglig.
Automate your GDPR compliance
Save 340+ hours per year on compliance work. Legiscope provides AI-powered GDPR management trusted by compliance professionals.
Discover Legiscope