Inbyggt dataskydd betyder att verksamheten gör dataskyddskraven till en del av hur en behandling utformas och fungerar. Dataskydd som standard betyder att grundinställningarna begränsar behandlingen till vad som är nödvändigt för varje särskilt ändamål. Artikel 25 i GDPR kräver båda delarna. Ett informationsblad eller en säkerhetsfunktion räcker därför inte om arbetsflödet samtidigt samlar in för mycket, ger för bred åtkomst eller behåller uppgifter utan ett motiverat slut.
Den praktiska uppgiften är att kunna visa varför lösningen behöver vissa uppgifter, vilka skydd som faktiskt fungerar och vem som följer upp dem. Den här guiden hjälper projektledare, verksamhetsansvariga och inköpare att formulera sådana krav. Exemplen är hypotetiska. De illustrerar beslut som behöver anpassas till den egna behandlingen, inte färdiga besked om att en viss produkt eller inställning uppfyller lagen.
Två skyldigheter genom hela behandlingens livscykel
Artikel 25.1 i GDPR gäller både när medlen för behandlingen bestäms och när själva behandlingen genomförs. Hänsyn ska tas till teknikens utveckling, kostnaderna för genomförandet, behandlingens art, omfattning, sammanhang och ändamål samt riskerna för människors rättigheter och friheter. Åtgärderna ska effektivt genomföra dataskyddsprinciperna och ge nödvändiga skydd. Det innebär en bedömning av resultatet, inte bara av om projektet har köpt en välkänd säkerhetslösning.
Artikel 25.2 pekar särskilt ut mängden insamlade uppgifter, behandlingens omfattning, lagringstiden och tillgängligheten. Som standard får bara de personuppgifter behandlas som är nödvändiga för varje specifikt ändamål. Uppgifter får inte genom grundinställningarna göras tillgängliga för ett obestämt antal personer utan den enskildes medverkan. IMY:s vägledning om inbyggt dataskydd beskriver hur dessa delar hänger ihop.
Skyldigheten ligger på den personuppgiftsansvariga. Ett biträde kan tillhandahålla viktiga funktioner och underlag, men ansvaret för den egna behandlingen försvinner inte genom ett inköp. Kraven gäller också befintliga system. Om en äldre lösning saknar rimliga behörigheter behöver verksamheten bedöma och åtgärda bristen; systemets ålder är inte ett generellt undantag. Samtidigt ska åtgärderna vara lämpliga för den faktiska behandlingen, inte identiska i varje organisation.
Börja med ändamålet innan ni bestämmer fälten
En blankett för bokning av ett studiebesök kan behöva kontaktuppgifter och uppgifter om antal deltagare. Att samtidigt fråga efter fullständigt personnummer, yrke och familjeförhållanden kräver en annan förklaring än att fälten finns i leverantörens standardformulär. Beskriv först vad personalen behöver kunna göra efter insamlingen. Pröva därefter om varje uppgift bidrar till detta och om uppgiften måste vara obligatorisk.
Dokumentera skillnaden mellan nödvändigt och praktiskt bekvämt. Ett telefonnummer kan underlätta en brådskande ändring men vara onödigt för en tjänst där all kommunikation fungerar via e-post. Om två kontaktvägar erbjuds kan användaren ibland välja en av dem. En fältmatris för uppgiftsminimering hjälper verksamheten att koppla varje fält till ett ändamål, en motivering och den funktion som använder uppgiften.
Separera också ändamål som råkar dela samma gränssnitt. Bokning och framtida marknadsföring är olika behandlingar. En frivillig extrafunktion ska inte döljas som ett villkor för den nödvändiga tjänsten. Fastställ rättslig grund innan ni utformar insamlingen. Om en viss behandling bygger på samtycke måste valet uppfylla kraven på frivilligt och informerat samtycke; en aktiverad standardruta skapar inte ett giltigt samtycke.
Gör nödvändiga begränsningar till grundinställningar
Ett nytt användarkonto bör få den åtkomst som arbetsuppgiften kräver, inte automatiskt ärva administratörens rättigheter. Definiera roller utifrån konkreta uppgifter: registrera ett ärende, handlägga det, godkänna en utbetalning eller utreda en avvikelse. Att två personer arbetar på samma avdelning visar inte i sig att båda behöver läsa samtliga ärenden. Tillfälliga utökningar behöver en ansvarig och ett sätt att återställa behörigheten.
Utforma standardvyer så att de visar det som behövs i den aktuella situationen. En reception kan behöva se att ett möte är bokat utan att se känsliga anteckningar inför mötet. En ekonomifunktion kan behöva betalningsstatus utan tillgång till hela kunddialogen. Pröva dessutom export, sökning och massuttag. Ett system kan ha restriktiva skärmvyer men ändå låta alla användare ladda ned hela registret.
Grundinställningarna måste fungera även när någon inte läser en manual. Testa därför ett helt nytt konto, en ny arbetsyta och en ny integration utan manuella förbättringar. Om skyddet förutsätter att varje anställd hittar fem dolda inställningar finns en tydlig felkälla. Beskriv vilka inställningar användaren får ändra och vilka begränsningar som måste upprätthållas centralt eftersom de följer av behandlingens ändamål eller risker.
Planera lagring och gallring redan vid insamlingen
Ett lagringsbeslut behöver både en motivering och en teknisk eller organisatorisk händelse som går att följa. Det kan vara att ett ärende avslutas, en ansökan förfaller eller en viss rättslig skyldighet upphör. Undvik att börja räkna först när någon råkar städa en mapp. Den praktiska planen ska omfatta huvudsakliga register, bilagor, exporter och andra kopior som verksamheten faktiskt använder.
Automatisk gallring kan vara lämplig, men alla uppgifter ska inte raderas enligt samma tidsregel. En organisation kan ha lagstadgade bevarandekrav eller behöva hantera en konkret rättslig tvist. För offentlig verksamhet måste även tillämpliga regler om allmänna handlingar och arkiv beaktas. Dataskydd som standard betyder därför inte att man alltid väljer den kortaste tänkbara tiden. Det betyder att behandlingen begränsas till det som behövs och har rättsligt stöd.
Knyt lagringsminimering och gallring till ett kontrollerbart arbetssätt. Kontrollera vad som händer med säkerhetskopior och återläsning, så att raderade uppgifter inte börjar användas igen av misstag. Om uppgifter behöver ligga kvar i avgränsade säkerhetskopior under en begränsad cykel måste detta bedömas och skyddas. En allmän hänvisning till backup är inte en motivering för obegränsad fortsatt användning.
Säkerhet ska skydda den behandling som verkligen behövs
Kryptering kan minska risken för obehörig åtkomst, men den gör inte en onödig insamling nödvändig. Bedöm vilka hot som är relevanta, var nycklarna finns och vilka personer eller tjänster som kan dekryptera informationen. Skydd för överföring, lagring och säkerhetskopior kan behöva utformas olika. Guiden om kryptering av personuppgifter hjälper till att skilja dessa användningar åt.
Pseudonymisering kan göra det möjligt att utföra viss analys utan direkt identifiering. Då måste kopplingen tillbaka till individer skyddas och åtkomsten begränsas. Pseudonymiserade uppgifter är fortfarande personuppgifter när de kan hänföras till en individ med kompletterande information. Ett internt löpnummer är därför inte ett generellt sätt att ta behandlingen utanför GDPR. Fråga om analysen i stället kan göras med tillräckligt aggregerade uppgifter.
Tekniska skydd behöver förvaltas efter införandet. Härdning av Windows- och Linuxmiljöer, uppdateringar och säker konfiguration kan stödja arbetet, men måste kombineras med ansvar för behörigheter och ändringar. Loggning behöver också ett eget ändamål, en avvägd detaljnivå och regler för åtkomst och lagring. Att samla in varje användares hela arbetsmönster under rubriken säkerhet är inte automatiskt proportionerligt.
Bygg in möjligheten att utöva rättigheter
En person ska inte bli beroende av att en enda utvecklare kan leta fram uppgifter i en databas. Kartlägg vilka system och mottagare som berörs och hur en begäran om tillgång, rättelse eller annan rättighet når rätt funktion. Systemens sök- och exportmöjligheter ska stödja ett korrekt svar utan att samtidigt lämna ut andra personers uppgifter. Därför behöver även granskning och säker leverans ingå i arbetsflödet.
Utforma informationen där den behövs. Ett formulär med ett ovanligt obligatoriskt fält bör förklara varför uppgiften efterfrågas innan personen skickar in den. En begriplig förklaring kan förebygga missförstånd, men den ersätter inte övrig information som GDPR kräver. Pröva text och funktion tillsammans: kan användaren förstå vem som behandlar uppgifterna, för vilka ändamål och vart en fråga ska skickas?
Rättelse och radering kan behöva följas genom flera system. Ett centralt register kan vara korrekt samtidigt som en gammal export fortsätter användas i ett lokalt arbetsflöde. Dokumentera sådana beroenden och hur uppdateringar når berörda funktioner. Bygg också in hantering av begränsningar och undantag. En knapp som alltid raderar allt är inte en bra lösning om vissa uppgifter måste bevaras enligt tillämplig lag.
Ställ verifierbara krav när ni köper ett system
Be leverantören visa hur den erbjudna versionen hanterar era viktigaste situationer. Ett konkret prov kan vara att skapa ett nytt konto, begränsa det till ett arbetsområde, göra ett kontrollerat exportuttag och avsluta kontot. Beskriv i förväg vilket resultat ni behöver och spara utfallet. En demonstration med säljarens särskilda administratörskonto säger lite om den miljö som vanliga användare faktiskt får.
När leverantören är personuppgiftsbiträde ska relationen regleras genom ett skriftligt avtal eller annan bindande unionsrättslig eller nationell rättsakt enligt artikel 28. Ett personuppgiftsbiträdesavtal behöver stämma med faktiska instruktioner, underbiträden och tekniska åtgärder. Avtalet kan kräva stöd för rättigheter och säkerhetsarbete, men kan inte skapa funktioner som systemet saknar. Kontrollera därför både texten och möjligheten att genomföra den.
Vid jämförelse av programvara för dataskyddsarbetet bör ni skilja verifierade funktioner från allmänna marknadsföringspåståenden. Fråga vilka inställningar som ingår, vilka som kräver tillägg och hur ändringar meddelas. En lagringsplats inom EES kan vara relevant för överföringsbedömningen, men är inte ett bevis på att artikel 25 är uppfylld. Utred även faktisk fjärråtkomst och andra mottagare när behandlingen kräver det.
Använd konsekvensbedömningen när risknivån kräver det
Om behandlingen sannolikt leder till hög risk ska en konsekvensbedömning göras innan den påbörjas enligt artikel 35. Bedömningen är mer omfattande än ett allmänt godkännande av projektet och kan leda till att utformningen ändras. Använd vägledningen om konsekvensbedömning för att pröva tillämpliga kriterier och IMY:s förteckning. Det är varken alla nya system eller endast stora organisationer som omfattas.
Ett hypotetiskt bokningssystem som börjar registrera stödbehov hos många sårbara personer kan innebära andra risker än den ursprungliga enkla kalendern. Att lägga till en fritextruta kan förändra behandlingen mer än projektgruppen först inser. Involvera verksamhetskunskap och dataskyddskompetens innan ändringen införs. Om höga risker kvarstår trots planerade åtgärder måste kravet på förhandssamråd enligt artikel 36 bedömas.
Även när en fullständig konsekvensbedömning inte krävs behöver beslut om utformningen kunna förklaras. En kortare dokumenterad riskbedömning kan vara ett användbart arbetssätt, utan att den blir en egen obligatorisk blankett i GDPR. Ange vilka omständigheter som ligger bakom slutsatsen och vad som skulle ändra den. Då blir det lättare att upptäcka när en senare funktion faktiskt kräver en ny bedömning.
Fördela ansvar och kontrollera resultatet efter lansering
Verksamhetsägaren behöver godkänna ändamål och användning, tekniskt ansvariga behöver omsätta kraven och inköpsfunktionen behöver säkra leverantörernas åtaganden. Dataskyddsombudet, när ett sådant finns, ger råd och övervakar inom sin roll. Ombudet ska inte göras ensamt ansvarigt för organisationens behandling. Skriv ned vem som beslutar om avvikelser och vem som ser till att besluten faktiskt genomförs.
Koppla dokumentationen till registerförteckningen så att projektets beskrivning går att jämföra med den löpande verksamheten. Registrera vilken version av systemet och vilka inställningar beslutet avsåg. Spara relevanta provresultat, motiveringar och åtgärder som återstår. Ansvarsskyldighet och bevis handlar här om att kunna visa faktisk efterlevnad, inte om att samla största möjliga dokumentmängd.
Efter en uppdatering kan standardinställningar eller integrationer förändras. Bestäm därför vilka ändringar som utlöser en ny kontroll och hur avvikelser fångas upp. En lämplig uppföljning kan undersöka nya kontons åtkomst, misslyckad gallring och oavsiktligt publika länkar. Anpassa kontrollernas frekvens till förändringstakt och risk. GDPR anger inte ett universellt intervall som passar varje system och varje behandling.
Genomför ett avgränsat mottagningsprov
Före driftsättning kan verksamheten genomföra ett sammanhängande prov med påhittade uppgifter. Låt en person registrera ett ärende, en annan handlägga det och en tredje försöka se information utanför sin roll. Kontrollera sedan vad en export innehåller och vad som händer när ärendet avslutas. Sådana praktiska prov är ett rekommenderat sätt att verifiera kraven; GDPR föreskriver inte just detta provformat. Använd inte verkliga känsliga uppgifter om provets syfte kan uppnås utan dem.
Anta att provet visar att en standardexport innehåller interna anteckningar som mottagaren inte behöver. Då bör frågan återföras till den som ansvarar för ändamålet och systeminställningen. Det räcker inte att skriva i manualen att användarna helst ska radera kolumnen efteråt. Undersök om exporten kan begränsas vid källan, om ett särskilt behörighetssteg behövs eller om arbetsflödet ska ändras. Dokumentera lösningen och genomför provet igen innan funktionen tas i bruk.
Om ett krav inte kan uppfyllas direkt ska avvikelsen beskriva berörda uppgifter, möjliga konsekvenser och vilka tillfälliga skydd som faktiskt finns. Ange ansvarig och en konkret uppföljning, men behandla inte en accepterad projektavvikelse som ett undantag från lagen. Om behandlingen inte kan genomföras lagenligt måste omfattningen ändras eller starten skjutas upp. Den bedömningen ska vara tydlig för den som beslutar om införandet, även när tidsplanen eller ett redan ingånget avtal skapar praktisk press.
Vanliga frågor om artikel 25
Måste alla inställningar alltid vara så restriktiva som möjligt?
De ska begränsa behandlingen till vad som är nödvändigt för varje särskilt ändamål. En inställning som omöjliggör en laglig och nödvändig arbetsuppgift är inte automatiskt rätt lösning. Utgångspunkten är ett motiverat behov, lämpliga skydd och rättsligt stöd. Valfri extra behandling får inte smygas in som standard bara för att den är enkel att aktivera.
Räcker ett godkänt inköp eller ett biträdesavtal?
Nej. Organisationen behöver också konfigurera, använda och följa upp lösningen så att kraven fungerar i den egna behandlingen. Avtal och leverantörsinformation är delar av underlaget. De ersätter inte kontroll av vilka uppgifter som samlas in, vem som får åtkomst och vad som händer när ändamålet eller lagringstiden upphör.
Behöver ett litet företag arbeta med inbyggt dataskydd?
Ja, artikel 25 gäller personuppgiftsansvariga oavsett storlek. Arbetets omfattning kan däremot anpassas efter behandlingens förutsättningar och risker. Ett litet företag kan ofta börja med tydliga ändamål, färre obligatoriska fält, begränsade behörigheter och en genomförbar gallringsrutin. Det viktiga är att skyddet fungerar och kan förklaras, inte att dokumentationen efterliknar en stor koncerns.