En IP-adresse kan være en personopplysning selv om virksomheten ikke kjenner navnet på brukeren. Det avgjørende er om adressen, alene eller sammen med andre opplysninger og relevante identifikasjonsmuligheter, kan knyttes til en fysisk person. Den praktiske oppgaven er å undersøke hvor adressen behandles, hva den kobles til, og hvorfor hvert ledd trenger den.
Personvernforordningen artikkel 4 og fortalepunkt 26 gir rammen for identifiserbarhet. Datatilsynets veiledning om dynamiske IP-adresser viser at også slike adresser kan omfattes. En teknisk betegnelse som «nettverksdata» er ikke en egen kategori som står utenfor personvernreglene.
Hva IP-adressen forteller og ikke forteller
En IP-adresse brukes i nettverkskommunikasjon. Den er ikke i seg selv en sikker identifikasjon av personen som utførte en handling. Flere personer kan dele en tilkobling, og en person kan bruke ulike adresser over tid. Proxyer, virksomhetsnettverk og andre tekniske mellomledd kan påvirke hvilken adresse tjenesten registrerer.
Dette begrenser hvilke slutninger virksomheten kan trekke, men gjør ikke automatisk opplysningen anonym. Et innlogget nettsted kan knytte IP-adressen til en konto. En arbeidsgiver kan ha tilgang til interne tilordninger og tidslogger. En nettleverandør kan ha andre relevante opplysninger. Vurderingen må derfor omfatte sammenhengen adressen inngår i.
Skill også mellom abonnent, enhet og faktisk bruker. En adresse som kan knyttes til et abonnement, beviser ikke nødvendigvis hvem i husstanden som brukte forbindelsen. Hvis adressen brukes i en sikkerhetssak eller kundevurdering, må usikkerheten bevares i dokumentasjonen. Kravet om riktige personopplysninger gjelder også tekniske slutninger.
Hva Breyer-dommen bidrar med
I Breyer-saken, C-582/14, vurderte EU-domstolen dynamiske IP-adresser registrert av en nettstedstilbyder når internettleverandøren hadde tilleggsopplysninger som kunne identifisere brukeren. Domstolens offisielle omtale av avgjørelsen fra 19. oktober 2016 forklarer betydningen av rettslige midler til å få identifikasjonen gjennomført ved hjelp av slike opplysninger.
Dommen innebærer ikke at enhver nettstedseier har en generell direkte rett til å få navn fra enhver internettleverandør. Identifikasjonsmuligheten må vurderes konkret. Saken gjaldt det tidligere personverndirektivet; ved dagens arbeid brukes GDPRs definisjon og vurdering av rimelig sannsynlige identifikasjonsmidler.
For et norsk prosjekt er den praktiske lærdommen at «vi har ikke navn i loggen» er en utilstrekkelig konklusjon. Undersøk hvilke koblinger virksomheten eller andre relevante aktører kan bruke lovlig og realistisk. Samtidig skal vurderingen ikke bygge på enhver rent teoretisk mulighet som er uten praktisk betydning.
Finn alle punktene der adressen behandles
Start med nettleserens eller appens forbindelse og følg den gjennom løsningen. Adressen kan behandles av en nettverksleverandør, en mellomliggende tjeneste, nettstedets server, et sikkerhetsverktøy og en analysetjeneste. Noen systemer mottar adressen kortvarig for kommunikasjon, mens andre lagrer den i logger eller knytter den til en profil.
Systemkartleggingen bør derfor vise mer enn hovedapplikasjonen. Be den tekniske eieren beskrive hvilke komponenter som lagrer full adresse, hvilke som forkorter eller erstatter den, og hvilke mottakere som kan få eksport. Kontroller også innstillinger for feilrapportering og støtte; de kan samle informasjon som ikke vises i standardrapporten.
En tenkt nettbutikk kan bruke følgende oversikt som utgangspunkt:
| Punkt | Opplysning og kobling | Arbeidsbeslutning |
|---|---|---|
| Nettverks- og sikkerhetsledd | Adresse, tidspunkt og tekniske hendelser | Dokumenter nødvendig sikkerhetsbruk og tilgang |
| Innloggingslogg | Adresse knyttet til kundekonto og innlogging | Skill sikkerhetsformålet fra markedsføring |
| Besøksstatistikk | Sidevisning og tekniske identifikatorer | Undersøk om full adresse trengs eller kan fjernes tidlig |
| Feilrapport | Adresse og mulig innhold fra forespørselen | Fjern unødvendige kundeopplysninger fra rapporteringen |
| Støtteeksport | Utvalgte hendelser fra en konkret sak | Begrens tidsrom, mottakere og videre lagring |
Tabellen dokumenterer spørsmål som må løses. Den gir ingen automatisk godkjenning av de beskrevne behandlingene. Hvert punkt trenger et reelt formål og en eier som kan forklare både innsamling og avslutning.
Hold fire vurderinger atskilt
Først kommer spørsmålet om personopplysninger. Deretter må virksomheten vurdere behandlingsgrunnlag og øvrige GDPR-plikter. I tillegg kan regler om lagring av eller tilgang til opplysninger på brukerens utstyr være relevante. Hvis personopplysninger overføres til et tredjeland, oppstår også en egen overføringsvurdering.
At IP-adressen er nødvendig for en nettverksforbindelse, betyr ikke at langvarig lagring for enhver senere analyse er nødvendig. På samme måte innebærer det at en behandling inneholder personopplysninger, ikke at samtykke alltid er eneste mulige grunnlag. Bruk metoden for behandlingsgrunnlag på det konkrete formålet.
Vurder norske regler om cookies og lignende teknologier ut fra den faktiske utstyrstilgangen, ikke bare om løsningen bruker en fil kalt cookie. Et verktøy kan ha flere funksjoner med ulike vurderinger. En generell påstand om at «IP er lovlig» besvarer ingen av disse spørsmålene alene.
Skill sikkerhetslogging fra analyse og profilering
Sikkerhetslogging kan ha behov for å oppdage misbruk, undersøke hendelser og beskytte tjenesten. Definer hvilke hendelser som skal undersøkes og hvilke opplysninger dette krever. Begrens deretter tilgang og lagring til formålet. En konkret rutine for sikkerhetslogger gjør det mulig å kontrollere sammenhengen mellom behov og data.
Besøksstatistikk kan ofte ha andre informasjonsbehov enn hendelsesundersøkelse. Spør om et aggregat eller mindre detaljer er tilstrekkelig for den planlagte beslutningen. Hvis data fra sikkerhetsloggen senere brukes til markedsføringsprofiler, må den nye bruken vurderes særskilt. Den opprinnelige sikkerhetsbegrunnelsen kan ikke bare overføres til et annet formål.
Ved ansatte er det særlig viktig at tekniske logger ikke uten videre tas i bruk som produktivitetsmåling. En adresse med mange hendelser sier ikke alene hvor mye en person arbeider eller hvem som faktisk utførte handlingene. Formålsendring, arbeidsrettslige rammer og personvern må vurderes før slik bruk.
Kontroller hva forkorting og hashing oppnår
Forkorting av en adresse kan redusere detaljnivået, men dere må undersøke når det skjer og hvilke andre identifikatorer som beholdes. Dersom full adresse allerede er sendt til en ekstern mottaker, endrer ikke senere forkorting det som ble overført. Dersom konto-ID eller en stabil sporingskode fortsatt følger hendelsen, kan brukeren fremdeles være identifiserbar.
Hashing gir heller ikke automatisk anonymitet. Verdier kan være gjettbare, og stabile hasher kan koble hendelser over tid. Beskriv metoden, tilgang til eventuelle hemmeligheter og hva mottakeren ellers vet. Pseudonymisering med kontrollert kobling er et mer presist begrep når løsningen fortsatt bygger på en identitetskobling som beskyttes.
En anonymitetskonklusjon bør gjelde et avgrenset datasett i en bestemt sammenheng. Dokumenter hvilke identifikatorer som er fjernet, hvilke koblinger som er vurdert og hvilke forutsetninger konklusjonen bygger på. Kontroller vurderingen på nytt hvis dere legger til nye felter eller endrer mottaker.
Avtal lagring og gi forståelig informasjon
Det finnes ikke én generell GDPR-frist for alle IP-logger. Bestem lagring ut fra det dokumenterte formålet og relevante øvrige krav. Skill vanlig løpende logg fra et avgrenset uttrekk som må undersøkes i en konkret hendelse. Et uttrekk bør ha egen eier og en planlagt vurdering av videre behov.
Personverninformasjonen bør forklare relevante formål, kategorier, mottakere, lagring og rettigheter på en måte brukeren kan forstå. «Tekniske data» kan være for lite presist hvis adressen kobles til konto eller brukes i profilering. Sørg for at teksten stemmer med den faktiske tjenesten og leverandørkjeden.
Avslutt gjennomgangen med dokumenterte innstillinger og en representativ kontroll: hvilke adresser mottas, hvor lagres de, når reduseres detaljene og hvem kan hente dem ut? Registrer begrensninger og nødvendige endringer. Da får virksomheten et konkret beslutningsgrunnlag for IP-behandlingen, fremfor et generelt ja eller nei som overser den aktuelle dataflyten.
Ved en rettighetsforespørsel må virksomheten vurdere om oppgitte opplysninger er tilstrekkelige til å finne relevante data og kontrollere hvem forespørselen gjelder. En IP-adresse alene kan være delt eller endret, og bør ikke ukritisk brukes som identitetsbevis. Samtidig skal ikke virksomheten avvise et krav bare fordi personen ikke kjenner en intern logg-ID. Undersøk hvilke avgrensede opplysninger som faktisk trengs, for eksempel et relevant tidspunkt eller en allerede autentisert konto.
Vær varsom med å sende hele logglinjer tilbake. De kan inneholde andre brukeres opplysninger, interne tekniske detaljer eller sikkerhetsrelevant informasjon. Lag et forståelig og nødvendig uttrekk etter en konkret vurdering, og dokumenter hvordan mulige tredjepartsopplysninger ble håndtert.