Gå til innhold
Legiscope
Meny
Personvern

Fødselsnummer: dokumenter behovet for sikker identifisering

Vurder nødvendigheten av fødselsnummer etter personopplysningsloven § 12, med konkrete alternativer og kontroll av innsamlingen.

Fødselsnummer brukes til å identifisere personer i mange norske arbeidsprosesser, men virksomheten skal kunne forklare hvorfor hele nummeret er nødvendig i akkurat den aktuelle behandlingen. At et system har et felt for fødselsnummer, eller at en leverandør ønsker en entydig nøkkel, avgjør ikke spørsmålet. Begynn med identifikasjonsbehovet og vurder hvilke opplysninger som faktisk trengs for å løse det.

Personopplysningsloven § 12 setter et særskilt vilkår for bruk av fødselsnummer og andre entydige identifikasjonsmidler: det må foreligge et saklig behov for sikker identifisering, og metoden må være nødvendig for slik identifisering. Fødselsnummer er ikke i seg selv en særlig kategori etter artikkel 9, men det betyr ikke at bruken er fri. Datatilsynet forklarer denne avgrensningen og gir eksempler på sin side om fødselsnummer.

Denne veiledningen gir en arbeidsmåte for å dokumentere vurderingen, endre unødvendige dataflyter og kontrollere at en begrensning faktisk virker. Den supplerer vurderingen av behandlingsgrunnlag, sikkerhet og øvrige plikter etter GDPR. Den særnorske identifikasjonsregelen erstatter ikke disse kravene, og en generell begrunnelse for kundebehandling er ikke alene et svar på om hele fødselsnummeret er nødvendig.

Skill identifikasjon fra autentisering

Identifikasjon handler om hvilken person en opplysning eller sak gjelder. Autentisering handler om å kontrollere at den som opptrer, faktisk er den vedkommende utgir seg for å være. Et fødselsnummer kan bidra til å skille mellom personer, men kjennskap til nummeret er ikke alene en sikker kontroll av hvem som ringer eller logger inn.

Kartlegg hvor virksomheten bruker nummeret til disse forskjellige formålene. Hvis kundestøtte bruker det som eneste «hemmelige» kontrollspørsmål, bør prosessen vurderes på nytt. En person kan kjenne andres nummer uten å ha rett til opplysningene. Se også passordpolicy og kontogjenoppretting for hvordan identitetskontroll må inngå i hele tilgangsprosessen.

Beskriv den konkrete arbeidsoppgaven

Skriv én setning om hva virksomheten skal gjøre: rapportere en opplysning til en bestemt mottaker, koble en sak til riktig person eller administrere et medlemskap. Unngå samleformål som «kundeadministrasjon og sikkerhet» når de dekker forskjellige handlinger. Den som vurderer nødvendighet, må forstå hva som mislykkes dersom fødselsnummeret ikke brukes.

Beskriv også konsekvensen av feil identifikasjon. Det kan være at opplysninger havner på feil person, at en rapportering avvises eller at en tjeneste gis på uriktig grunnlag. Vurder sannsynlighet og betydning med kjennskap til den faktiske prosessen. At navn kan være like, er et utgangspunkt for analysen, men ikke automatisk en begrunnelse for å samle fødselsnummer fra alle.

Undersøk mindre omfattende alternativer

Vurder om en intern kundereferanse, navn sammen med andre relevante opplysninger eller en kontroll i en etablert kanal kan løse behovet. Alternativet må være egnet til formålet, ikke bare teoretisk mulig. Dokumenter hvorfor det fungerer eller hvorfor det ikke gir tilstrekkelig sikker identifisering i den konkrete situasjonen.

Vurder dessuten om nummeret bare trengs i ett trinn. En opplysning kan være nødvendig ved en bestemt innrapportering uten å måtte vises på alle kundeskjermer eller følge med i hver eksport. Dataminimering i skjema og systemer hjelper med å skille innsamling, visning, bruk og videreformidling. Hver av disse handlingene kan ha forskjellige nødvendighetsvurderinger.

Arbeidsark for vurdering etter § 12

Felt Hva virksomheten bør dokumentere
Oppgave Den konkrete behandlingen og ønsket resultat
Identifikasjonsbehov Hvorfor riktig person må identifiseres sikkert
Feilkonsekvens Hva en forveksling kan føre til
Alternativer Opplysninger eller metoder som er undersøkt
Nødvendighet Hvorfor fødselsnummer trengs, eller kan fjernes
Avgrensning Hvilke personer, systemer og handlinger som omfattes
Grunnlag Behandlingsgrunnlag og eventuell konkret plikt
Sikkerhet Tilgang, visning, overføring og kontroll
Oppbevaring Når behovet opphører og hvordan kopier håndteres
Beslutning Eier, dato, konklusjon og videre tiltak

Arbeidsarket er et forslag til dokumentasjon, ikke et skjema fra Datatilsynet. Det bør være forståelig for både fagansvarlig og teknisk drift. Dersom begrunnelsen viser til et lovkrav, oppgi den konkrete bestemmelsen og hvilken oppgave den krever. «Lovpålagt» uten nærmere identifikasjon gjør det vanskelig å kontrollere om alle de aktuelle bruksområdene faktisk omfattes.

Finn hvor nummeret er kopiert

Kartlegg hovedsystem, rapporter, regneark, integrasjoner og utskrifter. Ta med feillogger, supportsaker og tidligere eksportmapper. Fødselsnummer kan ha blitt valgt som intern koblingsnøkkel lenge før virksomheten vurderte dagens personvernbehov. Det kan derfor finnes i tekniske felt som ikke vises i vanlig brukergrensesnitt.

Bruk systemoversikten til å finne eiere og avhengigheter. Spør leverandøren hva som skjer hvis feltet fjernes eller erstattes. En endring i hovedskjemaet er utilstrekkelig dersom en integrasjon fortsatt sender nummeret til et analyseverktøy. Samtidig må en nødvendig endring planlegges slik at legitime oppgaver og datakvalitet ikke ødelegges.

Lag en avgrenset tilgangsmodell

Gi tilgang etter arbeidsoppgave. En saksbehandler kan trenge å se hele nummeret ved en bestemt kontroll, mens andre roller bare trenger intern referanse. Vurder maskering i skjermbildet og en kontrollert måte å vise full verdi når det er nødvendig. Husk at maskering i grensesnittet ikke hjelper hvis samme bruker fritt kan eksportere hele feltet.

Kontroller også søk, utskrift, varsler og kopiering. Et system kan begrense visning i kundekortet, men sende full verdi i et automatisk e-postvarsel. Beskriv derfor hvilke handlinger rollen tillater, ikke bare hvilke menyer som er synlige. Bevar nok spor til å undersøke urettmessig bruk uten å skrive selve nummeret inn i alle sikkerhetslogger.

Hypotetisk eksempel: medlemsregisteret ber om fødselsnummer

En tenkt forening bruker et standardregister der fødselsnummer er obligatorisk. Fagansvarlig beskriver at formålet er å skille medlemmer og kontakte dem om aktiviteter. Gruppen undersøker om en intern medlemsreferanse og nødvendige kontaktopplysninger løser dette. Den finner ingen konkret oppgave i den aktuelle medlemsprosessen som krever fullt fødselsnummer.

Foreningen endrer skjemaet, avklarer importformatet og går gjennom tidligere kopier. Den lager en kontrollert plan for håndtering av eksisterende nummer og kontrollerer at nye registreringer fungerer. Hvis foreningen også har en separat rapporteringsoppgave med et dokumentert behov, vurderes denne for seg. Eksemplet viser hvorfor én organisasjon kan komme til ulike konklusjoner for forskjellige behandlinger.

Endringen følges opp hos leverandøren. Testmiljø og supporteksporter omfattes av gjennomgangen, slik at feltet ikke gjeninnføres ved neste import. Foreningen dokumenterer begrunnelsen og hva som faktisk er endret. Den registrerer ikke bare at «GDPR er gjennomgått», men kan vise hvilken unødvendig innsamling som opphørte.

Håndter henvendelser og identitetskontroll

Når noen ber om innsyn eller retting, må virksomheten sikre at opplysninger gis til riktig person. Dette gir ikke automatisk grunn til å kreve fødselsnummer i alle henvendelser. Vurder om identiteten allerede er tilstrekkelig avklart gjennom den etablerte kontakten, og be bare om ytterligere opplysninger når det er nødvendig i situasjonen.

Bruk innsynsretten etter artikkel 15 som ramme for selve rettighetsarbeidet. Dersom ekstra verifisering gjennomføres, bør dokumentasjonen vise metode og resultat uten at alle innhentede identitetsopplysninger beholdes unødvendig. En ny kopi av et identitetsdokument kan kreve egen tilgangs- og oppbevaringsvurdering og bør ikke bli liggende i en vanlig saksmappe av vane.

Avklar deling med databehandler og andre mottakere

Beskriv hvorfor en mottaker trenger fødselsnummer, hvilke oppgaver mottakeren utfører og i hvilken rolle. En databehandler trenger bare opplysninger som inngår i det dokumenterte oppdraget. Hvis leverandøren ønsker nummeret til egne formål, må rolle og grunnlag vurderes særskilt. Et teknisk krav i et importformat dokumenterer ikke alene nødvendigheten.

Knytt instrukser til den aktuelle databehandleravtalen. Oppgi om full verdi kan brukes i support, om den skal maskeres i testmiljø og hvilke eksporter som er tillatt. For andre mottakere må virksomheten kunne forklare delingen på selvstendig grunnlag. Det er ikke tilstrekkelig at begge parter allerede kjenner personens nummer.

Gjør oppbevaring og endring kontrollerbar

Fastsett hvor lenge behovet varer for hver behandling. Skill mellom nummer i et aktivt register og opplysninger som må bevares i avgrenset dokumentasjon av en konkret oppgave. En oppbevaringsplikt for en dokumenttype kan ikke uten videre brukes som begrunnelse for at alle kopier i alle systemer skal være fritt tilgjengelige like lenge.

Bruk lagringsbegrensning til å planlegge sletting eller annen nødvendig håndtering. Hvis et system er avhengig av fødselsnummer som teknisk nøkkel, må migreringen bevare riktige sammenhenger uten å spre nummeret til nye steder. Kontroller et relevant utvalg etter endringen, blant annet relasjoner mellom poster, eksport og søk.

Kontroller løsningen med realistiske arbeidsoppgaver

La en vanlig bruker registrere en ny person, finne en eksisterende sak og lage en nødvendig rapport. Kontroller hvilke felter som vises og eksporteres. La deretter en autorisert kontrollrolle gjennomføre oppgaven som eventuelt krever full verdi. Forskjellen mellom rollene bør være dokumentert og synlig i praksis.

Undersøk hva som skjer ved feilregistrering. En korrigering må ikke knytte tidligere opplysninger til feil person eller skape en duplikat som senere gir misvisende svar. Registrer hvordan opplysninger blir rettet i tilknyttede systemer. Behovet for sikker identifisering omfatter også endringer og feil, ikke bare førstegangsinnsamling.

Oppdater vurderingen når prosessen endres

En ny integrasjon, rapporteringsmottaker eller selvbetjeningsløsning kan endre nødvendighetsbildet. Angi derfor hvem som skal varsles når nye bruksområder foreslås. Den tidligere konklusjonen gjelder den beskrevne behandlingen og bør ikke brukes som en generell tillatelse til all fremtidig bruk av nummeret.

Resultatet bør være en konkret beslutning: hvor fødselsnummer er nødvendig, hvor et mindre omfattende alternativ skal brukes, og hvordan begge deler kontrolleres. Samle vurderingen og gjennomføringsbeviset i virksomhetens dokumentasjon. Det gjør det mulig å forklare både det særnorske vilkåret etter § 12 og hvordan valget følges i den faktiske driften.

Forklar valget i informasjonen til brukeren

Når fødselsnummer skal samles inn, bør informasjonen forklare den konkrete oppgaven det brukes til, sammen med øvrig relevant personverninformasjon. Unngå å presentere et felt som valgfritt dersom tjenesten i praksis avviser brukeren uten nummeret. Hvis det finnes et reelt alternativ, må brukeren forstå hvordan dette benyttes og hvilke praktiske følger det har. La fagansvarlig kontrollere teksten mot systemets oppførsel. En tydelig forklaring reduserer misforståelser, men gjør ikke en ellers unødvendig innsamling lovlig; nødvendighetsvurderingen må være på plass først.

L
Skrevet av
Legiscope
Legiscope

Sett veiledningen ut i praksis

Se hvordan Legiscope kobler personvernregistre, kildemateriale og kontrollert arbeid.

Bestill en tilpasset demo
Les videre

Relaterte artikler

01Personvern

AI Act-programvare 2026: verktøy for etterlevelse av KI-forordningen

AI Act-programvare kan organisere oversikt, vurderinger og dokumentasjon av KI-systemer. For en norsk virksomhet må valg av verktøy bygge på konkrete roller og bruksområder, samtidig som EU-frister…

4. juli 2026
02Personvern

Anonymisering: vurder om opplysninger fortsatt kan knyttes til personer

Anonymisering skal gjøre det slik at opplysninger ikke lenger kan knyttes til en identifiserbar person med midler som med rimelighet kan tenkes brukt. Å fjerne navn er ofte utilstrekkelig. Datoer,…

8. september 2026
03Personvern

Ansvarlighet i personvernarbeidet: dokumenter at tiltak virker

Ansvarlighet i personvernarbeidet betyr at virksomheten både skal følge reglene og kunne vise hvordan den gjør det. Dokumentasjonen bør knytte et konkret formål og en beslutning til faktisk…

8. september 2026
04Personvern

Arbeidsgivers innsyn i e-post: beslutning, varsel og protokoll

Før en arbeidsgiver åpner en ansatts e-postkasse, bør virksomheten kunne vise hvorfor innsyn er nødvendig, hvilke mindre inngripende alternativer som er vurdert, og hvordan den ansattes rettigheter…

8. september 2026
05Personvern

Artikkel 14: informer når opplysninger kommer fra andre

Når virksomheten får personopplysninger fra en samarbeidspartner, et offentlig register eller en kjøpt kontaktliste, har personen vanligvis ikke sett innsamlingsskjemaet deres. Informasjonsplikten…

8. september 2026
06Personvern

Automatiserte avgjørelser: identifiser terskelen i artikkel 22

Artikkel 22 i GDPR oppstiller som utgangspunkt et forbud mot visse automatiserte avgjørelser. Virksomheten må identifisere en avgjørelse, undersøke om den utelukkende bygger på automatisert…

8. september 2026
07Personvern

Avslutte databehandler: tilbakelevering og slettebekreftelse

Når en databehandleravtale avsluttes, må virksomheten vite hvor personopplysningene ender. Oppsigelse av abonnementet er ikke det samme som tilbakelevering eller sletting. En konto kan være stengt…

8. september 2026
08Personvern

Avvik og brudd på personopplysningssikkerheten (art. 33-34): 72-timersfristen 2026

Et brudd på personopplysningssikkerheten skal meldes til Datatilsynet uten ugrunnet opphold og senest innen 72 timer etter at den behandlingsansvarlige ble kjent med bruddet, med mindre bruddet…

4. juli 2026