GDPR 72-timers playbook for brud på persondatasikkerheden for CISO'er

Klokken er 02:13 en tirsdag morgen, da alarmen udløses.
Maria, CISO i en hurtigt voksende FinTech SaaS-platform, vågner til en eskalering fra SOC: Der ses anomale databaseforespørgsler fra en udviklerkonto. Kontoen har tilgået tabeller med kundenavne, e-mailadresser, transaktionshistorik og nationale identifikationsnumre. Inden for få minutter bekræfter teamet, at udviklerens legitimationsoplysninger blev stjålet i et phishing-angreb. Eksponeringsvinduet er uklart. Angriberens hensigt er ukendt. Omfanget er stadig under afklaring.
Fristen løber nu.
Efter GDPR kan Maria have 72 timer til at anmelde hændelsen til en tilsynsmyndighed, hvis den sandsynligvis medfører en risiko for fysiske personer. Efter NIS2 kan der, hvis virksomheden er en væsentlig eller vigtig enhed, og hændelsen er betydelig, være krav om en tidlig advarsel inden for 24 timer og en formel underretning inden for 72 timer. Efter DORA kan IKT-hændelsesrapportering i den finansielle sektor og forpligtelser vedrørende digital operationel robusthed også være relevante. Kunder, forsikringsselskaber, juridiske rådgivere, topledelse og auditorer vil alle forvente svar.
Det er her, en generisk hændelseshåndteringsplan ofte ikke slår til. En malware-runbook kan beskrive isolering af hosts. En SOC-procedure kan beskrive bevaring af logfiler. Men en ISO/IEC 27701:2025-proces for håndtering af PII-brud skal under pres kunne besvare vanskeligere spørgsmål:
- Blev personoplysninger eksponeret, ændret, mistet, destrueret eller tilgået uden autorisation?
- Handler organisationen som dataansvarlig, databehandler, fælles dataansvarlig eller underdatabehandler?
- Hvornår opstod kendskab, og hvilket bevismateriale dokumenterer det?
- Kræves regulatorisk anmeldelse efter GDPR Article 33?
- Er berørte personer udsat for høj risiko efter GDPR Article 34?
- Hvis organisationen handler som databehandler, hvor hurtigt skal den dataansvarlige underrettes?
- Hvilket bevismateriale vil dokumentere beslutningen seks måneder senere under en revision?
Forskellen mellem kaos og kontrol ligger ikke i antallet af sikkerhedsværktøjer i teknologistakken. Den ligger i, om organisationen har etableret et disciplineret ledelsessystem for databeskyttelse, et PIMS, som forbinder hændelseshåndtering, databeskyttelsesgovernance, bevisstyring, leverandøreskalering og regulatorisk rapportering i én forsvarlig livscyklus.
Brudhåndtering starter, før nogen siger “brud”
Den første operationelle fejl er at antage, at håndtering af PII-brud først starter, efter Jura har bekræftet et brud på persondatasikkerheden. I praksis starter processen, når en person, et system, en leverandør eller en kunde opdager noget, der kan involvere PII.
Clarysecs Zenith Blueprint: En auditors 30-trins køreplan Zenith Blueprint placerer denne menneskelige udløser i fasen Kontroller i praksis, trin 16: personrelaterede kontroller II. Vejledningen angiver:
“Et effektivt system til hændelseshåndtering starter ikke med værktøjer, men med mennesker. Control 6.8 fremhæver betydningen af at sikre, at hver medarbejder, kontrahent eller interessent ved, hvordan en potentiel sikkerhedshændelse genkendes og rapporteres, og føler sig tryg ved og bemyndiget til at gøre det.”
Det er vigtigt, fordi mange databeskyttelseshændelser ikke først opdages af en SIEM. De starter med en supportmedarbejder, der ser en anden kundes vedhæftede fil, en lønmedarbejder, der opdager et regneark sendt til forkert modtager, en kunde, der rapporterer en anden brugers faktura, eller en leverandør, der rapporterer en mistet laptop.
Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme, afsnittet Håndhævelse og efterlevelse, klausul 8.3.1, omsætter dette til en øjeblikkelig forpligtelse:
“Alle brud på persondatasikkerheden eller mistænkte hændelser skal straks rapporteres til koordinatoren for databeskyttelse.”
For enterprise-programmer placerer Databeskyttelses- og privatlivspolitik Data Protection and Privacy Policy, afsnittet Håndhævelse og efterlevelse, klausul 8.3.2, ledelsesansvaret:
“Databeskyttelsesrådgiveren (DPO) skal lede inddæmning, analyse og eskalering af brud i overensstemmelse med ISO/IEC 27035 og GDPR Articles 33 and 34.”
Det er skiftet fra “IT undersøger det” til “PIMS-livscyklussen for brud er aktiveret.”
Det første prespunkt: hændelse, sikkerhedshændelse, databeskyttelseshændelse eller PII-brud
Klokken 02:13 har Marias team en alarm. De har endnu ikke et bekræftet anmeldelsespligtigt brud. Den første kritiske beslutning er klassificering.
Zenith Blueprint, fasen Kontroller i praksis, trin 23: organisatoriske kontroller, forklarer ISO/IEC 27002:2022 control 5.25, vurdering af og beslutning om informationssikkerhedshændelser:
“Ikke enhver anomali er en katastrofe. Ikke enhver alarm signalerer kompromittering. I praksis drukner sikkerhedsteams og forretningsenheder i støj, loginforsøg, loganomalier, mindre politikbrud og shadow IT-aktivitet. Den reelle udfordring ligger ikke kun i detektion, men i at skelne det harmløse fra det skadelige og vide, hvad der kræver eskalering.”
En livscyklus for brud på persondatasikkerheden skal gøre denne skelnen gentagelig. Den må ikke afhænge af, hvem der tilfældigvis har vagt, hvilken jurist der deltager først, eller om CISO’en er komfortabel med usikkerhed.
En praktisk Clarysec-klassificeringsmodel skelner mellem fire stadier:
| Klassificeringsstadie | Spørgsmål | Typisk ansvarlig | Krævet bevismateriale |
|---|---|---|---|
| Hændelse | Er der sket noget usædvanligt? | Helpdesk, SOC, forretningsansvarlig | Sag, rapport, alarm, e-mail, logudtræk |
| Sikkerhedshændelse | Har hændelsen truet eller kompromitteret informationssikkerheden? | Hændelseskoordinator | Hændelsessag, triagenotater, berørte systemer |
| Databeskyttelseshændelse | Kan hændelsen involvere PII eller databeskyttelsesforpligtelser? | Ansvarlig for databeskyttelse eller DPO | PII-kategorier, registrerede, behandlingsrolle |
| Bekræftet eller mistænkt PII-brud | Blev PII eksponeret, mistet, ændret, destrueret eller tilgået ulovligt eller utilsigtet? | DPO, ansvarlig for databeskyttelse, Jura, forretningsansvarlig | Risikovurdering, beslutning om anmeldelse, bevisregister |
Ordet “mistænkt” er afgørende. Clarysec anbefaler ikke at vente på fuld sikkerhed, før arbejdsgangen for brud på persondatasikkerheden åbnes. Brudregisteret bør åbnes, når et PII-brud med rimelighed mistænkes, og derefter opdateres i takt med, at fakta modnes.
Politik for håndtering af PII-hændelser og -brud PII Incident and Breach Management Policy, afsnittet Klassificering og vurdering af brud, klausul 4.2.3, kræver, at dataansvarlige dokumenterer beslutningen før ekstern handling:
“[Dataansvarlig] Databeskyttelsesrådgiveren / rådgiveren inden for databeskyttelse SKAL vurdere risikoen for berørte registrerede for hvert bekræftet eller med rimelighed mistænkt PII-brud og registrere anbefaling om anmeldelse, risikobegrundelse og rådgivning i REG10, før den eksterne beslutning om anmeldelse træffes.”
Denne klausul er den operationelle kerne i revisionsklar GDPR-respons på brud: vurder risikoen, registrér begrundelsen, indhent rådgivningen, træf beslutningen, og bevar bevismaterialet i REG10.
72-timers fristen er et bevisproblem, ikke en kalenderpåmindelse
Mange teams behandler GDPR’s 72-timers krav om anmeldelse som en deadline i en projektplan. I en reel hændelse er det vanskelige at dokumentere, hvornår kendskab opstod, hvad der var kendt på det tidspunkt, hvor hurtigt organisationen handlede, og hvorfor beslutningen om anmeldelse var rimelig.
Incident Response Policy-sme Incident Response Policy-sme, afsnittet Formål, klausul 1.2, beskriver målet:
“Denne politik gør organisationen i stand til at minimere skade, beskytte kundedata og opfylde regulatoriske forpligtelser såsom GDPR’s 72-timers krav om anmeldelse af brud på persondatasikkerheden.”
Data Protection and Privacy Policy-sme, afsnittet Håndhævelse og efterlevelse, klausul 8.3.3, angiver:
“Hvor det kræves, skal underretning til myndigheder og berørte personer ske inden for 72 timer.”
For enterprise-programmer angiver Databeskyttelses- og privatlivspolitik, afsnittet Håndhævelse og efterlevelse, klausul 8.3.3:
“Brud, der opfylder den retlige tærskel for underretning, skal anmeldes til tilsynsmyndigheder inden for 72 timer.”
Formålet er ikke at anmelde enhver anomali. Formålet er at træffe en forsvarlig beslutning hurtigt nok til, at en påkrævet anmeldelse kan ske rettidigt. Et modent PIMS anvender derfor interne frister, der er kortere end de eksterne retlige frister.
| Tid fra kendskab | PIMS-handling | Bevismateriale, der skal indsamles i REG10 |
|---|---|---|
| 0 til 4 timer | Opret registrering af PII-hændelse, tildel ansvarlig, bevar indledende bevismateriale, identificér behandlingsrolle | Modtagelsesrapport, tidspunkt for kendskab, tildelte roller, indledende systemer og involverede data |
| 4 til 12 timer | Inddæm eksponering, identificér PII-kategorier, fastlæg forpligtelser som dataansvarlig eller databehandler | Inddæmningshandlinger, berørte datatyper, rollevurdering, leverandør- eller kundeafhængigheder |
| 12 til 24 timer | Udfør foreløbig risikovurdering, og afgør om anmeldelse til tilsynsmyndighed er sandsynlig | Risikobegrundelse, sandsynlig konsekvens, usikkerhed, DPO-rådgivning, juridisk input |
| 24 til 48 timer | Udarbejd anmeldelse eller begrundelse for ikke at anmelde, koordinér kunde- eller dataansvarlig-kommunikation | Udkast til anmeldelse, beslutningslog, godkendelser, kundeunderretninger, referencer til bevismateriale |
| 48 til 72 timer | Indsend påkrævet anmeldelse, dokumentér eventuel begrundelse for forsinkelse, forbered kommunikation til personer ved høj risiko | Indsendelsesbevis, regulatorisk reference, endelig beslutning, kommunikationsplan |
| Efter 72 timer | Fortsæt undersøgelsen, opdatér tilsynsmyndigheden efter behov, underret personer hvor det kræves, afslut læringspunkter | Opfølgningsrapporter, korrigerende handlinger, godkendelse af lukning, forbedringsbacklog |
Politik for håndtering af PII-hændelser og -brud, afsnittet Underretning og kommunikation, klausul 4.4.1, gør dokumentationskravet eksplicit:
“[Dataansvarlig] Den ansvarlige for databeskyttelse / PIMS-ansvarlige SKAL udarbejde en dokumenteret regulatorisk beslutning om anmeldelse for hvert bekræftet PII-brud uden unødig forsinkelse og inden for en intern frist, der understøtter gældende eksterne anmeldelsesfrister, og SKAL opbevare anmeldelsen, begrundelsen for ikke at anmelde eller begrundelsen for forsinkelse i REG10.”
En tilsynsmyndighed kan anfægte en beslutning. En auditor kan teste, om processen blev fulgt. Men hvis organisationen kan fremvise rettidigt bevismateriale, strukturerede kriterier, DPO-rådgivning og en dokumenteret begrundelse, står den langt stærkere end et team, der siger: “Vi drøftede det på et møde.”
Dataansvarlige og databehandlere har brug for forskellige brudforløb
Moderne SaaS-virksomheder opererer ofte i mere end én databeskyttelsesrolle. Marias FinTech-platform kan være dataansvarlig for sine direkte abonnenter og databehandler for enterprise-kunder. I et andet scenarie kan en B2B-supportportal være databehandler for kunders vedhæftede sagsfiler, men dataansvarlig for egne interne supportmetadata.
Den skelnen ændrer anmeldelses- og underretningsforløbet.
| Forpligtelse | Rolle som PII-dataansvarlig | Rolle som PII-databehandler |
|---|---|---|
| Primær pligt | Over for tilsynsmyndigheden og berørte personer, hvor tærsklerne er opfyldt | Over for den berørte dataansvarlige eller kunde |
| Underretningsmodtager | Relevant tilsynsmyndighed og, ved høj risiko, berørte personer | Kunde eller dataansvarlig angivet i kontrakten |
| Udløsende forhold for underretning | Risiko for fysiske personers rettigheder og frihedsrettigheder | Kendskab til et brud, der påvirker kundens PII |
| Tidslinje | Uden unødig forsinkelse og, hvor det er muligt, inden for 72 timer efter kendskab | Uden unødig forsinkelse og inden for kontraktlige frister, ofte 24 eller 48 timer |
| Risikovurdering | Skal vurdere risikoen for personer og træffe beslutning om anmeldelse efter Article 33 og 34 | Leverer fakta, så den dataansvarlige kan vurdere risikoen |
For databehandlere angiver Politik for håndtering af PII-hændelser og -brud, afsnittet Underretning og kommunikation, klausul 4.4.4:
“[Databehandler] Den ansvarlige for databeskyttelse / PIMS-ansvarlige SKAL underrette den berørte dataansvarlige eller kunde uden unødig forsinkelse og inden for enhver gældende kontraktlig frist efter at have fået kendskab til et PII-brud, der påvirker kundens PII, og SKAL registrere indledende underretninger og opfølgende underretninger i REG08 og REG10.”
En databehandler bør ikke vente på at færdiggøre den dataansvarliges GDPR-risikoanalyse. Databehandleren skal underrette den dataansvarlige med tilgængelige fakta og levere opdateringer, mens undersøgelsen fortsætter. Den dataansvarlige træffer derefter beslutning om anmeldelse til tilsynsmyndigheden og kommunikation til berørte personer for sin behandling.
Ved høj risiko for personer skal den dataansvarlige også vurdere direkte kommunikation. Politik for håndtering af PII-hændelser og -brud, klausul 4.4.3, angiver:
“[Dataansvarlig] Den ansvarlige for databeskyttelse / PIMS-ansvarlige SKAL koordinere kommunikation til berørte registrerede, når vurderingen af bruddet identificerer høj risiko eller et tilsvarende udløsende kommunikationskrav, og SKAL registrere kommunikationens indhold, målgruppe, timing, leveringsmetode og godkendelsesbevis i REG10.”
Enterprise-versionen af Databeskyttelses- og privatlivspolitik, afsnittet Håndhævelse og efterlevelse, klausul 8.3.4, understreger dette:
“Hvis der identificeres høj risiko for personer, skal berørte registrerede underrettes uden unødig forsinkelse, medmindre en undtagelse finder anvendelse, f.eks. hvis stærk kryptering er implementeret.”
Den undtagelse skal være baseret på bevismateriale. Det er ikke nok at sige “dataene var krypterede”. Organisationen skal kunne dokumentere, at de eksponerede data var ulæselige for uautoriserede parter, og at relevante nøgler ikke var kompromitteret.
Leverandører kan afgøre de første 24 timer
Tredjeparter ligger ofte inde med de fakta, der er nødvendige for klassificering og underretning. En cloududbyder kan ligge inde med adgangslogfiler. En løndatabehandler kan vide, hvilke medarbejdere der var berørt. En managed service provider kan have udført konfigurationsændringen. En underdatabehandler kan ligge inde med forensisk telemetri.
Kontraktvilkår om leverandørers brud skal derfor være på plads før hændelsen.
Third party and supplier security policy Third party and supplier security policy, afsnittet Styringskrav, klausul 5.3.3, omfatter kontraktlig styring af:
“Tidsfrister for underretning om brud, f.eks. inden for 24 eller 72 timer, afhængigt af kritikalitet og regulatoriske krav.”
For mindre organisationer understøtter Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme tilsvarende tidsfrister for underretning om brud som led i leverandørstyring.
Clarysec anbefaler, at leverandørkontrakter og databehandleraftaler definerer:
- Hvad der udgør et mistænkt PII-brud
- Hvem der skal underrettes og gennem hvilken kanal
- Frist for indledende underretning, ofte kortere end den dataansvarliges regulatoriske frist
- Minimumsfakta, der kræves i den første underretning
- Opdateringsfrekvens under undersøgelsen
- Pligter til bevaring af bevismateriale
- Krav om videreførelse af underretningsforpligtelser til underdatabehandlere
- Støtte til kommunikation med tilsynsmyndighed og registrerede
- Forpligtelser til korrigerende handlinger efter hændelsen
Hvis leverandøraftaler bruger vage formuleringer som “så hurtigt som praktisk muligt”, kan den dataansvarliges GDPR-frist afhænge af en anden organisations interne drøftelser. Det er ikke en forsvarlig driftsmodel.
Bevismateriale gør respons til forsvarlig efterlevelse
Under Marias hændelse har teamet brug for autentifikationslogfiler, databaseforespørgselsregistreringer, phishing-bevismateriale, ændringer i adgangsstyring, lister over berørte kunder, inddæmningshandlinger, DPO-rådgivning og kommunikationsudkast. I scenariet med en B2B SaaS-portal kan teamet have brug for skærmbilleder, tilladelser til objektlagring, support-sags-id’er, IAM-ændringer og adgangslogfiler på tværs af tenants.
Bevismaterialet skal bevares korrekt. Løse skærmbilleder, chateksporter og personlige mapper er ikke tilstrækkelige.
Zenith Blueprint, fasen Kontroller i praksis, trin 23, behandler ISO/IEC 27002:2022 control 5.28, indsamling af bevismateriale:
“Når en informationssikkerhedshændelse indtræffer, er et af de mest kritiske, men ofte oversete, elementer i responsen bevismateriale. Ikke logfiler, ikke skærmbilleder, ikke løse redegørelser, men korrekt bevaret, chain of custody-respekterende og manipulationssikkert bevismateriale.”
Politik for indsamling af bevismateriale og digital efterforskning Evidence Collection and Forensics Policy, afsnittet Styringskrav, klausul 5.5, angiver:
“Alt indsamlet bevismateriale skal være entydigt identificeret, mærket og opbevaret i et sikkert repository med:”
Politik for håndtering af PII-hændelser og -brud, afsnittet Bevismateriale, registrering og fortrolighed, klausul 4.5.1, forbinder dette bevismateriale med PIMS-registreringen:
“[Begge] Hændelseskoordinatoren SKAL vedligeholde en fuldstændig REG10-registrering for hver mistænkt eller bekræftet PII-hændelse fra modtagelse til lukning, herunder fakta, timing, klassificering, vurdering, handlinger, beslutninger, underretninger, referencer til bevismateriale og lukningsstatus.”
REG10 bliver den eneste autoritative kilde for hændelsen. REG08 registrerer kunde- eller dataansvarlig-underretninger, hvor det er relevant. Sammen gør de det muligt for sikkerhed, databeskyttelse, Jura og revision at arbejde ud fra én samlet beviskæde.
| REG10-felt | Eksempelpost |
|---|---|
| Hændelses-id | PII-2026-034 |
| Tidspunkt for kendskab | 2026-06-23 02:13 UTC, SOC-alarm bekræftet |
| Behandlingsrolle | Dataansvarlig for direkte abonnenter, databehandler for enterprise-kundedatasæt |
| Involveret PII | Navne, arbejds-e-mails, transaktionshistorik, nationale identifikationsnumre |
| Indledende klassificering | Bekræftet sikkerhedshændelse med mistænkt PII-brud |
| Inddæmning | Udviklerens legitimationsoplysninger tilbagekaldt, sessioner afsluttet, berørt databaseadgang begrænset |
| Risikovurdering | Ikke-offentlige identifikatorer tilgået; risiko for identitetssvig kan ikke udelukkes |
| Beslutning om anmeldelse | Anmeldelse til tilsynsmyndighed godkendt for dataansvarliges data; enterprise-kunder underrettet som dataansvarlige |
| Referencer til bevismateriale | Auth-log E-034-01, forespørgselseksport E-034-02, phishing-artefakt E-034-03 |
| Lukning | Rodårsag udbedret, MFA-kontroller styrket, phishing-træning opdateret, kundeopfølgning afsluttet |
Formålet er ikke bureaukrati. Formålet er at forhindre organisationen i at skulle rekonstruere hukommelsen ud fra spredte Slack-beskeder, efter tilsynsmyndigheden ringer.
Kortlægning af ISO 27701 PIMS-respons til ISO 27001 og ISO 27002
En moden proces for PII-brud ligger i krydsfeltet mellem databeskyttelsesgovernance og informationssikkerhedsledelse.
ISO/IEC 27001:2022 klausul 4.1 til 4.4 kræver, at organisationer forstår kontekst, interessenter, ISMS-omfang og ledelsessystemets processer. For håndtering af PII-brud betyder det, at processen skal afspejle regulatoriske forpligtelser, kundekontrakter, behandlingsroller, leverandørafhængigheder og sektorspecifikke krav, før en hændelse indtræffer.
Zenith Controls: Vejledning til kortlægning på tværs af efterlevelseskrav Zenith Controls hjælper med at kortlægge hændelseskontroller ind i en bredere assurance-model. De mest relevante ISO/IEC 27002:2022-kontroller er:
| ISO/IEC 27002:2022-kontrol | Behandling i Zenith Controls | Hvorfor den er vigtig for håndtering af PII-brud |
|---|---|---|
| 5.24 Planlægning og forberedelse af håndtering af informationssikkerhedshændelser | Korrigerende kontrol, Respond and Recover, styring og håndtering af informationssikkerhedshændelser | Definerer planer, roller, eskalationsveje, kommunikationsskabeloner og beredskab for brud på persondatasikkerheden |
| 5.25 Vurdering af og beslutning om informationssikkerhedshændelser | Detekterende kontrol, Detect and Respond, håndtering af informationssikkerhedshændelser | Skaber det strukturerede beslutningspunkt for klassificering af databeskyttelseshændelser og mistænkte PII-brud |
| 5.26 Respons på informationssikkerhedshændelser | Korrigerende kontrol, Respond and Recover, håndtering af informationssikkerhedshændelser | Aktiverer inddæmning, koordinering, understøttelse af underretning, genopretning og kommunikation med interessenter |
| 5.28 Indsamling af bevismateriale | Bevaring af bevismateriale og forensisk pålidelighed gennem hændelsens livscyklus | Understøtter GDPR-ansvarlighed, forensisk kvalitet, spørgsmål fra tilsynsmyndigheder og revisionsmæssig forsvarlighed |
| 6.8 Rapportering af informationssikkerhedshændelser | Menneskedrevet rapporteringskanal og awareness-træning | Sikrer, at mistænkte PII-hændelser rapporteres hurtigt af medarbejdere, kontrahenter og interessenter |
ISO/IEC 27035 understøtter struktureret hændelsesstyring. ISO/IEC 27037 understøtter håndtering af digitale beviser. ISO/IEC 29134 kan understøtte logikken i konsekvensanalyser vedrørende databeskyttelse, når afhjælpning af brud viser behov for en dybere DPIA-gennemgang. ISO/IEC 27701:2025 tilfører derefter databeskyttelsesrollens kontekst, påvirkning af registrerede, forpligtelser for dataansvarlige og databehandlere samt PIMS-krav til bevismateriale ind i ledelsessystemet.
Én hændelse, mange regulatoriske vinkler
Marias hændelse er ikke kun et GDPR-spørgsmål. Fordi virksomheden leverer cloudtjenester til kunder i den finansielle sektor, kan NIS2 og DORA også finde anvendelse. Kundekontrakter kan kræve underretning inden for 24 timer. Cyberforsikring kan kræve hurtig underretning. Intern governance kan kræve rapportering til bestyrelsen.
Hvis der oprettes særskilte fortællinger for hvert rammeværk, opstår der risiko for modstrid. Clarysec-metoden er at vedligeholde én samlet beviskæde og derefter udarbejde rammeværksspecifikke leverancer på grundlag af den.
| Rammeværk eller regulering | Hændelsesvinkel | Output fra Clarysecs beviskæde |
|---|---|---|
| GDPR | Brud på persondatasikkerheden, risiko for personer, anmeldelse til tilsynsmyndighed, kommunikation til berørte personer | REG10-beslutningsregistrering, DPO-rådgivning, begrundelse efter Article 33 og 34, dokumentation for kommunikation |
| ISO/IEC 27701:2025 | PIMS-styring, pligter for dataansvarlig og databehandler, risiko for registrerede, databeskyttelsesdokumentation | Klassificering af PII-hændelse, rollevurdering, REG08 og REG10, korrigerende handlinger |
| ISO/IEC 27001:2022 | ISMS-kontekst, interessenter, hændelseshåndteringsproces, løbende forbedring | Hændelsesregistrering, opdateringer af risikobehandling, input til ledelsens evaluering, bevismateriale for kontroleffektivitet |
| NIS2 | Håndtering af betydelige hændelser, faseopdelt rapportering, sikkerhedsforanstaltninger mod alle farer | Bevismateriale for 24-timers tidlig advarsel, 72-timers hændelsesunderretningspakke, understøttelse af endelig rapport efter én måned |
| DORA | IKT-relateret hændelsesstyring for finansielle enheder og digital operationel robusthed | Fakta om IKT-påvirkning, tredjepartsafhængigheder, feedback fra robusthedstest, understøttelse af hændelsesrapportering |
| NIST CSF 2.0 | Aktuel profil og målprofil, prioriteret handlingsplan, risikokommunikation | Opdateringer af gaps, målforbedringer, risikofortælling på bestyrelsesniveau |
| COBIT 2019 | Governance, ledelsesmål, ansvarlighed, kontroludførelse | RACI, beslutningslogfiler, procesmetrikker, sporing af korrigerende handlinger |
NIS2 Article 21 fastsætter cybersikkerhedsrisikostyringsforanstaltninger, herunder hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, vurdering af effektivitet, cyberhygiejne, kryptografi, adgangsstyring, aktivstyring, MFA og sikker kommunikation. NIS2 Article 23 fastsætter faseopdelt rapportering for betydelige hændelser, herunder tidlig advarsel inden for 24 timer, hændelsesunderretning inden for 72 timer, opdateringer efter anmodning og en endelig rapport senest én måned efter hændelsesunderretningen.
DORA finder anvendelse fra 17. januar 2025 og fastsætter ensartede krav til styring af IKT-risiko, IKT-relateret hændelsesrapportering, test af digital operationel robusthed, informationsdeling og styring af IKT-tredjepartsrisiko for finansielle enheder. For en FinTech-leverandør kan én hændelse derfor samtidig være et GDPR-brud, en betydelig hændelse efter NIS2, en DORA-relevant IKT-hændelse for kunder og en kontraktlig underretningshændelse.
Hvordan auditorer tester livscyklussen
Auditorer stopper sjældent ved “vis mig jeres hændelseshåndteringspolitik.” De tester, om livscyklussen fungerer under pres på bevismaterialet.
En ISO/IEC 27701:2025- eller ISO/IEC 27001:2022-auditor vil spørge, hvordan databeskyttelseshændelser kommer ind i ISMS og PIMS, hvem der klassificerer hændelser, hvordan pligter for dataansvarlige og databehandlere adskiller sig, og hvordan hændelser fører til korrigerende handlinger.
En GDPR-auditor eller tilsynsmyndighed vil fokusere på tidspunkt for kendskab, risiko for personer, DPO-inddragelse, begrundelse for anmeldelse, kommunikation til berørte personer og ansvarlighed. De kan udtage stikprøver af hændelser, der ikke blev anmeldt, for at teste om begrundelsen for manglende anmeldelse var dokumenteret.
En NIS2- eller DORA-gennemgang vil undersøge tærskler for betydelige hændelser, faseopdelt rapportering, IKT-påvirkning, tredjepartsafhængigheder, robusthedsmæssige konsekvenser, og om rapporteringen var tilpasset den relevante kompetente myndigheds eller kundes krav.
En NIST CSF 2.0-assessor vil spørge, om hændelsen ændrede organisationens aktuelle profil og målprofil. En COBIT 2019-reviewer vil fokusere på governance, ansvarlighed, procesejerskab, metrikker og sporing af korrigerende handlinger.
En stærk revisionspakke med bevismateriale bør omfatte:
| Bevismateriale | Hvorfor auditorer efterspørger det |
|---|---|
| REG10-hændelsesregistrering | Dokumenterer modtagelse, timing, klassificering, vurdering, beslutninger, underretninger og lukning |
| REG08-registrering af kunde- eller dataansvarlig-underretning | Dokumenterer databehandlerkommunikation og historik over kundeopdateringer |
| Oprindelig rapport eller alarm | Fastlægger, hvordan hændelsen blev opdaget, og hvornår kendskab begyndte |
| Tidslinje over centrale handlinger | Viser inddæmning, vurdering, godkendelser og beslutninger om anmeldelse |
| Vurdering af behandlingsrolle | Dokumenterer adskillelse af pligter for dataansvarlig og databehandler |
| PII-kategorier og berørte registrerede | Understøtter risikovurdering og omfanget af underretning |
| Anbefaling fra DPO eller rådgiver inden for databeskyttelse | Dokumenterer ansvarlig databeskyttelsesrådgivning før ekstern beslutning |
| Anmeldelse eller begrundelse for ikke at anmelde | Understøtter ansvarlighed efter GDPR Article 33 og 34 |
| Indeks over repository for bevismateriale | Dokumenterer bevismaterialets integritet og disciplineret chain of custody |
| Rodårsag og plan for korrigerende handlinger | Viser løbende forbedring og evaluering af kontroleffektivitet |
Det er her, Zenith Controls har kommerciel og operationel værdi. Det hjælper med at kortlægge det samme bevismateriale til ISO/IEC 27002:2022-hændelseskontroller, GDPR-ansvarlighed, NIS2-hændelseshåndtering, DORA-forventninger til robusthed, NIST CSF-kommunikation og COBIT-governance uden at genopbygge revisionsfortællingen hver gang.
En driftsrytme for de første 24 timer
En realistisk playbook for PII-brud skal være praktisk, ikke teoretisk. Overvej en SaaS-eksponering på tværs af tenants, som rapporteres af en kunde kl. 08:12.
Kl. 08:12 modtager customer success-teamet rapporten og følger rapporteringsadfærden fra Zenith Blueprint trin 16. Sagen tagges som en mistænkt PII-hændelse.
Kl. 08:25 åbner hændelseskoordinatoren REG10. Registreringen omfatter tidspunkt for kendskab, rapportør, system, mistænkte datatyper og ansvarlig.
Kl. 09:02 tilbageruller engineering-teamet ændringen i tilladelser. Logfiler eksporteres før rotation. Bevisforvalteren mærker kunderapporten, IAM-ændringen, eksporten af adgangslogfiler og bekræftelsen på inddæmning i det sikre repository.
Kl. 10:30 fastlægger den ansvarlige for databeskyttelse, at organisationen handler som databehandler for kundesupportvedhæftninger. Efter Politik for håndtering af PII-hændelser og -brud, klausul 4.4.4, skal berørte kunder, der er dataansvarlige, underrettes uden unødig forsinkelse og inden for kontraktlige frister. REG08 åbnes.
Kl. 12:00 vurderer DPO’en risikoen for registrerede. Dataene ser begrænsede ud, men nogle vedhæftede filer kan indeholde medarbejdernavne og interne id’er. DPO’en registrerer risikobegrundelsen og anbefalingen i REG10.
Kl. 15:00 modtager berørte kunder, der er dataansvarlige, den indledende underretning: hvad der skete, hvornår det blev opdaget, hvad der er inddæmmet, hvilke PII der kan være involveret, hvad der stadig analyseres, og hvornår næste opdatering kommer.
Kl. 18:00 modtager ledelsen en kort briefing: kundeunderretninger er sendt, beslutninger om anmeldelse til tilsynsmyndighed tilhører de dataansvarlige for kundens PII, intern behandling som dataansvarlig vurderes stadig, bevismateriale er bevaret, og rodårsagsanalyse er i gang.
Denne rytme forebygger de mest almindelige brudsvigt: overskredne frister, uklare roller, udokumenteret rådgivning og ukontrolleret kommunikation.
Almindelige fejlmønstre, der skal fjernes før næste alarm
De mest skadelige svigt i håndteringen af brud på persondatasikkerheden skyldes sjældent ét manglende dokument. De skyldes brudflader mellem sikkerhed, databeskyttelse, Jura, leverandører og forretningsansvarlige.
Clarysec ser ofte disse mønstre:
- Hændelseshåndteringsplaner findes, men klassificering af PII-brud mangler.
- GDPR 72-timers anmeldelse nævnes, men interne frister er ikke kortere end den retlige frist.
- Eskalering som databehandler forsinkes, fordi teams venter på fuldstændig rodårsagsanalyse.
- Leverandørkontrakter kræver ikke hurtig underretning om brud eller støtte til bevismateriale.
- DPO-rådgivning gives mundtligt og indføres aldrig i brudregisteret.
- Kommunikation til personer ved høj risiko overvejes for sent.
- Bevismateriale opbevares i personlige mapper, chattråde eller sagskommentarer.
- Beslutninger om ikke at anmelde dokumenteres ikke.
- Læringspunkter opdaterer ikke kontroller, træning, leverandørklausuler eller risikobehandlingsplaner.
Zenith Blueprint, trin 23, indfanger, hvorfor struktur er vigtig:
“Hændelseshåndtering uden struktur bliver til improviseret brandslukning. E-mails sendes, møder indkaldes, og beslutninger træffes følelsesbetonet eller inkonsistent. Men et modent ISMS gør respons til disciplin.”
Den disciplin er formålet med ISO/IEC 27701:2025-håndtering af PII-brud.
Opbyg Clarysecs livscyklus for PII-brud
Clarysecs tilgang kombinerer tre lag.
For det første leverer Zenith Blueprint implementeringskøreplanen. Trin 16 sikrer, at personer genkender og rapporterer mistænkte hændelser. Trin 23 operationaliserer vurdering, beslutning, respons og indsamling af bevismateriale gennem ISO/IEC 27002:2022-kontrollerne 5.25, 5.26 og 5.28.
For det andet definerer politikbiblioteket beføjelser og forpligtelser. SME-politikker gør rapportering, 72-timers kendskab og hændelsesregistre praktiske for mindre organisationer. Enterprise-politikker tildeler DPO-ledelse, brudtærskler, kommunikation til berørte personer, vilkår for leverandørunderretning, håndtering af bevismateriale og forensisk styring. Den PIMS-specifikke Politik for håndtering af PII-hændelser og -brud tilføjer rollebaserede pligter for dataansvarlige og databehandlere, REG08, REG10, begrundelse for anmeldelse og lukningsbevis.
For det tredje fungerer Zenith Controls som kompas på tværs af efterlevelseskrav. Det kortlægger hændelsesplanlægning, vurdering, respons og bevismateriale til et samlet billede på tværs af ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST CSF 2.0 og COBIT-lignende assurance-forventninger.
For CISO’er reducerer dette operationel uklarhed. For DPO’er skaber det et forsvarligt beslutningsspor for databeskyttelse. For compliance-ansvarlige forbinder det én hændelsesregistrering med flere regulatoriske leverancer. For auditorer skaber det sporbar dokumentation. For topledelsen reducerer det risikoen for, at en håndterbar databeskyttelseshændelse bliver til en regulatorisk og omdømmemæssig krise.
Dit næste skridt
Vent ikke på alarmen klokken 02:00 for at opdage, om jeres proces for PII-brud virker.
Start i denne uge med tre handlinger:
- Gennemgå, om jeres modtagelse af hændelser eksplicit registrerer mistænkte PII-hændelser.
- Bekræft, at pligter ved brud for dataansvarlige og databehandlere er adskilt i politikker, kontrakter og registre over bevismateriale.
- Gennemfør en tabletop-øvelse med et realistisk scenarie, f.eks. kompromitterede legitimationsoplysninger, eksponering på tværs af tenants, en lønfil sendt til forkert modtager, en mistet krypteret laptop eller en leverandørkompromittering.
Clarysec kan hjælpe jer med at operationalisere dette gennem Zenith Blueprint: En auditors 30-trins køreplan Zenith Blueprint, Zenith Controls: Vejledning til kortlægning på tværs af efterlevelseskrav Zenith Controls og ISO/IEC 27701:2025 PIMS-politiksættet, herunder Politik for håndtering af PII-hændelser og -brud PII Incident and Breach Management Policy, Databeskyttelses- og privatlivspolitik Data Protection and Privacy Policy, Incident Response Policy-sme Incident Response Policy-sme, Third party and supplier security policy Third party and supplier security policy og Politik for indsamling af bevismateriale og digital efterforskning Evidence Collection and Forensics Policy.
Download Clarysec PIMS-værktøjspakken, book en vurdering af brudberedskab, eller planlæg en demo for at gøre jeres GDPR 72-timers respons fra improviseret brandslukning til en disciplineret, revisionsklar proces.
Bliv PECB ISO/IEC 27701-certificeret og etablér dit PIMS
- ✓ Officielt PECB-kursusmateriale og to eksamensforsøg
- ✓ Certificeringsgebyr og første års AMF inkluderet, hvor relevant
- ✓ Selvstudium eller live online · kurset tildeles inden for 1 hverdag
Om forfatteren

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council