Sikkerhed og beredskab ved persondatabrud
Driftsprocedure, der skal øves. Den erstatter ikke en juridisk vurdering. Enhver faktisk hændelse dokumenteres, også når den vurderes ikke at være anmeldelsespligtig.
Sikkerhedsmål
Tilsynlog beskytter fortrolighed, integritet og tilgængelighed. Foranstaltningerne skal være risikobaserede og svare til den kørende produktion.
| Område | Nuværende produktgrundlag | Skal dokumenteres før bred alpha |
|---|---|---|
| Kundeadskillelse | Kundedata er afgrænset pr. virksomhed, og roller begrænser adgangen | Periodisk adgangsreview |
| Login og adgang | Personlige konti, roller og begrænsning af loginforsøg. Tofaktorlogin bruges i Tilsynlogs backoffice | Proces ved offboarding af platformpersonale og gennemgang af nødadgang |
| Platformens adgang til kundedata | Når Tilsynlog-teamet åbner en kundes post i backoffice eller vælger en aktiv kunde, logges person, kunde, tidspunkt og begrundelse. Kunden kan se loggen under Indstillinger → Jeres data | Månedlig stikprøve af loggen |
| Dokumenter og fotos | Privat lager. Filer hentes kun efter login eller via installatørens personlige, tidsbegrænsede link. Metadata (fx GPS-position) fjernes fra uploadede fotos | Sikker sletning ved ophør |
| Infrastruktur | Drift på egen infrastruktur med krypterede forbindelser | Patchplan, firewall, fysisk adgang og konfigurationsstyring |
| Backup | Daglig backup med kontrolsummer og kryptering, når backup flyttes fra serveren | Offsite-lokation, nøgleopbevaring og en dokumenteret gendannelsestest |
| Logfiler | Driftslogfiler opbevares i en begrænset periode og slettes løbende | Den endelige opbevaringsperiode dokumenteres |
| Opbevaring | Personoplysninger slettes eller pseudonymiseres efter de valgte frister | Endelige frister besluttes (se databehandleraftalens bilag C.4) |
| Leverandør til nødvendige driftsmails | DPA, domænebeskyttelse, bounce-håndtering og minimalt indhold | |
| Løbende vedligehold | Sikkerhed og driftsprocedurer gennemgås før ændringer tages i brug | Reviewproces, afhængighedsopdateringer og scanning før release |
Hvad er et muligt brud?
Et brud kan være uautoriseret adgang, fejludsendt e-mail, tabt eller fejlændret data, ransomware, manglende adgang til nødvendige data eller et dokumentlink sendt til en forkert modtager. Hændelsen behøver ikke være et angreb for at være et brud.
Første reaktion
- Stop og afgræns: Luk eller tilbagekald adgang, roter kompromitterede nøgler, stop udsendelser eller isolér den berørte komponent. Bevar spor og overskriv ikke logge.
- Registrér straks i backoffice under Platform → Sikkerhedshændelser: tidspunkt for opdagelse, hvem der opdagede hændelsen, berørte systemer og kunder, mulige data og midlertidige tiltag.
- Vurdér: Er fortrolighed, integritet eller tilgængelighed påvirket? Hvilke dataansvarlige og personer kan være berørt? Er data kommet til uvedkommendes kendskab?
- Underret: Hvis Tilsynlog er databehandler, underrettes den relevante dataansvarlige uden unødig forsinkelse med de kendte fakta. Hvis Tilsynlog selv er dataansvarlig, håndteres vurderingen internt.
- Ret og lær: Gendan sikkert, luk årsagen, dokumentér beslutninger og følg op med forebyggende tiltag.
Tidslinje og ansvar
| Tid | Ansvarlig | Handling |
|---|---|---|
| Straks | Den, der opdager hændelsen | Stop/afgræns, kontakt [beredskabskontakt], start hændelseslog |
| Hurtigst muligt | Teknisk ansvarlig | Bekræft omfang, bevar beviser, foreslå afhjælpning |
| Uden unødig forsinkelse | Databeskyttelsesansvarlig | Underret dataansvarlig, hvis Tilsynlog er databehandler |
| Senest inden 72 timer fra kendskab | Dataansvarlig | Vurder og, hvor påkrævet, anmeld til Datatilsynet. Fristen gælder den dataansvarlige og må ikke bruges som ventetid. |
| Efter hændelsen | Produktejer og teknisk ansvarlig | Dokumentér årsag, konsekvens, beslutning og forbedringer |
Ved høj risiko for registreredes rettigheder kan den dataansvarlige også skulle underrette de berørte personer. Tilsynlog må ikke selv træffe den juridiske afgørelse på kundens vegne uden aftalt instruks, men skal levere oplysningerne hurtigt.
Hændelseslog — minimumsfelter
- Sags-id, dato/tid for opdagelse og dato/tid for afgrænsning
- Anmelder og teknisk ansvarlig
- Hændelsestype og berørte systemer
- Berørte dataansvarlige, registrerede og datakategorier
- Fortrolighed/integritet/tilgængelighed og foreløbig risikovurdering
- Underretninger, tidspunkt, modtager og beslutning om anmeldelse
- Afhjælpning, rotéring/patch, gendannelse og efterkontrol
- Godkendelse og læringspunkter
Anmodning om sletning eller indsigt
- Kontrollér, hvem personen er, og hvilken kunde (dataansvarlig) oplysningerne hører til. Er Tilsynlog databehandler, videresendes anmodningen til kunden, som beslutter.
- Indsigt og dataportabilitet: Kundens driftsansvarlige kan selv hente alle data som zip-fil under Indstillinger → Jeres data.
- Sletning: Efter kundens instruks fjerner Tilsynlog navn og kontaktoplysninger på brugeren, i fejlmeldinger og modtagerlister, lukker adgangen og logger handlingen, som kunden kan se. Kontroller, fejl og elsikkerhedssager bevares uden navnet. Backup udløber efter sin rullende periode.
- Svar personen inden for én måned.
Øvelse
Proceduren afprøves mindst årligt og før bred lancering med et realistisk scenarie, fx forkert sendt installatørmail eller mistet administratoradgang. Øvelsen registreres i backoffice som en sikkerhedshændelse med markeringen "Det er en øvelse", med tid til afgrænsning og forbedringer.
Kilder: Datatilsynet om behandlingssikkerhed og Datatilsynet om håndtering af brud.