Krav til informasjonssikkerhet ved kjøp av skytjenester

Hvilke krav bør du stille til leverandørene, og hvilke krav bør du stille til tjenesten. Bør man stille særskilte krav til skytjenester? Her finner du råd og eksempler på hvilke spørsmål og krav du bør vurdere å stille til informasjonssikkerhet i en anskaffelsesprosess.

Publisert: 20. jun 2019, Sist endra: 25. aug 2020

Når du skal stille krav til informasjonssikkerhet i en tjeneste må du gjennomføre en risikovurdering av systemet eller arbeidsprosessen som tjenesten skal inngå i.

Risikoen ved å bruke skytjenester er avhengig av hvilken informasjon som skal behandles og om denne egner seg for å behandles i skyen. Hvilke tiltak har leverandøren implementert for å tilfredsstille dine krav til sikkerhet? Vurder om tiltakene er gode nok og hvilken risiko (restrisiko) du kan akseptere.

Krav til leverandør

Eksempel på kvalifikasjonskrav jf. FOA § 16-7

Krav til styringssystem for informasjonssikkerhet, ISO/IEC 27001 eller tilsvarende

ISO 27001 beskriver kravene til et styringssystem for informasjonssikkerhet. Dersom en leverandør etterlever kravene i ISO 27001 kan leverandøren bli sertifisert og få utstedt sertifikat.

Det er leverandørens virksomhet som blir sertifisert, og ikke tjenestene eller produktene som leveres. ISO 27001-sertifisering gir ingen garanti for at tjenestene som leveres er sikre.

Sjekk omfanget/scope for sertifikatet til leverandøren. Dersom den aktuelle tjeneste ikke er dekket av sertifikatet, så sier ikke sertifikatet noe om styringen av sikkerheten knyttet til selve tjenesten.

ISO/IEC 27001 har et tillegg med en referansekatalog med sikkerhetstiltak, Annex A, som benyttes som en sjekkliste. Brukere av standarden kan sammenligne sine valgte sikkerhetstiltak mot listen for å undersøke om noe vesentlig er utelatt. Innholdet i Annex A er hentet fra ISO/IEC 27002.

Forslag til kravtekst

Leverandørens kvalitetssikringsstandard jf FOA § 16-7

Leverandøren skal ha styringssystem for informasjonssikkerhet som tilfredsstiller kravene i ISO 27001 eller tilsvarende. 

Forslag til dokumentasjonskrav

Gyldig ISO 27001-sertifikat eller tilsvarende, eller attest utstedt av uavhengig organ som dokumentasjon for at leverandøren oppfyller kravene etter ISO 27001 eller tilsvarende.

Krav til tjenesten

Risikovurderingen vil avdekke behov for sikkerhetstiltak som du ønsker at leverandøren skal oppfylle. Nedenfor tar vi for oss noen områder hvor man bør vurdere risiko, hvilke tiltak som kan gjøres for å håndtere risikoene og forslag til krav i en kravspesifikasjon. De fleste eksemplene presenteres som BØR-krav/tildelingskriterier, men kan med litt bearbeidelse omskrives til MÅ-krav/minimumskrav.

Alle kravene til tjenesten finner du her.

R1    Trussel- og sårbarhetsvurderinger

Risiko

Trusselbildet endrer seg kontinuerlig, og derfor er det viktig at leverandøren har en løpende prosess for å identifisere, vurdere og prioritere trusselbildet, samt arbeider aktivt for å begrense sårbarheter.

Tiltak - hvordan redusere risiko

Leverandøren må holde seg oppdatert på risikobildet, analyserer løpende potensielle trusler og sårbarheter, og ha rutiner for å sikre at det blir gjennomført relevante tiltak.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren bør ha en løpende prosess for å identifisere, vurdere og prioritere trusselbildet. Det bør også arbeides aktivt for å begrense sårbarheter.

Dokumentasjonskrav - forslag til tekst

Beskriv prosessen for trussel- og sårbarhetsvurderinger. Beskriv også hvordan sårbarheter håndteres og hvilke prosedyrer med tidsrammer som brukes for de ulike typer av sårbarheter.

R2    Lock-In

Risiko

Dersom leverandøren ikke lenger tilfredsstiller dine behov eller gjør endringer i sine produkter eller betingelser som ikke kan aksepteres, må du kanskje bytte leverandør. Da må du på forhånd tenke på en rekke forhold og risikoer dersom du har låst deg til en leverandør (Lock-In).

- Overføring av data: Hvem er ansvarlig for å hente ut data, og hvilket format vil dataene ha, må dataene bearbeides før overføring? Hvor lang tid tar det, og hva koster det?

- Overføring av applikasjoner: Det kan være kostbart å omskrive eller rekonfigurere applikasjoner for å kunne kjøres på andre plattformer.

- Overføring av infrastruktur: Alle skyprodusenter (CSP) gjør ting litt forskjellig. Formater på virtuelle maskiner og tilhørende prismodeller varierer mellom ulike leverandører.

- Gjenbruk av Know-how: Kunnskap om verktøy og konfigurering kan sjelden gjenbrukes om du skifter leverandør. Det vil ta tid å tilegne seg samme kunnskapsnivå om ny skyplattform. Nye sertifiseringer må kanskje tas.

Tiltak - hvordan redusere risiko for Lock-In

Planlegg tidlig for exit: Allerede når du planlegger for implementering bør du legge en plan for exit og forstå kostnadene ved å bytte CSP. Ikke planlegg for lengre enn et par år for å ivareta fleksibiliteten din.

Design dine applikasjoner frikoblet fra skyplattform: Skyapplikasjonskomponenter bør være så løst knyttet som mulig til applikasjonskomponentene som samhandler med dem. Dette øker fleksibiliteten. 

Sørg for høy portabilitet av dine data: Unngå proprietær formatering for å maksimere portabiliteten til dine data. Beskriv datamodeller så tydelig som mulig ved å bruke skjemastandarder for å lage detaljert lesbar dokumentasjon. I tillegg bør du sørge for at skyleverandøren din tilbyr deg en måte å trekke ut data enkelt og rimelig.

Vurder multi-sky strategi: Du kan bruke en leverandør til prosessering og en annen for datavarehuset, mens du bruker en tredje til din kunstige intelligens. Ved å gå multi-sky blir du mindre avhengig av en leverandør for alle dine behov. En annen fordel er at du kan plukke det beste fra hver skyleverandør slik at du kan implementere "best-of-breed-tjenester" i applikasjonene dine.

Implementer DevOps verktøy og prosesser: Containerteknologi levert av ulike tilbydere bidrar til fjerne avhengigheter til skyleverandørene. De fleste CSPer støtter standard containerformat, som gjør det være enkelt å overføre applikasjonene dine til en ny skyleverandør om nødvendig.

Krav - forslag til tekst i kravspesifikasjon

Leverandøren skal yte bistand til Kunden dersom Kunden ønsker å avslutte avtalen. Leverandøren skal legge til rette for at Kundens data blir overført til Kunden eller til tredjepart utpekt av Kunden.

Kunden skal beholde eierskapet til Kundens data etter at kontrakten er avsluttet og til data er flyttet og/eller slettet fra tjenesten.

Dokumentasjonskrav - forslag til tekst

Beskriv hvilken bistand som ytes i forbindelse med avslutning av avtalen og hvilke aktiviteter med ansvarsmatrise for de ulike aktivitetene dersom Kunden ønsker å flytte Tjenestene. Beskriv hvilke forutsetninger som legges til grunn for slik bistand og hvilke begrensninger som gjelder. Bistanden skal prises i Prisbilaget.

R3    Endring og avlytting av data under overføring

Risiko

Data som overføres via nettverk kan tappes/avlyttes og endres dersom de ikke sikres. Dette gjelder både data som overføres til og fra tjenesten, internt i tjenesten og data som utveksles med andre tjenester f.eks. ved bruk av API.

Tiltak - hvordan redusere risiko for tap eller endring av data under overføring eller avlytting

Beskytte nettverk for å hindre uvedkommende tilgang til data og kryptering for å hindre uvedkommende å lese data.

Krav - forslag til tekst i kravspesifikasjon

Data som overføres via nettverk må sikres. Dette gjelder både data som overføres til og fra tjenesten, internt i tjenesten og data som utveksles med andre tjenester.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan data under overføring beskyttes, herunder beskyttelse av nettverk og bruk av kryptering.

R4    Datasenterets sikkerhet

Risiko

Uvedkommende kan få tilgang til data, gjøre endringer på systemer og urettmessig fjerne utstyr dersom datasentre ikke er fysisk sikret.

Tiltak - Hvordan redusere risiko for uautorisert adgang til datasenter

Datasenter som benyttes i tjenesten må kunne dokumentere fysisk sikring.

Krav - forslag til krav i kravspesifikasjon

Leverandør må forhindre uautorisert tilgang til sine datasenter samt beskytte mot tyveri, skade, tap og at utstyr svikter for å sikre kontinuerlig drift.

Dokumentasjonskrav - forslag til tekst

Beskriv hvilke fysiske sikringstiltak som benyttes i de datasenter som brukes for å levere tjenesten slik at uvedkommende ikke får tilgang til data, systemer og utstyr.

R5    Sikring av lagret informasjon

Risiko

Ofte er det mange ulike aktører som har adgang til en skyleverandørs datasentre, men som ikke skal ha tilgang til dine data. Derfor må dine data være sikret mot uautorisert tilgang.

Tiltak - Hvordan redusere risiko for uautorisert tilgang til dine data

En kombinasjon av fysisk sikring (se "Risiko: Datasenterets sikkerhet") og kryptering av lagrede data.

Du bør kreve at lagrede data skal være kryptert og sikre at håndtering av krypteringsnøkler følger beste praksis , f.eks. å skille nøkkeladministrasjon og bruk av nøkler. Krypteringsnøkler skal ikke lagres i skyen.

Krav - forslag til kravspesifikasjon

Det må defineres, velges, dimensjoneres og implementeres passende kryptografiske mekanismer støttet av en tilstrekkelig nøkkeladministrasjonsinfrastruktur for å sikre sikker drift av tjenestene. Det gjelder data i ro så vel som datastrømmer.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan plattform og lagrede data sikres ved bruk av kryptering. Beskriv hvordan krypteringsnøkler håndteres. Hvordan sikrer man skille mellom administrasjon av krypteringsnøkler og bruk av krypteringsnøkler.

R6    Separasjon mellom kunder

Risiko

En kunde kan påvirke en annen kundes tjeneste eller data dersom det ikke er tilfredsstillende skille mellom kundene.

Tiltak - Hvordan redusere risiko for at andre kunder skal kunne påvirke tjenesten

Leverandøren må sørge for tilstrekkelig skille mellom kundene sine. Dette kan gjøres ved bruk av anerkjente virtualiseringsteknikker for både prosessering, nettverk og lagring. Man kan også separere kunder ved bruk av operativsystem, webtjenere eller applikasjoner.

Krav - forslag til kravspesifikasjon

Leverandøren må skille kundens tjenester og data fra andre kunder.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan kundenes tjenester og data skilles fra hverandre og hvordan denne separasjonen kan kontrolleres og styres av Kunden.

R7    Sletting av data

Risiko

Data som skal slettes kan komme på avveie eller gjenskapes dersom leverandør ikke sletter dine data på en sikker og trygg måte. Dette gjelder også dersom leverandøren bytter ut sitt utstyr og flytter dine data over til nytt utstyr, da må leverandøren sikre at dine data ikke blir tilgjengelig på det gamle utstyret.

Tiltak - Hvordan redusere risiko for usikker og ukomplett sletting av data

Leverandøren må kunne dokumentere hvordan han sletter data og hvordan han sikrer at slettede data ikke kommer på avveie eller kan gjenskapes. Den eneste måten å fullstendig slette data på, er å ødelegge lagringsmediet. Det er det vanskelig å få gjennomført siden det ofte er andre kunder som også bruker samme ressurser til sine data.

Krav - forslag til kravspesifikasjon

Leverandøren må kunne dokumentere hvordan han sletter data og hvordan han sikrer at slettede data ikke kommer på avveie eller kan gjenskapes.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan du sletter data og sikrer at data som er slettet ikke blir tilgjengelig for andre eller kan gjenskapes. Beskriv også hvordan du sikrer at slettede data ikke blir tilgjengelig ved utskifting og fornyelse av infrastruktur.

R8    Tilgjengelighet

Risiko

Tjenesten kan bli utilgjengelig dersom den ikke er tilstrekkelig robust for å kunne stå imot uønskede hendelser. Uønskede hendelser kan være ondsinnede angrep, tekniske feil og menneskelige feil.

Tiltak - Hvordan redusere risiko for utilgjengelighet og nedetid

Leverandøren må forplikte seg til tilgjengelighet i tjenesten og garantere oppetid. Leverandøren bør også kunne vise til statistikk og historiske data for oppetid/tilgjengelighet.

Du kan også vurdere å be om informasjon om hvordan leverandøren har designet tjenesten for å kunne være robust og sikre oppetid/tilgjengelighet.

Krav - forslag til kravspesifikasjon

Tjenesten må være tilgjengelig for kunden når kunden har behov for tjenesten. Leverandøren må kunne garantere oppetid og dokumentere historisk oppetid/tilgjengelighet.

Dokumentasjonskrav - forslag til tekst

Beskriv den garanterte tilgjengelighet og dokumenter oppetidsgarantien med historiske data. Dersom det brukes ulike tilgjengelighetsgarantier, så skal disse beskrives og hvilke betingelser som gjelder for de ulike garantiene.

Beskriv hvilke tiltak og prosedyrer som er etablert for å sikre tjenestens robusthet og tilgjengelighet.

R9    Endringshåndtering

Risiko

Alle endringer som kan påvirke tjenesten må håndteres for å hindre utilsiktede hendelser. Dette gjelder både utvikling, nyanskaffelser og utskifting av applikasjoner, infrastruktur, nettverk og systemkomponenter.

Tiltak - Hvordan redusere risiko for hendelser ved endringer

Leverandøren må ha prosess for å håndtere endringer. Prosessen skal sikre at endringer som kan påvirke sikkerheten identifiseres og håndteres, og at uautoriserte endringer kan oppdages.

Krav - forslag til kravspesifikasjon

Leverandøren må ha prosess for å håndtere endringer for å sikre at endringer som kan påvirke sikkerheten identifiseres og håndteres, og at uautoriserte endringer kan oppdages.

Dokumentasjonskrav - forslag til tekst

Beskriv prosessen for endringshåndtering for både utvikling, integrasjoner, applikasjoner, nettverk og systemkomponenter. Beskriv også hvordan endringshåndtering ivaretas i hele verdikjeden for tjenesten. Hvordan sikrer man  at det kun er autoriserte endringer som blir implementert i tjenesten.

R10  Sporbarhet

Risiko

Leverandøren kan overlagt eller uforvarende utføre handlinger som skader integriteten til kundens data eller eksponere data for uvedkommende. Dette kan f.eks. være inkonsistente databasedumper, tilbakeføring av backup uten å ta hensyn til mellomliggende endringer, kopiering til mindre sikret infrastruktur eller snoking.

Tiltak - Hvordan redusere risiko

Alle handlinger som utføres av leverandøren skal logges. Loggen skal ikke kunne manipuleres. Kunden skal ha tilgang til loggene etter behov.

Alle handlinger som loggføres skal kunne kobles til den personen som har utført handlingen. Systemdesign skal sikre at det ikke er mulig å omgå logging f.eks. ved å logge inn på systemer på lavere nivå eller foreta spørringer direkte mot en database i stedet for å benytte applikasjonsgrensesnitt.

Kunden har rett til å revidere leverandørens virksomhet knyttet til behandling av kundens data, eller å få innsyn i revisjonsrapporter fra en uavhengig tredjepart med revisjonsrett.

Krav - forslag til kravspesifikasjon

Alle handlinger som utføres av leverandøren skal logges. Loggen skal ikke kunne manipuleres. Kunden skal ha tilgang til loggene etter behov.

Kunden har rett til å revidere leverandørens virksomhet knyttet til behandling av kundens data, eller å få innsyn i revisjonsrapporter fra en uavhengig tredjepart med revisjonsrett.

Dokumentasjonskrav - forslag til tekst

Beskriv hvordan og på hvilket detaljnivå handlinger utført av leverandøren som kan endre eller eksponere data logges, og hvordan loggene sikres mot manipulasjon.

Beskriv hvordan kunden får tilgang til disse loggene. Beskriv kundens rett til revisjon av leverandørens virksomhet knyttet til behandling av kundens data.

R11  Tilgangskontroll / Autentisering

Risiko

Det kan være svakheter i tilgangskontroll og autentiseringsmekanismer for en skytjeneste som gir en gyldig bruker, leverandørens administrator eller uvedkommende tilgang til informasjon eller funksjoner de ikke skal ha tilgang til, eller at autoriserte brukere ikke får tilgang til det de skal ha tilgang til.

Tiltak - Hvordan redusere risiko for at tilgangskontroll/autentisering feiler

Leverandøren må sørge for tilstrekkelig isolasjonsstyrke og robusthet i tilgangskontrollen for å gi rett person tilgang til rett datasett og rette funksjoner i løsningen, og kunne dokumentere at dette er implementert.

Leverandøren må tilby verktøy for administrasjon av kundens brukere og deres tilganger, ha tilstrekkelig støtte for bruk av eksterne identitetstilbydere (for eksempel Microsoft Azure AD) og støtte for eksterne identhåndteringsløsninger – IdM (støtte for standarder protokoller og api’er for kundens forsyning av brukers tilganger og roller i leverandørens løsning).

Krav - Forslag til tekst i kravspesifikasjon

Løsningen må ha tilstrekkelig isolasjonsstyrke og robusthet i tilgangskontroll.

Leverandør må tilby verktøy for administrasjon av kundens brukere og deres tilganger og ha tilstrekkelig støtte for bruk av eksterne identitetstilbydere.

Dokumentasjonskrav - Forslag til tekst

Beskriv hvordan kundens brukere (personer, prosesser eller applikasjoner) identifiseres, autentiseres, autoriseres, administreres og hvordan tilgang kan etterprøves (audit).

Dette inkluderer single-sign on, føderasjon med eksterne identitetstilbydere, integrasjon med Identity management systems (IdM) og aksessloggmuligheter.

R12  Sikkerhetsbrudd / Varsling

Risiko

Alle tjenester som eksponeres mot Internett vil være utsatt for angrep og mulige sikkerhetsbrudd. I tillegg vil utro ansatte hos Kunden og tjenesteleverandøren med de rette tilganger kunne medføre sikkerhetsbrudd. Derfor er det viktig at leverandøren har tilstrekkelig sikkerhetsovervåkning av tjenesten og rutiner for varsling ved hendelser.

Tiltak - Hvordan redusere risiko for at sikkerhetsbrudd oppstår og hvordan sikre gode varslingsrutiner

Leverandør har mange tiltak for å både hindre og detektere sikkerhetsbrudd. Disse kan man kreve en gjennomgang av, eller få tilgang til leverandørens revisjonsrapporter fra en tredjepart for deres vurdering av leverandørens sikkerhetsovervåkningen, vurdering av tilgangsstyringen til systemer og komponenter for leverandørens egne administratorer og hvilke prosedyrer og rutiner de har for varsling til kunder.

Spør Leverandøren om å få tilgang til sikkerhetslogger og integrer disse med egen løsning for sikkerhetsovervåkning.

Varslingsrutiner og tidsfrister skal også beskrives i databehandleravtalen man har med Leverandøren

Som kunde, etabler en mottakende organisasjon for varsler om sikkerhetsbrudd og behandling av disse for å vurdere tiltak som må iverksettes for å varsle videre og begrense skadeomfanget.

Krav - Forslag til tekst i kravspesifikasjon

Leverandøren må ha tilstrekkelig sikkerhetsovervåkning av tjenesten og rutiner for varsling ved hendelser. Leverandør skal på forespørsel gi kunden tilgang til revisjonsrapporter for vurdering av sikkerhetsovervåkningen, vurdering av tilgangsstyringen til systemer og komponenter for leverandørens egne administratorer og hvilke prosedyrer og rutiner de har for varsling.

Sikkerhetslogger skal overføres til kunden dersom kunden ber om det.

Dokumentasjonskrav - Forslag til tekst

Beskriv prosesser, rutiner og teknologi som utgjør sikkerhetsovervåkingen og sikkerhetssjekk av løsningen, og beskrive hvilke type loggdata som kan tilgjengeliggjøres for kunden (definerte og valgfrie sikkerhetsalarmer, sikkerhetsadvarsler og sikkerhetsloggingstjenester). 

Leverandøren bes også om å beskrive hvordan sikkerhetslogger, alarmer og advarsler kan integreres med Kundens egen sentrale sikkerhetsovervåkingsløsning.

Leverandøren bes beskrive hvordan de bruker ekstern penetrasjonstesting eller andre mekanismer for testing og kontroll av service/applikasjons- og infrastruktursikkerhet

Kilder til sikkerhetstiltak

Her finner du eksempler på ulike kilder med forslag til sikkerhetstiltak. Husk at det sjelden er et mål å sette krav til alle sikkerhetstiltakene fra en kilde uten tanke på virksomhetens faktiske behov, vurder å hente forslag til tiltak fra flere kilder.

ISO/IEC 27002 eller tilsvarende

Det er viktig at virksomheten har gode prosesser for å gjøre egne vurderinger av risikoer og håndtere disse med riktig valg av sikkerhetstiltak. ISO 27002 beskriver sikkerhetstiltak på ulike områder. For hvert område defineres sikkerhetstiltak med veiledning til hvordan man kan implementere tiltakene.

  • Kapittel 5 Information security policies
  • Kapittel 6 Organization information security policies
  • Kapittel 7 Human resource security
  • Kapittel 8 Asset management
  • Kapittel 9 Access control
  • Kapittel 10 Cryptography
  • Kapittel 11 Physical and environmental security
  • Kapittel 12 Operations security
  • Kapittel 13 Communications security
  • Kapittel 14 System acquisition, development and maintenance
  • Kapittel 15 Supplier relationships
  • Kapittel 16 Information security incident management
  • Kapittel 17 Information security aspects of business continuity management
  • Kapittel 18 Compliance

ISO/IEC 27017 eller tilsvarende

ISO 27017 bygger på de samme tiltakene som ISO 27002, men foreslår i tillegg en rekke sikringstiltak for skytjenester.

Det gjelder spesielt kapittel 9 - Access control, kapittel 12 - Operations security, kapittel 13 - Communications security, kapittel 15 - Supplier relations og kapittel 18 Compliance, som har forslag til ekstra sikringstiltak ved skytjenester. I tillegg inneholder ISO 27017 Annex A: Cloud service extended control set.

ISO/IEC 22313 eller tilsvarende

ISO 22313 er en veiledning som bygger på kravene i ISO 22301 om krav til styring og kontroll av kontinuitet i tjenesten, Business Continuity Management Systems (BCMS).

Veiledningen er basert på god internasjonal praksis for PLANLEGGING, ETABLERING, IMPLEMENTERING, DRIFT, OVERVÅKING, GJENNOMGANG, VEDLIKEHOLD og KONTINUERLIG FORBEDRING av et styringssystem som gjør det mulig være forberedt på hendelser som kan forstyrre tjenesten og å kunne være i stand til å respondere når hendelser oppstår for å sikre kontinuerlig drift.

NSMs Grunnprinsipper for IKT-sikkerhet

Grunnprinsippene beskriver hva en virksomhet bør gjøre for å sikre et IKT-system. De beskriver også hvorfor det bør gjøres, men ikke hvordan.

Grunnprinsippene er inndelt i fire kategorier:

1. Identifisere og kartlegge

2. Beskytte

3. Opprettholde og oppdage

4. Håndtere og gjenopprette

NSMs Grunnprinsipper for IKT-sikkerhet v2.0

Norm for informasjonssikkerhet i personvern i helse- og omsorgstjenesten

Normen er en bransjenorm utarbeidet og forvaltes av organisasjoner og virksomheter i sektoren med sikte på å bidra til tilfredsstillende informasjonssikkerhet og personvern hos den enkelte virksomhet og i sektoren generelt, samt å bidra til at det etableres mekanismer hvor virksomhetene kan ha gjensidig tillit til at øvrige virksomheters behandling av helse- og personopplysninger gjennomføres på et forsvarlig sikkerhetsnivå.

Normen kapittel 5 - Informasjonssikkerhet

- beskriver sentrale sikkerhetstiltak som skal gjennomføres av virksomheter som behandler helse- og personopplysninger. Dette omfatter både dataansvarlige og databehandlere.  Alle sikkerhetstiltak skal være egnede, og velges basert på risikovurderinger. Det kan dermed være nødvendig å gjennomføre mer omfattende tiltak enn det som er beskrevet her.

 

Sharethis

Hjelp oss å lage bedre nettsider

Fant du det du lette etter?

Hjelp oss å lage bedre nettsider
*