Håndtering af databrud: flowchart og 72-timers fristen i GDPR

Hvad er håndtering af databrud: flowchart og 72-timers fristen i gdpr?

Et brud på persondatasikkerheden er ethvert sikkerhedssvigt, der fører til, at personoplysninger bliver tilintetgjort, mistet, ændret, videregivet eller tilgået uden bemyndigelse, uanset om det sker ved et uheld eller med vilje. De fleste af dem er ikke cyberangreb. Det er en mail sendt til den forkerte modtager, et regneark med den skjulte fane i behold, en bærbar glemt i toget, et fildrev åbnet for alle, en backup, der viser sig ikke at kunne gendannes. Processen herunder udløses af en mistanke frem for en bekræftet konstatering, fordi det lovbestemte ur begynder at løbe, når organisationen bliver bekendt med, at der kan være sket et brud, ikke når undersøgelsen er færdig.

Dette er bevidst ikke en proces for håndtering af sikkerhedshændelser. Detektion, forensics, bevissikring, udrensning og verifikation af, at systemerne er rene, hører til dér og ejes af sikkerhedsafdelingen; her optræder de som ét inddæmningstrin og en overlevering af afhjælpningen tilbage til IT-sikkerhed. Er bruddet et cyberangreb, så kør begge: den tekniske håndtering genetablerer og sikrer miljøet, mens dette diagram kører ved siden af på sin egen frist og svarer på et andet spørgsmål: hvem skal have besked, hvornår, og hvad skriver I ned, hvis svaret er ingen. Det er heller ikke it-incident management, som er færdig, når driften er tilbage, og ikke processen for indsigtsanmodninger, som handler om, at borgere beder om deres egne oplysninger, frem for at organisationen mister dem.

To beslutninger bærer den juridiske vægt, og de bliver rutinemæssigt forvekslet. Anmeldelse til tilsynsmyndigheden er udgangspunktet efter GDPR: det er påkrævet, medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Underretning af de berørte personer er en separat og højere test, som kun gælder, når bruddet sandsynligvis vil indebære en høj risiko for dem. Et brud kan sagtens være anmeldelsespligtigt uden nogensinde at blive kommunikeret til de mennesker, det handler om. Det tredje, teams overser, er, at begge grene mødes: hvert eneste brud skal i den interne fortegnelse (også dem, I beslutter ikke at anmelde) sammen med begrundelsen for den beslutning.

Hvad dette flowchart dækker

I denne skabelon

• Fem rollebaner med en ejer på hvert trin (opdager / indberetter, IT-sikkerhed, DPO, juridisk og kommunikation) fordelt på fem fasekolonner: Indberetning, Vurdering og inddæmning, Anmeldelsesbeslutning, Anmeldelse samt Registrering og evaluering.
• Indberetningsfasen: 'Muligt databrud opdaget' og 'Indberet via kanalen for databrud' i indberetterens bane, hvorefter IT-sikkerhed kører 'Registrér indberetning og start tidslinjen', som fastlægger netop det tidspunkt, 72-timers fristen løber fra.
• Indledende vurdering og inddæmning i IT-sikkerhedsbanen, efterfulgt af beslutningen 'Er der personoplysninger involveret?' hos DPO'en, hvis nej-gren lukker sagen som ren sikkerhedshændelse i stedet for at trække den gennem hele det regulatoriske spor.
• 'Vurder alvor og risiko for de registrerede' i DPO-banen, hvorefter juridisk kører 'Afklar gældende anmeldelsespligter', før beslutningen 'Skal bruddet anmeldes til tilsynet?'.
• Den anmeldelsespligtige gren kører 'Udarbejd anmeldelse med juridisk gennemgang' og 'Anmeld til tilsynet inden 72 timer'; den ikke-anmeldelsespligtige gren kører i stedet 'Dokumentér begrundelsen for ikke at anmelde', så beslutningen er dokumenteret uanset udfald.
• En separat beslutning, 'Høj risiko for de registrerede?', der sender kommunikation videre til at udarbejde og sende en underretning til de berørte, og derefter en indførsel i fortegnelsen, som begge grene når frem til, afhjælpende tiltag hos IT-sikkerhed, en evaluering efter bruddet og lukning.

Hvornår du skal bruge skabelonen

• I skriver eller opdaterer en procedure for brud på persondatasikkerheden og har brug for én side, der viser, hvem der vurderer, hvem der beslutter, og hvem der anmelder.
• I vil have afklaret anmeldelsespligten på forhånd, så ingen klokken 17 om fredagen diskuterer, om uret overhovedet er begyndt at løbe.
• I kører en databruds-øvelse og vil teste hele 72-timers forløbet fra ende til anden, inklusive de udarbejdelses- og godkendelsestrin, der bruger størstedelen af tiden.
• I underviser medarbejdere i, hvad de skal indberette og hvor, for det første skridt i næsten alle rigtige databrud er, at en helt almindelig medarbejder bemærker noget.
• En auditor eller en kunde har bedt jer fremvise en dokumenteret databrudsprocedure (diagrammet dokumenterer proceduren, men beviser ikke i sig selv compliance).

Sådan fungerer det

1. Navngiv rollerne og indberetningskanalen

   Erstat de fem baner med de roller, I reelt har. Mindre organisationer har ofte ingen DPO og lægger banen sammen med juridisk eller en privacy-ansvarlig; andre tilføjer en ekstern advokat eller en cyberforsikring som egen bane. Læg derefter den faktiske indberetningsvej ind i trinnet 'Indberet via kanalen for databrud': én postkasse, én formular, ét telefonnummer, og en regel om, at man indberetter på mistanke i stedet for at undersøge først.

2. Fastlæg jeres myndigheder og jeres frister

   Ret trinnet 'Afklar gældende anmeldelsespligter', så det navngiver den eller de tilsynsmyndigheder, der gælder for jer (i Danmark Datatilsynet), jeres ledende tilsynsmyndighed, hvis I opererer på tværs af grænser, og eventuelle branchespecifikke regimer som NIS2 eller DORA. De regimer kører andre ure, så skriv hvert enkelt ned frem for at gå ud fra, at 72 timer dækker det hele. Tilføj også kontraktlige varslingsfrister over for kunder, som ofte er kortere end de lovbestemte.

3. Skriv jeres risikokriterier ned

   Kobl jeres egne kriterier på 'Vurder alvor og risiko for de registrerede': oplysningernes type og følsomhed, antallet af personer og registreringer, hvor let personerne kan identificeres, om data var krypteret eller på anden måde ubrugelige, om nogen af de registrerede er sårbare, samt skadens alvor og sandsynlighed. Kriterier, der er skrevet på forhånd, er det, der gør de to beslutninger forsvarlige bagefter.

4. Placér de to beslutninger og godkendelsen

   Skriv på diagrammet, hvem der ejer 'Skal bruddet anmeldes til tilsynet?' og 'Høj risiko for de registrerede?', hvem der må godkende selve anmeldelsen til tilsynsmyndigheden, og hvem der kan godkende ordlyden, der sendes til de registrerede. Tilføj en stedfortræder for hver. Databrud venter ikke på, at nogen kommer hjem fra ferie.

5. Sæt interne delfrister inden for de 72 timer

   Regn baglæns fra fristen, og sæt måltider på de mellemliggende trin: hvornår DPO'en skal have vurderingen, hvornår udkastet skal være hos juridisk, hvornår godkendelsen lukker. Den lovbestemte frist er yderkanten, ikke planen, og det er i udarbejdelsen og godkendelsen, timerne reelt forsvinder.

6. Peg registreringstrinnet mod jeres rigtige fortegnelse, og versionér diagrammet

   Kobl 'Før bruddet i fortegnelsen' til den log, I faktisk fører, og list de felter, den skal indeholde: de faktiske omstændigheder ved bruddet, dets virkninger, de afhjælpende tiltag og begrundelsen for hver anmeldelsesbeslutning, også de negative. Send derefter diagrammet til godkendelse hos DPO, juridisk, IT-sikkerhed og kommunikation, og gem den godkendte version, så den procedure, I øver, er den, I udgiver.

Ofte stillede spørgsmål

Hvornår begynder 72-timers fristen at løbe?

Efter GDPR skal en dataansvarlig anmelde et brud til tilsynsmyndigheden uden unødig forsinkelse og om muligt senest 72 timer efter at være blevet bekendt med, at der er sket et brud på persondatasikkerheden. At være bekendt betyder at have en rimelig grad af sikkerhed for, at en sikkerhedshændelse har kompromitteret personoplysninger, så en kort indledende verifikation accepteres, men I kan ikke udskyde uret ved at forlænge undersøgelsen. De 72 timer er kalendertimer, ikke arbejdstimer: weekender og helligdage ligger inden for vinduet. Derfor lægger dette diagram 'Registrér indberetning og start tidslinjen' helt fremme og noterer, hvem der indberettede hvad, og hvornår.

Hvad er forskellen på at anmelde til tilsynet og at underrette de registrerede?

Det er to forskellige tests med forskellige tærskler, og derfor tegner diagrammet dem som to beslutninger frem for én. Tilsynsmyndigheden skal underrettes, medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Anmeldelse er altså reelt udgangspunktet. De berørte personer skal kun underrettes, når bruddet sandsynligvis vil indebære en høj risiko for dem, og der findes anerkendte undtagelser, for eksempel hvis data var krypteret og fortsat er uforståelige, eller hvis I efterfølgende har truffet foranstaltninger, der gør, at den høje risiko ikke længere er sandsynlig. Et brud kan derfor godt anmeldes til tilsynet uden nogensinde at blive kommunikeret til de mennesker, det handler om.

Skal vi stadig registrere et brud, vi har besluttet ikke at anmelde?

Ja. GDPR kræver, at dataansvarlige dokumenterer ethvert brud på persondatasikkerheden (de faktiske omstændigheder, virkningerne og de afhjælpende tiltag), uanset om det blev anmeldt. I praksis er registreringen af et brud, I valgte ikke at anmelde, den vigtigste af de to, for den er det eneste bevis på, at beslutningen var begrundet frem for bekvem. Derfor kører grenen 'Anmeldes ikke' i dette diagram gennem 'Dokumentér begrundelsen for ikke at anmelde', og begge grene mødes i fortegnelsen.

Hvordan adskiller det sig fra en proces for håndtering af sikkerhedshændelser?

En proces for håndtering af sikkerhedshændelser handler om angriberen og miljøet: detektér, triagér, sikr spor, inddæm, rens ud, verificér at systemerne er rene, genetablér driften. Denne proces handler om de mennesker, hvis oplysninger blev berørt, og de forpligtelser, der følger, og den udløses af ethvert brud på persondatasikkerheden, også dem uden en angriber overhovedet, som en fejlsendt mail eller en backup, der ikke kan gendannes. De to overlapper ved inddæmningen og ved anmeldelsesgrenen, og ved en cyberhændelse kører I dem parallelt med sikkerhedsafdelingen som ejer af det tekniske spor og DPO'en som ejer af dette.

Hvad hvis vi er databehandler og ikke dataansvarlig?

En databehandler anmelder hverken til tilsynsmyndigheden eller underretter de registrerede. Databehandleren skal underrette den dataansvarlige uden unødig forsinkelse efter at være blevet bekendt med et brud på persondatasikkerheden, hvorefter den dataansvarlige kører vurderingen og begge anmeldelsesbeslutninger. Er det jeres situation, så skær diagrammet af ved beslutningen 'Skal bruddet anmeldes til tilsynet?', erstat den med jeres underretning til den dataansvarlige, og tjek jeres kontrakter: databehandleraftaler fastsætter ofte en fast intern frist, der er betydeligt kortere end den dataansvarliges 72 timer.