Artikel 32 kräver att personuppgiftsansvariga och biträden inför lämpliga, riskbaserade tekniska och organisatoriska åtgärder som skyddar konfidentialitet, integritet och tillgänglighet i personuppgiftsbehandlingen. Konkret innebär det kryptering, åtkomstkontroller, rutiner för återställning och regelbunden testning. Vilken nivå som är lämplig avgörs av teknikens utveckling, kostnad, behandlingens art och omfattning samt den faktiska risken för de registrerade.
Kort sagt:
- Åtgärderna ska följa en dokumenterad riskbedömning där teknik, kostnad, behandlingens omfattning och ändamål samt möjliga konsekvenser för registrerade vägs samman.
- Kryptera känsliga uppgifter och begränsa åtkomsten med rollbaserade behörigheter och flerfaktorsinloggning, men testa även återställning av nycklar och säkerhetskopior minst årligen.
- Storskalig behandling av känsliga uppgifter kräver ofta en konsekvensbedömning trots starka skydd; kvarstår hög risk ska tillsynsmyndigheten rådfrågas innan behandlingen inleds.
- Efter en personuppgiftsincident ska tillsynsmyndigheten normalt underrättas inom 72 timmar, och dokumenterade tester hjälper organisationen att visa att skydden fungerade.
Innehållsförteckning
- Vad artikel 32 säger och hur man tolkar kravet “lämplig säkerhetsnivå”
- Tekniska åtgärder: konkreta exempel och praktiska anvisningar
- Organisatoriska åtgärder: styrning, processer och kultur
- Bedöma vad som är “lämpligt”: en riskbaserad metodik
- Koppling till DPIA, incidentrapportering och tillsynspraxis
- Praktisk implementeringschecklista för artikel 32 (prioriterade åtgärder)
- Författarperspektiv från Trustview
- Hur Trustview kan hjälpa med artikel 32 i praktiken
- Vanliga frågor
- Källor
Vad artikel 32 säger och hur man tolkar kravet “lämplig säkerhetsnivå”
Lagtexten i GDPR ger inte en lista med obligatoriska åtgärder. Den beskriver istället ett resultat som ska uppnås: en säkerhetsnivå som är lämplig i förhållande till risken. Kärnformuleringen handlar om att säkerställa konfidentialitet (bara behöriga får tillgång), integritet (uppgifterna är korrekta och oförändrade), tillgänglighet (uppgifterna går att komma åt när de behövs) och motståndskraft i de system som behandlar uppgifterna. Dit hör även förmågan att återställa tillgänglighet och åtkomst till uppgifter i rimlig tid efter en incident.
Det som gör paragrafen svår att tillämpa i praktiken är just ordet “lämplig”. IMY:s vägledning om dataskyddsförordningen pekar ut fyra faktorer som styr bedömningen:
- Den tekniska utvecklingen: vilka lösningar som är rimliga och tillgängliga vid den tidpunkt behandlingen sker.
- Genomförandekostnaden: åtgärder ska stå i proportion till vad de kostar att införa, utan att kostnad blir en ursäkt för att avstå helt.
- Behandlingens art, omfattning, sammanhang och ändamål: en liten förening som hanterar medlemslistor har andra krav än en vårdgivare som behandlar känsliga hälsouppgifter i stor skala.
- Riskerna för fysiska personers rättigheter och friheter: ju allvarligare konsekvenser en läcka kan få för den registrerade, desto högre krav på skydd.
I praktiken betyder detta att två organisationer kan uppfylla artikel 32 med helt olika åtgärdspaket, så länge båda har gjort en seriös riskbedömning och kan visa att valet av åtgärder är motiverat. EDPB:s vägledning för mindre organisationer understryker samma poäng: pseudonymisering och kryptering rekommenderas, men ska väljas utifrån en faktisk riskanalys, inte som checklistepunkter man kryssar i av slentrian. En organisation som behandlar löneuppgifter för tio anställda behöver inte samma kontrollapparat som en som driver en nationell patientjournal, men båda måste kunna visa att de har resonerat sig fram till sin lämpliga nivå. Det är den riskbaserade ansatsen som gör artikel 32 svårare att “klara av” en gång för alla, men också mer meningsfull än en statisk checklista. Åtgärderna ska omprövas när behandlingen, hotbilden eller tekniken förändras.
Tekniska åtgärder: konkreta exempel och praktiska anvisningar
IMY:s vägledning om säkerhetsåtgärder listar flera tekniska åtgärder som återkommer i praktiken, även om listan inte är uttömmande och alltid ska anpassas efter den egna riskbilden.
- Kryptering: skyddar uppgifter i vila och under överföring, men kräver fungerande nyckelhantering. IMY:s vägledning om kryptering betonar att nycklar bör lagras separat från de krypterade uppgifterna och att rutiner för återställning av nycklar måste testas, annars riskerar en krypterad backup att bli obrukbar den dag den faktiskt behövs.
- Pseudonymisering: ersätter direkta identifierare med kodade värden så att uppgifterna inte går att knyta till en person utan ytterligare information. Lämplig när analys eller delning av data behövs, men full identifiering inte krävs för ändamålet.
- Autentisering och åtkomstkontroll: rollbaserad behörighet och multifaktorautentisering (MFA) begränsar vem som kan nå känsliga uppgifter och minskar skadan vid stulna inloggningsuppgifter.
- Loggning och nätverkssegmentering: spårbarhet i vem som gjort vad, och avgränsning av nätverk så att en komprometterad del inte automatiskt exponerar hela miljön.
- Patchning och skydd mot skadlig kod: regelbunden uppdatering av system och program, i kombination med antivirus och liknande skydd, minskar risken för intrång via kända sårbarheter.
- Backup och återställning: säkerhetskopior måste gå att återställa inom rimlig tid, vilket i praktiken innebär regelbundna återställningstester, inte bara att backuper tas.
Logghantering förtjänar ett särskilt omnämnande eftersom den ofta blir eftersatt. En tydlig definition av loggning ur ett juridiskt perspektiv visar hur loggar fungerar som bevis både vid interna utredningar och vid tillsynsärenden, vilket gör spårbarhet till en central del av artikel 32-arbetet snarare än en teknisk detalj.
Proffstips: Testa återställning av krypteringsnycklar minst en gång per år, inte bara backuper av själva datat, annars riskerar ni att upptäcka ett haveri i nyckelhanteringen först när det är för sent.
Gemensamt för alla tekniska åtgärder är att de måste gå att verifiera. En kontroll som bara finns på pappret, utan testning eller loggning av att den faktiskt fungerar, uppfyller inte kravet på en lämplig säkerhetsnivå.
Organisatoriska åtgärder: styrning, processer och kultur
Tekniska lösningar räcker inte ensamma. IMY:s vägledning pekar lika tydligt på organisatoriska åtgärder som styrdokument, processer, riskhantering och utbildning, och det är ofta här bristerna sitter när tillsynsärenden granskas.
- Styrdokument och roller: en informationssäkerhetspolicy som pekar ut vem som ansvarar för vad, inklusive hur leverantörer och underbiträden ska granskas innan de får tillgång till personuppgifter.
- Riskhantering som löpande process: risker ska identifieras, värderas och åtgärdas kontinuerligt, inte bara vid ett årligt tillfälle, och kopplas till konkreta ansvariga och deadlines.
- Kontinuitetsplanering: planer för hur verksamheten fortsätter om ett system slås ut, inklusive vem som aktiverar reservrutiner och hur länge en avbrottstid är acceptabel.
- Incidentberedskap: en dokumenterad process för att upptäcka, utreda och rapportera personuppgiftsincidenter, testad genom övningar snarare än bara nedskriven.
- Utbildning och uppföljning: återkommande utbildning av personal i säkerhetsrutiner, kompletterad med uppföljning som visar att rutinerna faktiskt följs i vardagen.
Leverantörsstyrning hör hemma i samma kategori. Ett biträdesavtal löser inte automatiskt säkerhetsfrågan, organisationen som är personuppgiftsansvarig behöver också bedöma om leverantören rent faktiskt har de tekniska och organisatoriska åtgärder som krävs. Den processen beskrivs mer utförligt i vår praktiska guide för dataskyddsarbete, som går igenom hur styrdokument och ansvarsfördelning hänger ihop i det löpande arbetet.
Utbildning är lätt att nedprioritera men avgör ofta om de tekniska åtgärderna håller i praktiken. En personal som inte vet hur lösenord ska hanteras eller vart en misstänkt incident ska rapporteras gör även den bästa tekniska lösningen verkningslös. Organisatoriska åtgärder är därför inte ett komplement till de tekniska, de är förutsättningen för att de tekniska åtgärderna fungerar över tid.
Bedöma vad som är “lämpligt”: en riskbaserad metodik
Att gå från lagtext till konkreta åtgärder kräver en metod, inte en gissning. En praktisk ordning som fungerar för de flesta organisationer:
- Identifiera: kartlägg vilka personuppgifter som behandlas, var de finns och vilka system som är inblandade.
- Uppskatta: bedöm sannolikheten för att något går fel och vilken konsekvens det får för de registrerade, från mindre obehag till allvarlig skada.
- Prioritera: rangordna riskerna så att resurser läggs där konsekvenserna är störst, inte bara där åtgärden är enklast att genomföra.
- Åtgärda: välj tekniska och organisatoriska åtgärder som står i proportion till risken, och dokumentera varför just den nivån valdes.
Kostnad och teknisk utveckling vägs in löpande i det här arbetet. En åtgärd som var orimligt dyr för några år sedan kan i dag vara standard, vilket betyder att en bedömning som gjordes vid ett tillfälle inte automatiskt håller för alltid. Metodiken för riskvärdering beskrivs mer i detalj i vår guide till GDPR-riskbedömning, som går igenom hur sannolikhet och konsekvens kan viktas mot varandra.
När riskanalysen visar att en behandling sannolikt medför hög risk för registrerades rättigheter krävs en konsekvensbedömning, DPIA, enligt artikel 35. Säkerhetsåtgärderna som planeras eller redan finns på plats ska redovisas i DPIA:n som en del av underlaget för om risken anses hanterad. Om kvarstående risk fortfarande bedöms som hög efter åtgärder ska tillsynsmyndigheten konsulteras innan behandlingen inleds. Vår guide för hur man genomför en konsekvensbedömning steg för steg går igenom hur den dokumentationen byggs upp i praktiken.
Koppling till DPIA, incidentrapportering och tillsynspraxis
Artikel 32 existerar inte isolerat. Den hänger samman med artikel 35 om konsekvensbedömningar och med artikel 33 och 34 om anmälningsskyldigheter vid personuppgiftsincidenter, och tillsynspraxis visar tydligt var gränserna i praktiken ligger.
Starka säkerhetsåtgärder kan minska den risk som annars skulle krävt en DPIA, men de tar inte bort kravet automatiskt. Om behandlingen i sig uppfyller kriterierna för hög risk, exempelvis storskalig behandling av känsliga uppgifter, krävs en konsekvensbedömning oavsett hur väl skyddad miljön är. Åtgärderna påverkar istället resultatet av bedömningen, det kvarstående risknivåvärdet, vilket i sin tur avgör om tillsynsmyndigheten behöver konsulteras.
Vid en faktisk personuppgiftsincident blir kopplingen till artikel 33 konkret. EDPB:s vägledning om anmälan av personuppgiftsincidenter slår fast att en anmälan till tillsynsmyndigheten normalt ska göras inom 72 timmar efter att incidenten upptäckts, och att den dokumentation som finns om de säkerhetsåtgärder som fanns på plats blir en central del av utredningen. Svaga åtgärder förvärrar inte bara själva incidenten, de försvårar också organisationens möjlighet att visa att man agerat med rimlig omsorg.
EDPB:s digest över tillsynsärenden kopplade till säkerhet och personuppgiftsincidenter ger konkreta exempel på vad som i praktiken lett till åtgärdskrav:
- Svag lösenordspraxis, till exempel korta eller återanvända lösenord utan krav på komplexitet.
- Osäkra rutiner för att skicka lösenord, exempelvis i klartext via e-post istället för krypterade kanaler.
- Bristande verifikation av att kryptering och återställningsrutiner faktiskt fungerade när de testades i efterhand.
Ett genomgående drag i tillsynspraxis är att myndigheter inte bara frågar om en åtgärd finns, utan om organisationen kan visa att den testats och fungerar. En policy om kryptering som aldrig kontrollerats mot en verklig återställning väger lätt i en utredning.
Praktisk implementeringschecklista för artikel 32 (prioriterade åtgärder)
En strukturerad genomgång gör det lättare att gå från lagtext till faktiskt genomförande, i rimlig prioriteringsordning.
- Inventera personuppgifter: kartlägg vilka uppgifter som behandlas, i vilka system och av vem, som grund för all vidare prioritering.
- Klassificera data efter känslighet: skilj på vanliga personuppgifter, känsliga kategorier och uppgifter med särskilt hög konsekvens vid läckage.
- Skydda de mest känsliga uppgifterna först: kryptering och striktare åtkomstkontroll där konsekvenserna av en incident är störst.
- Inför stark autentisering: rollbaserad åtkomst och MFA för system som hanterar personuppgifter, särskilt där fjärråtkomst förekommer.
- Säkerställ fungerande backup: regelbundna säkerhetskopior kombinerat med dokumenterade återställningstester, inte bara lagring.
- Testa regelbundet: penetrationstester, granskning av loggar och kontroll av att behörigheter fortfarande stämmer med vem som faktiskt behöver tillgång.
- Dokumentera allt: varje vald åtgärd ska gå att koppla till en riskbedömning, ett ansvar och ett datum för senaste uppföljning.
Proffstips: Sätt en fast kalenderpunkt för återställningstester och logggranskning, exempelvis kvartalsvis, så att verifieringen inte blir något som bara sker efter en incident.
Dokumentationen är själva beviset gentemot tillsynsmyndigheter och gentemot organisationens egen ledning. Utan spårbarhet mellan risk, åtgärd och ansvarig person blir det svårt att visa att artikel 32 faktiskt efterlevs, oavsett hur bra de tekniska lösningarna i grunden är.
Författarperspektiv från Trustview
I kundprojekt är det sällan den tekniska lösningen som fallerar först, det är dokumentationen och ägarskapet. Organisationer har ofta kryptering och backup på plats, men ingen kan peka ut vem som senast testade återställningen eller varför just den åtgärden valdes för den aktuella risknivån.
Det som faktiskt fungerar är att koppla ihop juridiken, processen och verktyget i samma arbetsflöde: riskbedömningen pekar ut vad som behöver skyddas, åtgärden dokumenteras direkt där risken finns beskriven, och uppföljningen sker på ett datum som redan är inplanerat. Då blir artikel 32 ett löpande arbete istället för ett projekt som görs om vart tredje år.
— Jesper
Hur Trustview kan hjälpa med artikel 32 i praktiken
Vi har byggt Trustview för att samla just den kopplingen mellan juridik, process och teknik på ett ställe. I plattformen kan du hålla registerförteckningen uppdaterad, bygga DPIA:er där säkerhetsåtgärder dokumenteras direkt mot varje behandling, samt logga incidenter med tidsstämplar för att underlätta hantering av 72-timmarsfristen.
Åtgärdsspårningen gör att varje vald kontroll kopplas till en ansvarig person och ett uppföljningsdatum, så att testningen faktiskt sker och går att visa upp vid en tillsynsgranskning. Behöver du juridisk tolkning av vad som är lämpligt för er specifika verksamhet erbjuder vi även juridisk rådgivning som komplement till plattformen. Se prisöversikten för att hitta rätt nivå för er organisation.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Vanliga frågor
Vad innebär artikel 32 i GDPR?
Artikel 32 kräver att personuppgiftsansvariga och biträden vidtar lämpliga tekniska och organisatoriska åtgärder för att skydda konfidentialitet, integritet och tillgänglighet i personuppgiftsbehandlingen. Vilken nivå som krävs avgörs av fyra faktorer: teknisk utveckling, kostnad, behandlingens art och risk.
Får man maila personnummer enligt GDPR?
Det finns inget absolut förbud mot att skicka personnummer via e-post, men det måste ske med en säkerhetsnivå som är lämplig för risken, exempelvis kryptering av meddelandet. Tillsynspraxis visar att osäkra rutiner för att skicka känslig information via e-post har lett till åtgärdskrav från tillsynsmyndigheter.
Vad innebär artikel 33 GDPR?
Artikel 33 reglerar skyldigheten att anmäla en personuppgiftsincident till tillsynsmyndigheten, normalt inom 72 timmar efter upptäckt. Anmälan ska beskriva vad som hänt, vilka uppgifter som berörts och vilka åtgärder som vidtagits, inklusive de säkerhetsåtgärder som redan fanns på plats enligt artikel 32.
Vilka måste ha dataskyddsombud?
Kravet på dataskyddsombud gäller bland annat myndigheter samt organisationer vars kärnverksamhet innebär storskalig övervakning eller storskalig behandling av känsliga personuppgifter. Oavsett om ett dataskyddsombud krävs formellt behöver varje organisation någon som ansvarar för att artikel 32-åtgärder faktiskt genomförs och följs upp.
Källor
- Dataskyddsförordningen i fulltext (IMY)
- EUR-Lex: GDPR (förordning 2016/679)
- Säkra personuppgifter | EDPB (SME-guide, SV)
