Hva er en varslingskanal – og hva bør den inneholde?

Hvorfor varsler er særlig sensitive opplysninger

Et varsel inneholder ofte opplysninger om enkeltpersoner som ikke selv har bedt om å bli omtalt, i tillegg til opplysninger om varsleren selv dersom vedkommende identifiserer seg. I mange saker vil innholdet også kunne omfatte helseopplysninger, opplysninger om fagforeningstilhørighet eller andre kategorier som etter personvernregelverket krever ekstra beskyttelse.

Konsekvensene av at slike opplysninger kommer på avveie er alvorlige, både for enkeltpersoner og for virksomhetens omdømme. Dette er bakgrunnen for at en varslingskanal ikke kan bygges som et hvilket som helst kontaktskjema, men må vurderes med samme sikkerhetsnivå som andre systemer som behandler sensitive personopplysninger.

Dataminimering i skjemaet

Et grunnleggende prinsipp er at skjemaet ikke bør samle inn mer informasjon enn det som er nødvendig for å behandle saken. Obligatoriske felt for navn, ansattnummer eller lignende bør unngås, slik at anonym varsling er reelt mulig der varsleren selv ønsker det.

Dataminimering gjelder også underveis i saksbehandlingen. Det bør være mulig å begrense hvilke detaljer som lagres i systemet dersom informasjonen ikke er nødvendig for den videre håndteringen, og saksbehandlere bør ha rutiner for å ikke etterspørre mer informasjon enn saken krever.

Rollebasert tilgangsstyring

Et sentralt krav er at systemet skiller tydelig mellom ulike roller, slik at ingen har tilgang til mer enn det rollen krever. Dette reduserer risikoen for at sensitiv informasjon spres unødvendig internt, og gjør det enklere å etterprøve hvem som har hatt tilgang til hva.

• Mottaker: kan ta imot nye varsler, men ikke nødvendigvis se hele sakshistorikken
• Saksbehandler: har tilgang til sakene vedkommende er satt til å behandle
• Administrator: styrer brukere, roller og systeminnstillinger, men bør ikke automatisk se saksinnhold
• Revisor: har lesetilgang til logger og rutiner for kontrollformål, uten å kunne endre saker

Teknisk skille mellom organisasjoner

For leverandører som tilbyr varslingskanal til flere virksomheter, er det avgjørende at data fra én organisasjon er teknisk og logisk atskilt fra andre organisasjoners data. Dette bør sikres på databasenivå, ikke bare gjennom tilgangskontroll i brukergrensesnittet, slik at en feil i én kundes oppsett ikke kan eksponere data fra en annen.

Virksomheter som vurderer en leverandør bør konkret spørre hvordan dette skillet er implementert, og be om en beskrivelse av arkitekturen som viser at saker ikke kan krysse organisasjonsgrenser ved en feil eller ved feilkonfigurering av tilganger.

Kryptering i transitt og på lagring

All kommunikasjon mellom varsler, saksbehandler og systemet bør skje over kryptert forbindelse, slik at innhold ikke kan avlyttes underveis. Dette er i dag en selvfølge for de fleste seriøse tjenester, men bør likevel etterspørres eksplisitt, spesielt for eldre systemer eller egenutviklede løsninger.

Minst like viktig er kryptering av data som lagres i ro, altså i databasen og i eventuelle sikkerhetskopier. Dette begrenser skadeomfanget dersom noen skulle få uautorisert tilgang til den underliggende infrastrukturen, og bør være standard for alle felt som inneholder saksinnhold og personopplysninger.

Vedlegg og signerte, tidsbegrensede lenker

Vedlegg som lastes opp i forbindelse med et varsel, for eksempel dokumenter, skjermbilder eller lydopptak, bør lagres atskilt fra selve saksteksten, i en privat lagringsløsning som ikke er direkte tilgjengelig uten autorisasjon. Dette begrenser eksponeringen dersom en lenke skulle komme på avveie.

Tilgang til vedlegg bør skje gjennom signerte lenker med kort levetid, slik at en lenke som deles utilsiktet eller lekker, ikke gir varig tilgang. Kombinert med logging av hvem som har åpnet et vedlegg og når, gir dette god sporbarhet uten å gå på bekostning av brukervennligheten for saksbehandler.

Sakskoder som ikke kan gjenopprettes

Mange varslingssystemer bruker en sakskode som varsleren kan bruke til å følge opp saken anonymt, uten å oppgi kontaktinformasjon. For at dette skal være reelt anonymt, bør sakskoden lagres som en hash i systemet, ikke i klartekst, slik at koden ikke kan gjenopprettes eller kobles til varslerens identitet av noen som får tilgang til databasen.

Dette har en praktisk konsekvens: dersom varsleren mister sakskoden, kan den ikke gjenopprettes av verken leverandøren eller virksomheten. Dette bør kommuniseres tydelig til varsleren når koden utstedes, slik at vedkommende forstår viktigheten av å lagre den trygt.

Revisjonslogg – hva bør logges?

En fullstendig revisjonslogg er nødvendig både for å oppdage misbruk og for å kunne dokumentere at saksbehandlingen har fulgt fastsatte rutiner. Loggen bør registrere hvem som har gjort hva, når, uten selv å avsløre sensitivt saksinnhold i loggposten.

• Innlogging og mislykkede innloggingsforsøk
• Åpning og lesing av en sak, inkludert hvilken bruker og tidspunkt
• Endringer i sakens status, tildeling eller rolletilganger
• Nedlasting eller visning av vedlegg
• Eksport av data ut av systemet

Sletting og lagringstid

Personopplysninger i en varslingssak skal ikke lagres lenger enn det som er nødvendig for formålet. Lagringstiden bør differensieres etter sakstype: en sak som ender uten grunnlag for videre oppfølging kan normalt slettes raskere enn en sak som har ledet til personalmessige reaksjoner eller rettslig prosess.

Sletterutinene må også omfatte sikkerhetskopier, ikke bare produksjonsdatabasen. Dersom en sak slettes i det aktive systemet, men fortsatt ligger i flere måneders backup-rotasjon, er slettingen i realiteten ikke gjennomført. Dette bør avklares konkret med leverandøren og fremgå av databehandleravtalen.

Databehandleravtale og underleverandører

Når en ekstern leverandør drifter varslingskanalen, skal det foreligge en databehandleravtale som regulerer hvordan opplysningene behandles, hvilke formål de kan brukes til, og hvilke sikkerhetstiltak som gjelder. Avtalen bør også liste opp eventuelle underleverandører, for eksempel skytjenesteleverandøren infrastrukturen kjører på.

Virksomheten bør be om innsyn i hvilke underleverandører som er involvert, og vurdere om disse i seg selv oppfyller nødvendige krav til sikkerhet og datalokasjon. Ansvaret for at kjeden av leverandører er forsvarlig, ligger til syvende og sist hos virksomheten som behandlingsansvarlig.

Datalokasjon i EU/EØS

Gitt hvor sensitive varslingsdata er, bør data som hovedregel lagres innenfor EU/EØS, slik at overføring til tredjeland og de særlige vurderingene dette krever etter personvernregelverket, unngås. Dette gjelder både primærlagring og sikkerhetskopier.

Dersom leverandøren benytter en global skyplattform, bør virksomheten få bekreftet konkret hvilken region dataene ligger i, og om support- eller driftspersonell utenfor EU/EØS kan få tilgang til dataene ved feilsøking. Slik tilgang bør i så fall være strengt regulert og logget.

To-faktor for saksbehandlere og risikovurdering

Saksbehandlere og andre med tilgang til varslingssaker bør være pålagt to-faktor autentisering ved innlogging. Et passord alene er ikke tilstrekkelig beskyttelse for en tilgang som kan avsløre identiteten til en varsler eller innholdet i en pågående sak.

Før en varslingskanal tas i bruk, bør virksomheten gjennomføre en risikovurdering, og i mange tilfeller en fullstendig personvernkonsekvensvurdering (DPIA), gitt at behandlingen normalt omfatter særlige kategorier personopplysninger i stor skala. Dette dokumenterer at risikoene er vurdert og at tiltakene står i forhold til dem.

Hvorfor e-post og delte mapper ikke er en varslingskanal

Det er fortsatt vanlig at virksomheter bruker en generisk e-postadresse eller en delt mappe som sin varslingskanal. Problemet er at e-post normalt ikke er ende-til-ende-kryptert, sakskoder for anonym oppfølging er vanskelige å realisere, og tilgangsstyringen er avhengig av at ansatte manuelt følger interne rutiner for hvem som får videresendt hva.

En delt mappe har tilsvarende svakheter: det er krevende å begrense tilgang presist, det finnes ofte ingen automatisk logg over hvem som har åpnet hvilke dokumenter, og sletting er avhengig av manuelle rutiner som lett glipper. Et dedikert system med sakskode, rollestyring, kryptering og logg løser disse svakhetene strukturelt, og internvarsling.no er bygget nettopp for dette formålet.

Sjekkliste ved valg av leverandør

Når en virksomhet skal velge leverandør av varslingskanal, bør følgende punkter avklares konkret før avtale inngås, slik at kravene til sikkerhet og personvern er dokumentert fra start.

• Er data teknisk atskilt mellom kunder, og hvordan er dette dokumentert?
• Er data kryptert både i transitt og på lagring, inkludert sikkerhetskopier?
• Lagres sakskoder som hash, og kan de ikke gjenopprettes av leverandøren?
• Finnes rollebasert tilgang med tydelig skille mellom mottaker, saksbehandler, administrator og revisor?
• Foreligger databehandleravtale med oversikt over underleverandører?
• Ligger data innenfor EU/EØS, inkludert eventuell support- og driftstilgang?
• Kreves to-faktor autentisering for saksbehandlere?
• Finnes det sletterutiner med definert lagringstid per sakstype?

Ofte stilte spørsmål