Hvordan velge riktig skyløsning for bedriften
Riktig skyløsning er den som dekker virksomhetens behov med akseptabel risiko, tydelig ansvar og en realistisk vei ut igjen. Pris og funksjoner er viktige, men valget bør også vurderes ut fra data, sikkerhet, tilgjengelighet, leverandøravhengighet, kompetanse og gjenoppretting.
En stor offentlig skytjeneste kan være tryggere og enklere å drifte enn en liten lokal installasjon. En privat eller driftet løsning kan samtidig gi større kontroll i enkelte situasjoner. Etiketten «sky», «privat» eller «norsk» avgjør ikke sikkerheten alene. Det avgjørende er hvordan tjenesten er bygget, avtalt, konfigurert, brukt og fulgt opp.
Start med behovet, ikke leverandøren
NSM anbefaler at verdi- og risikovurderingen gjøres før konkrete løsninger vurderes. En demonstrasjon kan være overbevisende, men den sier lite om hvor godt tjenesten passer virksomhetens kritiske arbeidsprosesser.
Beskriv først hva løsningen skal brukes til:
- hvilke arbeidsprosesser den skal støtte
- hvilke data den skal lagre eller behandle
- hvor mange brukere, enheter og eksterne samarbeidspartnere den skal betjene
- hvor lenge virksomheten kan være uten tjenesten
- hvor mye data virksomheten kan tåle å miste
- hvilke integrasjoner og eksportformater som må fungere
Dette gir kriterier som kan kontrolleres i stedet for en vag jakt på «den beste skyen».
Hva betyr offentlig, privat og hybrid sky?
NISTs definisjon av skytjenester skiller mellom tjenestemodeller og leveransemodeller. Begrepene beskriver ulike ting:
- SaaS: Kunden bruker leverandørens ferdige applikasjon, for eksempel e-post eller dokumentbehandling.
- PaaS: Kunden kjører egne applikasjoner på en plattform leverandøren drifter.
- IaaS: Kunden får infrastruktur som prosessering, lagring og nettverk, men har mer ansvar for operativsystemer og applikasjoner.
En offentlig sky tilbys til mange kunder av en skyleverandør. En privat sky er avsatt til én virksomhet, men kan stå både hos virksomheten og hos en ekstern driftsleverandør. En hybrid sky kombinerer flere separate miljøer med en form for data- eller applikasjonsflyt mellom dem.
«Self-hosted» betyr vanligvis at virksomheten eller dens driftspartner kontrollerer applikasjonen og ofte mer av infrastrukturen. Det er ikke det samme som at løsningen står fysisk på kontoret. Plassering, eierskap og driftsansvar må undersøkes hver for seg.
1. Kartlegg data og regulatoriske krav
Finn ut hvilke personopplysninger, forretningshemmeligheter, regnskapsdata og andre verdier tjenesten skal håndtere. Vurder konfidensialitet, integritet og tilgjengelighet: Hvem kan få innsyn, hva skjer ved feilaktige endringer, og hva er konsekvensen av nedetid?
Databehandlerrollen må avklares når en leverandør behandler personopplysninger på vegne av virksomheten. Datatilsynet bruker lagring av kundeopplysninger i en annen virksomhets skytjeneste som eksempel på når databehandleravtale er nødvendig.
Kontroller hvor data behandles, hvilke underleverandører som benyttes, hvordan supporttilgang styres og hvilke overføringsmekanismer som gjelder dersom personopplysninger kan behandles utenfor EØS. Fysisk lagring i Europa svarer ikke alene på alle disse spørsmålene.
2. Avklar hvem som har ansvar for hva
Skyleverandøren og kunden deler ansvaret, men grensen flytter seg med tjenestemodellen. I en SaaS-tjeneste drifter leverandøren mer av teknologien, mens kunden fortsatt må håndtere brukere, tilganger, datakvalitet, innstillinger og ofte sikkerhetskopiering. I IaaS har kunden normalt et langt større ansvar for operativsystem, applikasjoner, nettverk og oppdatering.
Lag en ansvarsmatrise for minst disse oppgavene:
- identiteter, flerfaktorautentisering og administratorroller
- sikker konfigurasjon og oppdateringer
- logging, varsling og hendelseshåndtering
- sikkerhetskopi og gjenoppretting
- dataklassifisering, sletting og eksport
- oppfølging av underleverandører og avtaleendringer
Uklare mellomrom er farligere enn en modell med mer eller mindre kundekontroll. Det som ikke inngår i leveransen må ha en annen eier.
3. Vurder sikkerhetsmekanismene som faktisk er tilgjengelige
Be om dokumentasjon på sikkerhetsstyring, uavhengige revisjoner og relevante sertifiseringer, men ikke behandle et sertifikat som bevis på at deres bruk av tjenesten er sikker. Kontroller hvilke funksjoner som følger med abonnementet, hvilke som koster ekstra, og hvilke virksomheten må etablere selv.
Vurder blant annet:
- phishing-resistent eller sterk flerfaktorautentisering
- rollebasert tilgang og separate administratorkontoer
- kryptering under overføring og lagring
- kunde- eller leverandørstyrte nøkler når det er relevant
- logger som kan eksporteres til uavhengig overvåking
- varsling ved uvanlige innlogginger og administrative endringer
- beskyttelse mot sletting og endring av data og sikkerhetskopier
Det britiske NCSC har fjorten prinsipper for vurdering av skyleverandører, blant annet databeskyttelse, sikker sletting, driftsmotstand, leverandørstyring, identitet og sikker bruk av tjenesten.
4. Mål tilgjengelighet i virksomhetens egen sammenheng
En oppetidsgaranti sier ikke nødvendigvis hvor raskt virksomheten er tilbake i arbeid. Tjenesten kan være tilgjengelig mens en konto, integrasjon, internettlinje eller lokal enhet er ute av drift. Undersøk også vedlikeholdsvinduer, støtte, statusinformasjon og hvordan leverandøren varsler hendelser.
Definer to praktiske mål:
- Gjenopprettingstid: Hvor lenge kan prosessen være utilgjengelig?
- Datatap: Hvor mye arbeid eller data kan virksomheten akseptere å miste?
Vurder deretter om virksomheten trenger offline arbeidsmåte, alternativ kommunikasjon, reserveforbindelse eller en manuell rutine mens tjenesten er nede.
5. Skill versjonshistorikk, redundans og backup
Redundans holder tjenesten tilgjengelig når utstyr feiler. Versjonshistorikk kan gjøre det mulig å hente en tidligere fil. Ingen av delene er automatisk en uavhengig sikkerhetskopi som beskytter mot kompromitterte administratorer, feilkonfigurasjon eller hendelser hos leverandøren.
Avklar hva leverandøren sikkerhetskopierer, hvor lenge kopiene beholdes, hvem som kan slette dem og hvordan en gjenoppretting bestilles. Virksomheten kan trenge en separat kopi utenfor tjenestens vanlige administrasjonsflate. 3-2-1-prinsippet hjelper med å spre risikoen, mens en gjenopprettingstest viser om kopiene faktisk kan brukes.
6. Test om virksomheten kan bytte leverandør
En exit-plan bør lages før avtalen signeres. Det er da virksomheten har best mulighet til å stille krav om eksport, bistand, frister og sletting.
Be om svar på disse spørsmålene:
- Kan alle data, metadata, rettigheter og logger eksporteres?
- Er eksportformatet dokumentert og lesbart av andre løsninger?
- Hva skjer med integrasjoner, arbeidsflyter og automatiseringer?
- Hvor lang tid tar en full eksport, og hva koster den?
- Hvor lenge er data tilgjengelige etter oppsigelse?
- Hvordan bekreftes sletting hos leverandør og underleverandører?
En liten prøveeksport er mer verdifull enn et generelt løfte om at data «kan tas ut». NSM anbefaler oversikt og kontroll gjennom hele livsløpet, sammen med bestillerkompetanse, risikovurdering og tydelige krav.
7. Beregn totalkostnaden over flere år
Sammenlign mer enn lisenspris. Ta med innføring, datamigrering, brukeradministrasjon, sikkerhetsfunksjoner, backup, integrasjoner, lagring, support, opplæring og framtidig utflytting. For infrastruktur kan også dataoverføring, trafikk og ressursforbruk påvirke regningen.
En egen eller privat løsning må på sin side inkludere maskinvare, datasenter, strøm, overvåking, oppdatering, beredskap og kompetanse. Kostnaden ved nedetid og manglende sikkerhet bør vurderes i begge modeller. Billigst per måned er ikke nødvendigvis lavest total risiko eller total kostnad.
8. Vurder kompetansen som kreves etter kjøpet
En tjeneste blir ikke ferdig forvaltet fordi den er skybasert. Virksomheten trenger fortsatt noen som administrerer brukere, følger opp varsler, gjennomgår tilganger, håndterer endringer og kontrollerer leverandøren.
Mer kontroll krever vanligvis mer driftskompetanse. Hvis virksomheten velger privat sky eller egen applikasjonsdrift, må ansvar for sikkerhetsoppdatering, kapasitet, logging, backup og hendelser være reelt bemannet. Hvis en driftspartner gjør arbeidet, bør leveransen være konkret og etterprøvbar.
En beslutningsmatrise som kan brukes i praksis
Gi hver kandidat en dokumentert vurdering for disse områdene:
- funksjonell dekning og brukervennlighet
- data, personvern og kontraktskrav
- identitet, logging og tekniske sikkerhetsmekanismer
- tilgjengelighet, støtte og beredskap
- backup og testet gjenoppretting
- integrasjoner, eksport og exit
- kompetanse og driftsansvar
- totalkostnad over avtaleperioden
Vekt områdene etter virksomhetens behov. En løsning som er best for en liten prosjektbedrift kan være feil for en virksomhet med lange oppbevaringskrav, sensitive data eller svært lav toleranse for nedetid.
Ofte stilte spørsmål
Er offentlig sky mindre sikker enn privat sky?
Ikke nødvendigvis. Store leverandører kan ha betydelig sikkerhetskompetanse og robuste driftsmiljøer. Privat sky kan gi mer kontroll, men kontroll må følges av kompetanse, vedlikehold og overvåking. Risikoen avgjøres av tjenesten, bruken og ansvarsdelingen.
Er data trygge hvis de lagres i Norge?
Norsk lagringssted kan være relevant, men svarer ikke alene på hvem som eier leverandøren, hvem som har administrativ tilgang, hvilke underleverandører som brukes, hvordan data sikres eller hvilke avtaler og regler som gjelder.
Må en bedrift ha egen backup av en SaaS-tjeneste?
Det avhenger av leverandørens gjenopprettingsmuligheter og virksomhetens krav. Avklar hva som inngår, hvilke hendelser som dekkes og om kopiene er tilstrekkelig uavhengige. Test gjenoppretting og eksport før en hendelse.
Hva er det viktigste kontrollspørsmålet?
Spør hva virksomheten selv fortsatt har ansvar for. Svaret avdekker ofte hull i tilgangsstyring, backup, overvåking og beredskap som ellers blir synlige først etter en hendelse.
Kilder og videre lesning
- NSM: Spørsmål om sky og tjenesteutsetting
- NSM: Bruk av tjenesteutsetting og skytjenester
- Datatilsynet: Når må man inngå databehandleravtale?
- NIST SP 800-145: The NIST Definition of Cloud Computing
- NCSC: Cloud Security Principles
Artikkelen ble faglig oppdatert 18. september 2026. Begreper, ansvarsdeling, sikkerhet, gjenoppretting, exit og beslutningskriterier er presisert, og uferdige henvisninger er fjernet.
