Den beste NIS2-programvaren for en norsk virksomhet er den som støtter virksomhetens faktiske ansvar, gir etterprøvbare beslutninger og fungerer sammen med sikkerhetsarbeidet som allerede utføres. Et navn i en produktkategori forteller lite om dette. Før dere sammenligner tilbud, bør dere avklare hvilke tjenester som omfattes av gjeldende regler, hvilke forventninger kunder stiller, og hvilke arbeidsprosesser dere trenger hjelp med.
Denne kjøpsveiledningen gir en fremgangsmåte for å lage et kravgrunnlag og gjennomføre en demonstrasjon med egne scenarioer. Den rangerer ikke leverandører. Pris, tilgjengelige integrasjoner og leveranseomfang må bekreftes i tilbudet. Et verktøy kan organisere dokumentasjon og oppfølging, men det gjennomfører ikke i seg selv sikkerhetstiltak eller avgjør om virksomheten oppfyller loven.
Avklar norsk rett før dere velger regelverkspakke
Status er kontrollert 27. september 2026. EFTAs faktablad om NIS2 beskriver direktivet som under vurdering for innlemmelse i EØS-avtalen. Dette må skilles fra at NIS2 allerede er vedtatt i EU, og fra medlemsstatenes nasjonale gjennomføring. En generell påstand om at NIS2 gjelder alle norske virksomheter fra en bestemt dato i 2026, gir derfor ikke et forsvarlig innkjøpsgrunnlag.
Norges digitalsikkerhetslov og tilhørende forskrift trådte i kraft 1. oktober 2025 og gjennomfører det første NIS-direktivet. Regjeringens omtale av lovverket skiller dette fra arbeidet med NIS2. NSMs veiledning beskriver to hovedgrupper: tilbydere av samfunnsviktige tjenester og tilbydere av digitale tjenester. Omfanget må vurderes etter loven, forskriften og den aktuelle tjenesten, ikke bare etter bransjenavnet i et salgsskjema.
Lag derfor et kort avklaringsnotat før demonstrasjonen. Notatet bør identifisere juridisk enhet, tjeneste, sektormyndighet og begrunnelsen for om virksomheten er omfattet. Marker egne forberedelser til NIS2 som forberedelser. Har konsernet etableringer eller tjenester i EU, må plikter der vurderes særskilt. Kundekrav om NIS2-relatert sikkerhetsdokumentasjon kan også oppstå selv om leverandøren ikke selv er direkte omfattet. Den norske gjennomføringsoversikten for NIS2 gir bakgrunn for denne avgrensningen.
Oversett behovet til konkrete leveranser
Begynn med det dere ikke får gjort godt nok i dag. Kanskje blir risikotiltak liggende uten eier, leverandørvurderinger mangler oppfølging, eller hendelsesloggen finnes i flere innbokser. Beskriv ønsket resultat med et eksempel som kan vises. «Ansvarlig leder kan se forfalte tiltak med begrunnelse og beslutte videre håndtering» er et mer presist behov enn «avansert risikomodul».
Skill mellom styringssystemet og tekniske sikkerhetsverktøy. En plattform som registrerer at flerfaktorautentisering er innført, behøver ikke kontrollere alle pålogginger. Et system som samler avvik fra en skanner, behøver ikke utbedre dem. Avklar hvilken kilde hvert bevis kommer fra, hvem som validerer det, og hvordan feil overføring blir synlig. Ellers kan en grønn oversikt dekke over manglende eller foreldede data.
Ta utgangspunkt i en kartlegging av IT-systemer og avhengigheter. Knytt en samfunnsviktig tjeneste til applikasjoner, identitetsløsninger, driftspartnere og kontaktpersoner. Kartet trenger ikke inneholde alle tekniske detaljer for å være nyttig, men det må gjøre konsekvensene av bortfall forståelige. Et verktøy som bare sorterer kontroller etter standardnummer, kan være utilstrekkelig hvis virksomheten trenger denne tjenesteoversikten.
Gjennomfør en demonstrasjon av ett risikoforløp
Bruk et oppdiktet, men realistisk scenario uten produksjonshemmeligheter: fjernaksess hos en driftspartner blir kompromittert og stanser en viktig tjeneste. Be leverandøren registrere hendelsesforløpet, berørte verdier og forutsetningene for risikovurderingen. Vurder om konsekvenser for tilgjengelighet, integritet og konfidensialitet kan beskrives uten at alt presses inn i samme ubegrunnede poengsum.
La deretter en fagansvarlig foreslå et tiltak og en leder vurdere gjenværende risiko. Demonstrasjonen bør vise hvem som kan endre vurderingen, hvordan uenighet dokumenteres, og hvilken versjon ledelsen godkjente. Et vedtak om å akseptere risiko bør ha begrunnelse og en utløser for ny vurdering. Programvaren skal ikke gjøre høy risiko akseptabel bare fordi noen har fylt ut alle feltene.
Følg ett tiltak helt til kontroll av effekt. Hvis tiltaket gjelder sikrere serveroppsett, kan veiledningen om herding av Windows og Linux brukes til å definere hva teknikerne faktisk skal levere. I demonstrasjonen registreres ansvar, dokumentasjon og avvik fra forventet resultat. Skill gjennomføring fra godkjenning: et lastet opp skjermbilde er ikke nødvendigvis tilstrekkelig bevis for at tiltaket virker over tid.
Kontroller hendelsesløpet under tidspress
Hendelsesstøtte bør begynne ved observasjonen, også når det ennå er uklart om hendelsen er meldepliktig. Be om registrering av tidspunkt, oppdagelseskilde, berørt tjeneste og foreløpig konsekvens. Systemet bør kunne vise hvem som foretar vurderingen og bevare senere rettelser. En ny vurdering skal ikke overskrive det virksomheten visste da første beslutning ble tatt.
Norske varslingskrav må hentes fra gjeldende norsk regelverk og relevant sektormyndighet. NSMs side om varsling etter digitalsikkerhetsloven er et naturlig utgangspunkt. Ikke legg inn EUs NIS2-frister som universelle norske frister. Et internasjonalt konsern kan trenge flere parallelle vurderinger av samme hendelse, med forskjellige mottakere, terskler og hjemler.
For tilbydere av samfunnsviktige tjenester angir NSM første varsel innen 24 timer etter kjennskap til hendelsen, oppdatering innen 72 timer og hendelsesrapport innen én måned etter første varsel. Plikten til å varsle uten unødig opphold må også ivaretas. At tallene ligner NIS2-forløpet, gjør ikke den norske hjemmelen til NIS2. For digitale tjenester må dere kontrollere deres egne terskler og plikter, slik at systemet ikke tildeler alle virksomheter samme varslingsløp.
Demonstrer dette med to regelverksprofiler på samme hendelse. Den som vurderer saken, skal kunne se hvorfor en profil gjelder, hvilke opplysninger som utløste vurderingen, og hvilken kilde fristen bygger på. Varslingsutkastet bør kunne inneholde foreløpige opplysninger uten at saksbehandleren tvinges til å gjette årsak eller omfang. Nye fakta må kunne legges til senere med tydelig tidspunkt.
Prøv også et scenario der samarbeidsplattformen er utilgjengelig. Hvem finner varslingskontaktene, hvem kan beslutte varsling, og hvordan dokumenteres det som gjøres uten tilgang til systemet? En nedlastbar beredskapspakke og en alternativ kontaktkanal kan være mer verdifulle enn en ekstra graf. Øv på å føre opplysningene tilbake etterpå, slik at tidspunkt og beslutninger beholdes. Dette knytter anskaffelsen til virksomhetens kontinuitetsplan.
Vis at leverandørrisiko kan følges opp
Et leverandørregister bør forklare hvorfor en leverandør er viktig. Antall spørreskjemaer sendt ut sier lite om risikoen ved én driftspartner med privilegert tilgang. Registrer hvilke tjenester leverandøren støtter, hvem som eier avtalen, og hvilke avhengigheter som finnes videre i leverandørkjeden. Det gjør det mulig å prioritere oppfølging der svikt faktisk kan ramme virksomheten.
Be om en demonstrasjon hvor en leverandør svarer ufullstendig. Kan saksbehandleren be om et konkret bevis, registrere en midlertidig vurdering og opprette et tiltak med frist? Kan dere skille mellom opplysninger leverandøren selv hevder, dokumentasjon dere har lest, og kontroller dere har utført? Dersom systemet behandler alle svar som like pålitelige, kan sammenstillingen gi et misvisende beslutningsgrunnlag.
Se samtidig på ansvarsfordelingen i kontrakten. Varsling fra leverandøren, tilgang til revisjonsopplysninger og bistand ved gjenoppretting må vurderes mot tjenestens kritikalitet. Ingen generell programvarefunksjon erstatter denne avtalegjennomgangen. For personopplysninger kommer også vurderingen av databehandlerrollen og databehandleravtalen etter artikkel 28. Leverandørsikkerhet og personvern kan dele dokumentasjon, men de har ikke identiske vurderingskriterier.
Vurder bevisenes kvalitet og levetid
Et bevisregister blir fort foreldet hvis dokumenter bare lastes opp én gang. Be om å se hvordan gyldighet, dokumenteier og neste vurdering angis. En rapport kan gjelde en annen konsernenhet, et annet datasenter eller en tidligere tjenesteversjon. Verktøyet bør hjelpe dere å registrere avgrensningen, slik at dokumentet ikke fremstår som generell dekning for hele leveransen.
Prøv en endring mens demonstrasjonen pågår. Bytt ansvarlig medarbeider, legg til et nytt driftssystem og trekk tilbake en tidligere godkjenning. Undersøk om berørte tiltak og vurderinger blir synlige, og om historikken viser årsaken. En automatisk påminnelse er nyttig bare dersom den sendes til en person som har myndighet og tid til å handle. Rutinen for oppfølging må derfor beskrives sammen med funksjonen.
For tekniske logger bør dere avklare om plattformen skal lagre rådata eller bare dokumentere kontrollen av dem. Unødvendig kopiering kan gi både kostnader og tilgangsproblemer. En rutine for sikkerhetslogger kan fastsette hvilke hendelser som undersøkes, hvor lenge opplysninger beholdes, og hvem som får se dem. Be leverandøren vise hvordan følsomme vedlegg skjermes fra brukere som bare trenger status.
Hold GDPR, DORA og NIS-arbeidet atskilt der det trengs
Felles organisasjonsdata og systemoversikter kan spare dobbeltarbeid. Likevel er en behandlingsprotokoll etter GDPR noe annet enn en oversikt over kritiske tjenester. Den beskriver behandling av personopplysninger, mens sikkerhetsstyringen også kan omfatte systemer uten slike opplysninger. Ved anskaffelse av programvare for behandlingsprotokoll bør dere derfor kontrollere at koblingen beholder begge perspektivene.
Finansielle virksomheter må vurdere sitt særskilte regelverk. Bruk oversikten over DORA i Norge til den rettslige avklaringen og kjøpsveiledningen for DORA-programvare til krav som gjelder denne anskaffelsen. At leverandøren har flere regelverksfaner, dokumenterer ikke at plikter, unntak og rapporteringsformat er korrekt innarbeidet for virksomhetens situasjon.
Et felles verktøy kan passe når de samme personene forvalter overlappende dokumentasjon. Separate løsninger kan passe når sikkerhetsoperasjoner, personvern og finansielt tilsyn krever forskjellige arbeidsflater. Sammenlign kostnaden ved integrasjon og dobbeltregistrering med kostnaden ved en for omfattende plattform. Den bredere sammenligningen av GDPR-programvare belyser personvernsiden, men avgjør ikke behovet for operativ sikkerhetsstøtte.
Undersøk tilgang, eksport og leverandørbytte
Programvaren kan inneholde sårbarheter, interne hendelsesbeskrivelser og avtaler som virksomheten ikke ønsker å spre. Be om en rollemodell som skiller administrasjon, faglig redigering, ledelsesbeslutning og ekstern innsynstilgang. Demonstrer en konsulent som bare skal se ett prosjekt. Kontroller både selve oppføringene, vedlegg, søk og eksport; en skjult meny er ikke tilstrekkelig avgrensning.
Krev en prøveeksport før avtalen inngås. Den bør inneholde relasjoner mellom tjenester, risikoer, tiltak og bevis, sammen med tidsstempler og nødvendig historikk. Et pent PDF-sammendrag kan være nyttig til et møte, men uegnet til videre arbeid i en annen løsning. Be virksomhetens egne medarbeidere åpne eksporten og forklare en beslutning uten tilgang til leverandørens portal.
Avklar også sletting, sikkerhetskopier og bistand ved avslutning. Hvor lenge vil dere ha lesetilgang, hva koster migreringshjelp, og hvilke data kan holdes tilbake etter kontrakten? Et ønske om lang historikk må balanseres mot behovet for å begrense tilgang og lagring. Dersom avtalen ikke beskriver leverandørbytte, kan et rimelig inngangstilbud gi uventet merarbeid senere.
Sammenlign tilbud på samme arbeidsmengde
Be alle kandidater prise det samme scenarioet: antall juridiske enheter, tjenester, interne brukere, eksterne bidragsytere og forventede integrasjoner. Skill abonnement fra oppsett, migrering, opplæring og løpende rådgivning. Ikke forutsett at ord som «ubegrenset» dekker lagring, API-bruk, regelverksoppdateringer eller eksport. Disse grensene bør stå i tilbudet og kunne følges opp i kontrakten.
Lag et internt estimat for arbeidet som fortsatt må utføres. Hvem kvalitetssikrer risikovurderinger, hvem følger opp leverandører, og hvem vurderer hendelser? Ta med tiden som brukes på å rette data og vedlikeholde integrasjoner. Prinsippene i veiledningen om programvarekostnader kan brukes som støtte, men prisene må innhentes for akkurat denne leveransen.
Vekt vurderingskriteriene før demonstrasjonene. En virksomhet med mange driftspartnere kan prioritere avhengigheter og oppfølging, mens en liten sikkerhetsfunksjon kan prioritere forståelig arbeidsflyt og enkel eksport. Marker absolutte minstekrav separat. Et system som ikke kan avgrense ekstern tilgang, bør ikke vinne fordi det har mange mindre funksjoner som gir ekstra poeng.
Avklar hvordan regelverksinnhold blir vedlikeholdt
Spør hvem som oppdaterer kravbiblioteket, og hvordan virksomheten får vite at en endring trenger vurdering. Et nytt regelverksnavn i menyen er ikke nok. En nyttig oppdatering bør identifisere kilden, datoen, berørte krav og mulige konsekvenser for eksisterende vurderinger. Dere må kunne se forskjellen mellom leverandørens tolkning og den rettslige teksten som tolkningen bygger på.
Be leverandøren vise en tidligere endring som et eksempel, uten å forutsette at en bestemt historikk finnes. Kan virksomheten beholde sin gamle vurdering, dokumentere ny vurdering og forstå hvilke tiltak som følger? Avklar også hvem som følger norske kilder og sektorspesifikke regler. Hvis dette ansvaret ligger hos dere, må det inngå i driftsmodellen og kostnadsberegningen. Programvaren kan varsle om en endring, men en navngitt ansvarlig må avgjøre hva den betyr for virksomheten.
Gjør piloten til en beslutning som kan etterprøves
Avgrens piloten til én tjeneste, ett risikoforløp og én hendelsesøvelse. Bruk representative, ufølsomme eksempeldata og avtal hvem som skal evaluere resultatet. La de som senere skal bruke systemet, utføre oppgavene selv. Leverandørens demonstratør kjenner snarveiene; det er virksomhetens evne til å fullføre arbeidet som bør avgjøre vurderingen.
Noter hvor brukerne stopper, hvilke forklaringer de trenger, og hvilke opplysninger de må holde utenfor løsningen. Disse funnene kan gi et bedre innføringsestimat enn antallet tilgjengelige funksjoner. Før beslutningen tas, bør hvert vesentlig avvik være enten løst, akseptert av rett person eller knyttet til et konkret kontraktsvilkår. Et løfte om en fremtidig funksjon er ikke det samme som en tilgjengelig leveranse.
Resultatet bør være et kort beslutningsnotat med rettslig avgrensning, prioriterte behov, dokumenterte demonstrasjoner, gjenstående arbeid og samlet kostnad. Oppgi også hva som ville utløse en ny vurdering, for eksempel endret regelverk eller vesentlig vekst. Da kan virksomheten forklare hvorfor løsningen ble valgt, også når medarbeidere eller leverandørrepresentanter senere skiftes ut.
Vanlige spørsmål før kjøp
Må vi kjøpe et NIS2-verktøy?
Nei, en produktetikett er ikke et generelt lovkrav. Dere må håndtere de pliktene som faktisk gjelder og kunne dokumentere arbeidet. Eksisterende systemer kan være tilstrekkelige dersom ansvar, bevis og oppfølging fungerer. Ny programvare bør begrunnes med et konkret behov og prøves mot det behovet før dere binder dere.
Gjelder NIS2s EU-gebyrer automatisk i Norge?
Nei. Reaksjoner må vurderes etter det regelverket og den jurisdiksjonen som faktisk gjelder. Den norske digitalsikkerhetsloven har egne bestemmelser om blant annet pålegg, tvangsmulkt og overtredelsesgebyr, omtalt i NSMs introduksjon til regelverket. Lovens reaksjonsbestemmelser må ikke erstattes av en generell presentasjon av EU-direktivets rammer. Programvarekjøp gir heller ingen garanti mot reaksjoner eller ledelsesansvar.
Kan en sertifisering eller standardpakke avgjøre valget?
Den kan gi relevant dokumentasjon, men dere må undersøke omfang, periode, kontrollresultater og forholdet til egne behov. En standardpakke kan gjøre kartlegging enklere; den avgjør ikke hvilke tjenester virksomheten har, hvilke krav som gjelder, eller om tiltak virker. Be derfor om å følge ett bevis fra faktisk kontroll til ledelsesbeslutning før dere godtar samlet status.