En rutin för personuppgiftsincidenter ska hjälpa verksamheten att agera när fakta fortfarande är ofullständiga. Den behöver ange vem som tar emot larmet, vem som begränsar skadan och vem som beslutar om anmälan. Ett formulär räcker inte om ingen läser inkorgen under helgen eller om behörigheten till anmälningstjänsten finns hos en frånvarande kollega.
Här får ni en arbetsgång och korta mallar att anpassa till organisationen. Tyngdpunkten ligger på den interna hanteringen. Den praktiska kontakten med myndigheten behandlas vidare i guiden om att anmäla en personuppgiftsincident till IMY. Utgångspunkten är artiklarna 4.12 och 32–34 i GDPR samt IMY:s vägledning om incidenthantering.
Vad ska utlösa rutinen?
En personuppgiftsincident är 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. Det omfattar både digital information och pappershandlingar. Ett feladresserat brev, ett ändrat kontonummer och en otillgänglig patientjournal kan därför behöva samma inledande bedömning som ett dataintrång.
Skilj mellan sekretess, riktighet och tillgänglighet. Att ingen har stulit uppgifter utesluter inte en incident. Om nödvändiga uppgifter förstörs eller inte går att använda kan människor ändå skadas. Omvänt är ett blockerat intrångsförsök inte automatiskt en personuppgiftsincident. Dokumentera vilka uppgifter som faktiskt berörts och vad som talar för respektive emot att en säkerhetsöverträdelse inträffat.
Personal ska kunna rapportera en misstanke utan att först avgöra den juridiska frågan. Ange konkreta signaler i rutinen: borttappad arbetsdator, fel mottagare, oväntad export, tillgång till en annan kunds konto eller ovanliga ändringar i register. Den som upptäcker händelsen ska beskriva observationen och bevara relevanta meddelanden, men inte själv börja undersöka andra personers konton.
Bestäm ansvar och kontaktvägar i förväg
Den personuppgiftsansvariga organisationen ansvarar för beslut enligt GDPR. Fördela arbetsuppgifterna mellan en incidentledare, tekniskt ansvarig och en person som bedömer konsekvenserna för de registrerade. I en liten verksamhet kan samma person ha flera uppgifter, men det måste finnas en ersättare och en fungerande möjlighet att fatta brådskande beslut.
Ett dataskyddsombud, om ni har ett, ger råd och följer hur skyldigheterna uppfylls. Ombudet ersätter inte ledningens ansvar och ska inte göras till ensam flaskhals för tekniska åtgärder. Se separat när dataskyddsombud krävs. Även en verksamhet utan ombud behöver utse någon som kan stödja riskbedömningen och hitta rätt juridisk kompetens.
Skriv kontaktvägar som fungerar även om e-postsystemet ligger nere. Bestäm hur anställda, reception, externa driftleverantörer och jourfunktioner ska nå incidentledaren. Testa numren och åtkomsten till dokumentationen. En rutin som bara ligger på den krypterade filservern är svår att använda när servern är den drabbade tjänsten.
Steg 1: registrera larmet och skydda berörda
Notera när händelsen upptäcktes, av vem, vilka system och uppgifter som kan beröras samt vilka omedelbara åtgärder som redan vidtagits. Be om tillräckliga fakta för prioriteringen. Undvik att sprida en fullständig kundlista till hela incidentgruppen när ett ärendenummer och en avgränsad beskrivning räcker.
Begränsa skadan utifrån situationen: stoppa en felaktig utsändning, stäng en exponerad delningslänk eller spärra ett kapat konto. Åtgärden måste samtidigt bedömas mot verksamhetens behov. Att stänga ett vårdsystem kan skapa en ny risk för patienter. Den tekniskt ansvariga bör därför samråda med den verksamhetsansvariga när avbrott påverkar kritiska arbetsuppgifter.
Bevara spår innan rutinmässig radering eller återinstallation förstör dem. Anteckna vilka loggar som säkrats, tidszoner, vem som gjort kopior och vilka förändringar som genomförts. Detta är en praktisk rekommendation för att kunna förstå förloppet; den innebär inte att alla loggar måste sparas obegränsat. Begränsa åtkomst och håll isär undersökningsmaterial från den kortare beslutsloggen.
Steg 2: fastställ när ni fick vetskap
Anmälan till behörig tillsynsmyndighet ska göras utan onödigt dröjsmål och, om möjligt, senast 72 timmar efter att den personuppgiftsansvariga fått vetskap om incidenten. Undantaget gäller om det är osannolikt att incidenten medför en risk för fysiska personers rättigheter och friheter. Fristen börjar alltså inte automatiskt vid den första tekniska störningen, men ni får inte skjuta upp vetskap genom en utdragen intern utredning.
Enligt EDPB:s slutliga riktlinjer 9/2022 handlar vetskap om en rimlig grad av säkerhet att en säkerhetsincident har äventyrat personuppgifter. Anteckna därför både det första larmet och den tidpunkt då underlaget blev tillräckligt. Beskriv varför tidpunkterna skiljer sig, om de gör det.
Tänk er att en leverantör på fredagen meddelar ett konstaterat obehörigt uttag av era kunduppgifter. Det går inte att vänta till måndagens ledningsmöte bara för att antalet kunder ännu är osäkert. Helger stoppar inte tidsräkningen. En kort inledande undersökning kan vara nödvändig, men den ska vara aktiv och syfta till ett snabbt ställningstagande.
Steg 3: bedöm risken för människor
Utgå från de möjliga konsekvenserna för personerna, inte från organisationens kostnader eller risken för negativ publicitet. Uppgifter kan användas för bedrägerier, diskriminering, trakasserier eller avslöjanden av privata förhållanden. Felaktiga eller otillgängliga uppgifter kan påverka vård, utbetalningar och möjligheten att utnyttja rättigheter.
Bedöm uppgifternas art, sammanhang, omfattning och hur lätt någon kan identifieras. En lista över deltagare i en allmän konferens och en lista över personer som söker skyddat boende innebär olika risker även om båda bara innehåller namn och telefonnummer. Ta hänsyn till barn, personer med skyddade uppgifter och andra som kan vara särskilt utsatta.
Mottagaren och kontrollmöjligheten spelar också roll. En betrodd mottagare som omedelbart bekräftar att ett felaktigt dokument raderats kan minska sannolikheten för skada. Bedömningen behöver stödjas av omständigheterna; ett artigt svar är inte alltid tillräckligt. När uppgifterna varit öppet tillgängliga på internet kan spridningen vara svår att överblicka även efter att felet har stängts.
Kryptering är relevant om skyddet faktiskt hindrar obehöriga från att läsa uppgifterna och nyckeln är säker. Den löser inte automatiskt förlust av tillgänglighet. En stulen krypterad dator med fungerande säkerhetskopior kan bedömas annorlunda än den enda dator som innehöll nödvändiga journaluppgifter. Beskriv den faktiska återställningsmöjligheten, inte bara att organisationen har en säkerhetskopieringspolicy.
Använd gärna en enkel riskmatris, men låt inte en totalsiffra ersätta resonemanget. Dokumentera vilka skadeförlopp som är rimliga, vilka skydd som fungerar och vilka fakta som saknas. Sätt en tidpunkt för omprövning när osäkerheten kan påverka beslutet. Förändrade fakta kan göra att en tidigare bedömning behöver ändras.
Steg 4: besluta om anmälan och information
Anmäl till IMY när myndigheten är behörig och undantaget för osannolik risk inte är uppfyllt. Kräv inte bevis på att en skada redan har inträffat. Inte heller krävs hög risk för myndighetsanmälan; hög risk är tröskeln för den separata skyldigheten att informera de registrerade enligt artikel 34.
Anmälan ska beskriva incidentens art och, om möjligt, kategorier och ungefärligt antal registrerade och personuppgiftsposter. Den ska också innehålla kontaktuppgifter till ombud eller annan kontaktpunkt, sannolika konsekvenser och vidtagna eller föreslagna åtgärder, inklusive åtgärder för att begränsa negativa effekter. Markera uppskattningar och skilj dem från bekräftade uppgifter.
Om allt inte kan lämnas samtidigt får informationen lämnas stegvis utan ytterligare onödigt dröjsmål. Det är bättre att lämna en saklig första anmälan med tydliga luckor än att invänta en perfekt slutrapport. Om anmälan görs senare än 72 timmar ska orsakerna till förseningen anges. En försening upphäver inte skyldigheten att anmäla.
Vid sannolik hög risk ska de registrerade informeras utan onödigt dröjsmål, på ett klart och tydligt språk. Beskriv vad som har hänt, sannolika konsekvenser, vad ni gör och hur de får kontakt. Ge användbara skyddsråd som passar händelsen. Undvik ett allmänt massutskick som uppmanar alla att byta lösenord när lösenorden inte berörts.
Artikel 34 har undantag: exempelvis skydd som gjort uppgifterna oläsbara för obehöriga, eller efterföljande åtgärder som säkerställer att hög risk inte längre sannolikt uppkommer. Om individuell information skulle kräva oproportionell ansträngning krävs i stället offentlig kommunikation eller en lika effektiv åtgärd. Det är inte ett undantag från att alls nå de berörda. Se informationen till drabbade enligt artikel 34 för utformningen.
Steg 5: återställ, följ upp och avsluta
Återställningen behöver bekräfta att tjänsten går att använda och att uppgifterna är riktiga. Att en säkerhetskopia går att läsa betyder inte att alla beroenden fungerar. Koppla därför incidentrutinen till återställningsplanen med RTO och RPO. Notera vilka kontroller som genomförts innan verksamheten återupptas och vem som godkänt det.
Följ upp rotorsaken separat från det omedelbara felet. Ett felaktigt utskick kan bero på otydliga mottagarlistor, för breda behörigheter eller ett gränssnitt som gör misstag sannolika. Åtgärden behöver rikta sig mot den faktiska orsaken. En allmän påminnelse till personalen räcker sällan om samma fel fortfarande är enkelt att upprepa.
Avsluta ärendet först när kvarstående uppgifter har en ansvarig och uppföljningsdatum. Det kan finnas tekniska åtgärder som fortsätter efter att själva incidenten upphört. Dokumentera det öppet i stället för att markera allt som färdigt. Bedöm även om nya uppgifter kräver komplettering till myndigheten eller ny information till berörda personer.
Pröva ett felaktigt utskick från upptäckt till beslut
Anta att löneavdelningen skickar en fil till fel extern mottagare. Börja med att stoppa fortsatt spridning och identifiera vilken fil som faktiskt skickades. Att ämnesraden nämner löner säger inte om bilagan innehåller namn, kontonummer, frånvarouppgifter eller bara totalsummor. Be mottagaren att inte använda uppgifterna och att radera materialet, men säkra samtidigt tillräcklig dokumentation om vad som hände.
Undersök sedan om filen öppnades, om den gick till en personlig adress eller en delad inkorg och om ytterligare mottagare fått tillgång. Ett återkallat e-postmeddelande är inte bevis för att alla kopior har försvunnit. Riskbedömningen behöver också ta hänsyn till uppgifter som kan avslöja hälsa eller privata ekonomiska förhållanden. Antalet berörda är relevant men ersätter inte bedömningen av konsekvenserna för varje person.
Dokumentera varför en bekräftelse från mottagaren påverkar bedömningen och vilka osäkerheter som återstår. Om mottagaren är okänd eller inte svarar ska ärendet ändå drivas vidare inom tillämpliga tidsramar. Om ni först bedömer risken som osannolik men senare får veta att filen publicerats, öppna beslutet på nytt och dokumentera när den nya informationen kom. Rutinen behöver alltså stödja omprövning, inte bara ett enda kryss i en blankett.
Avsluta med att pröva varför en fullständig lönefil kunde skickas via den aktuella kanalen. Behövdes alla kolumner, fanns en tydlig mottagarkontroll och kunde ett begränsat utdrag ha räckt? Bestäm en åtgärd som går att verifiera i nästa utskick. Detta hypotetiska exempel visar hur faktainsamling, risk och förebyggande arbete kan hänga ihop utan att på förhand bestämma att alla feladresserade meddelanden ska få samma juridiska utfall.
Mall: arbetsordning och beslutsträd
Följande text är en stomme för intern användning. Fyll i funktioner och kontaktvägar, och pröva sedan om en ersättare kan följa den utan muntliga instruktioner. Undvik ett fast krav på att hela ledningen ska underteckna varje beslut; den ordningen kan hindra snabba åtgärder.
Intern arbetsordning – anpassa före användning
Alla misstänkta händelser rapporteras till [kontaktväg]. Vid uteblivet svar kontaktas [ersättare]. [Funktion] leder hanteringen och öppnar ett ärende. [Funktion] begränsar teknisk skada. [Funktion] bedömer påverkan på människor och dokumenterar anmälningsbeslutet. [Funktion] skickar anmälan och kompletteringar. [Funktion] ansvarar för information till registrerade och uppföljning.
Misstänkt händelse → säkra fakta och begränsa skadan.
Personuppgiftsincident? Nej → dokumentera bedömningen i lämplig ärendelogg.
Ja → dokumentera enligt artikel 33.5 och bedöm risk.
Osannolik risk? Ja → dokumentera varför anmälan inte krävs; ompröva vid nya fakta.
Annars → anmäl utan onödigt dröjsmål, om möjligt inom 72 timmar från vetskap.
Sannolik hög risk? → pröva artikel 34 och dess undantag; informera när det krävs.
Återställ → följ upp → komplettera bedömningen → avsluta med ansvariga åtgärder.
Mall: incidentregistret enligt artikel 33.5
Alla personuppgiftsincidenter ska dokumenteras, även när de inte anmäls. Dokumentationen ska beskriva omständigheterna, effekterna och de korrigerande åtgärderna så att tillsynsmyndigheten kan kontrollera efterlevnaden. Ett särskilt kalkylblad är inte ett lagkrav; ett skyddat ärendehanteringssystem kan fungera om uppgifterna är samlade och går att följa.
| Fält att fylla i | Vad posten ska hjälpa er att visa |
|---|---|
| Ärendenummer och ansvarig | Vem som samordnar hanteringen |
| Upptäckt och vetskap | Tider, tidszon och grund för bedömningen |
| Händelse och omfattning | Uppgifter, personer, system och kända luckor |
| Konsekvenser och risk | Skadeförlopp, skydd och kvarstående osäkerhet |
| Beslut enligt artiklarna 33 och 34 | Skäl, beslutsfattare och omprövning |
| Åtgärder och kontakter | Innehåll, tidpunkt och ansvar |
| Anmälan och kompletteringar | Referens, datum och eventuell förklaring till försening |
| Avslut och uppföljning | Återställning, kvarstående arbete och verifiering |
Incidentregistret är inte samma sak som registerförteckningen över behandlingar. Den senare hjälper er att hitta berörda system, personkategorier och leverantörer. Länka mellan dokumenten utan att kopiera alla känsliga uppgifter. Bestäm också en motiverad lagringstid för incidentunderlaget och begränsa vilka som får läsa det.
När ett personuppgiftsbiträde är inblandat
Ett biträde ska underrätta den personuppgiftsansvariga utan onödigt dröjsmål efter att ha fått vetskap om en personuppgiftsincident. Biträdet ska inte först invänta sin egen bedömning att incidenten kräver myndighetsanmälan. Ange kontaktvägar, informationsformat och samarbete i ert personuppgiftsbiträdesavtal enligt artikel 28, eller i den andra bindande rättsakt som reglerar uppdraget när det alternativet är tillämpligt.
En leverantör kan sakna uppgifter om hur ni använder tjänsten och vilka personer som berörs. Begär därför fakta om åtkomst, tidsperiod, underleverantörer och avhjälpande åtgärder, men gör den egna konsekvensbedömningen. Om ni själva är biträde åt flera kunder behöver ni kunna identifiera vilka kunder som berörs utan att röja andra kunders information.
Öva på beslut som faktiskt kan bli svåra
En återkommande övning är en praktisk metod att kontrollera rutinen, inte ett generellt lagkrav på en viss årlig frekvens. Välj scenarier utifrån verksamheten. Låt exempelvis kundtjänsten ta emot ett felaktigt dokument och låt incidentledaren begära kompletterande fakta. Kontrollera om rapporteringen fungerar även när den vanliga ansvariga är frånvarande.
Pröva också ett tillgänglighetsfall: en filserver är krypterad, men den senaste säkerhetskopian saknar vissa ärenden. Vilka personer drabbas av att uppgifterna saknas, och vad kan verksamheten göra under återställningen? Dokumentera var övningen fastnar. Anpassa utbildningen för medarbetare efter de konkreta arbetsmoment som orsakar osäkerhet.
Som historiskt säkerhetsexempel beskrev IMY i augusti 2023 beslutet om Trygg-Hansa och en sanktionsavgift på 35 miljoner kronor. Bristerna gjorde uppgifter om omkring 650 000 kunder åtkomliga. Exemplet gäller bristande skydd av uppgifter; det ska inte användas som belägg för en särskild avgift för sen incidentanmälan. Återkommande incidenter kan även ge anledning att ompröva säkerhetsåtgärder och en befintlig konsekvensbedömning.
Vanliga frågor om incidentrutinen
Ska alla tekniska incidenter anmälas?
Nej. Avgör först om personuppgifter har påverkats på ett sätt som utgör en personuppgiftsincident. Dokumentera sedan varje sådan incident enligt artikel 33.5. Myndighetsanmälan krävs om det inte är osannolikt att incidenten medför risk för personers rättigheter och friheter. Dokumentationen av ett beslut att avstå ska visa varför undantaget är uppfyllt.
Kan vi vänta tills leverantören är klar?
Ni behöver tillräckliga fakta för att bedöma situationen, men leverantörens slutrapport är inget generellt villkor för anmälan. Lämna tillgängliga uppgifter och komplettera utan ytterligare onödigt dröjsmål när det behövs. Håll en egen tidslinje över vetskap, beslut och kontakter, så att beroendet av leverantören inte gör att ärendet tappar sin ansvariga.
Räcker det att spara en kopia av anmälan?
Inte alltid. Anmälan kan vara en del av dokumentationen, men den visar inte nödvändigtvis alla omständigheter, bedömningar och senare åtgärder. Bevara även det underlag som förklarar besluten, med lämplig åtkomstbegränsning. En kort beslutslogg som pekar på säkrade bilagor är ofta mer användbar än ett stort antal osorterade meddelanden.