Seks komponenter NIS2 krever av hver virksomhet — uavhengig av teknologivalg
Den 1. juli 2026 åpner registreringsportalen for digitalsikkerhetsloven. Første tilsyn fra NSM starter i oktober. Rundt 5000 norske virksomheter er direkte i scope. Men det egentlige tallet — de som vil få NIS2-krav reflektert tilbake til seg gjennom kontrakter, revisjoner og leverandørvurderinger — er langt høyere.
Denne artikkelen handler om noe svært konkret: hvilke seks tekniske komponenter en NIS2-konform virksomhet må ha på plass — uavhengig av om man bygger med Microsoft, Arctic Wolf eller en hybrid.
Komponentene er regelverksstyrt, ikke produktstyrt. Det betyr at hovedspørsmålet ikke er «hvilken leverandør», men «hvilke funksjoner er på plass, hvem eier dem, og hvordan dokumenteres det at de virker».
To ulike NIS2-samtaler
Det er to samtaler om NIS2 i norske ledergrupper akkurat nå.
Den første handler om styreansvar — som beskrevet i den første artikkelen i denne serien. Den handler om at styremedlemmer i virksomheter i scope nå personlig kan holdes ansvarlige for cybersikkerhetsbeslutninger. Den samtalen er strategisk og relativt kort: hvordan virksomheten kommer i en defensiv posisjon før tilsynene starter.
Den andre samtalen — den denne artikkelen handler om — er operasjonell. Den handler om hva virksomheten faktisk skal levere. Ikke jus og ansvar, men arkitektur, systemer og prosesser.
Det er samtalen CISO-er, COO-er, IT-direktører og daglige ledere nå må ta for å levere på det styret er pålagt å godkjenne.
Den samtalen starter ikke med teknologivalg. Den starter med arkitektur.
Hvorfor arkitekturen kommer før teknologivalget
NIS2 Artikkel 21 er regelverksstyrt, ikke produktstyrt. Direktivet beskriver ti minimumselementer som handler om funksjoner som må være på plass — risikohåndtering, hendelseshåndtering, driftskontinuitet, leverandørstyring, sikker utvikling, effektvurdering, opplæring, kryptografi, tilgangskontroll og MFA.
Det sier ingenting om hvilke leverandører eller produkter som leverer disse funksjonene.
Det betyr at hver virksomhet i scope må svare på det samme spørsmålet, uavhengig av teknologivalg:
Har vi en arkitektur som leverer alle de ti elementene, med navngitte eiere, dokumentert evidens og kontinuerlig oppfølging?
I praksis kan de ti elementene forenkles til seks tekniske komponenter som må fungere sammen. Hver av dem må være dekket — av Microsoft, Arctic Wolf, en hybrid eller noe helt annet.
Å fokusere på komponentene før leverandørene gir NIS2-prosjektet en struktur som overlever leverandørbytter, lisensendringer og neste «NIS2-løsning» som lanseres i markedet.
Det mange undervurderer: leverandørkjede-konsekvensen
Når NIS2 omtales i norske medier, brukes ofte tallet «5000 virksomheter er i scope». Det er essensielle og viktige virksomheter i de definerte sektorene.
Men direktivets Artikkel 21 punkt 2(d) krever at virksomheter i scope vurderer, overvåker og styrer cybersikkerhetsrisiko gjennom hele verdikjeden.
Det betyr at de må stille krav til leverandørene sine som speiler — og i mange tilfeller går utover — det de selv er pålagt.
I praksis betyr det at dersom du er:
- IT-leverandør til en bank,
- hosting-leverandør til et helseforetak,
- transportør for et energiselskap,
- eller utvikler programvare som inngår i kritisk infrastruktur,
…så vil du i løpet av 2026 sannsynligvis møte:
- nye sikkerhetsklausuler i kontrakter,
- krav om dokumentasjon og modenhet,
- revisjoner og leverandørkontroller,
- krav om rask hendelsesvarsling,
- og forventninger om en operasjonell sikkerhetsorganisasjon.
Hvis du leverer til flere virksomheter i scope, vil du motta varianter av disse kravene fra hver av kundene dine.
Uten en strukturert tilnærming blir dette fragmentert og kostbart. Med en strukturert arkitektur og dokumentasjon blir det håndterbart — og kommersielt forutsigbart.
«Du er kanskje ikke i scope — men kunden din er det.» Det er den operative realiteten mange virksomheter nå må forholde seg til.
De seks komponentene som må være på plass
Den stakk-uavhengige NIS2-referansearkitekturen — seks komponenter som hver må være dekket. Hvilken leverandør som leverer hva er en sekundær beslutning.
Når man forenkler de ti elementene til funksjonelle blokker, kan en NIS2-konform virksomhet beskrives som seks arkitekturkomponenter som må fungere sammen.
Komponent A — Identitet og tilgang
Autentisering, autorisasjon, MFA, privilegert tilgang og joiner-mover-leaver-prosesser.
Dette er fundamentet. Hvis identitetslaget er svakt, leverer ikke de andre komponentene mot NIS2.
Typiske leveranser:
Microsoft Entra ID + Conditional Access + PIM, eller alternativer som Okta, Ping og Duo.
Komponent B — Endepunkt og data
EDR, kryptografi, asset management og sikker enhetskonfigurasjon.
Typiske leveranser:
Intune + Defender for Endpoint, eller alternativer som CrowdStrike Falcon, Cortex XDR eller SentinelOne.
Det viktigste er ikke hvilken EDR som velges — men at én primærplattform faktisk er valgt, driftet og fulgt opp.
Komponent C — Deteksjon og respons (SOC)
24/7 overvåkning, triage og respons.
Dette er ofte gapet mellom regelverk og virkelighet i norske mellomstore virksomheter, fordi kontinuerlig SOC krever både bemanning, kompetanse og tuning.
Komponent D — Loggmottak og retensjon
Sentralisert logging, langtidsretensjon og søkbarhet ved hendelser.
Komponent E — Risikohåndtering og effektvurdering
Sårbarhetsstyring, attack surface management, sikkerhetsrevisjon og testing.
Komponent F — Cyberhygiene og opplæring
Awareness-programmer, phishing-simuleringer, dokumentert opplæring og styreopplæring etter Artikkel 20.
I tillegg kommer to tverrgående områder:
- driftskontinuitet,
- og leverandørkjede-sikkerhet.
For virksomheter som utvikler programvare kommer også sikker utvikling som egen disiplin.
Hvordan arkitekturvalgene faktisk ser ut i praksis
Det finnes i praksis to dominerende arkitekturmønstre i norske mellomstore virksomheter.
Mønster A — Konsolidert Security Operations-leverandør
En leverandør som Arctic Wolf leverer SOC/MDR, logging, risikostyring og awareness som integrert tjeneste.
Virksomheten beholder identitet og endepunkter, men kobler disse inn mot leverandørens deteksjonsplattform.
Konsekvens:
Én leverandør, én SLA, én rapporteringslinje.
Mønster B — Microsoft-baseline med intern drift
Microsoft 365 + Intune + Defender XDR + Sentinel + Purview leverer store deler av arkitekturen.
Men denne modellen forutsetter ofte:
- intern SOC-kompetanse,
- kontinuerlig tuning,
- vedlikehold av Sentinel,
- og drift av awareness-programmer.
Konsekvens:
Høy fleksibilitet — men også høy egeninnsats.
I praksis ender mange virksomheter med en hybridmodell:
Microsoft for identitet og endepunkt, kombinert med MDR/SOC-tjenester fra en ekstern leverandør.
Det er ikke en kompromissløsning. For mange mellomstore virksomheter er det den mest modne og realistiske NIS2-arkitekturen.
Hovedpoenget er uansett ikke hvilken leverandør som velges.
Hovedpoenget er at uten en bevisst arkitektur med dokumentert evidens og navngitte eiere per komponent, er virksomheten ikke NIS2-konform — uavhengig av hvor mange lisenser som er kjøpt.
Tre spørsmål du kan stille på neste ledergruppemøte
1. «Hvem eier hver av de seks komponentene — og hvor er det dokumentert?»
En NIS2-konform arkitektur har navngitte eiere per komponent.
Ikke «sikkerhetsteamet». Ikke «HR og IT i samarbeid».
Personer.
Hvis svaret begynner med «det avhenger av» — så er det jobben.
2. «Hvilke komponenter har vi i dag — og hvilke leveres som tjeneste versus intern drift?»
Bygg en enkel matrise:
seks komponenter × leveransemodell.
Marker:
- intern drift,
- tjenesteleveranse,
- eller gap.
Det er ofte første gang virksomheten får et reelt bilde av sin faktiske NIS2-tilstand.
3. «Hva koster det å lukke gapene før oktober — og hva koster det å la være?»
Det er ikke et retorisk spørsmål.
NIS2 åpner for sanksjoner opptil €10 millioner eller 2 % av global omsetning for essensielle virksomheter.
Det gjør kostnaden ved manglende modenhet til en konkret styresak.
Veien til første tilsyn — måned for måned
Mai 2026
Formell scope-vurdering.
Etabler prosjektorganisering og eierskap per komponent.
Bestill modenhetsgjennomgang.
Juni 2026
Prioriter gapene.
Vedta plan og ressursbehov.
Velg leveransemodell for komponentene som mangler.
Juli 2026
Registrer virksomheten.
Etabler varslings- og beredskapsorganisasjon.
Gjennomfør første tabletop-øvelse.
August 2026
Lever de første tekniske forbedringene.
Oppdater leverandørkrav og kontrakter.
Etabler kvartalsvis rapportering til styret.
September 2026
Slutt-trening.
Dokumentasjon og rollefordeling på plass.
Siste mulighet til å lukke kritiske gap.
Oktober 2026
Tilsynet starter.
Ingen virksomheter er «ferdige». Men forskjellen mellom et godt og et dårlig første tilsyn ligger i de fem foregående månedene.
Det viktigste å ta med seg
NIS2 er ikke en hendelse. Det er en operasjonell modningsprosess som kommer til å strekke seg over flere år.
Det første tilsynet er ikke målstreken — men det er en milepæl med konsekvenser for virksomheten, ledelsen og styret.
For virksomheter i scope: Bruk månedene fram mot oktober godt.
For virksomheter som ikke er direkte i scope, men leverer til virksomheter som er:
Forvent kundekrav, revisjoner og dokumentasjonsforespørsler i andre halvår 2026.
De som kan dokumentere modenhet og strukturert sikkerhetsarbeid kommer til å vinne kontrakter. De som ikke kan det, kommer til å tape dem.
Og uavhengig av om virksomheten velger Microsoft, Arctic Wolf eller en hybrid:
Start med komponentene — ikke med leverandørene.
Det er den eneste arkitekturen som overlever leverandørbytter, lisensendringer og neste reguleringsregime.
nLogic Security
nLogic er en pålitelig nordisk partner for nettverks- og sikkerhetsløsninger med høy ytelse, og hjelper virksomheter med å bygge sikkerhet som et system — fra styringsprosesser og leverandørkjeder til operasjonell sikkerhet og teknisk modenhet.
Denne artikkelen om NIS2-operasjonalisering er utarbeidet av nLogic Security, sikkerhetsteamet i nLogic.
Teamet arbeider med sikkerhetsarkitektur, SOC/MDR-strategi, identitet og tilgang, compliance, leverandørkjede-risiko og operasjonell sikkerhet i komplekse virksomhetsmiljøer.
Arbeidet handler ikke bare om teknologi, men om hvordan virksomheter faktisk bygger styringsmodeller, sikkerhetsarkitektur og dokumentasjon som tåler regulatoriske krav, revisjoner og reelle hendelser.
Disse artiklene er en del av nLogics arbeid med kunnskapsdeling, analyse og praktisk risikoreduksjon for virksomheter som skal operere under NIS2, Zero Trust-prinsipper og moderne regulatoriske krav til cybersikkerhet.
Powered by Knowledge. Driven by Trust.
Denne artikkelen fokusere på den operative siden av NIS2, hvordan virksomheter faktisk bygger en arkitektur og organisasjon som tåler tilsyn, leverandørkrav og regulatorisk oppfølging.
I den første artikkelen i serien så vi nærmere på hvordan NIS2 endrer styreansvar, personlig eksponering og forventningene til virksomhetsstyring på cybersikkerhetsområdet.
Ta kontakt for mer informasjon
