DORA artikkel 28, IKT-tredjepartsrisiko: revisjon av hosting- og WAF-leverandør for WordPress

#DORA artikkel 28, IKT-tredjepartsrisiko: revisjon av hosting- og WAF-leverandør for WordPress

Artikkel 28 i forordning 2022/2554 er den delen av DORA som avgjør om en kunde i finanssektoren i det hele tatt kan signere en hostingavtale eller et WAF-abonnement. Den gjelder kredittinstitusjoner, betalingsforetak, forsikringsselskaper, verdipapirforetak, tilbydere av kryptotjenester og rundt femten andre kategorier fra artikkel 2. Fra 17. januar 2025 gjelder den direkte, uten gjennomføring i nasjonal rett.

Dette er en støtteartikkel i pilaren om NIS2 og DORA på WordPress, med henvisninger til bevissporet for NIS2 vedlegg II og til gjennomgangen av CRA + NIS2 + DORA-stakken.

#TL;DR

• DORA artikkel 28 = generelle prinsipper for styring av IKT-tredjepartsrisiko.
• Artikkel 30 = obligatoriske avtaleklausuler.
• Artikkel 31 = ordningen for utpeking av CTPP, drevet av de europeiske tilsynsmyndighetene.
• Et WordPress-oppdrag for en bank eller et forsikringsselskap utløser registeroppføring, due diligence, klausuler og exit-plan.
• I registeret havner hosting, CDN, WAF, betalingsutvidelsen og utvidelsen for e-postutsendelse.

#Hvem DORA gjelder for i finanssektoren

Artikkel 2 nr. 1 lister opp de finansielle foretakene. De vanligste i WordPress-oppdrag:

• Kredittinstitusjoner og konsernene deres.
• Betalingsforetak og e-pengeforetak.
• Verdipapirforetak, også de som driver MTF eller OTF.
• Tilbydere av kryptotjenester under MiCA.
• Forsikrings- og gjenforsikringsforetak.
• Forsikringsformidlere over størrelsesterskelen.
• Tilbydere av folkefinansieringstjenester.
• Investeringsfond (UCITS-forvaltere, AIFM).

I tillegg kommer kritiske IKT-tredjepartsleverandører (CTPP), som utpekes etter artikkel 31 i fellesskap av EBA, ESMA og EIOPA. Den første utpekingsrunden fant sted i 2025 og domineres av hyperscalere (den offentlige listen ligger på portalen til de europeiske tilsynsmyndighetene). Et WordPress-byrå blir neppe CTPP. En plattform for administrert WordPress-hosting med en stor portefølje av finanskunder kan bli det.

#Kravene i DORA artikkel 28, nummer for nummer

Artikkel 28 har åtte numre. Disse er operative for et WordPress-oppdrag:

Artikkel 28 nr. 1. Det finansielle foretaket styrer IKT-tredjepartsrisiko som en integrert del av hele rammeverket for IKT-risikostyring. Rammeverket, retningslinjene og tilsynet ligger hos foretaket, ikke hos leverandøren. Leverandøren leverer bevis som støtter rammeverket.

Artikkel 28 nr. 2. En solid, helhetlig og godt dokumentert strategi for IKT-tredjepartsrisiko. Foretaket fører dokumentasjonen. Leverandøren må være klar til å levere innhold til den.

Artikkel 28 nr. 3. Et register over alle avtaler med IKT-tredjepartsleverandører, der de som støtter kritiske eller viktige funksjoner er markert. Registeret må kunne rapporteres til tilsynsmyndigheten. For WordPress: hosting, CDN, WAF, betalingsgateway, transaksjonell e-post, AI-leverandør, overvåkingsverktøy og lagringssted for sikkerhetskopier.

Artikkel 28 nr. 4. Due diligence før avtaleinngåelse. Identifisering og vurdering av alle vesentlige risikoer. Analyse av konsentrasjonsrisiko når en ny avtale legges til med samme leverandør eller en leverandør i samme konsern.

Artikkel 28 nr. 5. Vurdering av interessekonflikter. Styret godkjenner retningslinjene for bruk av IKT-tjenester som støtter kritiske eller viktige funksjoner.

Artikkel 28 nr. 7. Periodisk ny vurdering av avtalen.

Artikkel 28 nr. 8. Exit-strategi for IKT-tjenester som støtter kritiske eller viktige funksjoner. Dokumentert, testet og med en overgangsplan.

#Avtaleklausuler fra DORA artikkel 30 i hostingavtalen

Artikkel 30 nr. 2 lister opp minimumsklausulene i hver avtale. Artikkel 30 nr. 3 legger til klausuler for avtaler som støtter kritiske eller viktige funksjoner. Byråmalen jeg leverer sammen med hosting- og WAF-avtaler, dekker alle:

Denne matrisen fører jeg som én Markdown-fil i oppdragsmappen. Hver avtale kontrolleres mot den før signering.

#DORA-informasjonsregisteret for WordPress-leverandører

Et WordPress-oppdrag for et finansielt foretak berører flere IKT-tredjeparter enn innkjøpsavdelingen vanligvis regner med. Registeret jeg setter opp første dag i oppdraget:

• Hostingleverandør. Den faktiske operatøren av datasenteret, administrasjonspanelet, supportteamet. Kritisk eller viktig hvis WordPress er en del av leveransen av tjenester til kunder.
• CDN-leverandør. Cloudflare, Fastly, Akamai. Behandler trafikken, ser innholdet i forespørslene, terminerer TLS. Ofte kritisk eller viktig.
• WAF-leverandør. Noen ganger den samme som CDN, noen ganger en egen (Sucuri, Imperva). Inspiserer payloads. Kritisk eller viktig.
• Betalingsutvidelse. Stripe, Adyen, mollie, lokale gatewayer. Utvikleren av utvidelsen er én leverandør, operatøren av gatewayen er en annen. Begge skal inn i registeret.
• Transaksjonell e-post. SES, Postmark, SendGrid. Bærer tilbakestilling av passord, KYC-varsler, AML-varsler. Ofte kritisk eller viktig.
• Overvåking og APM. New Relic, Datadog, Sentry. Mottar stack traces og utdrag av payloads.
• Mål for sikkerhetskopi. S3, Backblaze, Wasabi. Holder databasen og opplastingene. Alltid kritisk eller viktig.
• AI-leverandør. Hvis WordPress bruker en LLM til kundevendte funksjoner (chat, sammendrag), er LLM-leverandøren innenfor omfanget.
• Markedsplass for utvidelser. WordPress.org, premium-markedsplasser. Oppdateringskanalene er en del av forsyningskjeden etter art. 28 nr. 2 bokstav d.

Registeret holder for hver leverandør: juridisk navn, avtalereferanse, tjenestebeskrivelse, dataflyter, kritikalitetsklassifisering, behandlingssted, dato for siste due diligence og henvisning til exit-strategien.

#Hvordan vurdere DORA-konsentrasjonsrisiko ved én skyleverandør?

Artikkel 28 nr. 4 innfører en test som fanger WordPress-byråer oftere enn man tror: ingen konsentrasjon av kritiske funksjoner hos leverandører i samme eiergruppe. En bank som bruker Cloudflare til CDN, Cloudflare Workers til backend, Cloudflare R2 til objektlagring og Cloudflare Stream til video, har høy konsentrasjonsrisiko hos én leverandør. Dette er ikke et funn som gjelder spesielt for Cloudflare; det samme gjelder for stakker på AWS, Azure eller GCP.

I WordPress ser det ofte slik ut: hosting på AWS, sikkerhetskopier på S3, e-post via SES, overvåking via CloudWatch. Fire AWS-avhengigheter, én leverandør. Risikoregisteret må anerkjenne dette tydelig og enten begrunne det eller planlegge diversifisering.

#DORA-exit-strategi for WordPress-hosting og WAF

Artikkel 28 nr. 8 krever at exit-strategien er dokumentert og testet. For WordPress-hosting og WAF omfatter en reell exit-strategi:

• Databaseeksport i standardformat. SQL-dump kompatibel med standard MySQL eller MariaDB, uten proprietære utvidelser.
• Eksport av filsystemet med opplastinger. Tar- eller zip-arkiv som kan lastes ned utenfor leverandørens panel.
• DNS-kontroll. Kontoen hos domeneregistraren eies av det finansielle foretaket, ikke av byrået og ikke av hostingleverandøren.
• Portable lisenser for utvidelser og temaer. Lisenser i foretakets navn, som kan overføres til ny hostingleverandør.
• Testet overgang. Et stagingmiljø hos en alternativ hostingleverandør som kan løftes til produksjon innen en dokumentert tid. Testen protokollføres og dateres.
• Avtalefestet overgangsvindu. Hostingavtalen forplikter leverandøren til å opprettholde tjenestene under migreringen, til samme pris, i minst en dokumentert periode.

Prisen for oppdrag som omfatter en exit-strategipakke settes individuelt; selve exit-dokumentet tar dager, ikke timer, og er et resultat av oppdraget.

#Hvordan DORA endrer innkjøp av tjenester fra WordPress-byråer

Et WordPress-byrå som kommer med en utfylt matrise over klausulene i artikkel 30, en ferdig mal for leverandørregisteret og en testet exit-strategi, kommer raskere gjennom innkjøpsprosessen. Det finansielle foretaket trenger ikke å oversette artikkel 28 til en avtale; det tar byråets ferdige materiale inn i sitt eget rammeverk for IKT-risikostyring.

Det er også grunnen til at en regulert kunde filtrerer leverandørlisten etter jurisdiksjon. Et byrå fra EU under EU-retten fjerner et friksjonslag; et byrå utenfor EU tvinger frem ekstra due diligence etter artikkel 28 nr. 4 om jurisdiksjonsrisiko.

#Hvordan klassifisere en kritisk eller viktig funksjon i DORA

Kritikalitet avgjøres verken av merkenavnet eller av avtaleverdien. Utgangspunktet er funksjonen tjenesten støtter, og følgen av at den blir utilgjengelig, svekket eller kompromittert. Bankens informasjonsside kan være viktig for kommunikasjonen, men ikke direkte støtte en kritisk finansiell tjeneste. En rimelig utvidelse som håndterer autentisering eller betalingsstatus, kan ha langt større operasjonell betydning enn lisenskostnaden antyder.

Klassifiseringskortet bør angi forretningstjenesten, prosesseieren, berørte kunder, data, gjenopprettingsmål, mulige manuelle omveier og avhengigheter til videre leverandører. Det registrerer også hvem som godkjente kvalifiseringen som kritisk eller viktig funksjon, og datoen for neste gjennomgang. Denne beslutningen bestemmer dybden i due diligence og tilleggsvilkårene fra artikkel 30. Det er ikke en merkelapp leverandøren kan sette på seg selv.

#Bevisliste for due diligence av IKT-leverandøren

Innkjøpsavdelingen bør få bevis som gjelder den konkrete tjenesten, ikke en generell sikkerhetsmappe. For hosting, CDN, WAF eller WordPress-drift omfatter pakken vanligvis:

• juridisk enhet, eierkonsern, leveransesteder og underleverandører;
• grenser for arkitektur og dataflyt, inkludert administrativ tilgang og supportveier;
• bevis for MFA, gjennomganger av privilegerte tilganger og fjerning av tilgang;
• prosesser for sårbarheter, patcher og endringer, med aktuelle eksempler på at de fungerer;
• varslingsvei ved hendelser, eskaleringskontakter og sikring av bevis;
• resultater fra gjenopprettings- og kontinuitetstester for den bestilte tjenesten;
• uavhengige rapporter, deres omfang, unntak og status for utbedringstiltak;
• foreslått SLA, gjenopprettingsmål, revisjonsstøtte og bistand ved avtaleslutt.

Et sertifikat støtter vurderingen, men beviser ikke automatisk at det dekker administrasjonspanelet for WordPress, supportteamet og backupmålet. Registrer i bevisregisteret dato, perioden som ble revidert, hvem som vurderte og åpne spørsmål. Hvis materialet er konfidensielt, kan man avtale kontrollert innsyn, en uavhengig rapport eller en konkret klausul. Et mangelpunkt skal ikke markeres som oppfylt bare fordi leverandøren nektet å utlevere dokumentet.

#Underleveranser i DORA hos WordPress-leverandører

Den direkte avtaleparten håndterer sjelden hele stakken. Et byrå for administrert WordPress kan bruke sky, CDN, et sakssystem, overvåking og ekstern support. Avtalen og registeret må skille avtaleparten fra virksomhetene som faktisk lagrer data, administrerer systemet eller støtter en kritisk eller viktig funksjon.

Det må fastsettes hvilke endringer i underleveranser som krever varsel, hva varselet inneholder, hvordan innsigelse eller oppsigelse fungerer og hva som skjer med eksisterende data. Vurderingen omfatter også konsentrasjon på fjerde nivå. To tilsynelatende uavhengige leverandører kan være avhengige av den samme hyperscaleren, DNS-operatøren eller identitetsleverandøren. En liste som ble samlet ved signering og aldri oppdatert, er ingen effektiv kontroll.

#Hvordan teste exit fra en IKT-leverandør

To logoer på et diagram garanterer ikke diversifisering. Hvis reservehostingen bruker samme skyregion, backupkontoen samme identitetssystem og DNS fortsatt er under kontroll av leverandøren som forlates, kan alternativet svikte sammen med primærtjenesten. Kartlegg felles eierskap, infrastruktur, geografi, administrative påloggingsdata og spesialkompetanse.

Exit-testen bør bekrefte at et autorisert team kan hente ut aktuelle data og konfigurasjon, kontrollere integriteten, gjenopprette tjenesten, flytte trafikken, bevare påkrevde registreringer og fjerne gammel tilgang. Mål tiden og sammenlign den med den aksepterte forretningsmessige toleransen. Noter manuelle trinn, lisensbegrensninger, formatproblemer og funksjoner som ikke lot seg gjenopprette. Resultatet kan være en akseptert restrisiko, en forbedringsplan eller bytte av tjenestekilde. Artikkel 28 pålegger ikke automatisk duplisering av hver avhengighet uansett kostnad.

#Periodisk gjennomgang av IKT-leverandøren og godkjenningskriterier

Hvor ofte ny vurdering skjer, avhenger av kritikalitet og endringer. En ny gjennomgang bør utløses av en vesentlig hendelse, et oppkjøp, et nytt behandlingssted, en viktig endring av underleverandør, en omlegging av tjenesten eller gjentatte SLA-brudd. Tjenesteeieren, innkjøp, sikkerhet, juridisk avdeling og personvern trenger tildelte roller. Å sende ut et årlig spørreskjema uten å vurdere svarene er ikke effektivt tilsyn.

Før godkjenning bør følgende foreligge: en kontrolleier, et komplett bevisregister, lukkede avtalehull eller formelt aksepterte unntak, en oppføring i registeret, en gjennomførbar exit-plan og en dato for neste gjennomgang. Godkjenningen skiller bekreftede fakta, leverandørens erklæringer, forhold utenfor omfanget og restrisiko. En leverandørrevisjon reduserer usikkerheten, men sertifiserer ikke det finansielle foretakets etterlevelse av DORA og garanterer ikke kontinuitet i tjenesten.

For å avklare omfanget til et pristilbud, send en skriftlig brief med den finansielle funksjonen, leverandøren og tjenesten, arkitekturen, dataklassene, kjente underleverandører, gjenopprettingsmålene, avtalestatus og innkjøpsfristen. En gjennomgang av beredskapen for NIS2 og DORA kan da strukturere leverandørregisteret, bevishullene, avtalesjekklisten, konsentrasjonsanalysen og planen for ny test av WordPress-flaten.

#Relaterte tekster om etterlevelse

• Pilar: NIS2 og DORA på WordPress: etterlevelsesstakken 2026
• Cyber Resilience Act + NIS2 + DORA: etterlevelsesstakken 2026 for headless WordPress