NIS2 og DORA på WordPress: hva en nettside må oppfylle i 2026

#NIS2 og DORA på WordPress: hva en nettside må oppfylle i 2026

To EU-rettsakter definerer i 2026 hva som kreves på cybersikkerhetssiden av en WordPress-nettside som driver regulert virksomhet i unionen: NIS2-direktivet (2022/2555) og DORA-forordningen (2022/2554). De er ikke utbyttbare. NIS2 er et direktiv med bredt sektorområde, transponert til nasjonal rett. DORA er en sektorforordning (finans) som gjelder direkte. Begge gjelder for WordPress hvis og bare hvis virksomheten som driver nettsiden er innenfor virkeområdet.

Artikkelen henger sammen med pillaren om headless WordPress-tjenester der det tekniske laget er beskrevet, og med pillaren om WCAG, BFSG og EAA, fordi tilgjengelighets- og cybersikkerhets-compliance i stadig større grad havner i samme innkjøpsforespørsel.

#TL;DR

• NIS2-transponeringsfrist: 2024-10-17. DORA gjelder fra 2025-01-17.
• NIS2: 18 sektorer, delt mellom vesentlige og viktige virksomheter.
• DORA: finanssektoren pluss kritiske IKT-leverandører.
• Krav: dokumentert risikostyring, hendelsesrapportering (24/72/30), revisjoner.
• WordPress i seg selv er ikke i virkeområdet; det er virksomheten som driver nettsiden som er det, hvis den er regulert.

#Tre ting man må vite med en gang

For det første, NIS2 og DORA gjelder for virksomheten, ikke teknologien. WordPress er verken “compliant” eller “non-compliant” som CMS. Compliant eller ikke er virksomheten som driver nettsiden. Hvis et sykehus, en bank, en skyleverandør eller en e-handelsoperatør over terskelen er innenfor virkeområdet, kommer også WordPress-nettsiden inn som en del av virksomhetens infrastruktur.

For det andre, nasjonal transponering av NIS2 er forsinket i mange medlemsstater. Fristen 2024-10-17 har gått ut, men flere land var på ulike stadier av lovgivningsprosessen etter denne datoen. Transponeringsstatusen varierer mellom medlemsstatene; sjekk relevant nasjonal rettsdatabase før den endelige revisjonen. For polsk medlemsstats-status er utkastet til endring av loven om det nasjonale cybersikkerhetssystemet offentlig tilgjengelig, og dens aktuelle status må verifiseres i ISAP før en endelig revisjon. Status per 2026-04 krever en separat juridisk vurdering; denne artikkelen erstatter ikke juridisk rådgivning.

For det tredje, DORA gjelder direkte. Forordningen krever ikke transponering. Hvis en finansvirksomhet eller en kritisk IKT-leverandør driver en WordPress-nettside, gjelder DORA-forpliktelsene fra 2025-01-17 uavhengig av nasjonal lovgivningsstatus.

#NIS2: virkeområde

NIS2-direktivet lister 18 sektorer. De vanligste tilfellene der WordPress kommer innenfor virkeområdet:

Vesentlige virksomheter (essential entities):

• Energi (elektrisitet, gass, olje, varme, hydrogen).
• Transport (luft, jernbane, sjø, vei).
• Bankvirksomhet.
• Finansmarkedsinfrastrukturer.
• Helsesektoren (sykehus, referanselaboratorier, legemiddelprodusenter, medisinsk utstyr).
• Drikkevann og avløp.
• Digital infrastruktur (DNS-leverandører, domeneregistre, leverandører av cloud computing, datasenter-tjenesteleverandører, content delivery networks, tillitstjenesteleverandører, leverandører av offentlige elektroniske kommunikasjonsnett).
• Forvaltning av IKT-tjenester (B2B).
• Offentlig forvaltning (vilkår definert i artikkel 2).
• Romfart.

Viktige virksomheter (important entities):

• Post- og kurertjenester.
• Avfallshåndtering.
• Produksjon, foredling og distribusjon av kjemikalier.
• Produksjon, foredling og distribusjon av matvarer.
• Produksjon i sektorene: medisinsk, data og elektronikk, maskin, bil.
• Leverandører av digitale tjenester (nettmarkedsplasser, søkemotorer, sosiale plattformer).
• Forskningsorganisasjoner.

Grunnterskel: mellomstor bedrift (50+ ansatte eller årlig omsetning eller balanse over 10 millioner EUR). Mikrofirmaer og små bedrifter er som regel utenfor virkeområdet, med unntak (for eksempel tillitstjenesteleverandører, TLD-registre, enkelte DNS-leverandører).

En vesentlig virksomhet har strengere forpliktelser. En viktig virksomhet har de samme tekniske kravene, men med mindre intensivt tilsyn.

#DORA: virkeområde

DORA gjelder for omkring 20 typer finansvirksomhet:

• Kredittinstitusjoner.
• Betalingsinstitusjoner.
• Institusjoner for elektroniske penger.
• Verdipapirforetak.
• Leverandører av kryptotjenester.
• Sentrale verdipapiroppgjørsnemnder.
• Sentrale motparter.
• Handelsplasser (børser).
• Transaksjonsregistre.
• Forsikrings- og gjenforsikringsforetak.
• Forsikrings- og gjenforsikringsformidlere.
• Tjenestepensjonsforetak.
• Kredittvurderingsbyråer.
• Revisorer som reviderer årsregnskapet til virksomheter omfattet av DORA.
• Administratorer av kritiske referanseverdier.
• Investeringsfond (UCITS, AIFM).
• Crowdfunding-tjenestetilbydere.
• Verdipapiriseringsregistre.

I tillegg kritiske IKT-tredjepartsleverandører (Critical ICT Third-Party Providers, CTPP) utpekt av europeisk tilsyn. Dette er mekanismen DORA bruker for å trekke forretningspartnere inn i sitt virkeområde, uten at de selv registreres som finansvirksomhet.

En WordPress-nettside drevet av en bank, et forsikringsselskap eller et investeringsfond kommer inn under DORA som del av virksomhetens IKT-systemer.

#Hva som konkret må gjøres: den felles kjernen

NIS2 og DORA har en felles kjerne av tekniske og organisatoriske krav. Implementering på WordPress:

Cyber-risikostyring. Dokumentert risikoregister, prosedyre for risikovurdering og -aksept, sikkerhetspolicyer godkjent av styret. Dette er dokumenter, ikke bare serverkonfigurasjon.

Tilgangskontroll og autentisering. Flerfaktor-autentisering (MFA) kreves for WordPress-administratorer. Sterke passord kreves. Sesjonsutløp kreves. Alle administratorkontoer må være navngitte, ikke delt.

Hendelseshåndtering. Prosedyre for deteksjon, klassifisering og rapportering av hendelser. En vesentlig hendelse under NIS2 er en hendelse med betydelig påvirkning på tjenesteleveransen. Rapportering til CSIRT eller kompetent myndighet innen 24 timer fra deteksjon (tidlig varsling), 72 timer med første vurdering, en måned med sluttrapport.

Forsyningskjedesikkerhet. Et WordPress-plugin, hosting, CDN, leverandør av transaksjons-e-post, SMS-leverandør, AI-leverandør. Hver av dem er del av kjeden. Det må finnes et register, risikovurderinger og kontraktsklausuler.

Forretningskontinuitet og katastrofegjenoppretting. Backup, kontinuitetsplan, gjenoppretting etter katastrofe, testet jevnlig, ikke bare utført.

Personalskolering. Kreves på styrenivå og i den bredere organisasjonen. En “intern presentasjon” er ikke nok; en dokumentert opplæringsplan kreves.

Sikkerhet i utviklings- og vedlikeholdsprosesser. Policyer for programvareutvikling, testing og sårbarhetsstyring. WordPress-core oppdateres; det må plugins også, med en prosess for testing på staging før produksjon.

Kryptografi. En kryptografipolicy, inkludert TLS, kryptering av data i hvile, digitale signaturer. WordPress krypterer ikke databasen som standard; løsningen er kryptering på filsystem- eller databasenivå.

#DORA-spesifikt: forvaltning av IKT-tredjeparter

DORA har en seksjon i kapittel V dedikert til forvaltning av IKT-tredjeparter. Den krever:

• Et register over alle avtaler med IKT-leverandører.
• Klassifisering av avtaler (kritiske, ikke-kritiske).
• Obligatoriske kontraktsklausuler i avtaler med leverandører av kritiske funksjoner.
• En avslutningsprosedyre med migreringsplan.
• Trusselbaserte penetrasjonstester (TLPT) minst en gang hvert 3. år for utvalgte virksomheter.

For en WordPress-operatør betyr dette at hostingleverandøren og kritiske plugins (security plugin, backup plugin, payment gateway plugin) kommer inn i IKT-registeret.

#NIS2-spesifikt: sanksjoner og tilsyn

NIS2-direktivet fastsetter administrative sanksjoner som nasjonale transponeringer omsetter til konkrete beløp. Øvre tak i selve direktivet:

• Vesentlig virksomhet: opptil 10 millioner EUR eller 2 prosent av årlig global omsetning, avhengig av hva som er høyest.
• Viktig virksomhet: opptil 7 millioner EUR eller 1,4 prosent av årlig global omsetning, avhengig av hva som er høyest.

Nasjonale transponeringer kan innføre egne tak; verifiseres i den til enhver tid gjeldende versjonen av loven for relevant jurisdiksjon.

Supplerende sanksjoner: midlertidig suspensjon av sertifisering, midlertidige forbud mot å inneha lederfunksjoner for ansvarlig person. Det siste er den mest synlige endringen i NIS2: ledelsen har personlig ansvar for cyber-risikostyring.

NIS2 artikkel 20 fastsetter dette direkte: ledelsesorganene skal godkjenne tiltakene for cyber-risikostyring, føre tilsyn med gjennomføringen og delta i relevant opplæring. Norge er ikke EU-medlem, men EØS-medlem, så NIS2 må først innlemmes i EØS-avtalen før den får direkte virkning her; i mellomtiden arbeider regjeringen med oppdatering av lov om digital sikkerhet (digitalsikkerhetsloven) for å samkjøre med NIS2-kravene, med Nasjonal sikkerhetsmyndighet (NSM) og Nasjonalt cybersikkerhetssenter (NCSC) som sentrale aktører. I praksis treffer det personlige ansvaret ikke bare styret, men også toppledersjiktet som har operativt ansvar for områder i omfang: IT-direktør, CISO, compliance-leder, personvernombud og operasjonsdirektør. For et WordPress-byrå flytter det hvem som må signere leveransen på kundens side: risikoregister, hendelsesrunbook og leverandørregister må godkjennes av denne ledelseslaget og leveres i bevisform som tåler tilsyn fra NSM.

#Et praktisk implementeringskart for WordPress

Fire arbeidskategorier, en revisjon:

Lag 1, infrastruktur. Compliant hosting. Off-site backup. TLS 1.3. WAF. 24/7 overvåking eller SOC-avtale. Oppdateringspolicy for core, themes, plugins.

Lag 2, applikasjon. MFA for administratorer. Sterke passord. Logging av alle administrative handlinger til en separat strøm. Anti-CSRF. Anti-XSS på malnivå. Inputvalidering. Begrensning av påloggingsforsøk.

Lag 3, organisasjon. Sikkerhetspolicyer. Risikoregister. IR-plan. BCDR-plan. IKT-leverandørregister. Prosedyre for rapportering av hendelser til CSIRT/regulator. Opplæring.

Lag 4, dokumentasjon og revisjon. Prosessdokumentasjon. Revisjonslogger. Periodisk ekstern eller intern revisjon. Oppbevaring med hensyn til GDPR-krav.

Det finnes ingen pålitelig prosentandel av kravene som WordPress oppfyller «rett ut av boksen». Resultatet avhenger av nettstedets rolle, data, arkitektur, leverandører og virksomhetens prosesser. CMS-konfigurasjonen er bare én del av et større kontrollsystem.

#Avklar virkeområdet før den tekniske revisjonen

Det første resultatet bør være en begrunnet avgrensning, ikke en liste over plugins som skal installeres. Identifiser virksomheten som leverer tjenesten, sektor, størrelse, land der den opererer og nettstedets rolle i tjenesteleveransen. Deretter bekrefter juridisk eller compliance-ansvarlig om nasjonal gjennomføring av NIS2, DORA, begge regelverk eller kontraktskrav fra kunden gjelder.

For WordPress kartlegges de faktiske forretningsfunksjonene. En offentlig informasjonsside, kundeportal, et skjema for helseopplysninger og en betalingsflate har ulike risikoprofiler. Registrer hvilke data som går gjennom systemet, hvilke integrasjoner som kan påvirke en transaksjon, hvor hemmeligheter lagres, hvem som har administrativ tilgang, og hvilke tjenester publisering, innlogging og brukerkommunikasjon avhenger av. Ta med DNS, CDN, hosting, kodearkiv, deploypipeline, transaksjons-e-post, sikkerhetskopier og overvåking.

Omfangsmatrisen bør knytte hver forretningsfunksjon til eier, system, leverandør, datatype, kritikalitet og grunnlag for vurderingen. Hvis nettstedet holdes utenfor en del av programmet, dokumenterer du begrunnelsen, godkjenneren og datoen for ny vurdering. Dokumentet støtter revisjonen, men erstatter ikke en tolkning fra kompetent myndighet eller juridisk rådgivning. For norske virksomheter må også status for innlemmelse i EØS og nasjonale regler kontrolleres på vurderingstidspunktet.

#Fra krav til bevis: en kontrollmatrise som kan etterprøves

En sikkerhetspolicy uten bevis på bruk er en erklæring. En konfigurasjon uten kobling til krav og risiko er samtidig vanskelig å forsvare. Hver kontroll bør derfor ha eier, frekvens, beviskilde og prosedyre for unntak.

For WordPress kan bevispakken omfatte eksport av roller og privilegerte kontoer, bekreftelse av MFA, oppdateringshistorikk, sårbarhetsresultater, endringsgodkjenninger, loggretensjon, gjenopprettingsrapport og resultat fra kontinuitetstest. For WAF er et skjermbilde av en aktiv bryter utilstrekkelig. Dokumenter regler, hvem som mottar varsler, hvordan varslene behandles og hvordan konfigurasjonen endres sikkert. For backup er en vellykket, målt gjenoppretting beviset, ikke meldingen om at en jobb er fullført.

Matrisen skiller mellom en kontroll som er utformet, implementert og bekreftet i drift. Dermed blir ikke tilstedeværelsen av et dokument forvekslet med en fungerende prosess. Unntak registreres med risiko, kompenserende tiltak, eier og utløpsdato. Uten en ny vurderingsdato blir et midlertidig unntak lett et permanent og usynlig avvik.

#Hendelsesberedskap uten å gjenta varslingsprosedyren

På dette overordnede nivået er det viktigst å gjøre data og ansvar tilgjengelig før en hendelse oppstår. Overvåkingen må støtte vurdering av tidspunkt, omfang og påvirkning. Logger fra administratoraktivitet, applikasjon, WAF, hosting og identitetsleverandør bør ha synkronisert tid, kontrollert tilgang og en oppbevaringsperiode avtalt med sikkerhet og personvern.

Runbooken angir hvem som klassifiserer hendelsen, sikrer bevis, tar forretningsbeslutninger og kommuniserer med myndighet, CSIRT, kunder og leverandører. Kontaktlisten må være tilgjengelig utenfor WordPress og den primære e-postløsningen. En skrivebordsøvelse kan dekke overtatt administratorkonto, aktivt utnyttet plugin-sårbarhet, DNS-endring, datalekkasje fra et skjema eller bortfall av hosting. Målet er ikke å forutsi alle angrep, men å finne hull i beslutninger, informasjon og kommunikasjon.

Etter øvelsen registreres tid til oppdagelse, eskalering og sentrale beslutninger, manglende informasjon og korrigerende tiltak. Planen bør ikke fremstilles som om den forhindrer hendelser. Den skal redusere usikkerhet og gjøre responsen dokumenterbar.

#Leverandørkontroll, avtaler og en realistisk utgang

Start med ett eid register over hosting, CDN, DNS, domene, SaaS-plugins, betaling, e-post, analyse, backup, kodearkiv og teknisk støtte. For hver leverandør registreres funksjon, data, lokasjoner, underleverandører, avhengigheter, varslingsvilkår, tilgang til bevis og hvordan tjenesten kan erstattes.

Leverandørvurderingen stopper ikke ved et sertifikat. Undersøk om avtalen regulerer varsling, bistand ved hendelser, tilgangs- og revisjonsrettigheter, underleverandører, tilbakelevering eller sletting av data og hjelp ved avslutning. For en kritisk plugin uten et modent alternativ er konsentrasjon og bortfall av vedlikehold egne risikoer. Utgangsplanen bør navngi eier, migreringsrekkefølge, nødvendige eksporter, tester og hvor lenge redusert tjeneste kan aksepteres.

Selv når en WordPress-leverandør ikke er direkte omfattet av DORA, kan en regulert kunde stille tilsvarende krav gjennom avtalen. Det er viktig å skille dette kontraktsansvaret fra en påstand om at leverandøren selv har fått en bestemt lovstatus.

#Akseptanse, begrensninger og løpende styring

Avtal en målbar definisjon av ferdig før utbedringen begynner. Kritiske kontoer skal bestå test av MFA og tilgangsfjerning, oppdateringer skal gå gjennom staging og tilbakerullingsplan, backup skal gjenopprettes, varsler skal nå ansvarlig vakt, og leverandørregisteret skal ha eier og neste gjennomgang. Et funn lukkes etter retest i riktig miljø og vedlagt bevis, ikke bare fordi en endring er distribuert.

Sluttrapporten skiller mellom bekreftede kontroller, delvis implementerte kontroller, forhold som ikke kunne verifiseres i omfanget, leverandøravhengigheter og akseptert restrisiko. En WordPress-revisjon kan ikke bekrefte organisasjonsprosesser som ikke er undersøkt. Den er heller ikke en sertifisering eller garanti mot sikkerhetshendelser.

Etter første utbedring opprettholdes endringsregister, periodisk gjennomgang av leverandører og privilegerte kontoer, gjenopprettingstester og øvelser tilpasset risikoprofilen. Vesentlige endringer i arkitektur, innlogging, hosting eller integrasjoner utløser ny vurdering. Ledelsen eller utpekt risikoeier bør få en kort oversikt over unntak, hendelser, testresultater og forsinkede tiltak, ikke bare en teknisk sårbarhetsliste.

For et omfang som kan estimeres, send en skriftlig brief med nettstedets adresse, sektor og markeder, WordPress-løsningens rolle, kritiske reiser, leverandører, hostingmodell, kjente risikoer og ønsket tidsplan. En NIS2- og DORA-beredskapsvurdering kan da omfatte teknisk avgrensning, bevismatrise, utbedringsplan og retest. Juridisk virkeområde og eventuelle meldinger til myndigheter må bekreftes av virksomhetens juridiske eller compliance-funksjon.

#Hva som skjer videre

Praktiske konsekvenser for valg av team som driver WordPress: et byrå som driver nettsiden for en virksomhet omfattet av NIS2 eller DORA, blir selv en del av forsyningskjeden. Vår karriereside nevner EU-jurisdiksjon og compliance som standard, fordi dette er et innkjøpsfilter i 2026.

#Hvor denne artikkelen passer inn

Artikkelen henger sammen med pillaren om headless WordPress-tjenester (teknisk lag), pillaren om WCAG/BFSG/EAA (tilgjengelighets-compliance på samme innkjøps-scoreboard), WPPolands karriereside (signal om EU-jurisdiksjon) og artikkelen om nearshore Polen (EU-jurisdiksjon som verdi for den vestlige kjøperen).