WordPress i Norge og NIS2 - hva byrået må levere i 2026

#WordPress i Norge og NIS2 - hva byrået må levere i 2026

Regulerte norske kunder stiller i 2026 samme spørsmål til WordPress-leverandørene sine: kan dere levere det compliance-folka våre etterspør. De vil ikke ha en juridisk vurdering. De vil ha en mappe med dokumenter som kan legges på revisorens bord uten omskriving.

Mange kaller dette “NIS2-krav”. Juridisk er det upresist, og forskjellen avgjør hvilke frister og hvilke paragrafer mappen skal svare på. Denne artikkelen går gjennom hva som faktisk gjelder i Norge, hva det betyr for et byrå som drifter WordPress for en regulert kunde, og hva mange norske WordPress-byråer fortsatt mangler.

#Gjelder NIS2 i Norge i 2026

Nei, ikke som norsk lov. Norge er ikke EU-medlem, og et EU-direktiv får virkning her først når det er tatt inn i EØS-avtalen og gjennomført i norsk rett. For NIS2 har ingen av delene skjedd ennå.

Det som gjelder, er digitalsikkerhetsloven (LOV-2023-12-20-108) og digitalsikkerhetsforskriften (FOR-2025-06-20-1131). Begge trådte i kraft 1. oktober 2025. Lovdata oppgir EØS-henvisningen til loven som direktiv (EU) 2016/1148, altså det første NIS-direktivet. NSM skriver det samme i kunngjøringen av loven: loven innfører NIS-direktivet, i EU er det erstattet av NIS2, og NIS2 skal etter hvert innføres i norsk rett sammen med CER-direktivet. I NSMs introduksjon til loven står det at arbeidet med det fortsatt pågår. NSMs veileder viser til at Justis- og beredskapsdepartementet har satt i gang prosesser for en samtidig og koordinert gjennomføring av NIS2 og CER, med henvisning til Meld. St. 9 (2024-2025). En dato for når NIS2 gjelder i Norge, er ikke satt.

I EU er tidslinjen en annen. NIS2-direktivet, direktiv (EU) 2022/2555, påla medlemsstatene å vedta nasjonale regler innen 17. oktober 2024 og anvende dem fra 18. oktober 2024 (artikkel 41). Samme dato ble NIS1 opphevet i EU (artikkel 44).

To konsekvenser for et norsk WordPress-byrå:

• Norske kunder i de regulerte sektorene stiller krav etter digitalsikkerhetsloven, ikke etter NIS2. Fristene og kravene er likevel tett på NIS2, se under.
• Kunder i EU som er omfattet av NIS2, sender NIS2-kravene videre gjennom kontrakten. Artikkel 21 nr. 2 bokstav d krever sikkerhet i leverandørkjeden, og artikkel 21 nr. 3 sier at virksomheten skal ta hensyn til sårbarhetene hos hver direkte leverandør og kvaliteten på leverandørens sikkerhetspraksis. Mer om dette i gjennomgangen av NIS2 og DORA for WordPress.

NSM gir selv en praktisk regel: en virksomhet som allerede oppfyller NIS2-kravene, trenger sannsynligvis ikke store tilpasninger for å følge digitalsikkerhetsloven, utover innmelding og varsling. For et byrå med kunder på begge sider av grensen betyr det at én felles baseline er mulig.

#Hvem digitalsikkerhetsloven gjelder for

Loven har to grupper av tilbydere (§ 2):

• Tilbydere av samfunnsviktige tjenester i sektorene energi, transport, helse, vannforsyning, bank, finansmarkedsinfrastruktur og digital infrastruktur. Etter § 6 gjelder det virksomheter som leverer en tjeneste som er viktig for kritiske samfunnsmessige eller økonomiske aktiviteter, som er avhengige av nettverks- og informasjonssystemer for å levere den, og der en hendelse kan forstyrre leveransen betydelig. De skal melde seg inn hos NSM og sektormyndigheten.
• Tilbydere av digitale tjenester etter § 9: nettbaserte markedsplasser, nettbaserte søkemotorer og skytjenester. Skytjeneste er definert som en tjeneste som gir tilgang til en skalerbar og fleksibel samling av delbare databehandlingsressurser.

Forskriften § 2 har et unntak for små virksomheter i den andre gruppen. Tilbydere av digitale tjenester med færre enn 50 ansatte og en årlig omsetning eller balanse som ikke overstiger 10 millioner euro, er unntatt fra sikkerhetskravene i § 15 og varslingsplikten i § 17. NSM understreker i introduksjonen at de øvrige pliktene, som risikovurdering og beredskapsplan, fortsatt gjelder.

Loven § 5 avklarer forholdet til annet regelverk: kravene til sikkerhet og varsling gjelder så langt det ikke er fastsatt tilsvarende eller strengere krav i annen lov. Banker og andre finansforetak har egne IKT-regler, og det er tilsynsmyndighetene som avgjør hvilket sektorregelverk som går foran. NSM presiserer at alvorlige hendelser uansett skal varsles til riktig tilsynsmyndighet med kopi til NSM som nasjonalt kontaktpunkt.

Hva betyr dette for byrået selv. Etter ordlyden faller et byrå som utvikler og vedlikeholder nettsteder, ikke inn under noen av de tre kategoriene i § 9. Et byrå som selger en egen hostingplattform, bør lese definisjonen av skytjeneste og unntaket i forskriften § 2 nøye. For de fleste byråer kommer kravene ikke direkte fra loven, men fra kunden.

#Hvorfor byrået får kravene gjennom kunden

Nøkkelen er forskriften § 14, oppfølgingsplikten. En tilbyder av samfunnsviktige tjenester skal påse at leverandører som utfører arbeid som kan påvirke sikkerheten i nettverk og informasjonssystemer, gjør det slik at kravene til forsvarlig sikkerhet overholdes. Tilbyderen skal gjøre sikkerhetstiltakene gjeldende overfor leverandørene “gjennom avtale eller på annen egnet måte”.

Et byrå med administratortilgang til kundens WordPress, deploy-rettigheter eller tilgang til databasen er en slik leverandør. NSM utdyper i introduksjonen til loven og forskriften hva oppfølgingen innebærer:

• kunden skal følge opp leverandøren løpende, ikke bare kontrollere i etterkant,
• sikkerhetskravene skal gjelde for hver enkelt leverandør og underleverandør, gjennom avtaler, revisjoner, rapportering eller sikkerhetskrav i kjeden,
• kravene skal stå i forhold til risikoen og bygge på kundens dokumenterte risikovurdering,
• plikten gjelder enten hele eller bare deler av tjenesten er satt bort, og eksisterende avtaler skal revideres hvis de ikke gir et forsvarlig sikkerhetsnivå.

Det siste punktet er grunnen til at mange byråer i 2026 får tilsendt en ny databehandler- og sikkerhetsavtale midt i en løpende kontrakt. Standardavtalen fra før loven trådte i kraft dekker sjelden revisjonsrett, varslingsfrister og underleverandørliste.

Loven går også ett skritt lenger. Etter § 14 har både tilbydere og “de som handler på vegne av en tilbyder” plikt til å gi tilsynsmyndigheten de opplysningene den krever, og gi tilgang til lokaler og utstyr. Brudd på § 14 kan etter § 17 gi overtredelsesgebyr også når overtredelsen er begått av noen som handler på tilbyderens vegne. NSM skriver i introduksjonen at hvis en del av tjenesten er satt bort til en underleverandør som ikke selv er underlagt loven, er det tilbyderens ansvar å sørge for tilgang til opplysninger og lokaler hos leverandøren. I praksis havner det som en revisjonsklausul i byråets kontrakt.

#Hvilke tekniske tiltak kunden må kunne dokumentere

Forskriften § 10 lister minstekravene til teknologiske sikkerhetstiltak for tilbydere av samfunnsviktige tjenester. Hvert punkt har en direkte WordPress-side, og det er her byråets dokumentasjon blir kundens bevis:

Forskriften har en regel som ofte overses: kan et av tiltakene ikke gjennomføres, skal virksomhetens leder godkjenne unntaket, begrunnelsen skal dokumenteres i styringssystemet for sikkerhet, og tilsynsmyndigheten skal orienteres. Har kunden for eksempel en eldre redaktørkonto som ikke kan bruke tofaktor, er det ikke byråets beslutning å la den stå. Byrået skal melde det til kunden slik at unntaket kan behandles riktig.

NSM nevner personelltiltak særskilt: ansatte, leverandører og andre med tilgang skal ha tilgang etter rolle, få opplæring, og tilgangen skal fjernes når den ikke lenger trengs. For et byrå betyr det at en utvikler som slutter, skal fjernes fra hver kundes WordPress, hosting, Git-repo og DNS samme dag, og at det finnes en logg som viser det.

#Varslingsfrister etter digitalsikkerhetsloven for WordPress-hendelser

Forskriften § 17 setter fristene for tilbydere av samfunnsviktige tjenester:

• første varsel senest innen 24 timer etter at tilbyderen fikk kjennskap til hendelsen,
• oppdatering av informasjonen innen 72 timer,
• hendelsesrapport innen én måned fra det første varselet ble sendt.

Varselet skal inneholde tilbyderens navn og kontaktinformasjon, berørt tjeneste, hva som har skjedd med mulige årsaker og konsekvenser, antall berørte brukere og virkninger i andre land. Det sendes til tilsynsmyndigheten med kopi til NSM, på NSMs eget skjema. Hendelsesrapporten skal i tillegg vise hvilke avhjelpende tiltak som er satt i verk.

NSM legger til en setning på siden om varsling etter digitalsikkerhetsloven som er skrevet for byråer: fristene er absolutte og gjelder også hvis hendelsen skjer hos en samarbeidspartner eller underleverandør. Et kompromittert WordPress-nettsted hos et byrå er altså kundens 24-timersfrist, ikke byråets interne sak.

Det har tre praktiske følger for byråets rutine:

1. Byrået må varsle kunden så raskt at kunden rekker sitt eget varsel innen 24 timer. Avtalen bør si hvor raskt, til hvem og i hvilken kanal, også utenfor kontortid.
2. Byråets første melding bør allerede inneholde det kunden trenger i skjemaet: hva som er berørt, hva som har skjedd, mulige årsaker og konsekvenser og et anslag over berørte brukere.
3. Byrået må levere grunnlaget for kundens hendelsesrapport, med tidslinje, sannsynlig årsak og tiltak, i god tid før månedsfristen.

Sammenlignet med NIS2 artikkel 23 er strukturen nesten lik: tidlig varsel innen 24 timer, hendelsesmelding innen 72 timer og sluttrapport. Forskjellen ligger i startpunktet for siste frist. I NIS2 løper én måned fra hendelsesmeldingen etter 72 timer. I den norske forskriften løper den fra det første varselet. Et byrå med både norske og EU-kunder bør ha begge fristene i malen. Den detaljerte gjennomgangen av hver frist står i artikkelen om hendelsesrapportering etter 24 timer, 72 timer og én måned.

#Dokumentasjon et WordPress-byrå må levere i 2026

Med § 10, § 14 og § 17 som grunnlag blir mappen konkret. Sju leveranser et WordPress-byrå bør kunne vise frem for en regulert kunde:

• Ansvars- og leverandørerklæring: hva byrået er ansvarlig for, hva kunden er ansvarlig for, hvor data ligger, hvilken jurisdiksjon som gjelder, og hvilke underleverandører som brukes (CDN, feilsporing, deploymentsleverandør, supportverktøy).
• Hendelsesrapporteringsrutine: tidsstemplet rapport ved sikkerhetshendelse med deteksjon, innesperring, rotårsak, tiltak og kommunikasjon. Felt som speiler NSMs varslingsskjema, ikke en uformell e-post.
• Logg over testede gjenopprettinger: bevis på at restore er testet, ikke bare at backup er tatt. Det dekker § 10 bokstav d.
• Tilgangsstyringsoversikt: hvem på teamet har produksjonstilgang, når den ble gitt, når den utløp, og status for sterk autentisering.
• Endringslogg: hver produksjonsendring tidsstemplet og knyttet til en arbeidsoppgave. Den viser at oppdateringer er kvalitetssikret og testet, slik § 10 bokstav f krever.
• Sikkerhetsbaseline: hvilke kontroller er på plass (WAF, herding, plugin-policy, oppdateringsfrekvens, overvåkning), hvilke er ikke, og hvorfor. Ærlig snarere enn markedsføring, fordi et manglende tiltak skal godkjennes av kundens leder.
• Avtaleklausuler: SLA, varslingsfrist mot kunden, exit-plan, revisjonsrett og underleverandørliste.

For byråer som vil bli på leverandørlisten hos regulerte norske kunder, er mappen ikke valgfri. Den samme strukturen finnes i lengre form i bevissporet etter NIS2 vedlegg II.

#Vanlige mangler hos norske WordPress-byråer

De samme hullene går igjen når et byrå skal svare på en leverandørvurdering for første gang.

Loggen over testede gjenopprettinger finnes ikke. Backup-rutinen finnes, men ingen har testet en restore på lang tid. Svaret “vi gjør det ved behov” holder ikke når kunden skal vise at systemene kan gjenopprettes innen rimelig tid.

Hendelsesrapporten er en e-posttråd. Det fungerer for et lite byrå med uformelle rutiner, men ikke for en kunde som skal sende første varsel innen 24 timer og en rapport med rotårsak innen én måned.

Underleverandørlisten er ufullstendig. CDN-leverandøren er listet, men ikke det interne supportverktøyet, deploymentsleverandøren eller analyseverktøyet. Kunden oppdager det først når en hendelse hos en av disse rammer tjenesten, og fristen gjelder uansett.

Sikkerhetsbaseline er markedsføring snarere enn sjekkliste. “Vi har topp sikkerhet” er ikke et svar en revisor kan bruke. Det må være en konkret liste over hva som er på plass og hvilke kontroller som er valgt bort, med begrunnelse.

Tilganger blir ikke trukket tilbake. Tidligere ansatte og frilansere har fortsatt administratorkonto i kundens WordPress eller hostingpanel. NSM krever rutiner for å fjerne tilgang fra personer som slutter eller ikke lenger trenger den.

#Slik kommer byrået i gang med dokumentasjonen

For et byrå som ikke har dette på plass, er rekkefølgen viktigere enn verktøyet:

1. Skriv ned dagens infrastruktur ærlig: underleverandører, jurisdiksjoner, sikkerhetskontroller og backupfrekvens.
2. Test en restore på en sandkasse. Loggfør tidsstempel og resultat.
3. Skriv en hendelsesmal med feltene fra NSMs varslingsskjema, tidslinje, rotårsak og kommunikasjon.
4. Innfør disiplin i endringsloggen: hver deploy får en linje med dato, beskrivelse og ansvarlig.
5. Lag et tilgangsstyringsdokument: hvem har hva, status for sterk autentisering og rutine for tilbaketrekking.
6. Avtal en øvelse med kunden. NSM anbefaler at tilbydere øver beredskapsplanen minst én gang i året og tar med leverandører der det er relevant.

Første versjon blir ikke perfekt. Poenget er at den finnes, er datert og blir oppdatert, fordi risikovurderingen kunden bygger på, skal oppdateres jevnlig og ved hver endring som kan påvirke sikkerheten.

#Dekker hostingleverandøren kravene alene

Nei. En hostingleverandør eller et CDN med egne sertifiseringer dekker sin egen del av leveransen, ikke byråets. Oppfølgingsplikten i § 14 gjelder hver leverandør som utfører arbeid som kan påvirke sikkerheten, og byrået som har administratortilgang og deployer kode, er en av dem. Byrået må derfor dokumentere sin egen rolle og sine egne tiltak, og i tillegg kunne vise hvilke underleverandører det selv bruker og hvor dataene ligger.

#Hva gjelder når kunden ikke er regulert

En kunde utenfor sektorene i § 2 har ingen plikter etter digitalsikkerhetsloven. Grunnlaget er likevel det samme byrået trenger for egen del: testet gjenoppretting, en hendelsesrutine og kontroll med tilganger. Behandler nettstedet personopplysninger, gjelder personopplysningsloven og GDPR uansett, med meldeplikt til Datatilsynet ved avvik. Kunden kan også vokse inn i regulering, eller bli underleverandør til en regulert virksomhet og få kravene gjennom kontrakten.

For en ren brosjyreside er hele mappen for mye. For en kunde som leverer til energi, finans, helse eller digital infrastruktur, er den minimum. En bredere oversikt over standardene som berører CMS-prosjekter, står i guiden til sikkerhetsstandarder for bedrifts-CMS.

#Hvilke sanksjoner digitalsikkerhetsloven gir

Tilsynsmyndigheten kan etter loven gi pålegg om retting (§ 15), tvangsmulkt (§ 16) og overtredelsesgebyr (§ 17). Etter forskriften § 24 kan gebyret utgjøre opptil 25 ganger grunnbeløpet i folketrygden eller fire prosent av foretakets årsomsetning forrige regnskapsår, der det høyeste beløpet er øvre ramme, men aldri mer enn 50 millioner kroner. Ved utmålingen skal det blant annet legges vekt på om tilbyderen gjennom retningslinjer, opplæring, kontroll eller andre tiltak kunne ha forebygget overtredelsen.

Det siste er grunnen til at kunden vil ha byråets dokumentasjon. En kunde som kan vise at sikkerhetskravene var avtalt med leverandøren og fulgt opp, står sterkere enn en kunde som bare kan vise til en tillitsfull relasjon.

#Hva endres når NIS2 kommer inn i norsk rett

Ingen kan si når det skjer, men direktivteksten viser hva som kommer i tillegg. Artikkel 20 krever at ledelsen godkjenner og fører tilsyn med sikkerhetstiltakene, kan holdes ansvarlig for brudd og skal gjennomgå opplæring. Artikkel 21 nr. 2 lister minst ti tiltaksområder, blant annet hendelseshåndtering, kontinuitet med backup og gjenoppretting, sikkerhet i leverandørkjeden, sikkerhet ved anskaffelse, utvikling og vedlikehold inkludert sårbarhetshåndtering, kryptografi og flerfaktorautentisering.

For et WordPress-byrå er det meste allerede dekket hvis mappen over er på plass. Det nye er større vekt på sårbarhetshåndtering i utvikling og vedlikehold, og at kunden etter artikkel 21 nr. 3 skal vurdere hver direkte leverandørs sikkerhetspraksis. Et byrå som bygger dokumentasjonen etter digitalsikkerhetsloven nå, slipper å begynne på nytt når NIS2 blir norsk lov.

#Hvorfor velge et WordPress-byrå med dokumentasjonen på plass

Etterlevelse er ikke bare en kostnad for kunden. Det er risikoreduksjon kunden kan vise til styre, tilsynsmyndighet og forsikringsselskap, og et kriterium som skiller leverandører i en anbudsprosess. Et WordPress-byrå som kan levere mappen samme uke som den blir etterspurt, gjør kundens jobb med forskriften § 14 enklere.

WPPoland bygger WordPress-prosjekter med denne dokumentasjonen som en del av leveransen, fordi det er den eneste måten WordPress kan forbli en ærlig løsning for regulerte sektorer.