NIS2 vedlegg II for WordPress-byråer: omfang, frister og bevisspor

#NIS2 vedlegg II for WordPress-byråer: omfang, frister og bevisspor

Artikkel 21 i direktiv 2022/2555 er den operative bestemmelsen som avgjør hvordan en revisjon ser ut. Vedlegg I og vedlegg II avgjør hvem som må gjennom den. Denne teksten kobler de ti tiltakene i artikkel 21 nr. 2 til konkrete kontroller i et WordPress-byrå og til bevisfilene jeg forventer når en regulert kunde setter i gang en leverandørvurdering.

Artikkelen støtter søylen om NIS2 og DORA på WordPress, med henvisning til playbooken for hendelsesrespons de første 24 timene.

#TL;DR

• Artikkel 21 nr. 2 lister opp ti risikostyringstiltak. Ingen av dem er valgfrie.
• Vedlegg I = vesentlige virksomheter. Vedlegg II = viktige virksomheter. Samme tiltak, ulikt tilsyn.
• Revisor ser etter fire artefakter per tiltak: policy, eier, registrering av gjennomføring, gjennomgangsrytme.
• Bøtene i artikkel 34 rammer virksomheten, ikke WordPress-leverandøren, men leverandørkjedeklausuler skyver forpliktelsene nedover.
• I hvert regulert oppdrag fører jeg én mappe per bokstav i artikkel 21.

#Hvilke virksomheter omfattes av NIS2 vedlegg I og vedlegg II

Vedlegg I lister opp vesentlige virksomheter: energi, transport, bank, finansmarkedsinfrastruktur, helse, drikkevann og avløpsvann, digital infrastruktur, forvaltning av IKT-tjenester (B2B), offentlig forvaltning, romfart. Vedlegg II lister opp viktige virksomheter: post- og budtjenester, avfallshåndtering, kjemikalier, mat, produksjon av medisinsk utstyr, datamaskiner og elektronikk, maskiner og motorvogner, leverandører av digitale tjenester, forskningsorganisasjoner.

Begge vedleggene gjelder for mellomstore og større virksomheter (50+ ansatte, eller årlig omsetning over 10 mill. EUR, eller balansesum over 10 mill. EUR). Mikrovirksomheter og små virksomheter er utenfor det direkte omfanget, med unntakene i artikkel 2 nr. 2: tillitstjenesteytere, TLD-registre, enkelte DNS-leverandører, offentlig forvaltning, tilbydere av offentlige elektroniske kommunikasjonsnett.

Et praktisk filter for et WordPress-byrå: sykehus, bank, kjemisk anlegg, datasenteroperatør, TLD-register, UCITS-forvalter. Er kunden en av disse, starter avgrensningsarbeidet. Er kunden et hotell, en SaaS-oppstart eller en regional forhandler, ender avgrensningen som regel med “utenfor omfanget, god sikkerhetspraksis gjelder fortsatt”.

#Tiltakene i NIS2 artikkel 21 i et WordPress-byrå

Direktivteksten leses som ti bokstaver fra a til j. Hver bokstav blir en mappe i prosjektrepoet mitt.

(a) Retningslinjer for risikoanalyse og sikkerhet i informasjonssystemer. Et signert risikoregister med eiendeler, trusler, sannsynlighet, konsekvens og behandling. For WordPress: produksjonsserver, stagingserver, utvidelsesoppsett, eksterne API-er (betaling, e-post, analyse, AI), administratorkontoer, innholdsdatabase. Trusler: RCE i en utvidelse, credential stuffing, løsepengevirus mot sikkerhetskopiene, GDPR-brudd via eksport. Behandling: oppdateringsplan, MFA, kryptert sikkerhetskopi utenfor stedet, WAF-regelsett.

(b) Hendelseshåndtering. Deteksjon, klassifisering, respons, gjenoppretting, oppsummering. Bevis: IR-runbook med navngitte eiere, overvåkingsverktøy som utløser varsler (Wordfence, Sucuri, hostingens IDS, Cloudflare-varsler), Slack- eller PagerDuty-kanal, mal for post-mortem.

(c) Kontinuitet i virksomheten, herunder håndtering av sikkerhetskopier og katastrofegjenoppretting, samt krisehåndtering. Sikkerhetskopi med lagring utenfor stedet, definert RPO og RTO, testet gjenoppretting. Plan for krisekommunikasjon med én kontaktperson mot media og én mot tilsynsmyndigheten. Årlig gjenopprettingsøvelse med rapport.

(d) Sikkerhet i leverandørkjeden, herunder sikkerhetsaspekter ved forholdet mellom hver virksomhet og dens direkte leverandører eller tjenesteytere. Her havner WordPress-byrået. Den regulerte virksomheten fører et leverandørregister, klassifiserer leverandørene etter kritikalitet, gjennomfører due diligence og skriver sikkerhetsklausuler inn i kontraktene. DORA artikkel 28 bruker samme logikk, strengere for finanssektoren.

(e) Sikkerhet ved anskaffelse, utvikling og vedlikehold av nettverks- og informasjonssystemer, herunder håndtering og offentliggjøring av sårbarheter. En dokumentert sikker utviklingssyklus. For WordPress: kodegjennomgang av egne utvidelser og temaer, skanning av avhengigheter (Snyk, Dependabot, Plugin Checker på WordPress.org), en e-postadresse for å melde sårbarheter, en policy for patchhåndtering.

(f) Retningslinjer og prosedyrer for å vurdere effekten av tiltakene for styring av cybersikkerhetsrisiko. Intern eller ekstern revisjon, eller penetrasjonstest. Bevis: beskrivelse av omfang, testrapport, register over korrigerende tiltak, protokoll fra retest.

(g) Grunnleggende cyberhygiene og opplæring. Årlig opplæring for alle ansatte, rollebasert opplæring for administratorer. Bevis: opplæringsregister med navn, datoer og innhold.

(h) Retningslinjer og prosedyrer for bruk av kryptografi og, der det er relevant, kryptering. TLS 1.3 på kanten, kryptering av sikkerhetskopier, kryptering av databasekopier i hvile. Policy for hashalgoritmer (ikke MD5 og SHA-1). Oversikt over kryptografiske nøkler.

(i) Personellsikkerhet, retningslinjer for tilgangskontroll og forvaltning av eiendeler. En joiner-mover-leaver-prosess. Navngitte administratorkontoer, ingen delte påloggingsdetaljer. Eiendelsoversikt som dekker alle WordPress-installasjoner, stagingmiljøer, tilganger til kodelagre og tilganger til hostingkonsoller. Kvartalsvis gjennomgang av tilganger.

(j) Bruk av flerfaktorautentisering eller løsninger for kontinuerlig autentisering, sikret tale-, video- og tekstkommunikasjon og sikret nødkommunikasjon. MFA på hver WordPress-administratorpålogging, hver hostingkonsoll, hver CDN-konsoll, hvert kodelager, hver e-postkonto. Ingen unntak for “betrodde interne kontoer”.

#Hvilke bevis en NIS2-revisor krever for hvert tiltak

For hver av de ti bokstavene forventer jeg fire artefakter når revisor kommer:

Denne tabellen med fire kolonner fører jeg for hver bokstav i artikkel 21 nr. 2. Ti bokstaver, førti artefakter. Slik ser revisjonspermen ut i 2026.

#Frister for hendelsesrapportering etter NIS2 artikkel 23

Vedlegg II beskriver normaltilstanden. Når en hendelse inntreffer, gjelder artikkel 23:

• 24 timer fra kjennskap: tidlig varsel til CSIRT eller kompetent myndighet.
• 72 timer fra kjennskap: melding med innledende vurdering og kompromitteringsindikatorer.
• 1 måned fra kjennskap: sluttrapport med rotårsak og iverksatte korrigerende tiltak.
• Statusrapport underveis når tilsynsmyndigheten ber om det.

Den detaljerte playbooken for de første 24 timene finner du i artikkelen WordPress, hendelsesrespons under NIS2.

#NIS2-bøter og ledelsens ansvar

Artikkel 34 fastsetter tak som nasjonal gjennomføring ikke kan senke:

• Vesentlige virksomheter: minst 10 mill. EUR eller 2 % av samlet global årlig omsetning, avhengig av hvilken verdi som er høyest.
• Viktige virksomheter: minst 7 mill. EUR eller 1,4 % av samlet global årlig omsetning, avhengig av hvilken verdi som er høyest.

Artikkel 20 nr. 1 legger ansvaret på ledelsesorganene, inkludert plikten til å føre tilsyn med gjennomføringen. Artikkel 20 nr. 2 krever at medlemmene av organet gjennomgår opplæring. Nasjonal gjennomføring kan legge til personlige sanksjoner mot den ansvarlige personen; status for den polske loven om det nasjonale cybersikkerhetssystemet bør kontrolleres i ISAP før revisjonen.

#Hvordan avgrense byråets tjenesteomfang i en NIS2-leverandørvurdering

Byråpakken starter med en beskrivelse av grensen. Angi kontraktspartene, kundens tjeneste, produksjonsnettstedene, kodelagrene, miljøene, integrasjonene og leverandørene som byrået faktisk håndterer. Ansvaret for WordPress-kode, hosting, DNS, CDN, identitet, betaling og redaksjonell tilgang beskrives hver for seg. At et verktøy finnes i arkitekturen, gjør ikke automatisk byrået til eier av kontrollen.

I det samme dokumentet registreres unntak og forutsetninger. Har kunden sin egen identitetsleverandør, eller forvalter kunden databasen selv, må det stå. Leverer byrået kode, men godkjenner ikke produksjonsendringer, må også den fordelingen være synlig. Den regulerte kunden har ansvaret for NIS2-klassifiseringen og nasjonal rett; byrået leverer bevis for sin egen tjeneste.

#NIS2 RACI-matrise for kunde, byrå og hosting

En matrise i RACI-stil dekker godkjenning av endringer, nødutrullinger, triage av sårbarheter, privilegert tilgang, kjøring av sikkerhetskopier, godkjenning av gjenoppretting, eskalering av hendelser, gjennomgang av logger og leverandørexit. Hver rad angir kundens rolle, byråets rolle, godkjenner, hvor beviset ligger og eskaleringskanal.

Delte kontroller krever presisjon. Hostingen kan ta kopien, byrået kan følge med på at den kjøres, og kunden kan fastsette gjenopprettingsmålet. Oppføringen “hostingen har ansvaret” skjuler kontroll- og beslutningspliktene til de andre partene. Matrisen oppdateres når omfang, arkitektur eller personer endres.

#NIS2-bevis for endringer, sårbarheter og tilganger

For en endring tar du vare på forespørselen, risikovurderingen, gjennomgangen fra en annen person, testen, godkjenningen, registreringen av utrullingen og resultatet av en eventuell tilbakerulling. En nødendring har en kortere vei, men ikke en vei uten dokumentasjon: registrer beslutningstakerens fullmakt, begrunnelsen og fristen for etterkontroll. En release bør knytte sammen sak, commit og tidspunkt i produksjon.

For en sårbarhet registreres kilden til varselet, eiendelen og versjonen, begrunnelsen for prioriteringen, eksponeringen, beslutningen, fristen og retesten. En eksport fra skanneren sier ikke alene om problemet gjaldt produksjon, eller om et unntak ble akseptert. Når en utvidelse mangler en støttet patch, trengs kompenserende kontroller og en beslutning om erstatning.

For en tilgang registreres navngitt identitet, rolle, begrunnelse, godkjenner, MFA, dato for tildeling og siste gjennomgang. Fjerning av tilgangen til en som slutter, eller av en utløpt supportkonto, må også etterlate spor. Passord og gjenopprettingskoder hører ikke hjemme i bevispermen.

#Hvordan teste gjenoppretting fra sikkerhetskopi som NIS2-bevis

En grønn status på sikkerhetskopijobben bekrefter at filen ble laget, ikke at den kan gjenopprettes. Beviset beskriver omfang, rytme, kryptering, plassering, oppbevaringstid, feilvarsling og hvem som har lov til å gjenopprette. Deretter gjennomføres en gjenoppretting i et isolert miljø, der start, slutt, integritetskontroll, applikasjonstest og avvik fra RPO og RTO registreres.

Ta med avhengigheter utenfor databasen: mediefiler, konfigurasjon, hemmeligheter, DNS, kantregler, planlagte jobber og utrullingsdefinisjoner. En gjenoppretting av bare databasen kan gi et nettsted som åpner, men som ikke sender meldinger eller tar imot betaling. Mottaksprotokollen presiserer hvilken tjeneste som ble gjenopprettet, hva som ble simulert og hva som ble utelatt.

#Hvor ofte NIS2-bevis bør gjennomgås og godkjennes

Hvert bevis får en eier og en utløser for oppdatering. Tilganger kan gjennomgås kvartalsvis, gjenopprettings- og hendelsesøvelser årlig eller etter en vesentlig endring, og sårbarheter og patcher løpende. En endring i kontrakt, arkitektur, leverandør eller en kritisk utvidelse utløser en målrettet gjennomgang.

Et artefakt er godkjent når det er oppdatert, har en eier, er knyttet til en kontroll innenfor omfanget, er lagret på rett sted og er kontrollert av den ansvarlige rollen. Mangler føres separat med risiko, eier og frist. Du skal ikke lage en manglende historisk registrering som om den fantes fra før.

Pakken viser utvalgte kontroller hos leverandøren i en bestemt periode. Den er ikke et NIS2-sertifikat, en juridisk vurdering eller bevis på at kunden er fullt ut i samsvar. Den garanterer heller ikke at hendelser uteblir. Begrensningene bør stå på forsiden.

#Pristilbud på en NIS2-leverandørpakke for WordPress

For et pristilbud sender du kontraktspartene, tjenestebeskrivelsen, arkitekturen, miljøene, kritiske integrasjoner, leverandørspørreskjemaet, revisjonsdatoen og en liste over tilgjengelige bevis. Ikke send hemmeligheter i den første meldingen. Vårt arbeid med NIS2- og DORA-beredskap kan omfatte leverandørpakken for WordPress, ansvarsmatrisen, bevismanglene og godkjenningen. Det erstatter ikke kundens juridiske vurdering.

#Hva leverandørens sikkerhetspakke for regulerte kunder inneholder

Et WordPress-byrå som vil beholde regulerte kunder i 2026, leverer to artefakter i hvert oppdrag:

1. En egenerklæring mot artikkel 21 nr. 2 bokstav d, som beskriver sikkerhetstiltakene byrået selv har innført.
2. Et referansedokument som kunden legger inn i sin egen perm for artikkel 21, og som viser hvordan WordPress-oppdraget svarer til hvert av de ti tiltakene.

Begge pakker jeg i en “leverandørens sikkerhetspakke” og legger ved tilbudet. Det fjerner en runde med innkjøpsavdelingen og viser at vi forstår den regulatoriske konteksten. Pris for oppdrag innen compliance engineering er individuell; omfanget av permen styrer timene, ikke en prisliste.

#Relaterte tekster om etterlevelse

• Søyle: NIS2 og DORA på WordPress: etterlevelsesstakken 2026
• WordPress-hendelsesrespons under NIS2: 24-timers playbook for tidlig varsel
• Cyber Resilience Act + NIS2 + DORA: etterlevelsesstakken 2026 for headless WordPress