Definition: vad är en personuppgiftsincident?

GDPR Art. 4.12 definierar personuppgiftsincident som en säkerhetsincident som leder till oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller obehörig åtkomst till personuppgifter som överförts, lagrats eller på annat sätt behandlats.

Definitionen är bred. Vanliga exempel:

  • Ransomware som krypterar filserver med kundregister
  • Mejl med personuppgifter skickat till fel mottagare
  • Stulen laptop med okrypterad personalregister
  • Phishing-attack som ger angripare åtkomst till Microsoft 365-konto
  • Felkonfigurerad S3-bucket eller publik Google-drive
  • Anställd som olovligt söker upp uppgifter om bekanta
  • Tekniskt fel som gör kunders orderhistorik synlig för andra kunder
  • Förlorad backup-tape med personaluppgifter

Art. 33: anmälan till IMY inom 72 timmar

Personuppgiftsansvarig ska anmäla incidenten till IMY utan onödigt dröjsmål och senast inom 72 timmar efter att incidenten blivit känd. Om 72-timmarsfristen överskrids ska motiveringen bifogas anmälan.

Undantag gäller endast om incidenten sannolikt inte medför någon risk för de registrerade. Beviskravet ligger på den personuppgiftsansvarige. Vid osäkerhet är huvudregeln att anmäla, eftersom utebliven anmälan är en sanktionsgrund i sig.

Anmälan görs via IMY:s e-tjänst. Den måste innehålla:

  • Beskrivning av incidentens art, inklusive kategorier av registrerade och uppgifter samt ungefärligt antal
  • Kontaktuppgifter till DPO eller annan kontaktpunkt
  • Sannolika konsekvenser av incidenten
  • Åtgärder som vidtagits eller föreslås för att hantera incidenten och begränsa skadan

Art. 34: information till registrerade vid hög risk

Om incidenten sannolikt leder till hög risk för de registrerades rättigheter och friheter ska personuppgiftsansvarig informera dem utan onödigt dröjsmål. Kommunikationen ska vara tydlig, klar och lättbegriplig.

Informationen ska innehålla samma punkter som i Art. 33, med fokus på praktisk risk och vilka åtgärder den registrerade själv kan vidta (byta lösenord, bevaka konton, kontakta bank).

Undantag från Art. 34 finns i tre fall: (a) om tekniska skyddsåtgärder som kryptering gör uppgifterna oläsliga för obehöriga, (b) om efterföljande åtgärder säkerställer att den höga risken inte längre är sannolik, eller (c) om individuell information skulle kräva oproportionerlig ansträngning, i vilket fall allmän information (t.ex. pressmeddelande) kan användas.

Tidsgränsen i praktiken: när börjar klockan ticka?

EDPB:s guideline 9/2022 klargör att 72-timmarsfristen börjar när personuppgiftsansvarig har rimlig visshet om att en incident har inträffat. En vag misstanke räcker inte, men väntan på fullständig teknisk utredning försvarar inte heller dröjsmål.

I praktiken innebär det:

  • Första indikation från SOC eller användare: klockan startar inte än, men inledande triage ska påbörjas
  • Bekräftad incident (t.ex. ransomware identifierat): klockan startar nu
  • Utredning pågår men fakta är oklara: anmäl inom 72 timmar med den information som finns, komplettera sedan
  • Upptäckt inom koncern där svensk enhet är personuppgiftsansvarig: klockan startar när koncernens incident response-team bekräftar incidenten

Preliminär och kompletterande anmälan

IMY accepterar anmälan i etapper. Om fakta inte är fullständigt klarlagda inom 72 timmar ska en preliminär anmälan lämnas in med tillgänglig information, och kompletteringar skickas successivt. Det är bättre att anmäla tidigt med ofullständig information än att vänta på fullständig utredning och missa fristen.

Kompletterande anmälan kan skickas i dagar eller veckor efter första anmälan. Slutlig utredning, rotorsaksanalys och åtgärdsplan ska dock vara klar så snart som praktiskt möjligt.

Samspel med NIS2 och AI Act

Ett svenskt bolag som är både NIS2-omfattat och personuppgiftsansvarigt kan behöva skicka parallella rapporter vid en cyberincident. Tidsramarna är olika:

RegelverkTidsgränsMottagareTröskel
NIS2 / Cybersäkerhetslagen (SFS 2025:1506)24 timmar: early warning. 72 timmar: incidentrapport. 1 månad: slutrapport.CSIRT hos sektorsmyndighetBetydande incident som påverkar tillhandahållandet av tjänsten
GDPR Art. 3372 timmarIMYRisk för registrerade (alla utom obefintlig risk)
AI Act Art. 7315 dagar (48 timmar vid dödsfall eller allvarlig skada)IMY som marknadskontrollmyndighet samt providernAllvarlig incident med högrisk-AI-system

Tre parallella rapporter i praktiken

Exempel: ett svenskt logistikföretag (NIS2 viktig entitet) drabbas av ransomware som krypterar personaldatabasen samt ett AI-baserat transportplaneringssystem (högrisk per Bilaga III, kritisk infrastruktur) blir otillgängligt.

Resultat: tre parallella rapporter. Early warning till transportsektorns CSIRT inom 24 timmar. Incidentrapport till CSIRT inom 72 timmar. Anmälan till IMY för personuppgiftsincident inom 72 timmar. Om systemet orsakat förutsebar skada aktualiseras även AI Act Art. 73 inom 15 dagar (48 timmar vid allvarlig skada).

En compliance-plattform som integrerar de tre processerna sparar tid, minskar risken för motstridig dokumentation och säkerställer att tidsgränserna hanteras parallellt istället för sekventiellt.

Dokumentationskrav enligt Art. 33.5

Alla personuppgiftsincidenter ska dokumenteras internt i ett incidentregister, även om de inte anmäls till IMY. Registret ska innehålla fakta om incidenten, dess effekter och vidtagna åtgärder. Syftet är att IMY vid tillsyn ska kunna verifiera att Art. 33 följs.

Registret ska omfatta även incidenter som bedömdes inte kräva anmälan. Bedömningen att anmälan inte krävs ska vara dokumenterad och motiverad.

Sanktioner vid bristande incidenthantering

Brott mot Art. 33 och 34 faller under den lägre sanktionsnivån (Art. 83.4 a): 10 miljoner euro eller 2 procent av global omsättning. IMY har utdömt flera sanktionsbeslut för utebliven eller försenad anmälan. Vanliga brister:

  • Utebliven anmälan där risk fanns
  • Försenad anmälan utan tillräcklig motivering
  • Bristfällig information till registrerade vid hög risk
  • Ofullständigt internt incidentregister
  • Bristfällig utredning av rotorsak

Praktisk incidentprocess

En fungerande incidentprocess enligt GDPR, NIS2 och AI Act bör omfatta följande steg:

  • Detektion. SOC, automatiska varningar, anställda och externa anmälare ska kunna rapportera incidenter i en kanal.
  • Triage. Incidentchef klassificerar omfattning och utlöser parallella klockor (NIS2 24h, GDPR 72h, AI Act 15d där tillämpligt).
  • Inneslutning. Tekniska åtgärder för att stoppa spridning.
  • Bedömning. Risk för registrerade, omfattning av personuppgifter, eventuell rapportering till CSIRT och IMY.
  • Anmälan. Parallell rapportering till relevanta myndigheter inom tidsramarna.
  • Kommunikation. Till registrerade vid hög risk, till styrelsen, till media vid behov.
  • Utredning och åtgärd. Rotorsaksanalys och långsiktiga åtgärder.
  • Dokumentation. Incidentregister per Art. 33.5 och intern kunskapsbank.