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 av de europeiske tilsynsmyndighetene (EBA, EIOPA og ESMA) gjennom felleskomiteen, etter anbefaling fra tilsynsforumet. Den første listen ble publisert 18. november 2025 og omfatter 19 leverandører: offentlige skyer (Amazon Web Services, Google Cloud, Microsoft, Oracle), IT-rådgivning og outsourcing (Accenture, Capgemini, IBM, Kyndryl, NTT DATA, Tata Consultancy Services), tele- og datasenteroperatører (Colt, Deutsche Telekom, Equinix, InterXion, Orange), leverandører av finansdata (Bloomberg, LSEG Data and Risk) og programvare (FIS, SAP). Ingen WordPress-hosting og ingen CDN står på listen. Et WordPress-byrå er en vanlig IKT-tredjepartsleverandør, og pliktene i artikkel 28 til 30 når det gjennom avtalen med det finansielle foretaket.

#Kravene i DORA artikkel 28, nummer for nummer

Artikkel 28 har ti nummer. De åtte første binder det finansielle foretaket; nr. 9 og 10 gir de europeiske tilsynsmyndighetene i oppdrag å utarbeide tekniske standarder. Hva hvert nummer betyr for et WordPress-oppdrag:

Artikkel 28 nr. 1. Det finansielle foretaket styrer IKT-tredjepartsrisiko som en integrert del av IKT-risikoen i sitt rammeverk for IKT-risikostyring. Bokstav a er setningen innkjøp siterer oftest: foretaket er til enhver tid fullt ansvarlig for å oppfylle pliktene sine, også etter at tjenesten er satt ut. Bokstav b innfører forholdsmessighet, målt etter art, omfang, kompleksitet og betydning av IKT-avhengighetene. Leverandøren leverer bevis; ansvaret flytter ikke over.

Artikkel 28 nr. 2. En strategi for IKT-tredjepartsrisiko som gjennomgås jevnlig, og som omfatter retningslinjer for bruk av IKT-tjenester som støtter kritiske eller viktige funksjoner. Ledelsesorganet gjennomgår jevnlig risikoen i disse avtalene. Mikroforetak og foretak under den forenklede ordningen i artikkel 16 nr. 1 er unntatt fra dette nummeret.

Artikkel 28 nr. 3. Et informasjonsregister over alle avtaler om IKT-tjenester, der de som støtter kritiske eller viktige funksjoner er skilt ut. Foretaket rapporterer minst én gang i året til vedkommende myndighet om antall nye avtaler, kategorier av leverandører og hvilke tjenester som leveres, gjør hele registeret tilgjengelig på forespørsel og varsler myndigheten i tide om enhver planlagt avtale for en kritisk eller viktig funksjon. For WordPress: hosting, CDN, WAF, betalingsgateway, transaksjonell e-post, AI-leverandør, overvåkingsverktøy og lagringssted for sikkerhetskopier.

Artikkel 28 nr. 4. Før avtaleinngåelse vurderer foretaket om avtalen støtter en kritisk eller viktig funksjon (bokstav a), om tilsynsmessige vilkår for avtaleinngåelsen er oppfylt (bokstav b), alle relevante risikoer, inkludert IKT-konsentrasjonsrisikoen i artikkel 29 (bokstav c), gjennomfører due diligence av leverandørens egnethet (bokstav d) og vurderer interessekonflikter (bokstav e).

Artikkel 28 nr. 5. Avtaler bare med leverandører som følger egnede standarder for informasjonssikkerhet. For kritiske eller viktige funksjoner tar foretaket hensyn til de mest oppdaterte standardene av høyeste kvalitet. En ISO/IEC 27001- eller SOC 2-rapport fra hostingleverandøren teller som bevis bare hvis omfanget dekker den avtalte tjenesten.

Artikkel 28 nr. 6. Foretaket fastsetter på forhånd, risikobasert, hvor ofte og på hvilke områder leverandøren skal revideres og inspiseres, og kontrollerer at revisorene har nødvendig kompetanse når tjenesten er teknisk kompleks.

Artikkel 28 nr. 7. Avtalen må kunne sies opp ved vesentlig mislighold fra leverandøren, ved forhold som kan endre utførelsen av funksjonene (inkludert vesentlige endringer hos leverandøren), ved påviste svakheter i leverandørens IKT-risikostyring, eller når vedkommende myndighet ikke lenger kan føre effektivt tilsyn med foretaket på grunn av avtalen.

Artikkel 28 nr. 8. Exit-strategier for IKT-tjenester som støtter kritiske eller viktige funksjoner. Exit skal ikke forstyrre virksomheten, begrense etterlevelsen av regulatoriske krav eller svekke kontinuiteten og kvaliteten i tjenestene til kundene. Exit-planene skal være helhetlige, dokumenterte, tilstrekkelig testet og jevnlig gjennomgått.

Artikkel 28 nr. 9 og 10. Oppdrag om tekniske standarder. Nr. 9 førte til gjennomføringsforordning (EU) 2024/2956 med malene for registeret. Nr. 10 førte til delegert forordning (EU) 2024/1773 om innholdet i retningslinjene i nr. 2.

#Avtaleklausuler fra DORA artikkel 30 i hostingavtalen

Artikkel 30 nr. 1 krever at hele avtalen, inkludert tjenestenivåavtalene, står i ett skriftlig dokument. Nr. 2 lister minimumsinnholdet i enhver IKT-avtale; nr. 3 legger til innholdet for avtaler som støtter kritiske eller viktige funksjoner. Byråmalen jeg leverer sammen med hosting- og WAF-avtaler, følger samme nummerering:

Nr. 4 legger til at partene bør vurdere standardavtaleklausuler utarbeidet av offentlige myndigheter. Jeg holder denne matrisen 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. Gjenopprettingen avhenger av det, så det støtter som regel en kritisk eller viktig funksjon.
• 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 i betydningen leverandørkjede for IKT-tjenester i artikkel 1 nr. 2 i gjennomføringsforordning 2024/2956.

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

#Malene for DORA-informasjonsregisteret etter gjennomføringsforordning 2024/2956

Registeret har ikke fritt format. Gjennomføringsforordning (EU) 2024/2956 fastsetter standardmalene foretaket bruker for registeret etter artikkel 28 nr. 3. Tre av reglene endrer hva et WordPress-byrå må levere:

• Leverandøridentifikator. Artikkel 3 nr. 5 krever at hver leverandør som er en juridisk person, identifiseres med en gyldig og aktiv LEI-kode eller den europeiske unike identifikatoren EUID, og med begge der de finnes. For et selskap i EU kommer EUID fra foretaksregisteret; LEI må søkes om separat. Fysiske personer som driver næring, er unntatt.
• Rang i leverandørkjeden. Artikkel 2 gir hver leverandør en rang: den direkte leverandøren har alltid rang 1, og hver underleverandør et høyere tall. Fakturerer byrået hosting fra en tredjepart, har byrået rang 1 og hostingleverandøren rang 2.
• Underleverandører bak kritiske eller viktige funksjoner. Artikkel 3 nr. 2 bokstav b krever at alle underleverandører som faktisk bærer disse tjenestene, føres inn i registeret, og nr. 6 krever at også de oppgir LEI eller EUID, via den direkte leverandøren.

Artikkel 5 lister malene, blant dem B_05.01 (direkte leverandører og underleverandører), B_05.02 (leverandørkjeden for IKT-tjenester), B_06.01 (identifisering av funksjoner) og B_07.01 (vurdering av tjenester som støtter kritiske eller viktige funksjoner). Etter den strukturen inneholder arket jeg gir kunden, per leverandør: juridisk navn, LEI eller EUID, rang, tjeneste, steder for levering og behandling og funksjonen den støtter.

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

Konsentrasjonsrisiko har en egen artikkel. Artikkel 28 nr. 4 bokstav c viser til artikkel 29, som for tjenester som støtter kritiske eller viktige funksjoner krever at foretaket sjekker om en ny avtale binder det til en leverandør som ikke lett kan erstattes, eller legger enda en avtale til hos samme leverandør eller nært forbundne leverandører. En bank som bruker Cloudflare til CDN, Cloudflare Workers til backend, Cloudflare R2 til objektlagring og Cloudflare Stream til video, havner i det andre tilfellet. Dette er ikke et funn som gjelder Cloudflare spesielt; det samme gjelder AWS-, Azure- eller GCP-stakker.

I WordPress ser det ofte slik ut: hosting på AWS, sikkerhetskopier i S3, e-post via SES, overvåking med CloudWatch. Fire AWS-avhengigheter, én leverandør. Artikkel 29 nr. 1 ber foretaket veie nytte og kostnader ved alternativer, som å bruke ulike leverandører; den krever ikke spredning for enhver pris. Risikoregisteret må anerkjenne konsentrasjonen eksplisitt og enten begrunne den eller planlegge spredning. Artikkel 29 nr. 2 legger til, for underleverandører etablert i et tredjeland, gjeldende insolvensrett, begrensninger i rask gjenoppretting av data og etterlevelse av EUs personvernregler.

#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. Artikkel 30 nr. 3 bokstav f krever en obligatorisk overgangsperiode der leverandøren fortsetter å levere tjenesten mens foretaket flytter. Hostingavtalen fastsetter lengde og pris.
• Tilbakelevering av data. Artikkel 30 nr. 2 bokstav d krever at foretaket kan få tilgang til, gjenopprette og få tilbake dataene sine i et lett tilgjengelig format hvis leverandøren blir insolvent, avvikler virksomheten eller avtalen opphører.

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 gjør at foretaket i tillegg må veie det artikkel 29 nr. 2 krever for et tredjeland: gjeldende insolvensrett, rask gjenoppretting av data og etterlevelse av EUs personvernregler.

#Hvordan klassifisere en kritisk eller viktig funksjon i DORA

Artikkel 3 nr. 22 i DORA definerer en kritisk eller viktig funksjon som en funksjon der en forstyrrelse vesentlig ville svekke foretakets økonomiske resultater eller soliditeten eller kontinuiteten i tjenestene og virksomheten, eller der svikt vesentlig ville svekke etterlevelsen av konsesjonsvilkårene eller andre plikter etter finansregelverket. 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. Artikkel 3 nr. 2 i delegert forordning 2024/1773 krever at foretakets retningslinjer fastsetter metoden for å avgjøre hvilke IKT-tjenester som støtter kritiske eller viktige funksjoner, og når vurderingen skal gjennomgås.

#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.

Delegert forordning (EU) 2025/532, som utdyper artikkel 30 nr. 2 bokstav a, fastsetter disse vilkårene. Etter artikkel 3 avgjør foretaket før signering om leverandøren kan sette ut en tjeneste som støtter en kritisk eller viktig funksjon, og signerer bare hvis leverandøren kan vurdere underleverandørene sine og identifisere alle. Artikkel 4 krever at avtalen angir hvilke tjenester som kan settes ut, og at leverandøren fortsatt er ansvarlig for og overvåker tjenestene underleverandørene leverer. Artikkel 5 regulerer vesentlige endringer: leverandøren varsler dem i god tid, avtalen gir en rimelig frist til å godkjenne eller protestere, og endringen gjennomføres først når foretaket har godkjent den eller latt fristen løpe ut uten innsigelse.

#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. Artikkel 28 nr. 6 krever at hyppighet og områder for revisjon fastsettes på forhånd, og artikkel 3 nr. 1 i delegert forordning (EU) 2024/1773 pålegger ledelsesorganet å gjennomgå retningslinjene for IKT-tjenester som støtter kritiske eller viktige funksjoner, minst én gang i året. En ny gjennomgang av leverandøren bør i tillegg 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