GDPR och IT-säkerhet: tekniska åtgärder och vad du gör vid en personuppgiftsincident

GDPR brukar säljas med sanktionsavgifter på upp till fyra procent av den globala årsomsättningen. De finns, men för de flesta mindre företag är det inte där risken ligger. Risken är att en personuppgiftsincident händer utan att någon känner igen den, och att ingen vet vad som ska göras de första 72 timmarna. Den här sidan handlar om just det, och om de tekniska åtgärder som gör att incidenten blir mindre när den väl kommer. Det bredare sammanhanget finns i guiden om IT-säkerhet för företag.

Vad är en personuppgiftsincident?

En personuppgiftsincident är en säkerhetsincident som leder till att personuppgifter förstörs, går förlorade, ändras, röjs eller blir åtkomliga för någon som inte ska ha dem. Det gäller både olyckor och angrepp.

Definitionen är bredare än de flesta tror. Här är några vanliga exempel:

• Ett mejl med en kundlista eller en lönefil skickas till fel mottagare.
• En bärbar dator utan diskkryptering blir stulen.
• En angripare loggar in i en anställds mejlkorg med ett stulet lösenord.
• Ransomware krypterar ett system med kunduppgifter, även om inget har kopierats ut.
• Data raderas av misstag och det finns ingen säkerhetskopia att återställa från.

De två sista exemplen missas ofta. En incident behöver inte innebära att något har läckt. Om uppgifterna inte går att komma åt när de behövs är det också en personuppgiftsincident.

Vad kräver GDPR av IT-säkerheten?

GDPR kräver lämpliga tekniska och organisatoriska åtgärder för att skydda personuppgifterna, anpassade efter risken. Det står i artikel 32, som nämner fyra saker särskilt: pseudonymisering och kryptering, förmåga att fortlöpande skydda uppgifternas konfidentialitet, riktighet och tillgänglighet, förmåga att snabbt återställa uppgifterna efter en incident, och regelbunden testning av att åtgärderna fungerar.

Ordet "lämpliga" gör att GDPR inte ger dig en färdig lista. Du förväntas själv bedöma vad som rimligt skyddar de uppgifter du har. Så här ser det oftast ut i en vanlig IT-miljö:

Krav i artikel 32	Konkret åtgärd i IT-miljön
Kryptering	Diskkryptering på alla datorer och telefoner, krypterad överföring, krypterade säkerhetskopior
Konfidentialitet	MFA på alla konton, behörigheter efter roll, begränsad extern delning, konton stängs när någon slutar
Riktighet	Loggning av inloggningar och behörighetsändringar, separata administratörskonton
Tillgänglighet och återställning	Säkerhetskopior där minst en kopia är isolerad, dokumenterad återställning
Regelbunden testning	Återställningstest, genomgång av behörigheter, uppföljning av säkerhetsloggar

Många av åtgärderna är desamma som i allt annat säkerhetsarbete, och det är poängen. Du behöver inte en separat GDPR-säkerhet. Grunderna finns i Datasäkerhet i företag.

En åtgärd förtjänar extra uppmärksamhet. Kryptering är det som gör en stulen dator till en borttappad dator. GDPR säger att du inte behöver informera de drabbade om uppgifterna var skyddade så att de är oläsbara för den som kommer åt dem, till exempel genom kryptering. Det är en av få åtgärder som både är gratis, redan inbyggd i Windows och Mac, och direkt minskar vad du måste göra efter en incident.

Vad gör du vid en personuppgiftsincident?

Klockan börjar gå när du har fått kännedom om incidenten, inte när du är klar med utredningen. Följ stegen i ordning och skriv ner vad du gör medan du gör det.

1. Begränsa skadan. Byt lösenord och spärra konton som kan vara kapade, be mottagaren av ett felskickat mejl att radera det, koppla bort en smittad dator från nätverket. Det kommer före allt annat.
2. Starta en incidentlogg. Skriv ner när incidenten upptäcktes, av vem och hur. Klockslaget för när du fick kännedom är det som räknas för 72 timmar.
3. Ta reda på vad som hänt. Vilka uppgifter berörs, ungefär hur många personer, och vilken sorts uppgifter? Känsliga uppgifter som hälsa, personnummer eller ekonomi väger tyngre än namn och e-post.
4. Bedöm risken för de drabbade. Är det osannolikt att incidenten medför risk för personerna behöver du inte anmäla, men du ska dokumentera bedömningen. Finns det en risk ska du anmäla. Är risken hög ska du också informera personerna.
5. Anmäl till IMY inom 72 timmar. Anmälan görs i IMY:s e-tjänst för personuppgiftsincidenter. Beskriv vad som hänt, vilka uppgifter och ungefär hur många personer som berörs, vilka konsekvenser det kan få och vad du har gjort. Har du inte alla uppgifter, anmäl det du vet och komplettera senare. Blir anmälan sen ska du ange varför.
6. Informera de drabbade vid hög risk. Gör det utan onödigt dröjsmål och med enkla ord: vad som hänt, vad det kan innebära för dem, vad du har gjort och vad de själva kan göra, till exempel byta lösenord. Undantag finns, bland annat om uppgifterna var krypterade.
7. Dokumentera och följ upp. Alla incidenter ska dokumenteras, även de du inte anmäler. Skriv ner orsaken, åtgärderna och vad du ändrar så att det inte händer igen.

Tveka inte i steg 4 om du är osäker. En anmälan som visar sig vara onödig kostar en halvtimme. En incident som borde ha anmälts och inte blev det är betydligt svårare att förklara i efterhand.

Omfattas du av cybersäkerhetslagen kan samma incident också behöva rapporteras till NCSC. Det är en separat rapport med egna tidsfrister, se incidentrapportering enligt NIS2 och NIS2 och GDPR för hur de två hänger ihop. Är incidenten ett ransomwareangrepp finns de första åtgärderna på sidan om ransomware.

Vem gör vad när det händer?

Ansvaret för anmälan ligger på verksamheten, men jobbet fördelas på flera personer. Bestäm fördelningen innan du behöver den.

IT, internt eller hos en leverantör. Begränsar skadan, tar fram vad som hänt tekniskt och säkrar loggar. Om IT-driften ligger hos en leverantör är den oftast ett personuppgiftsbiträde, alltså någon som behandlar uppgifter för din räkning. Biträdet ska meddela dig utan onödigt dröjsmål när det upptäcker en incident. Kontrollera att ditt biträdesavtal säger hur snabbt och till vem.

Dataskyddsombudet, om du har ett. Ger råd om riskbedömningen och om anmälan. Dataskyddsombudet ska vara inblandat, men beslutet att anmäla ligger inte hos ombudet.

Ledningen. Fattar beslutet och står för det. Ledningen ska också se till att det finns en rutin och att den har övats. Rutinen hör hemma i företagets IT-säkerhetspolicy.

Ett påhittat men typiskt exempel: en redovisningsbyrå med tolv anställda upptäcker en fredag eftermiddag att en medarbetares mejlkorg har använts för att skicka falska fakturor till kunderna. Mejlkorgen innehåller löneunderlag. IT-leverantören spärrar kontot samma kväll, men ingen vet vem som ska bedöma om det är en personuppgiftsincident. Måndag förmiddag har halva tiden gått. Med en rutin där ett namn står bredvid varje steg hade anmälan kunnat vara klar innan helgen var slut.

Anmälan är inte det svåra

Det svåra med en personuppgiftsincident är sällan själva anmälan. Formuläret går att fylla i på en halvtimme. Det svåra är att känna igen incidenten, veta vem som gör vad och kunna svara på vad som faktiskt skyddade uppgifterna. Ingen pärm svarar på det. Kryptering, MFA, loggar och en testad säkerhetskopia gör det. Se till att de finns på plats innan du behöver dem.

Så hjälper Nod till

Nod går kostnadsfritt igenom vilka tekniska åtgärder din IT-miljö har i dag, jämfört med tabellen ovan, och hjälper dig att ta fram en incidentrutin med namn bredvid varje steg. Driftar Nod din miljö kan vi ta ansvar för kryptering, MFA, loggning och säkerhetskopiering, och vi tar fram det tekniska underlaget om en incident inträffar. Beslutet att anmäla och själva anmälan är fortfarande ditt ansvar. [FYLL I: hur snabbt Nod meddelar kunden vid en incident enligt biträdesavtalet] Läs mer om IT-säkerhet hos Nod.