Leverandørstyring – krav under NIS2, DORA og digitalsikkerhetsloven, og hvordan små virksomheter gjør det i praksis

Leverandørstyring er arbeidet med å kartlegge hvilke leverandører virksomheten er avhengig av, vurdere hvilken risiko hver av dem utgjør for IKT-sikkerheten, stille krav i avtaler og følge opp at kravene faktisk holdes. Fram til nylig var dette noe de fleste små og mellomstore virksomheter gjorde etter beste evne, eller ikke i det hele tatt. Det er ikke lenger valgfritt. NIS2 og DORA stiller eksplisitte krav til risikostyring av leverandører, og digitalsikkerhetsloven gjør allerede i dag oppfølging av leverandører til en plikt for virksomheter som er omfattet.

Grunnen er enkel. Et angrep mot en leverandør er i praksis et angrep mot alle kundene. Når regnskapssystemet, skyplattformen eller IT-driftsleverandøren blir kompromittert, er det deres data, deres drift og deres ansvar som rammes. Regelverkene flytter derfor ansvaret dit det hører hjemme: hos virksomheten som velger og bruker leverandøren.

Hva leverandørstyring er – og hvorfor det angår dere nå

Leverandørstyring omfatter hele livsløpet til en leverandørrelasjon:

• Kartlegging: Hvilke leverandører har dere, og hva leverer de?
• Risikovurdering av leverandører: Hva skjer med dere hvis leverandøren feiler, blir angrepet eller forsvinner?
• Krav og avtaler: Hvilke sikkerhetskrav stiller dere, og står de skriftlig?
• Oppfølging: Hvordan vet dere at kravene etterleves etter at kontrakten er signert?

Mange virksomheter med 50 til 249 ansatte har mellom 20 og 60 leverandører som på en eller annen måte berører IKT-systemene. Det inkluderer ikke bare IT-driftsleverandøren, men også lønnssystemet, CRM-verktøyet, e-postleverandøren, backupløsningen, nettbutikkplattformen og alarmselskapet som har fjerntilgang til lokalene.

Det som gjør dette til et regulatorisk spørsmål nå, er at regelverkene ikke lenger nøyer seg med at dere sikrer egne systemer. De krever at dere kan dokumentere at dere har vurdert risikoen i leverandørkjeden og håndtert den. Kan dere ikke vise dette, har dere et avvik, uavhengig av hvor godt dere har sikret egen infrastruktur.

Hvilke regelverk som stiller krav

Tre regelverk er sentrale for norske virksomheter. De gjelder ulike grupper, og det er viktig å vite hvilket som treffer dere.

NIS2 artikkel 21(2)(d) om sikkerhet i leverandørkjeden

NIS2-direktivet (EU 2022/2555) pålegger vesentlige og viktige virksomheter å innføre risikostyringstiltak for cybersikkerhet. Artikkel 21(2)(d) nevner sikkerhet i leverandørkjeden eksplisitt, inkludert sikkerhetsrelaterte forhold i avtaler mellom virksomheten og dens direkte leverandører og tjenesteleverandører.

Hvem gjelder det for: Virksomheter i sektorene direktivet lister opp (blant annet energi, transport, helse, vann, digital infrastruktur, offentlig forvaltning, produksjon av visse varer, avfallshåndtering, post og næringsmidler) som er mellomstore eller større. Mellomstor betyr i denne sammenhengen minst 50 ansatte eller årsomsetning over 10 millioner euro. Det vil si at de fleste virksomheter i Kravklars målgruppe er i eller nær virkeområdet hvis de er i en av sektorene.

Status i Norge: NIS2 er ikke innlemmet i EØS-avtalen ennå. Det er derfor ikke mulig å oppgi en bekreftet dato for når direktivet gjelder i Norge. Det som gjelder i dag, er digitalsikkerhetsloven og digitalsikkerhetsforskriften, som trådte i kraft 1. oktober 2025. De gjennomfører det opprinnelige NIS-direktivet og stiller allerede krav til risikostyring og til oppfølging av leverandører. Virksomheter som forbereder seg på NIS2, oppfyller samtidig kravene i dagens lov.

DORA for finansforetak

DORA (forordning EU 2022/2554) gjelder finansforetak: banker, forsikringsselskaper, verdipapirforetak, betalingsforetak, forvaltningsselskaper, pensjonsforetak og en rekke andre. Kapittel V handler om styring av IKT-tredjepartsrisiko og er det mest detaljerte regelverket som finnes om leverandørstyring.

Kjernekravene i kapittel V:

• Foretaket skal ha en strategi for IKT-tredjepartsrisiko og vurdere konsentrasjonsrisiko (for mange kritiske tjenester hos samme leverandør).
• Foretaket skal føre et register over alle avtaler om IKT-tjenester fra tredjeparter, med egne felt for tjenester som støtter kritiske eller viktige funksjoner.
• Avtaler skal inneholde nærmere angitte bestemmelser om blant annet tjenestenivå, sikkerhet, revisjonsrett, hendelsesvarsling, underleverandører og avslutning.
• Foretaket skal ha exitstrategier for kritiske tjenester.

DORA-loven og DORA-forskriften trådte i kraft i Norge 1. juli 2025 og gjelder de fleste foretak under Finanstilsynets tilsyn.

IKT-forskriften er opphevet – DORA gjelder hele finanssektoren

Forskrift om bruk av informasjons- og kommunikasjonsteknologi (IKT-forskriften) fra 2003 regulerte lenge utkontraktering av IKT-virksomhet i finanssektoren, med krav om skriftlig avtale, at foretaket beholder ansvaret, og innsyn for foretaket, revisor og Finanstilsynet. Forskriften ble opphevet 1. september 2026. Fra samme dato følger også finansieringsforetak, eiendomsmeglingsforetak og inkassoforetak deler av DORA-regelverket, med tilpasninger i DORA-forskriften. Finanssektoren har dermed ett IKT-regelverk, ikke to. Søker dere fortsatt etter kravene i IKT-forskriften, er det DORA-loven og DORA-forskriften dere skal lese.

Kort oppsummert: Er dere et finansforetak, gjelder DORA nå. Er dere i en NIS2-sektor, gjelder digitalsikkerhetsloven nå og NIS2 senere. Er dere ingen av delene, er leverandørstyring likevel det kundene, forsikringsselskapet og revisor kommer til å spørre om.

En enkel modell for små virksomheter

Dere trenger ikke et eget compliance-team for å gjøre dette forsvarlig. En modell i fire trinn dekker det regelverkene krever, og lar seg gjennomføre av én IT-ansvarlig med støtte fra daglig leder.

1. Kartlegg

Lag en liste over alle leverandører som leverer IKT-tjenester, har tilgang til systemene deres eller behandler data på deres vegne. Start med fakturaene fra regnskapet, gå deretter gjennom brukerkatalogen og se hvilke eksterne kontoer og integrasjoner som finnes.

For hver leverandør noterer dere hva de leverer, hvilke data de har tilgang til, og hvilke prosesser hos dere som stopper hvis leverandøren faller bort.

Eksempler på leverandørtyper dere typisk finner:

• Skyleverandør (Microsoft 365, Google Workspace, Azure, AWS)
• Regnskaps- og lønnssystem (Tripletex, Visma, PowerOffice)
• IT-drift og support (lokal driftspartner med administratortilgang)
• SaaS-verktøy (CRM, prosjektstyring, HR-system, e-signering)
• Nettverk og telefoni (internettleverandør, sentralbord)
• Fysisk sikkerhet med fjerntilgang (alarm, adgangskontroll, kameraovervåking)

2. Klassifiser

Del leverandørene inn i tre nivåer etter hvor kritiske de er:

• Kritisk: Driften stopper eller sensitive data eksponeres hvis leverandøren feiler. Typisk skyleverandør, IT-drift og regnskapssystem.
• Viktig: Merkbar ulempe, men driften fortsetter. Typisk CRM eller prosjektverktøy.
• Lav: Kan erstattes på dager uten vesentlig skade. Typisk enkeltstående verktøy med lite data.

Klassifiseringen avgjør hvor mye innsats dere legger i de neste trinnene. En kritisk leverandør vurderes grundig og følges opp årlig. En lav leverandør registreres og kontrolleres ved fornyelse.

3. Vurder

Gjennomfør en risikovurdering av hver kritisk og viktig leverandør. Bruk et fast spørsmålssett (se neste avsnitt) slik at vurderingene blir sammenlignbare. Innhent dokumentasjon fra leverandøren: sertifiseringer (ISO 27001, SOC 2), sikkerhetserklæringer, databehandleravtale og beskrivelse av underleverandører.

Vurderingen skal ende i en konklusjon: akseptabel risiko, akseptabel med tiltak, eller ikke akseptabel. Tiltak kan være avtaleendringer, tekniske begrensninger (for eksempel MFA og minst mulig tilgang for driftspartneren) eller plan for bytte av leverandør.

4. Følg opp

Sett en dato for neste gjennomgang på hver leverandør. Kritiske leverandører vurderes årlig, viktige hvert annet år, og alle ved vesentlige endringer som oppkjøp, sikkerhetshendelser eller endret tjenesteomfang. Loggfør hendelser hos leverandører og be om hendelsesrapport når noe skjer.

Hele modellen kan leve i ett regneark med én rad per leverandør. Det er tilstrekkelig dokumentasjon for både digitalsikkerhetsloven og NIS2 for en virksomhet i denne størrelsen. Finansforetak under DORA trenger et mer formelt register med feltene forordningen krever.

Hva en leverandørvurdering bør inneholde

En leverandørvurdering for kritiske og viktige leverandører bør dekke disse punktene:

1. Tjenestebeskrivelse: Hva leverer leverandøren, og hvilke funksjoner hos dere avhenger av tjenesten?
2. Datatilgang: Hvilke data behandler eller får leverandøren tilgang til, og er de personopplysninger eller forretningskritiske?
3. Tilgangsnivå: Har leverandøren administratorrettigheter, fjerntilgang eller integrasjoner mot andre systemer?
4. Kritikalitet: Klassifisering og begrunnelse.
5. Sertifiseringer og attester: ISO 27001, SOC 2 type II eller tilsvarende, med gyldighetsdato.
6. Databehandleravtale: Foreligger den, og dekker den faktisk behandling?
7. Sikkerhetskrav i avtalen: Krav til tilgangsstyring, kryptering, logging og sårbarhetshåndtering.
8. Hendelsesvarsling: Frist og kanal for varsling ved sikkerhetsbrudd hos leverandøren.
9. Underleverandører: Hvem bruker leverandøren, og hvor lagres data geografisk?
10. Kontinuitet og gjenoppretting: Leverandørens plan for driftsavbrudd, og hvilke RTO/RPO dere er lovet.
11. Revisjons- og innsynsrett: Kan dere eller en tredjepart kontrollere leverandøren?
12. Exitplan: Hvordan får dere data ut, og hvor lang tid tar det å bytte?
13. Finansiell og operasjonell stabilitet: Er det risiko for at leverandøren forsvinner?
14. Konsentrasjonsrisiko: Hvor mange kritiske tjenester ligger hos samme leverandør?
15. Konklusjon og tiltak: Risikonivå, besluttede tiltak, ansvarlig og dato for neste gjennomgang.

Punktene 10 til 14 er de som oftest mangler i små virksomheter, og de er samtidig de regelverkene legger mest vekt på.

Vanlige feil

Alt-eller-ingenting-vurderinger. Noen virksomheter sender et spørreskjema på 80 spørsmål til alle leverandører, får svar fra tre, og gir opp. Andre gjør ingenting fordi de ikke rekker å gjøre alt. Riktig tilnærming er å gjøre grundig vurdering av de fem til ti kritiske leverandørene og enkel registrering av resten. Regelverkene krever proporsjonalitet, ikke perfeksjon.

Vurdere én gang og glemme. En leverandørvurdering fra 2023 sier lite om risikoen i 2026. Leverandøren kan ha byttet underleverandør, flyttet data til et annet land eller hatt en hendelse. Uten en fast dato for neste gjennomgang forfaller dokumentasjonen, og dere står uten grunnlag når tilsynet eller kunden spør.

Ingen eier. Når leverandørstyring ikke er tildelt en navngitt person, faller det mellom IT, innkjøp og ledelse. IT-ansvarlig bør eie den tekniske vurderingen, mens daglig leder eier beslutningen om risikoaksept. Begge navnene skal stå i dokumentet.

Krav som ikke står i avtalen. Muntlige forsikringer fra en selger er ikke leverandørstyring. Hvis kravet til hendelsesvarsling innen 24 timer ikke står i kontrakten eller databehandleravtalen, finnes det ikke.

Kom i gang

Last ned Kravklars leverandørvurderingsmal i Excel. Den inneholder de 15 punktene ovenfor som kolonner, en enkel klassifiseringsguide og felt for eier og neste gjennomgang. Malen er laget for at én person skal kunne fylle den ut for 30 leverandører på en arbeidsdag.

Vil dere se hvordan leverandøreksponering henger sammen med resten av sikkerhetsarbeidet, kan dere ta Kravklars egenvurdering. Leverandørstyring er ett av områdene som vurderes, ved siden av tilgangsstyring, hendelseshåndtering, backup og styring. Resultatet viser hvor dere står i forhold til kravene i digitalsikkerhetsloven og NIS2, og hva dere bør prioritere først.