GDPR Art. 32: vad ”riskbaserad säkerhet” faktiskt betyder

Artikel 32 är den del av GDPR som oftast diskuteras vid tillsyn. Den kräver att personuppgiftsansvariga vidtar ”lämpliga tekniska och organisatoriska åtgärder” i förhållande till risken för behandlingen. Det låter enkelt, och är samtidigt det svåraste att bevisa.

Här är vad det faktiskt betyder.

Vad Art. 32 säger

Den personuppgiftsansvarige och personuppgiftsbiträdet ska vidta lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken, inbegripet, när det är lämpligt, bland annat:

a) pseudonymisering och kryptering b) förmågan att fortlöpande säkerställa konfidentialitet, integritet, tillgänglighet och motståndskraft hos system c) förmågan att snabbt återställa tillgängligheten och tillgången till personuppgifter i händelse av en fysisk eller teknisk incident d) ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten

Nyckeltermerna: lämpliga och i förhållande till risken.

Vad ”lämpligt i förhållande till risken” innebär

Det finns ingen fast lista. GDPR:s logik är att säkerhetsnivån ska stå i proportion till risken, vilket innebär att ni måste:

1. Identifiera risker som hotar rättigheter och friheter hos de registrerade.
2. Bedöma dem (sannolikhet och konsekvens).
3. Välja åtgärder som är proportionella mot risken.
4. Dokumentera hela resonemanget.

Det är exakt vad en riskbedömning är. Art. 32 implicerar att ni har en sådan.

När räcker det inte?

Art. 35, konsekvensbedömning (DPIA), kommer in när behandlingen är högriskabel. Typiska exempel:

• Automatiserat beslutsfattande med rättsverkan (Art. 22).
• Storskalig systematisk övervakning.
• Storskalig behandling av känsliga uppgifter (hälsa, etnicitet, religion).
• Sårbara registrerade (barn, anställda i anställningskontexten, patienter).

Om DPIA krävs, er Art. 32-riskbedömning är en del av DPIA-dokumentationen. Men ni behöver också beskrivning av behandlingen, proportionalitetsbedömning och eventuellt DPO-samråd.

Hur IMY bedömer er

Integritetsskyddsmyndigheten (IMY) bedömer vid tillsyn om ni:

1. Har dokumenterat riskbedömning. Utan det är alla andra diskussioner meningslösa.
2. Har valt proportionella åtgärder. Företag som hanterar känsliga hälsouppgifter kan inte ha svagare skydd än ett bloggföretag.
3. Har testat åtgärderna. Krypteringen som aldrig verifierats. Backupen som aldrig återställts.
4. Granskar processen regelbundet. Engångsbedömning räcker inte.

Det här är samma sak som ISO 27001 begär, fast i GDPR-kontext.

Typiska risker ni bör bedöma

Oavsett bransch finns ett grundläggande set:

• Obehörig åtkomst till personuppgifter. Interna och externa vektorer.
• Spridning. Läckage via fel mottagare, obehörig export, felkonfiguration.
• Ändamålsförskjutning. Data samlad för ett syfte, använt för ett annat.
• Otillräcklig transparens. Ni kan inte svara när någon frågar ”vilken data har ni om mig?”.
• Rätten att bli glömd. Ni kan inte radera när någon begär det.
• Portabilitet. Ni kan inte exportera på begäran (Art. 20).
• Säkerhetsincidenter. Ransomware, intrång, förlorad hårdvara med personuppgifter.

Bedöm varje mot er specifika behandling. I RiskNote gör AI:n en första analys baserad på er bransch och organisation.

Tekniska vs organisatoriska åtgärder

Art. 32 nämner båda. Balans är nyckeln.

Tekniska åtgärder: kryptering (vila och transport), åtkomstkontroll, MFA, loggning, patching, backup, DLP.

Organisatoriska åtgärder: policyer, utbildning, behörighetsrutiner, incidentprocesser, leverantörsavtal, DPO-roll (om tillämpligt), klassificering.

Ni behöver båda. En organisation med världsklassig kryptering men okända behörighetsrutiner har ett Art. 32-problem.

Vad ni bör göra nu

1. Har ni en dokumenterad riskbedömning av all personuppgiftsbehandling? Om nej, börja där.
2. Har ni identifierat vilka behandlingar som är högriskabla? DPIA-krav kan gälla dem.
3. Har ni en årlig granskningsrutin? Art. 32 d kräver regelbunden utvärdering.
4. Har ni testat era åtgärder? Restore-test, penetrationstest, phishing-simulering.

Om ni vill ha struktur i 1 och 3, RiskNote är byggt just för detta. Se vår GDPR-ramverkssida eller starta en gratis provperiod.

Nästa inlägg: DPIA-mall, när räcker en riskbedömning och när behöver ni en fullständig DPIA?