När en personuppgiftsincident inträffar är den sämsta tidpunkten att räkna ut din anmälningsprocess mitt under själva incidenten. Klockan tickar redan, folk är stressade och besluten du fattar under det första dygnet avgör om du håller en laglig frist eller får förklara för tillsynsmyndigheten varför du missade den.

GDPR ger dig 72 timmar att anmäla en kvalificerande incident till tillsynsmyndigheten. Det låter som gott om tid ända tills du lever det. Den här guiden går igenom vad som faktiskt räknas som en personuppgiftsincident, när du måste anmäla, vad 72-timmarsklockan verkligen betyder och hur du bygger en incidentplan så att processen sköter sig själv när du behöver den som mest.

Vad räknas som en personuppgiftsincident

En personuppgiftsincident är inte bara att en angripare stjäl din kunddatabas. Artikel 4 i GDPR definierar det brett: en säkerhetsincident som leder till oavsiktlig eller olaglig förstöring, förlust, ändring eller obehörigt röjande av eller obehörig åtkomst till personuppgifter. Det täcker tre typer av fel:

• Konfidentialitetsbrott. Någon ser personuppgifter som inte borde, som ett mejl skickat till fel mottagare eller en felkonfigurerad behörighet.
• Integritetsbrott. Personuppgifter ändras utan behörighet, så att du inte längre kan lita på att de stämmer.
• Tillgänglighetsbrott. Du förlorar åtkomst till personuppgifter, oavsett om det beror på utpressningsprogram, oavsiktlig radering eller en misslyckad säkerhetskopia.

Den sista överraskar team. En attack med utpressningsprogram som låser dina egna filer, utan att någon data lämnar huset, är fortfarande en personuppgiftsincident eftersom du har förlorat tillgängligheten. Detsamma gäller en laptop som glöms på tåget om den innehåller okrypterade personuppgifter.

Poängen är att "incident" är bredare än "hackerattack". Bygger du din process bara kring de dramatiska scenarierna missar du de vardagliga, och de vardagliga är betydligt vanligare.

När du måste anmäla

Två separata skyldigheter träder in, och de har olika trösklar.

Anmälan till tillsynsmyndigheten (artikel 33)

Du måste anmäla till din tillsynsmyndighet, som i Sverige är IMY, om det inte är osannolikt att incidenten medför en risk för fysiska personers rättigheter och friheter. Läs det noga: utgångspunkten är att du anmäler. Du hoppar bara över det när du kan motivera att det inte finns någon verklig risk, och du dokumenterar resonemanget oavsett.

Ett röjande av en handfull företagsmejladresser når kanske inte upp till tröskeln. Ett röjande av hälsouppgifter, ekonomiska detaljer eller inloggningsuppgifter gör det nästan säkert.

Information till de registrerade (artikel 34)

Det finns en högre tröskel för att informera personerna själva. Du måste informera de registrerade när incidenten sannolikt leder till en hög risk för deras rättigheter och friheter. Det betyder att risken är så allvarlig att människor kan behöva agera, som att byta lösenord eller hålla utkik efter bedrägeri.

Du kan slippa informera de registrerade om du redan gjort uppgifterna oläsbara, till exempel med stark kryptering, eller om du vidtar åtgärder efteråt som tar bort den höga risken. Men om tillsynsmyndigheten gör en annan bedömning kan den ändå kräva att du informerar.

Två skyldigheter, två trösklar: anmäl till myndigheten vid en risk, informera de registrerade vid en hög risk.

Vad 72-timmarsklockan faktiskt betyder

De 72 timmarna löper från det ögonblick du får kännedom om incidenten, inte från när den inträffade och inte från när du blir klar med utredningen. Kännedom innebär att du har en rimlig grad av säkerhet på att en säkerhetsincident har påverkat personuppgifter.

Två saker följer av det.

För det första kan "kännedom" komma vid en obekväm tidpunkt: en fredagskväll, mitt i en semester. Klockan pausar inte för din kalender. Det är just därför processen måste vara redo före incidenten, inte sättas ihop under den.

För det andra behöver du inte alla svar innan du anmäler. GDPR tillåter uttryckligen fasad anmälan. Du kan skicka en första anmälan med det du vet och sedan komplettera med detaljer allteftersom utredningen fortsätter. Tillsynsmyndigheter föredrar en snabb och ofullständig anmälan framför en sen och polerad. Anmäler du efter 72 timmar måste du förklara dröjsmålet.

Vad anmälan måste innehålla

Artikel 33 anger miniminivån. Även en första, fasad anmälan bör täcka så mycket av det här som möjligt:

• Incidentens art, inklusive kategorierna och det ungefärliga antalet registrerade och poster som berörs.
• Namn och kontaktuppgifter till ditt dataskyddsombud eller annan kontaktpunkt.
• De sannolika konsekvenserna av incidenten.
• De åtgärder som vidtagits eller föreslås för att hantera incidenten och begränsa dess effekter.

Lägg märke till hur mycket av det här du kan förbereda i förväg. Din kontaktpunkt ändras inte per incident. Dina vanliga åtgärder är kända. Det du fyller i medan det pågår är den specifika omfattningen och effekten. Ju mer av strukturen som finns på plats i förväg, desto mindre uppfinner du under press.

Bygg incidentplanen innan du behöver den

En incidentplan, ofta kallad runbook, förvandlar panik till procedur. Som minst namnger den vem som gör vad:

1. Upptäckt och triage. Någon bekräftar om en personuppgiftsincident faktiskt inträffat och noterar tidpunkten för kännedom. Det startar klockan.
2. Bedömning. En namngiven ägare bedömer risken för de registrerade, vilket avgör båda skyldigheterna: anmäla till myndigheten (risk) och informera de registrerade (hög risk).
3. Anmälan. En namngiven ägare skriver och skickar anmälan enligt artikel 33 och förbereder kommunikation enligt artikel 34 om tröskeln nås.
4. Dokumentation. Varje incident dokumenteras oavsett om du anmälde eller inte, inklusive fakta, effekter och resonemanget bakom beslutet.

Det sista steget är lätt att hoppa över och viktigt att behålla. Artikel 33 kräver att du dokumenterar alla incidenter, anmälningspliktiga eller inte, så att tillsynsmyndigheten kan granska din bedömning. "Vi valde att inte anmäla, och här är exakt varför" är ett giltigt svar bara om du skrev ner det då.

Tilldela riktiga namn, inte roller som ingen kommer ihåg klockan nio på kvällen. Bestäm ersättarna också, för incidenter väntar inte på att folk ska sitta vid sina skrivbord.

Så håller OptiTech tidslinjen ärlig

Det svåraste med en incident är inte den tekniska lösningen. Det är att i efterhand bevisa att du hanterade fristen korrekt. Det är ett dokumentationsproblem, och det är där ett program slår en improviserad insats.

OptiTech spårar personuppgiftsincidenter med 72-timmarsklockan synlig, så att tidslinjen och besluten dokumenteras medan de sker i stället för att rekonstrueras i efterhand. I OptiTech Console loggar du tidpunkten för kännedom, och fristen finns rakt framför dig. Varje incident bär sin ägare, sin riskbedömning, anmälningsbeslutet och resonemanget, så att inget hänger på någons minne.

Eftersom incidenten lever i samma program som ditt register över behandlingar kan du besvara frågan om omfattning snabbare. När du redan vet vilka behandlingar som rör vilka personuppgifter slutar arbetet med att räkna ut vem som berörs vara ett arkeologiprojekt. Och varje incident, anmäld eller inte, stannar på register med sin motivering, vilket är exakt vad artikel 33 ber dig behålla.

GDPR, NIS2 och DORA är inte samma anmälan

Om du omfattas av mer än ett regelverk, anta inte att en anmälan täcker allihop. De har olika trösklar, frister och mottagare.

• GDPR handlar om personuppgifter. Du anmäler till dataskyddsmyndigheten inom 72 timmar från kännedom.
• NIS2 handlar om betydande incidenter som påverkar väsentliga eller viktiga tjänster. Det går på ett snabbare spår: en tidig varning inom 24 timmar, följd av en fylligare anmälan, oftast till en nationell CSIRT eller behörig myndighet.
• DORA täcker allvarliga IKT-relaterade incidenter hos finansiella enheter, med egna klassificeringströsklar och en egen rapporteringstidslinje till relevant finansiell tillsynsmyndighet.

En enda säkerhetsincident kan utlösa två eller tre av de här samtidigt, var och en med sin egen klocka och sin egen mottagare. Att kartlägga vilka regelverk som gäller dig, och för vilka system, är arbete du gör före en incident, inte under. Att spåra varje skyldighet som en egen kontroll hindrar dig från att hålla en frist medan du tyst missar en annan.

Kom igång

Du behöver ingen kris för att bygga det här. En realistisk första omgång:

1. Skriv incidentplanen med namngivna ägare och deras ersättare för upptäckt, bedömning, anmälan och dokumentation.
2. Förbered anmälningsmallen med allt artikel 33 låter dig fylla i i förväg.
3. Bestäm dina risktrösklar så att beslutet att anmäla eller inte är väglett, inte improviserat.
4. Sätt upp incidentspårning med 72-timmarsklockan synlig, så att tidslinjen dokumenterar sig själv.

En incident är stressande hur redo du än är. Men de företag som hanterar den väl är inte de som reagerar snabbast. Det är de som i förväg bestämde exakt vad de skulle göra.

Vill du ha 72-timmarsklockan på din sida innan du behöver den? Boka en demo och se hur OptiTech spårar personuppgiftsincidenter med tidslinjen och besluten dokumenterade medan de sker.