NIS2 vs DORA: overlapp i omfang for WordPress-byråer i 2026

#NIS2 vs DORA: overlapp i omfang for WordPress-byråer i 2026

Direktiv 2022/2555 (NIS2) og forordning 2022/2554 (DORA) dekker liknende grunn, men med ulik mekanikk. NIS2 er et direktiv som gjennomføres av hver medlemsstat i nasjonal rett. DORA er en forordning som gjelder direkte. NIS2 dekker et bredt sett med vesentlige og viktige sektorer. DORA er finansspesifikk. Der de overlapper (det meste av risikostyring, hendelseshåndtering, forsyningskjede) kan ett godt bygget bevisspor dekke begge. Der DORA går lenger (informasjonsregister, trusselbaserte penetrasjonstester), må WordPress-byrået legge til deltaene.

Dette er en støtteartikkel inne i pilaren om NIS2 og DORA på WordPress, med kryssreferanser til bevissporet for bilag II, veiledningen om DORA artikkel 28, feltguiden for informasjonsregisteret og tidslinjen 24/72/30 for hendelsesrapportering.

#Kort oppsummert

• DORA er lex specialis for finansielle enheter; NIS2 gjelder ellers.
• Overlapp: risikostyring, hendelseshåndtering, kontinuitet, forsyningskjede, rapportering.
• Kun DORA: skjema for informasjonsregisteret, TLPT for kritiske enheter, preskriptive tredjepartsklausuler.
• Kun NIS2: bredere sektoromfang (energi, transport, helse, offentlig forvaltning), varianter i nasjonal gjennomføring.
• Praktisk regel: hvis noen kunde er under DORA, bygg bevissporet til DORA-nivå og nedskaler for NIS2.

#Hvordan NIS2 selv navngir DORA

Artikkel 1(2) i NIS2 sier: der sektorspesifikke unionsrettsakter krever at vesentlige eller viktige enheter styrer cybersikkerhetsrisiko eller melder betydelige hendelser, gjelder disse sektorspesifikke bestemmelsene. DORA er en av disse aktene. En finansiell enhet i DORAs omfang overholder derfor ikke dobbelt: den overholder DORA, og de tilsvarende NIS2-bestemmelsene anses oppfylt.

Det DORA ikke uttrykkelig adresserer (for eksempel deler av NIS2s ansvar for ledelsesorganet, opplæring, sektorfelles CSIRT-samarbeid), dekker fortsatt NIS2-grunnlinjen.

For et WordPress-byrå betyr dette: hvis kunden er en bank, et investeringsselskap, en betalingsinstitusjon, et forsikringsselskap, en kapitalforvalter, en TPP under PSD2 - dominerer DORA. Bygg til DORA. Hvis kunden er et sykehus, et TLD-register, en energidistributør, en postoperatør - dominerer NIS2. Bygg til NIS2.

#Beslutningstre: NIS2, DORA, eller begge?

Regelen ovenfor (“DORA for finans, NIS2 for alt annet”) holder for de opplagte tilfellene. Den bryter sammen for tilfellene som faktisk tar en ettermiddag å avgrense: et fintech-selskap under terskelen for betydelig enhet, en sykehusgruppe med et betalingsdatterselskap, eller et byrå som aldri har signert noe med ordet «NIS2» i det, men oppdager en klausul om forsyningskjeden gjemt i et bilag. Flytskjemaet nedenfor er gjennomgangen vi bruker på en innledende samtale med en ny kunde, før noen kontraktsgjennomgang starter.

flowchart TD
    A["Er kunden en finansiell enhet under DORA artikkel 2?"] -->|"Ja"| B["Er det en bank, et investeringsselskap, en betalingsinstitusjon, et forsikringsselskap, en kapitalforvalter, eller en PSD2-TPP?"]
    A -->|"Nei"| C["Er kunden i en NIS2-sektor under bilag I eller II: energi, transport, helse, vann, digital infrastruktur, offentlig forvaltning, post, avfall, eller produksjon?"]
    B -->|"Ja"| D["DORA primær: bygg informasjonsregister, TLPT-beredskap, konsentrasjonsrisikoanalyse"]
    B -->|"Nei - under terskel eller unntatt"| C
    C -->|"Ja"| E["NIS2 primær: bygg risikoregister etter artikkel 21, bevisspor for bilag II, delta for nasjonal gjennomføring"]
    C -->|"Nei"| F["Er byrået kontrahert av en enhet som selv er i omfanget, altså er du en IKT-tredjepartsleverandør?"]
    F -->|"Ja - kunden er DORA-omfang"| G["Inntrekking via forsyningskjeden under DORA artikkel 28: kundens kontraktsklausuler fører videre forpliktelser på DORA-nivå"]
    F -->|"Ja - kunden er NIS2-omfang"| H["Inntrekking via forsyningskjeden under NIS2 artikkel 21(2)(d): kundens kontraktsklausuler fører videre forpliktelser på NIS2-nivå"]
    F -->|"Nei"| I["Ingen av regimene gjelder direkte eller indirekte: overvåk kundens vekst og sektorreklassifisering årlig"]
    D --> J["Har konsernet ikke-finansielle datterselskaper som også bruker byrået?"]
    E --> J
    J -->|"Ja"| K["Blandet regime i holdingen: hold bevisene på DORA-nivå som tak og kartlegg datterselskaper individuelt"]
    J -->|"Nei"| L["Ett bevisspor på ett nivå er tilstrekkelig"]

Det er to grener der byråer oftest bommer på svaret. Først grenen «Nei - under terskel eller unntatt» ut av B: en kunde kan være en finansiell enhet under DORA artikkel 2 og likevel ikke være en bank eller et forsikringsselskap i vanlig forstand - crowdfunding-tjenesteleverandører og noen betalingsinstitusjoner ender opp her, og de stopper ikke å være DORA-enheter bare fordi de er små. For det andre grenen F: et byrå uten en eneste regulert kunde på papiret kan fortsatt bli trukket inn i DORA-forpliktelser dersom en av dets hosting- eller vedlikeholdsunderkontrakter ligger under en regulert enhets forsyningskjede, flere ledd nedover.

#Anvendelighetsmatrise

Seks kundearketyper et byrå sannsynligvis vil møte, kartlagt mot primærregime, hvordan forpliktelsen når byrået, og nivået bevissporet bør avgrenses til.

Mønsteret som overrasker nye avgrensningssamtaler: så snart ett kundeforhold hvor som helst i byråets portefølje er DORA-omfang, er det operasjonelt billigere å bygge hvert bevisspor til DORA-nivå og nedskalere for rene NIS2-kunder enn å drive to parallelle dokumentasjonssystemer.

#To anonymiserte avgrensningssaker

Detaljene nedenfor er sammensatt og strippet for identifiserende opplysninger; ingen kundenavn forekommer noe sted i denne delen.

Sak A: regional samvirkebank. En samvirkebank med rundt 40 filialer i én region satte ut sin bedriftsnettside og et internt intranett for ansatte, begge WordPress-baserte, til et eksternt byrå. Banken er en finansiell enhet under DORA artikkel 2 uten forbehold - «samvirke»-strukturen endrer ikke dette. Avgrensningssamtalen bekreftet at byrået måtte oppføres i bankens informasjonsregister som en IKT-tredjepartsleverandør, konkret i tabellene B.02.01 (kontraktsavtaler) og B.05.01 (støttede funksjoner), selv om bankens størrelse holdt den under terskelen for avansert trusselbasert penetrasjonstesting. Byrået måtte likevel besvare konsentrasjonsrisikospørsmålet under artikkel 29 - «hvem andre kan ta over hosting og vedlikehold innen åtte uker» - fordi bankens compliance-ansvarlige behøvde det svaret skriftlig uavhengig av TLPT-status. Den resulterende mappestrukturen for bevissporet gjenspeilte oppsettet 05_dora_register/ beskrevet senere i denne artikkelen, fylt fra dag én av engasjementet i stedet for å bli ettergått rett før en revisjon.

Sak B: kommunal sykehusgruppe. En gruppe kommunale sykehus som driver en delt pasientinformasjonsportal og et intranett for ansatte, begge WordPress-baserte, kontraherte den samme bevissporstilnærmingen, men endte på den motsatte siden av treet. Sykehus ligger i NIS2 bilag I (helsesektor), og gruppen hadde ingen finansiell enhetsstatus noe sted i sin struktur, så DORA kom aldri i bildet. Ingen skjema for informasjonsregisteret ble bygget - det ville vært bortkastet innsats, siden det femten-tabells RoI-formatet er et DORA-spesifikt krav uten NIS2-motstykke. I stedet bygde byrået et enklere leverandørregister pluss et due diligence-spørreskjema og en SLA-klausul for hendelsesmelding knyttet til sykehusets nasjonale NIS2-gjennomføring (som satte egne rapporteringsfrister og kompetent myndighet, forskjellig fra 24t/72t/1-måneds-rytmen brukt ellers i denne pilaren). Den praktiske lærdommen av å sammenligne de to sakene: DORA-omfangskunden kostet omtrent dobbelt så mye i innledende dokumentasjonsarbeid som NIS2-omfangskunden, nesten helt på grunn av skjemaet for informasjonsregisteret, og dette kostnadsgapet er den beste prediktoren for hvilket nivå av bevisspor som bør tilbys for et nytt engasjement.

#Hva som overlapper

Fem store overlappsområder der ett enkelt artefakt betjener begge regimer:

Risikostyring. NIS2 artikkel 21 lister ti tiltak; DORA artikkel 5-15 dekker samme konseptuelle grunn mer detaljert. Et risikoregister som navngir eiendeler, trusler, sannsynlighet, konsekvens og behandling oppfyller begge. Detaljnivået skiller seg: DORA forventer mer granularitet for kritiske eller viktige funksjoner; NIS2 forventer proporsjonalitet.

Hendelseshåndtering. NIS2 artikkel 22-23 og DORA artikkel 17-23 krever begge klassifisering, respons, gjenoppretting, ettergranskning og rapportering. Rapporteringsfristene skiller seg noe (NIS2: 24t tidlig varsel, 72t melding, 1-måneds sluttrapport; DORA: liknende, med sektorspesifikke maler). Den interne håndbok for hendelsesrespons kan deles.

Kontinuitet. NIS2 artikkel 21(2)(c) og DORA artikkel 11 krever begge backup, testet gjenoppretting, off-site, med dokumentert RPO og RTO. En BCDR-plan med én årlig gjenopprettingsøvelseslogg oppfyller begge.

Kontroller for forsyningskjeden. NIS2 artikkel 21(2)(d) og DORA artikkel 28 krever begge leverandørregister, due diligence, kontraktsklausuler, exit-plan. DORAs informasjonsregister er et strengere skjema; å bygge til DORA gir NIS2-forsyningskjede-etterlevelse gratis.

Rapportering. Begge krever rapportering til kompetent myndighet. NIS2 utpeker nasjonal CSIRT og kompetent myndighet; DORA rapporterer til finansregulatoren (nasjonal pluss ESA-ene). Den interne bevisforberedelsen er den samme; adressaten er forskjellig.

#Hva DORA legger til på toppen

Tre delta der DORA går lenger enn NIS2, og WordPress-byrået må legge til spesifikke bevis:

Skjema for informasjonsregisteret. Kommisjonens gjennomføringsforordning 2024/2956 spesifiserer femten tabeller med navngitte kolonner. Dekket i detalj i feltguiden for informasjonsregisteret. NIS2 har ingen motstykke; byrået under kun NIS2-forpliktelser trenger ikke dette skjemaet.

Trusselbasert penetrasjonstesting. DORA artikkel 26 krever avansert TLPT for finansielle enheter klassifisert som betydelige. Byrået som drifter kritisk infrastruktur for en slik enhet kan være i omfang som et testet system. NIS2 nevner sårbarhetshåndtering bredt, men ikke TLPT.

Konsentrasjonsrisiko og substituerbarhet. DORA artikkel 29 krever en uttrykkelig konsentrasjonsanalyse: hvor mange kritiske funksjoner støtter denne tredjeparten, og hvor lett kan den erstattes. Byrået må kunne svare på «hvem andre kan gjøre dette arbeidet innen åtte uker om vi forsvinner». NIS2 har ingen sammenlignbar preskriptiv forventning.

#Hva NIS2 legger til på toppen

To delta der NIS2 rekker lenger enn DORA i ikke-finansielle sammenhenger:

Sektorbredde. Sykehus, ISP-er, telekomoperatører, postoperatører, matproduksjon, offentlig forvaltning, forskningsorganisasjoner er i NIS2. De fleste er ikke i DORA. Byrået som jobber over disse kundesektorene holder ett NIS2-formet spor per sektor.

Varianter i nasjonal gjennomføring. Fordi NIS2 er et direktiv, gjennomfører hver medlemsstat detaljer med lokal smak. Den tyske gjennomføringen (KRITIS-DachG / NIS2UmsuCG) skiller seg fra den polske (KSC) som skiller seg fra den norske. Byrået som opererer over landegrenser holder et lite delta-dokument per jurisdiksjon.

#Ett bevisspor, begge regimer

#Beslutningsmatrise for et WordPress-oppdrag

Start med juridisk enhet, regulert tjeneste og jurisdiksjon, og knytt deretter WordPress-systemet til funksjonen det støtter. Matrisen registrerer om NIS2, DORA, begge eller ingen synes relevante, hvem som gjorde vurderingen og hvilken nasjonal regel som ble kontrollert. Byrået leverer tekniske fakta; kunden og rådgiverne eier den juridiske klassifiseringen.

Når begge regimer berører samme finansielle tjeneste, bør man ikke drive to separate kontrollprogrammer. Bruk DORA som sektorspesifikt utgangspunkt der bestemmelsene gjelder, og behold relevante NIS2- og nasjonale delta. Dette er en konkret vurdering, ikke en generell påstand om at ett regelverk alltid fortrenger det andre.

Bevis kan bare gjenbrukes når omfang, eier, periode og akseptansekriterier samsvarer. Samme gjenopprettingstest kan støtte begge kartleggingene, mens DORA-register og myndighetsmaler forblir separate. Hver kontroll får kundeier, byråeier, kontrollør, lagringssted og oppdateringsutløser. Gap-registeret skiller manglende implementering, manglende bevis og uavklart juridisk tolkning.

Kartleggingen godtas når hver kontroll har bevis eller dokumentert gap, felles artefakter kryssrefereres og restrisiko har en eier. Endring i arkitektur, leverandør, tjeneste eller regelverk utløser ny vurdering. Matrisen er verken sertifisering eller garanti mot hendelser.

#Arbeidsscenario: finanskonsern med offentlig portal

Et finanskonsern bruker WordPress til en offentlig produktportal, skjemaer og et beskyttet partnerområde. Konsernet er i en DORA-kontekst, mens et annet selskap i gruppen samtidig kan levere en NIS2-relevant tjeneste. Det gjør ikke automatisk hver side til et kritisk system. Matrisen knytter derfor hver rute og integrasjon til forretningsprosess, juridisk enhet og dataflyt.

Kunden eier vurderingen av regelverk, kritikalitet og myndighetskontakt. Byrået eier avtalte bevis for applikasjon, endringer og drift. Hosting, identitet og skjematjeneste kan ha andre eiere. En uklar overgang registreres som et styringsgap og legges ikke stilltiende på byrået.

En felles patchrapport kan støtte begge kartlegginger når den gjelder samme produksjonsversjon, periode og testomfang. En gjenopprettingstest av den offentlige portalen beviser derimot ikke nødvendigvis gjenoppretting av partnerområdet dersom identitet, database eller RTO er forskjellig. Aksepten kontrollerer dermed ikke bare at en fil finnes, men at den underbygger den konkrete påstanden.

#Før gap etter årsak, ikke etter regelverk

Ett felles gap-register hindrer doble oppgaver. Årsaken merkes som manglende kontroll, ineffektiv kontroll, manglende bevis, utdatert bevis, uklar eier eller uavklart klassifisering. Deretter refereres berørte NIS2- og DORA-kartlegginger. Utbedringen utføres én gang, mens vurderingen for hvert regime forblir separat og sporbar.

Ved lukking bekrefter kontrolleieren implementasjon og bevis, mens ansvarlig for etterlevelse bekrefter bruken i sitt kart. En teknisk rettelse kan derfor være ferdig selv om et juridisk eller kontraktsmessig spørsmål fortsatt er åpent. Dette hindrer at en grønn utviklingsoppgave blir tolket som full regulatorisk godkjenning.

Beslutningsloggen bør også angi dato, versjon og neste kontrollpunkt, slik at senere gjennomganger kan skille historiske forutsetninger fra dagens faktiske tjenesteomfang.

Send en skriftlig beskrivelse av enheter, land, tjeneste, arkitektur, leverandører, eksisterende kontrollkart og frist. Vår EU-etterlevelsesrevisjon for WordPress kan strukturere overlapp og bevisgap uten å erstatte juridisk rådgivning.

Et praktisk oppsett for bevissporet som dekker begge:

• 00_governance/ - risikoregister, godkjenning fra ledelsesorganet, gjennomgangsrytme.
• 01_risikostyring/ - kartlegging av artikkel 21 / artikkel 5, kontroller, bevisfiler.
• 02_hendelsesrespons/ - håndbok, bordøvelser, ettergranskninger, maler for 24/72/30.
• 03_kontinuitet/ - backuppolicy, logger for gjenopprettingstester, BCDR-plan.
• 04_forsyningskjede/ - leverandørregister, liste over underleverandører, due diligence-filer.
• 05_dora_register/ - inndata til informasjonsregisteret (15 tabeller) for DORA-kunder.
• 06_rapportering/ - tidligere rapporter, adressatlogg, fristlogg.
• 07_jurisdiksjoner/ - delta for NIS2-gjennomføring per medlemsstat.
• 08_tlpt/ - for DORA-betydelige enheter, TLPT-rapporter og utbedring.

Bygg det én gang, itererer kvartalsvis, og neste leverandørgjennomgang tar timer ikke uker.

#Kryssreferanser

• NIS2 bilag II for WordPress-byråer: bevisspor
• DORA artikkel 28 IKT-tredjepartsrisiko for WordPress
• DORA informasjonsregister for WordPress-leverandører: obligatoriske felt
• NIS2 tidslinje for hendelsesrapportering 24t/72t/1M
• Pilaren om NIS2 og DORA på WordPress
• EU-etterlevelsesrevisjon for WordPress