Persondata og beredskab

Persondatabrud i appen: undersøg, begræns og dokumentér hændelsen

Et persondatabrud er ikke kun et hackerangreb. Det kan også være en forkert modtager, en bruger der ser en anden kundes data, en utilsigtet ændring eller personoplysninger, som bliver utilgængelige. En rolig proces hjælper jer med at standse skaden, bevare fakta og træffe de juridiske beslutninger i tide.

Udgivet 6. november 2026 · Ca. 12 minutters læsetid

Genkend bruddet, før I vurderer anmeldelsen

GDPR definerer et brud på persondatasikkerheden som en sikkerhedshændelse, der fører til hændelig eller ulovlig destruktion, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger. Det betyder, at fortrolighed, rigtighed og tilgængelighed alle kan være ramt. Spørgsmålet er først, om persondata er kompromitteret – ikke om nogen havde onde hensigter.

Type	Eksempel i en app	Mulig skade
Fortrolighed	En kunde kan hente en anden kundes dokument	Misbrug, diskrimination eller tab af kontrol
Integritet	En fejl ændrer kontonummer, journalnote eller adgangsrolle	Forkerte beslutninger, betalinger eller rettigheder
Tilgængelighed	Persondata slettes eller låses uden brugbar gendannelse	Personen eller virksomheden kan ikke bruge nødvendige oplysninger

Et nedbrud uden persondata er ikke automatisk et persondatabrud. Omvendt kan appen se grøn ud, mens en autorisationsfejl stille viser oplysninger til den forkerte bruger.

Start et særskilt hændelsesspor med det samme

Notér tidspunktet for det første signal og tidspunktet, hvor virksomheden med rimelig sikkerhed blev klar over, at persondata var kompromitteret. EDPB beskriver kendskab som en rimelig grad af sikkerhed for, at en sikkerhedshændelse har påvirket persondata. En kort indledende undersøgelse kan derfor være nødvendig, men den skal begynde hurtigt.

1. Opret én beskyttet sag: Giv den et id, en ejer, klokkeslæt og en løbende tidslinje.
2. Afgræns observationen: Hvilken funktion, brugergruppe, datatype, periode og hvilket miljø kan være berørt?
3. Fordel ansvar: Én koordinerer, én undersøger teknikken, og den dataansvarlige ejer vurderingen af anmeldelse og underretning.
4. Stop tilfældige ændringer: Frys uvedkommende deploys, oprydning og logrotation, som kan ændre situationen eller fjerne spor.
5. Sæt en beslutningsrytme: Aftal næste faktakontrol i timer, ikke efter at hele årsagen er fundet.

Start ikke med at kopiere alle berørte data. Bevar relevante logs, hændelses-id'er og systemspor med begrænset adgang. Store udtræk af persondata kan skabe en ny risiko og gøre sagsmappen unødigt følsom.

Begræns skaden uden at ødelægge beviserne

Den aktive skade skal stoppes først. Vælg den smalleste sikre handling, der begrænser yderligere adgang, ændring eller tab. Det kan være at deaktivere en enkelt eksport, gøre et område skrivebeskyttet, tilbagekalde en kompromitteret session eller nøgle, sætte et job på pause eller rette en konkret adgangsregel.

Bevar relevante adgangslogs, auditspor, deploy-id, konfiguration og tidspunkt, før de overskrives, hvis det kan gøres uden at forlænge skaden.
Kontrollér om samme fejl findes i andre miljøer, kunder, roller, dokumenttyper eller API-ruter.
Skeln mellem at lukke hullet og at rydde op i følgerne. En rettet regel gør ikke allerede hentede filer hemmelige igen.
Dokumentér hver nødændring med udfører, tidspunkt, forventet virkning og faktisk resultat.
Undgå brede nulstillinger og sletninger, indtil konsekvensen for beviser, drift og de berørte personer er forstået.

Byg risikovurderingen på mennesker – ikke kun antal rækker

Risikoen vurderes for de berørte personers rettigheder og frihedsrettigheder. EDPB peger blandt andet på datatyper, identifikationsmulighed, konsekvensens alvor, sandsynlighed, antal personer og om sårbare personer er berørt. Ét alvorligt brud kan derfor veje tungere end et stort, men ufølsomt datasæt.

Oplysninger: Er der loginoplysninger, økonomi, lokation, helbred, børn, fortrolige forhold eller kombinationer, der gør personer let genkendelige?
Eksponering: Hvem kunne få adgang, i hvor lang tid, og findes der bevis for visning, download, ændring eller videre deling?
Konsekvens: Kan bruddet føre til identitetstyveri, svindel, økonomisk tab, omdømmeskade, diskrimination eller tab af kontrol?
Beskyttelse: Var data effektivt krypteret, så modtageren ikke kan læse dem, og er nøglerne fortsat beskyttet? Hvis data kun er pseudonymiseret, skal I særskilt vurdere muligheden for at forbinde dem med en person og beskyttelsen af de ekstra oplysninger.
Afhjælpning: Kan modtageren troværdigt bekræfte sletning, kan adgang tilbagekaldes, og kan personen selv gøre noget konkret for at begrænse skaden?

Skriv både kendte fakta, usikkerheder og begrundelsen for vurderingen. Effektiv kryptering, hurtig tilbagekaldelse eller en betroet fejlmodtager kan mindske risikoen, men fjerner ikke automatisk, at der har været et brud. Pseudonymisering kan gøre identifikation sværere, men gør ikke i sig selv oplysningerne uforståelige.

Træf tre adskilte beslutninger

Dokumentation, anmeldelse til Datatilsynet og underretning af berørte personer er ikke samme beslutning. Den dataansvarlige skal vurdere dem særskilt på baggrund af den konkrete hændelse.

Beslutning	Tærskel	Praktisk handling
Intern dokumentation	Alle konstaterede persondatabrud	Gem fakta, virkning, vurdering og afhjælpning, også når der ikke anmeldes
Anmeldelse til Datatilsynet	Medmindre risiko for personers rettigheder og frihedsrettigheder er usandsynlig	Anmeld uden unødig forsinkelse og om muligt inden 72 timer efter kendskab
Underretning af personer	Når bruddet sandsynligvis medfører høj risiko	Underret uden unødig forsinkelse i klart sprog med brugbare råd

72 timer er ikke en ventetid. Datatilsynet skriver, at anmeldelse skal ske uden unødig forsinkelse og om muligt inden 72 timer. Hvis alle oplysninger ikke er klar, giver GDPR mulighed for at give dem trinvis uden unødig yderligere forsinkelse. En sen anmeldelse skal begrundes.

Saml det, anmeldelsen og underretningen skal bygge på

Datatilsynets blanket beder blandt andet om bruddets karakter, kontaktpunkt, sandsynlige konsekvenser og de foranstaltninger, der er truffet eller planlagt. EDPB fremhæver desuden kategorier og omtrentligt antal berørte personer og poster, hvor det er muligt. Præcise tal må ikke blive en undskyldning for at vente.

Beskriv hændelsen, tidsrummet og systemerne uden at vedlægge unødvendige personoplysninger.
Angiv kategorier og et forsvarligt estimat for personer og dataposter; markér tydeligt hvad der endnu er ukendt.
Beskriv sandsynlige konsekvenser for mennesker, ikke kun tekniske komponenter.
Beskriv hvad der allerede er gjort, hvad der er planlagt, og hvordan yderligere skade begrænses.
Angiv et kontaktpunkt, der faktisk kan modtage og besvare opfølgende spørgsmål.

En besked til berørte personer skal være klar og konkret: hvad er sket, hvilke oplysninger og konsekvenser er relevante, hvad gør virksomheden, og hvad kan personen selv gøre nu? Undgå både juridisk tåge og garantier, som undersøgelsen ikke understøtter.

Afklar dataansvarlig og databehandler før hændelsen

Hvis appen behandler persondata for en kunde, kan virksomheden bag appen være databehandler, mens kunden er dataansvarlig. GDPR kræver, at databehandleren underretter den dataansvarlige uden unødig forsinkelse efter at være blevet bekendt med et brud. Det er den dataansvarlige, der vurderer risiko og pligt til anmeldelse.

Skriv i databehandleraftalen, hvem der kontaktes døgnet rundt, og hvilke første oplysninger der skal følge med.
Undgå en intern frist, der bruger hele den dataansvarliges 72-timers vindue.
Kortlæg underdatabehandlere og cloudleverandørers kontaktveje, så deres hændelse hurtigt kan kobles til jeres kunder og data.
Aftal hvem der kommunikerer til brugere, kunder, Datatilsynet og eventuelle andre myndigheder, så beskeder ikke modsiger hinanden.

Øv processen med en lille, realistisk hændelse

En papirplan virker først, når de rigtige personer kan bruge den under tidspres. Øv eksempelvis, at en almindelig bruger kan hente en anden virksomheds fil. Brug ikke rigtige kundedata; giv deltagerne sikre testspor og lad dem arbejde fra første alarm til dokumenteret beslutning.

Kan supporten genkende signalet og finde den private eskaleringsvej?
Kan teknikeren afgrænse bruger, fil, tidsrum og deploy uden et stort dataudtræk?
Kan den dataansvarlige se kendskabstidspunkt, konsekvenser og manglende fakta?
Kan teamet udarbejde en foreløbig anmeldelse og en forståelig besked til berørte?
Bliver nødændringer, beviser og endelig gendannelse dokumenteret og verificeret?

Typiske fejl

Kun hacking tæller: Fejlsendte mails, for brede roller, ændrede data og utilgængelighed bliver overset.
Uret starter efter årsagsanalysen: Kendskabstidspunktet bliver ikke noteret, mens teamet leder efter den perfekte forklaring.
72 timer bliver et mål: En klar anmeldelsespligtig hændelse venter unødigt på sidste detalje.
Alt eksporteres til et regneark: Undersøgelsen opretter en ny, bred kopi af følsomme oplysninger.
Risiko måles kun i antal: Datatype, sårbarhed og mulig skade for den enkelte bliver glemt.
Databehandleren vurderer alene: Den dataansvarlige får besked for sent eller uden brugbare fakta.
Brugerne får en vag undskyldning: De får ikke at vide, hvilke konkrete forholdsregler der kan beskytte dem.
Ikke-anmeldte brud forsvinder: Virksomheden kan senere ikke vise hændelsen, vurderingen eller forbedringerne.

Tjekliste til et persondatabrud i appen

☐ Medarbejdere og support ved, hvordan et muligt persondatabrud straks eskaleres privat.
☐ Første signal, kendskabstidspunkt, ejer og næste beslutningstidspunkt er noteret.
☐ Fortrolighed, integritet og tilgængelighed er vurderet – ikke kun uautoriseret adgang.
☐ Berørte systemer, datatyper, personer, tidsrum og mulige modtagere er afgrænset.
☐ Aktiv skade er begrænset med en dokumenteret ændring, og nødvendige spor er bevaret sikkert.
☐ Risikoen for mennesker er vurderet med fakta, usikkerheder og afhjælpende forhold.
☐ Intern dokumentation, anmeldelse og underretning er besluttet hver for sig.
☐ En nødvendig anmeldelse sker uden unødig forsinkelse og om muligt inden 72 timer efter kendskab.
☐ Manglende oplysninger følges op trinvis, og en eventuel forsinkelse begrundes.
☐ Berørte personer får klar information og konkrete råd uden udokumenterede garantier.
☐ Dataansvarlig, databehandler og underdatabehandlere har fungerende kontaktveje og ansvar.
☐ Hændelsen afsluttes med verificeret rettelse, opdateret risikovurdering og navngivne forbedringer.

Denne guide er en teknisk og organisatorisk arbejdsramme, ikke juridisk rådgivning. Brug Datatilsynets aktuelle vejledning og få konkret databeskyttelsesfaglig hjælp ved en virkelig hændelse.

Relaterede guides

Officielle kilder

Guidens juridiske og organisatoriske fakta er kontrolleret mod Datatilsynet, EDPB og selve databeskyttelsesforordningen. Kontrollér altid den aktuelle vejledning, når en konkret hændelse skal vurderes.

Virker appen, men mangler persondataberedskabet?

Startklar kan bruges til at kortlægge jeres konkrete dataflow, kontaktveje, logs og tekniske begrænsninger, så processen passer til den app og organisation, I faktisk har.

Se Startklar-forløbet