Risikovurdering: læsning af personoplysninger logges ikke pr. bruger
| Felt | Værdi |
|---|---|
| Kontrolområde | NIS2 art. 21, stk. 2, litra i (adgangskontrol) |
| Version | 1.0 |
| Senest opdateret | 2026-09-28 |
| Restrisiko | Middel |
Foranstaltning
Når en bruger læser personoplysninger i platformen, registreres læsningen ikke som en selvstændig hændelse med bruger-id. Kørsler logges derimod med bruger, tidspunkt, input og output.
Begrundelse
Platformen logger det, brugere gør, når de kører agents, men ikke hver visning af en side eller et resultat. Login registreres kun som et API-kald i applikationsloggen, uden bruger-id, jf. Dataflow, afsnit 7.
Risiko og restrisiko
Risiko: Misbrug af adgangen til at læse personoplysninger, fx af en intern bruger hos kunden, kan ikke efterfølgende dokumenteres ud fra en læselog pr. bruger.
Restrisiko: middel. Kørsler og ændringer kan spores til en bruger, men ren læsning kan ikke.
Kompenserende foranstaltninger
- Kørsler logges med bruger, tidspunkt, input og output, så det kan dokumenteres, hvem der har kørt hvad og med hvilke data.
- Administrative handlinger logges i auditsporet.
- Rollebaseret adgangskontrol med team-isolation begrænser, hvem der overhovedet kan se en given kørsel.
- syv.ai's medarbejdere logger ikke ind på produktionsservere eller databasen i den daglige drift.
- Kørselshistorik slettes automatisk efter den opbevaringsperiode, kunden har valgt (standard 6 måneder).
Hvorfor restrisikoen er acceptabel
De handlinger, der ændrer data eller udløser behandling, kan spores. Manglen gælder rent læsende adgang, som kunden begrænser med roller og teams. Det er en kendt begrænsning, som kunden kan tage med i sin egen DPIA, jf. DPIA-skabelonen.
Genvurdering
Vurderingen tages op igen, hvis en kunde stiller krav om læselog, eller hvis platformen får en sådan funktion.