Privacy notice
Versjon: 2026-07-29
Last Updated: 2026-07-29
Personvernerklæring for Firmaradar
Denne personvernerklæringen forklarer hvilke personopplysninger Firmaradar behandler, hvorfor vi behandler dem, hvor opplysningene kommer fra, og hvilke rettigheter du har.
Språk: Dette dokumentet er utstedt på norsk. Enhver oversettelse — utført av menneske eller maskin/AI — er kun veiledende; den norske originalen er den autoritative versjonen.
Erklæringen gjelder for:
- besøkende på portalen
- kontaktpersoner hos kunder og potensielle kunder
- registrerte portalbrukere
- personer som fremkommer i eier- og selskapsdata som gjøres tilgjengelig i tjenesten
Rettighetskilder i kortform: GDPR art. 13 og 14 regulerer informasjon til registrerte, art. 28 regulerer databehandleravtaler, art. 32 informasjonssikkerhet, og art. 44 flg. overføring ut av EØS. Se Lovdata/GDPR og EUR-Lex. For eierdata viser vi også til Skatteetatens Aksjonærregister og BRREG åpne data.
1. Behandlingsansvarlig
| Felt | Verdi |
|---|---|
| Juridisk selskapsnavn | Firmaradar AS |
| Organisasjonsnummer | 937 724 187 |
| Postadresse | Fredbos vei 76, 1383 Asker |
| Kontakt for personvernhenvendelser | personvern@firmaradar.no |
Verdiene over er også eksponert i portalens runtime-konfigurasjon
(portal_settings.privacy_*) og vises på den offentlige
personvern-siden, slik at endringer kun trenger å skje ett sted.
Hvor avtaler eller særskilt informasjon utpeker en annen behandlingsansvarlig, gjelder den utpekingen i stedet for denne tabellen.
2. Hvilke opplysninger vi behandler
2.1 Portalbrukere og kundeansvarlige
- navn
- e-postadresse
- passordhash
- rolle og tilganger i portalen
- tilknyttet kundeprofil
- innloggings- og sikkerhetsdata
- API-nøkler og nøkkelmetadata
- bruks- og aktivitetslogger
- meldinger sendt via kontakt- og supportsider
- audit-spor over hvilke person-profiler en bruker har slått opp
(tabellen
person_profile_access_log— oppslagstidspunkt, bruker-id, formålskode og pseudonymisert nøkkel). Audit-sporet håndhever dagsgrenser, oppdager misbruk og leverer innsynsrett ved DSAR.
2.2 Selskaps- og eierdata
Portalen gjør tilgjengelig selskaps- og eierinformasjon hentet fra åpne og lovlige kilder:
- foretaksnavn og organisasjonsnummer (ikke personopplysning for juridiske personer)
- konsern- og strukturinformasjon
- eierandeler og aksjeantall
- navn på eiere
- opplysninger om juridiske personer som eiere
- opplysninger om fysiske personer som eiere — navn, fødselsår, poststed, landkode og en pseudonymisert personidentifikator (se § 2.3)
For brukere som ikke er logget inn, viser portalen ikke slike data utover eventuelle aggregerte antall.
2.3 Pseudonymiserte personidentifikatorer
Når vi lagrer en fysisk person fra eier- eller rolledata, genererer
vi en pseudonymisert identifikator som brukes til å koble rader på
tvers av tabeller (owner_person_key i aksjeeierboken,
role_person_id for BRREG-roller). Identifikatoren beregnes med
HMAC-SHA256 hvor nøkkelen er et internt hemmelig sekret
(FIELD_ENCRYPTION_KEY) som ikke er en del av databasen.
Konsekvenser:
- Identifikatorene er konsistente på tvers av lagring slik at samme person gjenkjennes mellom selskap, snapshots og rolledata.
- Identifikatorene kan ikke regenereres ut fra en databasekopi alene — den hemmelige nøkkelen må også være kjent. Dette tilfredsstiller GDPR artikkel 4(5) sin definisjon av pseudonymisering: tilleggsinformasjonen som kreves for å koble en identifikator til en person, lagres adskilt fra de pseudonymiserte dataene og er underlagt tekniske og organisatoriske tiltak.
- For fysiske personer i aksjeeierboken inngår fødselsår i identifikatoren slik at to ulike personer med samme navn ikke får samme identifikator.
2.4 Utledede relasjoner til politisk eksponerte personer
Hvitvaskingsloven § 2 bokstav g, som gjennomfører fjerde hvitvaskingsdirektiv artikkel 3 nr. 11, pålegger rapporteringspliktige å identifisere ikke bare politisk eksponerte personer (PEP), men også deres nære familiemedlemmer og kjente medarbeidere. For å gjøre våre kunder i stand til å oppfylle denne plikten, utleder vi slike relasjoner og lagrer dem som egne oppføringer.
Dette er en slutning vi selv gjør — ikke en offentlig listeføring. Ingen myndighet har ført disse personene opp noe sted. En oppføring betyr at vi, ut fra kildene under, har kommet til at en navngitt privatperson etter all sannsynlighet er nærstående til en politisk eksponert person. Vi skiller dette uttrykkelig fra oppføringer på offentlige sanksjons- og PEP-lister, både i vår egen database og i enhver leveranse til kunde.
Hvilke opplysninger. Navn og normalisert navnform, eventuelle alias, fødselsår der kilden oppgir det, land, hvilken type relasjon det gjelder (forelder, ektefelle, barn, barns ektefelle, søsken eller forretningsmessig medarbeider), hvilken politisk eksponert person relasjonen gjelder, og om relasjonen anses aktiv eller historisk. Vi registrerer ikke øvrige opplysninger om den nærstående.
Hvor opplysningene kommer fra. Familierelasjoner utledes av Wikidatas offentlig tilgjengelige strukturerte data. Medarbeider- relasjoner utledes av offentlige eier- og rolleopplysninger fra Brønnøysundregistrene og aksjeeierbøker, ved at vi identifiserer personer som deler eierskap eller styreverv med en politisk eksponert person over gitte terskler. Sammenstillingen og slutningen er vår.
Om lovens avgrensning. Loven nevner ektefelle eller likestilt samboer, barn, barns ektefelle eller samboer, og foreldre. Søsken er ikke nevnt. Vi tar likevel med søsken som et tilleggssignal, og merker dem uttrykkelig som utenfor lovens definisjon slik at kunden kan vekte dem deretter. Der fødselsår mangler, kan oppføringen bare knyttes til deg på navn alene, og også dette merkes.
Behandlingsgrunnlag. Berettiget interesse etter artikkel 6 nr. 1 bokstav f: å forebygge hvitvasking og økonomisk kriminalitet og sette rapporteringspliktige i stand til å oppfylle sine lovpålagte plikter. Vi har vurdert at denne interessen ikke overstyres av dine interesser, blant annet fordi opplysningene er avgrenset til det relasjonen gjelder, fordi de er merket som slutninger og ikke som konstateringer, og fordi de ikke i seg selv utløser noen avgjørelse. Du kan når som helst protestere mot behandlingen etter artikkel 21.
Hvem opplysningene deles med. Kun kunder som uttrykkelig har bedt om det, og som er koblet på av oss etter en egen vurdering. De leveres i så fall som en egen, tydelig merket liste, atskilt fra oppføringer på offentlige lister, der hver rad bærer et merke om at den er utledet, og der leveransen innledes med et forbehold om at radene er grunnlag for manuell vurdering og ikke en konstatering.
Retting og sletting. Mener du at en relasjon er uriktig, retter eller sletter vi den, og leveransemekanismen er innrettet slik at rettelsen også slår gjennom hos kunder som allerede har mottatt opplysningen. Se § 12 om hvordan du tar kontakt.
Om individuell varsling (artikkel 14 nr. 5 bokstav b). Per 29. juli 2026 omfatter dette i størrelsesorden 170 000 personer, i all hovedsak utenfor Norge, og vi har ingen kontaktopplysninger til dem. Å varsle hver enkelt ville derfor kreve en uforholdsmessig innsats i lovens forstand. Vi påberoper oss unntaket i artikkel 14 nr. 5 bokstav b, og gjør — som det kompenserende tiltaket bestemmelsen krever — denne informasjonen offentlig tilgjengelig her, sammen med et åpent skjema for innsyn, retting og sletting som ikke krever at du er kunde hos oss.
3. Hvor opplysningene kommer fra
Opplysningene vi behandler kommer fra ulike kilder:
- fra deg eller din virksomhet ved opprettelse og bruk av konto
- fra vår interne administrasjon av kundeforhold og tilganger
- fra åpne offentlige kilder, herunder Brønnøysundregistrene
- fra aksjeeierbøker eller andre lovlig tilgjengelige kilder for eierinformasjon
- fra tekniske logger som oppstår når portalen brukes
- fra slutninger vi selv gjør ved å sammenstille flere av kildene over — se § 2.4 om utledede relasjoner til politisk eksponerte personer. Slike opplysninger er ikke hentet fra et register; de er vår vurdering, og merkes som det.
Når vi behandler personopplysninger som ikke er innhentet direkte fra den registrerte (typisk fra offentlige registre eller aksjeeierbøker), oppfyller vi informasjonsplikten i tråd med GDPR artikkel 14 og de unntakene som eventuelt gjelder. I praksis gis generell informasjon her og i portalen; individuell direktevarsling kan være uforholdsmessig når opplysningene kommer fra offentlig tilgjengelige kilder og gjelder mange personer i selskaps- og eierdata.
For utledede relasjoner til politisk eksponerte personer gjelder en egen vurdering, fordi opplysningen der ikke stammer fra et offentlig register, men er vår egen slutning. Se § 2.4.
4. Formål med behandlingen
Vi behandler personopplysninger for å:
- levere portaltilgang og autentisering
- administrere brukere, roller, kundetilganger og API-nøkler
- gjøre selskaps- og eierdata tilgjengelig i henhold til tjenestens formål og kundens avtalte tilgangsnivå
- tilby søk, nedlastinger, API-funksjonalitet og overvåkningstjenester
- føre logger for sikkerhet, misbruksforebygging, feilsøking og dokumentasjon
- håndtere kundehenvendelser, support og prisforespørsler
- oppfylle rettslige forpliktelser og ivareta våre legitime interesser
5. Behandlingsgrunnlag
Vi behandler personopplysninger på ett eller flere av følgende grunnlag (GDPR artikkel 6):
- Avtale — når behandlingen er nødvendig for å oppfylle en avtale med kunden eller gjennomføre tiltak før avtaleinngåelse
- Rettslig forpliktelse — når behandlingen er nødvendig for å oppfylle en rettslig forpliktelse
- Berettiget interesse — for sikker drift, tilgangskontroll, dokumentasjon, misbruksforebygging og levering av en tjeneste for søk i selskaps- og eierdata fra lovlige kilder
For eier- og selskapsdata i portalen er behandlingsgrunnlaget normalt ikke samtykke, men en vurdering av berettiget interesse og nødvendighet, kombinert med tilgangsstyring og dataminimering.
5.1 Mindreårige
Personer som ifølge fødselsåret er under 18 år maskeres automatisk i
person-profil-visningene. Profilen vises kun for super-admin og kun
mot eksplisitt formålsbekreftelse; oppslaget logges med koden
minor_with_admin_override i audit-sporet. Vanlige portalbrukere får
HTTP 403 og en henvisning om å kontakte support hvis tilgang er
nødvendig.
Tiltaket gjenspeiler GDPR artikkel 8 og prinsippet om særlig vern for barn.
6. Hvem vi deler opplysninger med
Vi deler personopplysninger bare når det er nødvendig og lovlig. Opplysninger kan deles med:
- leverandører av drift, hosting, e-post og teknisk infrastruktur (databehandlere / sub-prosessorer; se § 7)
- interne administratorer eller personer med tjenstlig behov
- kunder og brukere med tilgang til de datasettene deres avtale og rettighetsnivå åpner for
- offentlige myndigheter når vi er rettslig forpliktet til det
Der andre behandler personopplysninger på våre vegne, skal det foreligge databehandleravtale der loven krever det.
7. Sub-prosessorer
Følgende sub-prosessorer kan behandle personopplysninger på våre vegne. Listen oppdateres ved endring; vesentlige endringer varsles til kunder etter databehandleravtalen.
Geografisk fotavtrykk i korthet: Kjerne- og portaldata (Aksjeeierboken, BRREG-roller og øvrige offentlige register-/kildedata) er fysisk lagret i Norge hos Gigahost. Eksterne leverandører er hovedsakelig EU/EØS-baserte. Cloudflare, Stripe og Microsoft kan ha konsern- eller edge-behandling utenfor EØS; dette skal dekkes av SCC, Data Privacy Framework der aktuelt, og Transfer Impact Assessment.
| Tjeneste | Formål | Type personopplysninger | Land / region | Overføringsgrunnlag |
|---|---|---|---|---|
| Fiken AS | Forhåndsbetaling med faktura og regnskapsintegrasjon for kunder | OAuth-tokens, regnskapsmetadata for kundens egne data, faktura-PII (navn, adresse, e-post) | Norge | Norsk databehandler (ingen overføring ut av EØS). Signert DPA tilgjengelig på fiken.no/bruker/avtaler (krever innlogget Fiken-konto). |
| Gigahost AS | Hosting av produksjons-server (web, agent, PostgreSQL og transaksjonell e-post via egen Postfix). All persistert PII er fysisk lagret her. | All persistert PII, e-postadresse og meldingsmetadata for transaksjonell e-post | Norge | Norsk databehandler. Signert DPA arkivert 2026-06-24 (se DPA-arkivet). |
| Stripe Payments Europe Ltd. | Kortbetaling for abonnement og marketplace. Aktuelt kun for kunder som velger å betale med kort. | Navn, e-post, betalingsmetadata (kortdata håndteres av Stripe, ikke av oss) | Irland (med konsernbehandling i USA) | EU-databehandler; konserntilknyttede overføringer dekket av Stripes EU-SCC og Data Privacy Framework |
| Microsoft Ireland Operations Ltd. (Office 365 / Exchange Online) | DMARC-rapportpostboks og Microsoft Graph-lesing; ikke ordinær transaksjonell e-post i normal drift. | Mailboksmetadata og DMARC-rapportinnhold | Irland (med global infrastruktur) | EU-databehandler; tredjelandsoverføringer dekket av Microsofts EU-SCC og DPF |
| Mullvad VPN AB | Aktiv, bærende VPN-egress-infrastruktur for teknisk innhenting mot eksterne offentlige kilder (bl.a. finansielle data og sanksjons-/PEP-sourcing). Kun nett-egress; ingen kunde-PII overføres. | IP-trafikk-metadata; ingen kunde-PII overføres via VPN | Sverige | Ren nett-egress/transitt — ikke databehandler (ingen DPA nødvendig) |
| Cloudflare, Inc. | CDN, DDoS-beskyttelse og WAF foran portalen. Kun transit; persistert data forblir hos Gigahost i Norge. | IP-adresser, request-metadata i transit | USA (global edge) | EU-SCC + Data Privacy Framework |
| Brønnøysundregistrene (BRREG) | Henting av offentlig selskaps- og rolledata; ikke en databehandler-relasjon. | Vi sender ingen PII til BRREG | Norge | Offentlig kilde |
Kundens valg ved betaling: Der kunden har valgfrihet mellom betalingsmetoder, kan kunden velge basert på sitt eget personverntilfang. DPA-status for faktiske databehandlere skal være arkivert i DPA-oversikten før signert produksjonslaunch.
Når vi henter inn en ny sub-prosessor som behandler personopplysninger, oppdateres tabellen og databehandleravtalen før behandlingen starter.
8. Tilgangsstyring og synlighet i portalen
Vi bruker rolle- og tilgangsstyring for å begrense hvilke data som vises for hvilke brukere:
- Uinnloggede brukere skal ikke få innsyn i personrelaterte eierdata utover eventuelle aggregerte antall.
- Innloggede brukere får bare tilgang til data som følger av kontoens rettigheter og kundens avtale.
- Utvidet tilgang til full eierskapsoversikt, CSV-uttrekk og API-funksjoner gis særskilt.
8.1 Support- og feilsøkingstilgang (impersonering)
For support og feilsøking kan en autorisert Firmaradar-administrator midlertidig se og betjene portalen som din bruker («test som bruker»). Slik tilgang:
- gis kun av en super-administrator og krever en dokumentert begrunnelse;
- er tidsbegrenset (som standard 30 minutter) og kan når som helst avsluttes;
- logges særskilt i en uforanderlig revisjonslogg (hvem, for hvem, når, fra hvilken pseudonymisert IP og hvorfor), oppbevart i minst 365 dager;
- attribueres administratoren — ikke deg — i alle bruks-, sikkerhets- og faktureringslogger;
- medfører ingen betaling, kjøp, kreditt-/kvotetrekk eller endring av abonnementet ditt;
- varsles til deg og selskapets administrator per e-post og som melding i portalen når økten avsluttes, med tidspunkt, varighet og begrunnelse, slik at du kan ta kontakt dersom tilgangen var uventet;
- påvirker ikke din egen innlogging (du logges ikke ut).
Modusen er som standard avslått og aktiveres kun ved reelt supportbehov.
9. Lagringstid
Vi lagrer personopplysninger så lenge det er nødvendig for formålene de ble samlet inn for, med mindre lengre lagring følger av lov eller dokumenterte behov.
Lagringstidene håndheves teknisk via en sentral retention-policy som
kjøres daglig (kl 03:00 UTC). Tabellen retention_policy i databasen
er den autoritative kilden — utdraget under er en menneskelesbar
speiling av den.
| Datasett (tabell) | Lagringstid | Hjemmel/begrunnelse |
|---|---|---|
Aksjeeier-historikk (aksjeeierbok_holding) |
7 år (2555 dager) | Skatteloven § 8-2, regnskapsloven |
Søkelogg (portal_search_event) |
180 dager | Drift, sikkerhet, antimisbruk |
Request-innsikt (portal_request_insight) |
180 dager | Drift, sikkerhet, antimisbruk |
Person-rolleindeks (role_person_index) |
90 dager etter sist sett | BRREG-rollecache, dataminimering |
Revokerte API-nøkler (portal_api_key) |
30 dager etter revoke | Drift, sporbarhet ved misbruk |
IP-adresse ved registrering (external_portal_user.signup_ip) |
90 dager (anonymiseres, raden beholdes) | Sikkerhet, antimisbruk |
Person-profil-audit (person_profile_access_log) |
365 dager | GDPR art. 32 — sikkerhetsmessige tiltak, misbruksdeteksjon |
API-/MCP-audit (api_call_audit) |
60 måneder | Kunde-/partneraudit, sikkerhet og tvisteløsning |
AML/PEP-screeningbevis (aml_check_audit) |
60 måneder | Konservativt etter hvitvaskingsloven § 30, jurist bekrefter C3 |
AML-rapport/jobbartefakter (aml_rapport) |
5 år der rapporten brukes som AML-dokumentasjon; ellers kortere teknisk jobblagring | Pre-screeningbevis og etterprøvbarhet; jurist bekrefter endelig modell |
Bulk-eksport-jobber (bulk_csv_export_job, bulk_dd_pdf_job, due_diligence_api_job) |
30 dager (jobb, fil og blob slettes) | DPIA § 3.3 — teknisk jobblagring, dataminimering |
Bulkoppslag-jobber (bulk_job) |
Nedlasting i 48 timer; raden slettes etter 30 dager | DPIA § 3.3 — teknisk jobblagring, dataminimering |
| Konto, support og kundehenvendelser | Avtaleperioden + inntil 12 måneder, med mindre lov eller tvist krever mer | Kundeadministrasjon, support og dokumentasjon |
| Faktura-/betalingsmetadata | Etter bokføringsplikt og leverandørens betalingsvilkår | Regnskap, betaling og lovpålagt dokumentasjon |
Anonymisering av signup_ip skjer ved SHA-256-hashing — den
opprinnelige IP-adressen kan ikke gjenfinnes etterpå, men en hash
beholdes slik at gjentakelser kan kobles uten å avsløre opprinnelig
IP.
Backup-strategi: data kan forekomme i backup i opptil 12 måneder selv etter at retention-policyen har slettet det fra aktiv løsning. Backup-restorering brukes kun ved hendelser og kjører gjennom retention-jobben på nytt.
Hvis virksomheten ønsker andre lagringstider eller en utvidet backupstrategi, må dette konfigureres og dokumenteres særskilt.
10. Informasjonssikkerhet
Vi bruker tekniske og organisatoriske tiltak for å beskytte personopplysninger:
- autentisering og rolle-/tilgangskontroll
- logging av tilganger og kritiske handlinger
- overvåkning av bruk
- begrensning av eksport og API-tilgang
- pseudonymisering av personidentifikatorer (se § 2.3)
- TLS-kryptering av all trafikk mellom egne tjenester
- segregering av kundedata fra portal-administrasjon
- backup- og restore-rutiner
- hendelsesrespons og tilgangsrevisjon
- underleverandørkontroll og DPA-arkiv for databehandlere
Detaljerte tekniske kontroller er dokumentert i internt sikkerhetsherderings-rammeverk (Sprint A-G, lukkede funn 2026-04 → 2026-05).
11. Dataminimering i utgående kommunikasjon
Firmaradar lagrer kjerne- og portaldata på servere i Norge, med backup hos norsk leverandør. Pseudonymiserte personidentifikatorer er kryptografisk adskilt fra rådata (se § 2.3). Intern trafikk mellom egne tjenester er TLS-kryptert. Data forlater ikke vår infrastruktur for intern matching mot nedlastede datasett, men kan behandles hos leverandører når det er nødvendig for e-post, betaling, sikker transit eller støttefunksjoner.
Når data forlater vår infrastruktur — i e-post, ved betaling, eller ved oppslag mot eksterne registre — kan vi ikke garantere geografisk ruting eller mellomliggende servere. Internett-ruting og mottakerens egne tjenester er utenfor vår kontroll. Vi har derfor en bevisst dataminimerings-strategi for utgående kommunikasjon:
11.1 Automatiske e-postvarsler
Automatiske varsler gjelder selskaper kunden selv har valgt å overvåke. Vi minimerer mengden personopplysninger som forlater vår infrastruktur:
- Kunde vs. overvåket selskap. Varselet identifiserer aldri hvilken kunde (abonnent) overvåkningen tilhører — kun det overvåkede selskapet omtales. Kundens egen identitet fremgår ikke av e-posten.
- Emne (subject). Standard-emne er generisk (eks. «Nytt varsel fra Firmaradar») og inneholder verken selskaps- eller personnavn. Velger kunden et tilpasset emne, kan det inneholde det overvåkede selskapets navn/organisasjonsnummer (kundens eget valg).
- Innhold (body). Innholdet identifiserer det overvåkede selskapet — navn og organisasjonsnummer, eventuelt morselskap/konserntopp — samt hendelsestype, kategori, dato og statusendring. For hendelser knyttet til fysiske personer (sanksjons-/PEP-treff, AML) tas ingen personnavn, fødselsår eller andre personidentifikatorer med; detaljene krever innlogging i portalen.
Eksempel: «Firma X (org.nr …) har utløst signal Y. Åpne for detaljer.» - Offentlige registre. For hendelser fra offentlige registre (eks. BRREG- kunngjøringer) kan innholdet gjengi kunngjøringens offentlige detaljer, siden informasjonen allerede er offentlig tilgjengelig.
Eksempel: «Firma X har ny kunngjøring: Y.» - Lenker peker til ressurser som krever aktiv innlogging; rene magic-tokens i URL unngås for å hindre at lekket e-post gir tilgang.
11.2 Innkommende kommunikasjon
E-post-henvendelser som inneholder personopplysninger kan vi ikke kontrollere på avsenderside. Ved behov for utveksling av sensitive opplysninger henviser vi kunden til portalens innloggede support-flow framfor e-post.
12. Dine rettigheter
Du kan etter personvernregelverket blant annet ha rett til:
- innsyn i hvilke personopplysninger vi behandler om deg
- retting av uriktige opplysninger
- sletting når vilkårene er oppfylt
- begrensning av behandling
- dataportabilitet der vilkårene er oppfylt
- å protestere mot behandling som bygger på berettiget interesse
- å klage til Datatilsynet
Firmaradar bruker ikke personopplysningene til automatiserte avgjørelser med rettsvirkning for registrerte. Risiko- og compliance-signaler er beslutningsstøtte og krever kundens egen vurdering der resultatet kan få konsekvenser for en person.
Firmaradar har per dato ikke utpekt personvernombud. Henvendelser går til kontaktadressen i § 1.
For å utøve en rettighet, send forespørsel til
personvern@firmaradar.no eller bruk skjemaet under
/personvern/art14-forsporsel. Skjemaet krever ikke at du er kunde
eller har konto hos oss — det er åpent nettopp fordi mange av dem det
gjelder, ikke har noe kundeforhold til Firmaradar.
Gjelder henvendelsen en utledet relasjon til en politisk eksponert person (§ 2.4), oppgi gjerne hvilken relasjon du mener er uriktig. Vi har da et raskere grunnlag for å finne oppføringen, siden slike rader ofte er registrert på navn og eventuelt fødselsår alene.
13. Endringer i erklæringen
Vi kan oppdatere denne personvernerklæringen ved behov. Den nyeste versjonen skal alltid være tilgjengelig i portalen. Vesentlige endringer varsles til registrerte brukere via e-post eller portal- varsel.
Dette dokumentet er den autoritative erklæringen. Personvernsiden
/personvern i portalen er et sammendrag av den, og skal lenke til
fullversjonen her.
Versjonsregel: versjonsnummeret (**Versjon:** øverst) er datoen for
siste innholdsmessige endring i dette dokumentet. Samme verdi vises på
personvernsiden i portalen og lagres som den versjonen brukeren har bekreftet
at er lest. Endres innholdet, bumpes versjonslinja her og konstanten
PRIVACY_NOTICE_VERSION i portalkoden i samme endring. En sjekksum-lås i
testsuiten fanger innholdsendringer som er gjort uten bump. Rene
metadata-oppdateringer (versjonslinja og sjekksummen selv) flytter ikke
versjonen.