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 for en regulert virksomhet, med en kommersiell komponent i leveransen, havner under alle tre på en gang. Den gode nyheten: Én dokumentasjonspakke kan dekke alle tre 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 hendelsesplaybooken og teksten om tilgjengelighet etter BFSG og EAA.

#Hva er CRA, NIS2 og DORA som samlet regelverk, kort fortalt?

• CRA er produktregulering. NIS2 er regulering av virksomheter. DORA er regulering av finansielle foretak.
• Headless WordPress for regulerte virksomheter kan havne under alle tre.
• Én dokumentasjonspakke ordnet etter kontroll slår tre separate papirspor.
• Rapporteringsplikter i CRA fra 2026, fulle produsentplikter fra 2027.
• NIS2 fra gjennomføringsfristen 2024-10-17; DORA direkte anvendelig fra 2025-01-17.

#Hvordan påvirker headless WordPress 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 er 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 selges eller lisensieres til et finansielt foretak. WordPress selv, som gratis åpen kildekode utgitt av et fellesskap, er ikke omfattet av CRA ifølge fortalepunkt 15 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. Både NIS2 artikkel 21(2)(d) og DORA artikkel 28(2) krever at denne kjeden er kartlagt, klassifisert og kontrollert 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 krever CRA, NIS2 og DORA 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: innebygd sikkerhet og sikkerhet som standard, sårbarhetshåndtering gjennom hele støtteperioden, sikkerhetsoppdateringer, programvarestykkliste (SBOM), rapportering av aktivt utnyttede sårbarheter til ENISA innen 24 timer etter at man ble kjent med dem, og rapportering av alvorlige hendelser innen 24 timer etter at man ble kjent med dem.

Tidsplan for anvendelse etter artikkel 71:

• Plikt til å rapportere sårbarheter og hendelser fra 2026.
• Fulle produsentplikter fra 2027 (36 måneder etter ikrafttredelse).
• Kravene til samsvarsvurdering for “viktige” og “kritiske” produkter med digitale elementer følger egne løp.

Å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. Artikkel 23 fastsetter tidlig varsel innen 24 timer, melding innen 72 timer og sluttrapport etter én måned. Artikkel 21(2)(d) trekker leverandører inn i virkeområdet gjennom avtaleforpliktelser.

Gjennomføringsfristen var 2024-10-17. 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 utpekes av de europeiske tilsynsmyndighetene. Artikkel 28 gjelder styring av IKT-risiko knyttet til tredjeparter. Artikkel 16 til 19 dekker livssyklusen for håndtering av IKT-hendelser. Artikkel 24 til 27 dekker testing av digital operasjonell motstandsdyktighet, inkludert TLPT.

Gjelder direkte i hele EU fra 2025-01-17.

#Hvor overlapper CRA, NIS2 og DORA?

Et headless WordPress-oppdrag for et finansielt foretak, med en kommersiell frontend-bundle i leveransen, treffer følgende overlapp:

Åtte overlappende kontroller. Én dokumentasjonspakke med åtte mapper, hver med kryssreferanser til alle tre regelverkene, 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 krever et headless-prosjekt 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. Generert med npm audit signatures pluss en CycloneDX-generator. SBOM er en leveranse etter CRA artikkel 13; under NIS2 og DORA tjener den sårbarhetshåndteringen.
• SBOM for WordPress-backenden. Oversikt over utvidelser og temaer med versjon og lisens. Plugin checker fra WordPress.org pluss 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 dekker ikke en felles pakke for CRA, NIS2 og DORA?

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

Samsvarsvurdering etter CRA. “Viktige” og “kritiske” produkter med digitale elementer trenger samsvarsvurdering av tredjepart etter CRA vedlegg VII. NIS2 og DORA har ikke et tilsvarende grunnlag for tredjepartssertifisering (TLPT i DORA er det nærmeste). Planlegg samsvarsvurderingen som et eget arbeidsløp.

TLPT etter DORA artikkel 26. Trusselbasert penetrasjonstesting for utpekte vesentlige finansielle foretak følger TIBER-EU-rammeverket. NIS2 og CRA krever ikke testing i denne dybden.

Sektorspesifikt tilsyn. NIS2 har sektorvise kompetente myndigheter. DORA har de felles undersøkelsesteamene etter artikkel 31. CRA har markedstilsynsmyndigheter etter vedlegg VIII. Tre ulike tilsynskanaler krever fortsatt separate kommunikasjonsprosesser.

#Hva krever CRA, NIS2 og DORA 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 til CRA etter hvert som ENISA publiserer dem gjennom 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