# GDPR-anmälningsplikt: 72 timmar efter incidenten

> Personuppgiftsincident och anmälan inom 72 timmar: vad art. 33 och 34 i GDPR kräver efter ett serverangrepp och vad ni bör dokumentera redan nu.

Källa: https://phpsos.de/sv/compliance/dsgvo-meldepflicht-72-stunden/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Om skyddet för personuppgifter överträds vid ett angrepp kräver art. 33 GDPR en anmälan till tillsynsmyndigheten, om möjligt inom 72 timmar från det att ni fick kännedom, förutsatt att det finns en risk för de registrerade. Vid hög risk tillkommer enligt art. 34 underrättelse till de registrerade. Oberoende av det måste ni dokumentera varje överträdelse. Den här sidan är allmän information och ingen juridisk rådgivning.

> **Viktigt:**
> Ingen juridisk rådgivning: om och när det i det enskilda fallet finns en anmälningsplikt bedömer ert dataskyddsombud eller en advokat. Vi levererar de tekniska fakta som bedömningen vilar på.

## Personuppgiftsincident och anmälan inom 72 timmar: vad art. 33 reglerar

Art. 33 GDPR gäller ”personuppgiftsincidenter”, alltså överträdelser av skyddet för personuppgifter. Avsett är varje säkerhetsincident som leder till förstörelse, förlust, ändring, obehörigt röjande av eller obehörig åtkomst till personuppgifter. En komprometterad webbserver med kunddatabas, kontaktformulär eller sökandeuppgifter kan omfattas.

Anmälan till tillsynsmyndigheten ska göras utan onödigt dröjsmål och om möjligt inom 72 timmar efter att den personuppgiftsansvarige fick kännedom om överträdelsen. Den behövs inte om överträdelsen sannolikt inte medför någon risk för fysiska personers rättigheter och friheter. Den som anmäler senare än 72 timmar måste motivera förseningen. Information får lämnas stegvis.

## Vad en anmälan bör innehålla

Art. 33.3 GDPR anger minimiinnehåll. Förbered de här punkterna även om allt ännu inte är klart:

- överträdelsens art, om möjligt med kategorier och ungefärligt antal berörda personer och register
- namn och kontaktuppgifter till dataskyddsombudet eller en annan kontaktpunkt
- sannolika konsekvenser av överträdelsen
- vidtagna eller föreslagna åtgärder för att åtgärda och mildra eventuella negativa följder

Särskilt vid angrepp mot webbservrar är omfattningen ofta oklar i början. Då hjälper en ärlig första anmälan med det kända läget och beskedet att ytterligare insikter lämnas in senare.

## När börjar fristen efter ett serverangrepp?

Fristen knyter an till kännedomen, inte till tidpunkten för angreppet. I praktiken är avgränsningen ofta svår: ett meddelande om en sårbarhet som PHP2Shell grundar ensamt ännu ingen kännedom om en dataskyddsöverträdelse. Hittar ni däremot konkreta tecken på ett intrång, till exempel en webshell eller misstänkta databasförfrågningar, kan läget se annorlunda ut.

Dokumentera därför från början med klockslag vem som fick vilken information och när, och vilka steg som följde. Den tidslinjen hjälper vid den juridiska bedömningen och vid myndighetens frågor. En noggrann teknisk undersökning, till exempel genom [IT-forensik](https://phpsos.de/sv/leistungen/it-forensik/), klargör om och vilka uppgifter som faktiskt berördes.

## Underrättelse av de registrerade enligt art. 34

Om överträdelsen sannolikt medför en hög risk för de registrerades rättigheter och friheter måste även de berörda personerna underrättas utan onödigt dröjsmål. Det kan till exempel gälla inloggningsuppgifter, bankuppgifter eller hälsouppgifter. Underrättelsen ska i klart och tydligt språk beskriva vad som har hänt och åtminstone ange kontaktpunkten, de sannolika konsekvenserna och de vidtagna åtgärderna.

Art. 34 föreskriver undantag, till exempel om uppgifterna har gjorts obegripliga för obehöriga, exempelvis genom kryptering. Skulle en underrättelse till varje enskild person medföra en oproportionerlig ansträngning kan i stället ett offentligt meddelande eller en lika effektiv åtgärd komma i fråga. Om ett undantag gäller hör till den juridiska bedömningen. Hur ni informerar kunder begripligt beskrivs under [Kriskommunikation efter ett angrepp](https://phpsos.de/sv/compliance/krisenkommunikation/).

## Dokumentationsplikt enligt art. 33.5

Oberoende av anmälningsplikten kräver art. 33.5 GDPR att varje överträdelse dokumenteras: fakta, effekter och vidtagna avhjälpande åtgärder. Dokumentationen måste göra det möjligt för tillsynsmyndigheten att kontrollera efterlevnaden. Det gäller även om ni efter prövning kommer fram till att ingen anmälan behövs.

För webbservrar betyder det i praktiken: säkra loggar innan de roteras, notera fynd med tidpunkt, anteckna beslut och deras motivering. Vid PHP2Shell rekommenderar facktidningarna att serverloggar sparas från och med den 20 oktober 2026. En patch tar dessutom inte bort skadlig programvara som redan har förts in och bevisar inte att ingenting hände tidigare.

## Praktiskt förlopp under de första timmarna

1. Rapportera misstanken internt till en fast kontaktpunkt och ta in dataskyddsombudet.
2. Säkra bevis: loggar, fillistor, databasutdrag, innan något raderas eller sätts upp på nytt.
3. Klargör tekniskt om personuppgifter kan ha berörts.
4. Juridisk bedömning av anmälnings- och underrättelseplikten, vid behov med advokat och försäkringsgivare.
5. Anmälan via tillsynsmyndighetens formulär, kompletteringar vid nya insikter.

En förberedd [IT-beredskapsplan](https://phpsos.de/sv/compliance/notfallplan-erstellen/) förkortar de här stegen avsevärt.

## Hur hjälper PHP SOS konkret?

- Vi säkrar loggar och systemtillstånd så att de förblir användbara för bedömningen och en senare granskning.
- Vi klargör tekniskt om och vilka uppgifter som var åtkomliga och levererar en begriplig sammanfattning för dataskyddsombud och jurister.
- Vi för en tidslinje över de tekniska insikterna som ni kan använda för anmälan och dokumentation.
- Vid bekräftat intrång tar vi över [Incident Response](https://phpsos.de/sv/leistungen/incident-response/) och sanering.


## Vanliga frågor

**När börjar de 72 timmarna löpa?**  
Enligt art. 33 GDPR från den tidpunkt då den personuppgiftsansvarige fick kännedom om överträdelsen. När det kan anses ha skett i det enskilda fallet är en juridisk bedömning. Dokumentera därför exakt när vem hade vilken information.

**Måste varje säkerhetslucka anmälas?**  
Nej. En sårbarhet ensam är ännu ingen överträdelse av skyddet för personuppgifter. Anmälningsplikt kan uppstå om det finns tecken på att obehöriga hade eller kunde ha haft tillgång till sådana uppgifter och en risk för de registrerade därmed uppstår.

**Vad gör jag om jag efter 72 timmar ännu inte vet allt?**  
Art. 33.4 GDPR tillåter att information lämnas stegvis om den inte kan tillhandahållas samtidigt. En försenad anmälan ska motiveras. Att vänta på fullständig klarhet är därför i regel ingen anledning att låta fristen löpa ut.

**Vem anmäler om webbhotellet berördes?**  
Anmälningsskyldig är den personuppgiftsansvarige, alltså i regel det företag som driver webbplatsen. Ett personuppgiftsbiträde som webbhotellet måste enligt art. 33.2 GDPR informera den personuppgiftsansvarige utan onödigt dröjsmål.

**Var anmäler jag en personuppgiftsincident?**  
Hos den behöriga tillsynsmyndigheten för dataskydd, i Sverige Integritetsskyddsmyndigheten (IMY). Företag i andra länder anmäler till respektive lands myndighet. De flesta myndigheter erbjuder onlineformulär för detta.

## Källor

- [GDPR art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI](https://www.bsi.bund.de/)
- [php.net: säkerhetsmeddelanden](https://www.php.net/)