Cyber Resilience Act + NIS2 + DORA: etterlevelse i 2026 for headless WordPress

#Cyber Resilience Act + NIS2 + DORA: etterlevelse i 2026 for headless WordPress

Mellom 2024 og 2026 har tre EU-rettsakter landet på det samme operative innholdet. Cyber Resilience Act (forordning (EU) 2024/2847) regulerer produkter med digitale elementer som gjøres tilgjengelige på EU-markedet. NIS2-direktivet (2022/2555) regulerer virksomheter som leverer samfunnskritiske eller viktige tjenester. DORA-forordningen (2022/2554) regulerer finansielle foretak og tredjepartsleverandørene av IKT som de er avhengige av. Et headless WordPress-prosjekt som leverer en kommersiell komponent til en regulert kunde, havner under CRA på produktsiden og under NIS2 eller DORA på virksomhetssiden. For et finansielt foretak erstatter DORA reglene i NIS2 om risikostyring og rapportering, i stedet for å komme i tillegg. Den gode nyheten: Én dokumentasjonspakke kan dekke alt dette hvis den struktureres etter kontroll og ikke etter rettsakt.

Denne artikkelen avslutter pilarartikkelen om NIS2 og DORA på WordPress og knytter sammen dokumentasjonssporet etter vedlegg II, leverandørrevisjonen etter DORA artikkel 28, 24-timers hendelsesplanen og teksten om tilgjengelighet etter BFSG og EAA.

#CRA, NIS2 og DORA som samlet regelverk, kort fortalt

• CRA er produktregulering. NIS2 er regulering av virksomheter. DORA er regulering av finansielle foretak.
• Et headless WordPress-prosjekt kan havne under CRA gjennom sine kommersielle komponenter, og under NIS2 eller DORA gjennom kunden som driver det.
• For finansielle foretak gjelder DORA i stedet for NIS2 artikkel 21 og 23 (NIS2 artikkel 4 og fortalepunkt 28).
• Én dokumentasjonspakke ordnet etter kontroll slår tre separate papirspor.
• Rapporteringsplikter i CRA fra 11. september 2026, full anvendelse fra 11. desember 2027.
• NIS2 fra gjennomføringsfristen 2024-10-17; DORA direkte anvendelig fra 2025-01-17.

#Hvordan headless WordPress påvirker etterlevelse av CRA, NIS2 og DORA

Et headless WordPress-prosjekt skiller to lag. Innholdslaget kjører WordPress som redigeringsverktøy og autoritativ kilde, og eksponerer innholdet via REST API eller GraphQL. Presentasjonslaget kjører et frontend-rammeverk (Next.js, Astro, Nuxt, SvelteKit) som henter innholdet og gjengir det for brukerne.

For etterlevelse endrer dette skillet risikoflaten på tre måter.

Frontenden kan være et produkt. En Next.js-applikasjon med kommersielle biblioteker, rullet ut av et byrå, kan være et “produkt med digitale elementer” etter CRA når den leveres som ledd i kommersiell virksomhet. WordPress selv, som gratis åpen kildekode utgitt av et fellesskap og ikke inntektsført av utviklerne, er ikke omfattet av CRA (fortalepunkt 15 og 18 i forordning (EU) 2024/2847); kommersielle pakker bygget oppå kan være det.

Leverandørkjeden er bredere. Headless-prosjekter drar inn npm-avhengigheter (ofte hundrevis), edge-funksjoner i CDN, tjenester for bildeoptimalisering, søkeleverandører og kommentarsystemer. NIS2 artikkel 21(2)(d) krever at omfattede virksomheter sikrer forholdet til sine direkte leverandører, og DORA artikkel 28(3) krever at finansielle foretak fører et informasjonsregister over alle avtaler om IKT-tjenester. Begge deler fører til en oversikt over kjeden med kontroll gjennom avtaler.

Hendelsesflaten er delt. En sårbarhet kan ligge i WordPress-backenden, i frontend-bundlen, i en edge-funksjon eller i et tredjeparts-API. 24-timersfristen i NIS2 og rapporteringsfristene i DORA gjelder virksomheten uansett hvor feilen sitter. Byråets runbook må oppdage og prioritere hendelser på tvers av alle fire lag.

#Hva CRA, NIS2 og DORA krever hver for seg

#CRA (forordning (EU) 2024/2847)

Dekker produkter med digitale elementer som gjøres tilgjengelige på EU-markedet. Artikkel 13 fastsetter produsentens plikter: en dokumentert vurdering av cybersikkerhetsrisiko (artikkel 13(2) og 13(3)), de grunnleggende kravene i vedlegg I del I, som sikker standardkonfigurasjon, sårbarhetshåndtering gjennom støtteperioden etter vedlegg I del II, sikkerhetsoppdateringer og en programvarestykkliste (SBOM, vedlegg I del II punkt 1). Artikkel 14 legger til rapportering: aktivt utnyttede sårbarheter og alvorlige hendelser meldes samtidig til CSIRT-et som er utpekt som koordinator og til ENISA, gjennom den felles rapporteringsplattformen i artikkel 16, med et tidlig varsel innen 24 timer etter at produsenten ble kjent med dem.

Tidsplan for anvendelse etter artikkel 71:

• Rapporteringsplikter etter artikkel 14 fra 11. september 2026.
• Kapittel IV om tekniske kontrollorganer (artikkel 35 til 51) fra 11. juni 2026.
• Alt annet, inkludert de fulle produsentpliktene, fra 11. desember 2027.
• Kravene til samsvarsvurdering for “viktige” og “kritiske” produkter med digitale elementer følger egne løp (artikkel 32).

Åpen kildekode som utvikles og leveres uten kommersiell virksomhet, faller utenfor CRA. Fortalepunktene skiller mellom ikke-kommersielle bidrag til åpen kildekode og kommersiell pakking. WordPress-kjernen er ikke-kommersiell åpen kildekode; et administrert WordPress-tilbud solgt som produkt, med premium-utvidelser under én samlet lisens, kan krysse inn i CRAs virkeområde.

#NIS2 (direktiv 2022/2555)

Dekker virksomheter (samfunnskritiske og viktige) som er oppført i vedlegg I og vedlegg II. Artikkel 21(2) lister opp ti risikostyringstiltak, bokstav a til j (mer om dette i artikkelen om dokumentasjonssporet etter vedlegg II). Artikkel 23(4) fastsetter tidlig varsel innen 24 timer, melding innen 72 timer og sluttrapport etter én måned (mer om dette i 24-timers planen for hendelsesrespons). Artikkel 21(2)(d) trekker leverandørene inn indirekte: virksomheten må dekke sikkerheten i leverandørkjeden, inkludert forholdet til direkte leverandører og tjenesteleverandører, og artikkel 21(3) krever at den tar hensyn til hver leverandørs praksis for sikker utvikling.

Gjennomføringsfristen var 2024-10-17 (artikkel 41). Flere medlemsstater ble forsinket; sjekk nasjonal status før en endelig revisjon.

#DORA (forordning 2022/2554)

Dekker finansielle foretak oppført i artikkel 2 og kritiske tredjepartsleverandører av IKT (CTPP) som de europeiske tilsynsmyndighetene utpeker etter artikkel 31. Artikkel 28 til 30 gjelder IKT-risiko knyttet til tredjeparter: de generelle prinsippene, informasjonsregisteret og exitstrategiene står i artikkel 28 (mer om dette i artikkelen om leverandørrevisjon etter DORA artikkel 28), og de obligatoriske avtalevilkårene står i artikkel 30. Artikkel 17 til 19 dekker prosessen for håndtering av IKT-relaterte hendelser, klassifiseringen av dem og rapporteringen av alvorlige hendelser. Artikkel 24 til 27 dekker testing av digital operasjonell motstandsdyktighet, inkludert TLPT.

Gjelder direkte i hele EU fra 2025-01-17 (artikkel 64).

#Gjelder NIS2 fortsatt når DORA omfatter et finansielt foretak

Ikke for de delene som betyr noe her. NIS2 artikkel 4(1) kobler ut direktivets egne regler om risikostyring, rapportering og tilsyn når en sektorspesifikk EU-rettsakt stiller krav som i virkning er minst likeverdige. Fortalepunkt 28 i NIS2 peker på DORA som denne rettsakten for finansielle foretak: DORAs regler om IKT-risikostyring, hendelsesrapportering, testing av motstandsdyktighet, informasjonsdeling og IKT-tredjepartsrisiko gjelder i stedet for reglene i NIS2.

For et headless WordPress-oppdrag deler dette kundene i to grupper:

• En bank, et forsikringsselskap, en betalingsinstitusjon eller et verdipapirforetak arbeider under DORA. Dokumentasjonspakken viser til DORA-artikler, og hendelsesrapporter går til den kompetente finansmyndigheten etter DORA artikkel 19.
• Et sykehus, et energiselskap, et offentlig forvaltningsorgan eller en annen virksomhet i vedlegg I eller II arbeider under den nasjonale gjennomføringen av NIS2. Dokumentasjonspakken viser til artikkel 21(2), og hendelsesrapporter går til CSIRT eller kompetent myndighet etter artikkel 23.

CRA går på tvers av begge: Leverer byrået et kommersielt produkt, gjelder produsentpliktene uansett hvilket regime kunden er under. Overlappstabellen lenger ned har derfor en NIS2-kolonne og en DORA-kolonne, men et enkelt oppdrag fyller bare én av dem.

#Når byrået selv havner under NIS2

NIS2 når ikke bare kunden. Vedlegg I punkt 9 nevner IKT-tjenesteforvaltning mellom virksomheter, som omfatter leverandører av administrerte tjenester og leverandører av administrerte sikkerhetstjenester. Artikkel 6 nr. 39 definerer en leverandør av administrerte tjenester som en virksomhet som yter tjenester knyttet til installasjon, forvaltning, drift eller vedlikehold av IKT-produkter, nettverk, infrastruktur eller applikasjoner, gjennom bistand eller aktiv administrasjon hos kunden eller på avstand.

Et byrå som drifter hosting, oppdateringer og overvåking av kundenes WordPress-installasjoner gjennom en driftsavtale, passer til denne beskrivelsen. Størrelsestesten i artikkel 2(1) avgjør om det er omfattet: direktivet gjelder virksomheter som regnes som mellomstore etter Kommisjonens rekommandasjon 2003/361/EF, eller som overstiger disse tersklene. Etter artikkel 2 i rekommandasjonen har et lite foretak færre enn 50 ansatte og omsetning eller balanse på inntil 10 millioner EUR, så et byrå med 50 eller flere ansatte og en egen driftslinje for hosting er tilfellet som må sjekkes. Er det omfattet, trenger det egne tiltak etter artikkel 21 og en egen rapporteringslinje etter artikkel 23, adskilt fra kundenes.

#Er et headless WordPress-nettsted et produkt etter CRA

Vanligvis ikke, og forordningen sier det rett ut. Fortalepunkt 12 i CRA slår fast at nettsteder som ikke støtter funksjonaliteten til et produkt med digitale elementer, faller utenfor virkeområdet, og at skytjenester som SaaS, PaaS og IaaS i stedet omfattes av NIS2. Et markedsføringsnettsted eller en nettbankfront på headless WordPress er et nettsted som driftes som en tjeneste, ikke et produkt som bringes i omsetning.

CRA kommer inn gjennom tre smalere dører:

• Et kommersielt produkt solgt til mange kunder. Et premium-tema, en betalt utvidelse eller et lisensiert startsett for frontend som leveres som ledd i kommersiell virksomhet, er et produkt med digitale elementer (artikkel 3 nr. 1).
• En app med egen backend. Artikkel 3 nr. 2 og fortalepunkt 11 behandler “fjerndatabehandling” som er utviklet av eller for produsenten, og som produktet ikke kan utføre en av sine funksjoner uten, som en del av produktet. Når en mobilapp leveres med et eget WordPress REST-endepunkt den er avhengig av, ligger endepunktet innenfor appens CRA-virkeområde.
• Åpen kildekode-komponenter i et kommersielt produkt. Artikkel 13(5) krever at produsenter utviser aktsomhet når de integrerer komponenter fra tredjeparter, også fri og åpen kildekode, og artikkel 13(6) krever at en sårbarhet funnet i en komponent rapporteres til den som vedlikeholder den.

Ingen av produkttypene i vedlegg III (viktige produkter) eller vedlegg IV (kritiske produkter) er et CMS, et tema eller en nettfrontend. Et typisk WordPress-produkt bruker derfor prosedyren for intern kontroll (modul A i vedlegg VIII), ikke et teknisk kontrollorgan.

#Hvordan rapporteringsfristene i CRA, NIS2 og DORA skiller seg

Hver rettsakt har sin egen klokke, og den starter på ulikt tidspunkt:

DORA-fristene kommer fra Kommisjonens delegerte forordning (EU) 2025/301, ikke fra DORA selv. En praktisk følge for en headless-stack: Frontend-byrået som også er CRA-produsent, kan skylde ENISA sin egen 24-timers rapport om den samme sårbarheten som banken rapporterer til tilsynet sitt. De to rapportene bør vise til hverandre, og runbooken bør angi hvem som sender hva.

#Hvor CRA, NIS2 og DORA overlapper

Et headless WordPress-oppdrag med en kommersiell frontend-bundle i leveransen treffer følgende overlapp. NIS2-kolonnen gjelder kunder utenfor finanssektoren, DORA-kolonnen finansielle foretak:

Åtte overlappende kontroller. Én dokumentasjonspakke med åtte mapper, hver med kryssreferanser til CRA og til regimet kunden er under, dekker dem alle.

#Hvordan bygge en felles dokumentasjonspakke for CRA, NIS2 og DORA

Jeg strukturerer pakken etter kontrollområde, ikke etter regelverk. Hver kontrollmappe inneholder:

1. Policy. Godkjent av virksomhetens ledelsesorgan. Med kryssreferanser til de relevante artiklene i CRA / NIS2 / DORA.
2. Prosesseier. Navngitt rolle i virksomheten, pluss byråets navngitte kontaktperson.
3. Implementeringsbevis. Logger, revisjonsrapporter, skanneresultater, testresultater, avtaleklausuler.
4. Koblingstabell. Tre kolonner: CRA-artikkel, NIS2-artikkel, DORA-artikkel. Hvor policyen hører hjemme i hver.
5. Gjennomgangslogg. Årlig eller hyppigere gjennomgang, datert og signert.
6. Revisjonshistorikk. Eksterne revisjoner, penetrasjonstester, henvendelser fra tilsynet, alt datert og merket.

Den felles pakken unngår det vanligste sløseriet ved etterlevelse av flere rettsakter: å skrive det samme risikoregisteret tre ganger for tre tilsynsmyndigheter. Ett register, tre artikkelhenvisninger i metadataene.

#Hvilken dokumentasjon et headless-prosjekt trenger for CRA, NIS2 og DORA

Et headless-prosjekt legger til artefakter som et monolittisk WordPress-oppdrag ikke trenger:

• SBOM for frontend-bundlen. En CycloneDX- eller SPDX-fil som lister hver npm-avhengighet med versjon og lisens. npm CLI genererer den med npm sbom --sbom-format cyclonedx (eller spdx); npm audit signatures er en egen kontroll som verifiserer registersignaturer. SBOM er en leveranse etter CRA vedlegg I del II; under NIS2 og DORA tjener den sårbarhetshåndteringen og oversikten over eiendeler.
• SBOM for WordPress-backenden. Oversikt over utvidelser og temaer med versjon og lisens. WP-CLI eksporterer den med wp plugin list --fields=name,version,update_version,wporg_status,wporg_last_updated --format=json og wp theme list --format=json; lisensen står i headeren til hver utvidelse, i tillegg til interne låsefiler for versjoner.
• Oversikt over edge-funksjoner. Cloudflare Workers, Netlify Functions, Vercel Edge. Hver funksjon er en del av leverandørkjeden og en del av hendelsesflaten.
• Dokumentasjon av API-kontrakten. OpenAPI- eller GraphQL-skjema for headless-API-et, med sikkerhetsdefinisjoner, rate limits og autentisering.
• Bevis fra frontendens utrullingspipeline. CI/CD-logger, resultater fra containerskanning, bevis på skanning etter hemmeligheter, gjennomgang av avhengigheter i hver PR.
• Overvåking på tvers av lag. Ett dashbord eller én runbook som korrelerer hendelser fra WordPress-backend, frontend-applikasjon, edge-lag og tredjeparts-API-er.

For en regulert virksomhet er dette settet med artefakter obligatorisk. For en uregulert virksomhet er det god praksis, men budsjettsamtalen blir strammere.

#Hva en felles pakke for CRA, NIS2 og DORA ikke dekker

Det finnes tre områder der én pakke ikke dekker alt.

Samsvarsvurdering etter CRA. Etter artikkel 32 trenger viktige produkter i klasse I som ikke bruker harmoniserte standarder, alle viktige produkter i klasse II og kritiske produkter EU-typeundersøkelse eller full kvalitetssikring etter vedlegg VIII, med et teknisk kontrollorgan involvert, eller en europeisk ordning for cybersikkerhetssertifisering der en slik finnes. NIS2 og DORA har ikke et tilsvarende grunnlag for tredjepartssertifisering (TLPT i DORA er det nærmeste). Planlegg samsvarsvurderingen som et eget arbeidsløp når produktet faller inn under vedlegg III eller IV.

TLPT etter DORA artikkel 26. Trusselbasert penetrasjonstesting for utpekte finansielle foretak gjennomføres minst hvert tredje år på produksjonssystemer i drift, og de tekniske standardene bak følger TIBER-EU-rammeverket. NIS2 og CRA krever ikke testing i denne dybden.

Sektorspesifikt tilsyn. NIS2 har sektorvise kompetente myndigheter. DORA har de kompetente finansmyndighetene i artikkel 46, og for hver kritisk tredjepartsleverandør av IKT en ledende tilsynsmyndighet med et felles undersøkelsesteam (artikkel 40). CRA har markedstilsynsmyndigheter etter artikkel 52. Tre ulike tilsynskanaler krever fortsatt separate kommunikasjonsprosesser.

#Hvilke bøter CRA, NIS2 og DORA fastsetter

Taket varierer fordi rettsaktene regulerer ulike parter:

• CRA artikkel 64. Brudd på de grunnleggende kravene i vedlegg I eller på artikkel 13 og 14: opptil 15 millioner EUR eller 2,5 % av global årsomsetning, det høyeste av de to. Andre plikter for markedsdeltakere: opptil 10 millioner EUR eller 2 %. Uriktige eller villedende opplysninger til tekniske kontrollorganer eller markedstilsynsmyndigheter: opptil 5 millioner EUR eller 1 %.
• NIS2 artikkel 34. Brudd på artikkel 21 eller 23: et maksimum på minst 10 millioner EUR eller 2 % for samfunnskritiske virksomheter, og minst 7 millioner EUR eller 1,4 % for viktige virksomheter. Medlemsstatene kan gå høyere.
• DORA artikkel 50. Beløpene fastsettes av medlemsstatene, som må gi de kompetente myndighetene sanksjonsmyndighet. Overfor kritiske tredjepartsleverandører av IKT kan den ledende tilsynsmyndigheten etter artikkel 35 ilegge en daglig tvangsmulkt på opptil 1 % av gjennomsnittlig daglig global omsetning, i høyst seks måneder.

For byrået er det CRA-linjen som havner i eget regnskap, fordi byrået er produsenten. Bøtene etter NIS2 og DORA rammer kunden, og derfor skyver kundene dem nedover kjeden gjennom avtaleklausuler.

#Hva CRA, NIS2 og DORA krever av WordPress-byråer

Et WordPress-byrå som vil levere headless-prosjekter til regulerte virksomheter i 2026, må:

1. Bygge malen for den felles dokumentasjonspakken én gang og gjenbruke den på tvers av oppdrag.
2. Generere SBOM som en del av utrullingspipelinen, ikke i etterkant.
3. Holde leverandørregisteret oppdatert som et levende dokument.
4. Opprettholde beredskap for hendelseshåndtering i begge lag (WordPress og frontend).
5. Følge med på gjennomføringsrettsaktene og de delegerte rettsaktene Kommisjonen vedtar under CRA, og bli kjent med ENISAs felles rapporteringsplattform før artikkel 14 gjelder fra 11. september 2026.

Prisingen er individuell; omfanget av etterlevelsen styrer hvor lenge oppdraget varer, ikke en fast månedlig avtale.

#Relaterte veiledninger om CRA, NIS2 og DORA

• Pilar: NIS2 og DORA på WordPress: hva en nettside må oppfylle i 2026
• NIS2 vedlegg II for WordPress-byråer: omfang, frister og bevisspor
• DORA artikkel 28, IKT-tredjepartsrisiko: revisjon av hosting- og WAF-leverandører
• WordPress og NIS2: 24-timers plan for hendelsesrespons
• BFSG og EAA: den tyske fristen i 2025 for WordPress-nettbutikker