Att föra en incidentlogg, dokumentera riskbedömning och anmäla till tillsynsmyndigheten inom 72 timmar, om risken inte är osannolik, är GDPR:s kärnkrav vid personuppgiftsincidenter. Kravet gäller oavsett om ni väljer att anmäla eller inte. Vid hög risk för de registrerade måste ni även informera dem direkt, enligt artikel 34. Ett beslut att avstå från anmälan måste dokumenteras precis lika noggrant som ett beslut att anmäla.
Kort sagt:
- Innan 72 timmar måste organisationen dokumentera incidentens tidpunkt, typ, berörda data, riskbedömning och beslut för att följa GDPR:s krav.
- En detaljerad incidentlogg bör innehålla tidsstämplar, orsak, berörda uppgifter, riskanalys, åtgärder samt kopplingar till registerförteckningen för att underlätta efterhandsgranskning.
- Hög risk för de registrerade kräver både anmälan till IMY och direkt information till de drabbade, särskilt vid känsliga uppgifter eller stort antal berörda.
- Utan tydliga roller och ansvar kan organisationer missa 72-timmarsfristen, så en väldefinierad delegationsordning och kontaktlista är avgörande.
- Användning av system som kopplar incidentlogg och registerförteckning underlättar snabb och korrekt incidenthantering samt stärker dokumentationen inför tillsyn.
Innehållsförteckning
- Snabb checklista: vad gör ni inom de första 72 timmarna
- Vad incidentloggen ska innehålla: fält, nivåer och dokumentationskrav
- Hur bedömer ni risken för de registrerade?
- Roller, ansvar och beslutsvägar vid incidenthantering
- Praktiska mallar och dokumentationsrutiner för incidentloggen
- Vanliga fallgropar och snabbvinster i incidentarbetet
- Vad de flesta glömmer i sin incidenthantering
- Kom igång med strukturerad incidentloggning i Trustview
- Källor
Snabb checklista: vad gör ni inom de första 72 timmarna
Klockan börjar ticka i det ögonblick organisationen får kännedom om incidenten, inte när den faktiskt inträffade. Det är en distinktion som avgör om ni håller tidsfristen eller inte.
De första timmarna avgör hur mycket skada ni kan begränsa och hur trovärdig er dokumentation blir senare.
- Isolera och stoppa läckan. Stäng av åtkomst, återkalla nycklar eller ta ner tjänsten om det krävs för att hindra fortsatt spridning.
- Logga tidpunkter direkt. Notera när incidenten upptäcktes, av vem och hur, innan minnet av händelsen börjar suddas ut.
- Kartlägg vilka data som berörts. Identifiera personuppgiftskategorier, ungefärligt antal registrerade och om känsliga uppgifter ingår.
- Gör en preliminär riskbedömning. Bedöm sannolikhet och allvarlighetsgrad för de registrerade, inte för organisationen själv.
- Fatta och dokumentera anmälningsbeslutet. Skriv ner motiveringen oavsett vilket beslut ni landar i.
- Förbered anmälan till Integritetsskyddsmyndigheten (IMY). Ange tydligt vilka uppgifter som fortfarande saknas, och skicka kompletteringar när de blir tillgängliga.
Proffstips: Skicka en preliminär anmälan till IMY även om utredningen inte är klar. En anmälan med ”uppgift saknas, kompletteras senast [datum]” är juridiskt starkare än att vänta och riskera att missa 72-timmarsfristen.
Vad incidentloggen ska innehålla: fält, nivåer och dokumentationskrav
En incidentlogg som håller för granskning behöver täcka fem områden: tid, händelse, risk, beslut och koppling till resten av verksamhetens dataskyddsarbete. EDPB:s riktlinjer 9/2022 beskriver vilka fält en anmälan enligt artikel 33.3 måste innehålla, och samma struktur bör ligga till grund för den interna loggen, oavsett om ni anmäler eller inte.
Fältlistan bör innehålla:
- Tidsstämplar för upptäckt, intern rapportering, riskbedömning och eventuell anmälan till IMY.
- Beskrivning av incidenten, inklusive orsak, teknisk karaktär och vilka system eller register som berörts.
- Kategorier av registrerade och personuppgifter som drabbats, samt en uppskattning av antalet berörda.
- Riskanalys med bedömningsgrunder: sannolikhet för skada, typ av konsekvens och om känsliga uppgifter ingår.
- Beslutsmotivering, särskilt utförlig när beslutet blir att inte anmäla till IMY.
- Åtgärder som vidtagits, både omedelbara och långsiktiga, för att begränsa skada och förhindra upprepning.
- Koppling till registerförteckningen och eventuell konsekvensbedömning som redan finns för den aktuella behandlingen.
Den sista punkten är lätt att glömma men avgörande. En incident som rör ett register ni redan har kartlagt i er registerförteckning blir enklare att bedöma, eftersom ni redan vet vilka behandlingar och rättsliga grunder som berörs.
Hur bedömer ni risken för de registrerade?
Riskbedömningen avgör två separata beslut: om ni ska anmäla till IMY, och om ni dessutom måste informera de registrerade direkt. Det är lätt att blanda ihop dem, men tröskeln för det senare ligger högre.
Hög risk föreligger typiskt när känsliga uppgifter läckt (hälsodata, ekonomisk information, inloggningsuppgifter), när risken för identitetsstöld är påtaglig, eller när ett stort antal registrerade berörs utan att organisationen kan begränsa spridningen. EDPB:s exempelsamling beskriver konkreta scenarier som hjälper er att kalibrera bedömningen mot verkliga fall snarare än abstrakta kriterier.
En anmälan till IMY ska enligt artikel 33.3 innehålla:
- Beskrivning av incidentens art och omfattning.
- Kontaktuppgifter till dataskyddsombudet eller annan kontaktpunkt.
- Sannolika konsekvenser av incidenten.
- Åtgärder som vidtagits eller föreslås för att hantera och begränsa skadan.
Information till registrerade krävs vid hög risk och ska vara skriven på klarspråk, med samma innehåll som anmälan men anpassat för att hjälpa mottagaren skydda sig själv, till exempel genom att byta lösenord eller bevaka sitt kreditupplysningsstatus.
IMY granskar ofta inte bara anmälda incidenter, utan även varför en organisation valt att inte anmäla. Det gör beslutsmotiveringen i incidentloggen till en av de viktigaste delarna av hela dokumentationen, oavsett vilken riktning beslutet tar.
Roller, ansvar och beslutsvägar vid incidenthantering
Otydliga roller är den vanligaste orsaken till att organisationer missar 72-timmarsfristen. Ansvaret är dock tydligt fördelat i regelverket, det är den interna eskaleringen som ofta brister.
- Den personuppgiftsansvarige bär det juridiska ansvaret för att anmäla till IMY och för att fatta det slutgiltiga beslutet om anmälningsplikt.
- Dataskyddsombudet stödjer bedömningen, granskar dokumentationen och håller ofta kontakten med tillsynsmyndigheten och de registrerade.
- Personuppgiftsbiträdet ska rapportera en incident till den personuppgiftsansvarige utan onödigt dröjsmål, men saknar egen anmälningsskyldighet gentemot IMY.
- IT- och säkerhetsfunktionen ansvarar för teknisk utredning, isolering och bevissäkring.
En kontaktlista med telefonnummer, inte bara e-post, och en tydlig delegationsordning för vem som får fatta anmälningsbeslutet vid frånvaro, sparar värdefulla timmar när klockan väl börjar ticka.
Praktiska mallar och dokumentationsrutiner för incidentloggen
En incidentlogg som bara finns som ett Word-dokument på någons skrivbord håller inte i längden, vilket tydligt framgår i exempel på integritetspolicy för boendeorganisationer. Den behöver leva i ett system som resten av organisationen känner till och kan använda under tidspress.
En minimal mall täcker datum, beskrivning, riskbedömning och beslut. En utökad mall lägger till kopplingar till registerförteckningen, ansvarig handläggare, status på åtgärder och en logg över varje uppdatering som skickats till IMY.
- Använd versionshantering så varje ändring i riskbedömningen går att spåra i efterhand.
- Begränsa skrivåtkomst till dataskyddsombud och utsedda handläggare, men ge läsåtkomst brett inom ledningen.
- Sätt en bevarandetid som matchar era övriga dataskyddsrutiner, ofta flera år, eftersom IMY kan begära in historiska incidenter vid tillsyn.
- Kräv att biträden rapporterar enligt en standardiserad mall, så informationen går att klistra in direkt i er logg utan omformulering.
Proffstips: Koppla varje incident till den behandling den rör i registerförteckningen. Då ser ni snabbt om samma system eller leverantör dyker upp i flera incidenter, ett mönster som annars lätt göms i separata dokument.
Vanliga fallgropar och snabbvinster i incidentarbetet
De brister vi ser oftast handlar sällan om okunskap om 72-timmarsregeln. De handlar om svag dokumentation: riskbedömningar utan tydlig motivering, beslut att inte anmäla som saknar skriftlig grund, och loggar som aldrig kopplas till registerförteckningen eller till en genomförd DPIA.
De snabbaste förbättringarna kommer från tre saker: en riskbaserad prioriteringsmodell som skiljer allvarliga incidenter från rutinärenden, en färdig mall som tvingar fram alla obligatoriska fält, och en tydlig ansvarsfördelning som är känd innan krisen inträffar. En plattform som Trustview kan koppla incidentloggen direkt till åtgärdsuppföljning och registerförteckning, vilket gör att bedömningsunderlaget finns samlat den dag IMY frågar efter det.
Vad de flesta glömmer i sin incidenthantering
Det vanligaste misstaget är inte att missa 72-timmarsfristen. Det är att behandla anmälan som slutpunkten i stället för dokumentationen. Många organisationer lägger all kraft på att formulera en anmälan till IMY och glömmer att samma noggrannhet krävs när beslutet blir att avstå.
Det är ett obalanserat fokus, för tillsynsmyndigheten granskar minst lika ofta de fall där ingen anmälan skedde. En incidentlogg utan skriftlig motivering till varför risken bedömdes som osannolik är svår att försvara i efterhand, oavsett hur korrekt bedömningen faktiskt var.
Prioritera därför beslutsmotiveringen lika högt som själva anmälningstexten. Bygg loggen så att den kopplas till registerförteckning och konsekvensbedömningar från start, i stället för att försöka rekonstruera sambanden månader senare. Och sluta se incidentloggen som ett engångsdokument. Den är ett levande underlag som växer varje gång ett beslut, en åtgärd eller en uppdatering till IMY läggs till.
— Jesper
Kom igång med strukturerad incidentloggning i Trustview
Trustview samlar incidentloggning, riskbedömning och åtgärdsuppföljning i samma system som er registerförteckning och era konsekvensbedömningar, så ni slipper leta efter samband mellan lösa dokument när klockan tickar mot 72 timmar.
Plattformen ger er färdiga fält för tidsstämplar, riskanalys och beslutsmotivering, och håller reda på vilka uppgifter som fortfarande saknas i en pågående anmälan. Varje incident kopplas automatiskt till rätt behandling i registerförteckningen, vilket gör bedömningsunderlaget komplett från första minuten snarare än något ni återskapar i efterhand. Läs mer om hur hanteringsprocessen för dataintrång kan struktureras i praktiken, eller boka en genomgång av plattformen för att se hur incidentloggen fungerar i er egen miljö.
Källor
Primärkällor: IMY om personuppgiftsincidenter och EDPB:s riktlinjer 9/2022 ger den juridiska grunden för anmälningskrav och dokumentation.
- IMY — Notification of a personal data breach (engelska sida)
- EDPB — Riktlinjer 9/2022 (svensk version)
