DORA-informasjonsregisteret for WordPress-leverandører: obligatoriske felt

#DORA-informasjonsregisteret for WordPress-leverandører: obligatoriske felt

Artikkel 28(3) i forordning 2022/2554 pålegger hvert finansielt foretak å føre og oppdatere et informasjonsregister over avtaler med tredjeparts IKT-leverandører. Gjennomføringsforordning (EU) 2024/2956 fastsetter feltstrukturen: femten tabeller med navngitte kolonner. Et WordPress-byrå som leverer tjenester til en bank, et forsikringsselskap, et verdipapirforetak eller en betalingsinstitusjon havner i dette registeret og må levere data i tide og i riktig form.

Dette er en støtteartikkel under hovedsiden om NIS2 og DORA på WordPress, med henvisning til forklaringen av DORA artikkel 28 om tredjepartsrisiko.

#Sammendrag

• Femten tabeller fastsatt av gjennomføringsforordning 2024/2956.
• Avtaler om kritiske eller viktige funksjoner har ekstra kolonner (erstattbarhet, konsentrasjonsrisiko, exitplan).
• Kjeder av underleverandører er gjennomsiktige ned til det nivået som er vesentlig for det finansielle foretaket.
• Byrået sender ikke inn registeret; byrået mater det.
• De fleste byråer hopper over fire av de femten tabellene ved første innsending.

#Hvilke 15 tabeller har DORA-informasjonsregisteret

I henhold til artikkel 28(3) må hvert finansielt foretak rapportere registeret minst én gang i året til sin tilsynsmyndighet og til den europeiske tilsynsmyndigheten gjennom et felles rapporteringsrammeverk. Gjennomføringsforordningen fra 2024 definerer skjemaet. De femten tabellene:

1. Opplysninger om foretaket.
2. Opplysninger om filialen.
3. Opplysninger om datterselskapet.
4. IKT-tjenester.
5. Identifisering av funksjoner.
6. Avtaler.
7. Avtalens funksjoner.
8. Avtalens IKT-tjenester.
9. Avtalens risiko.
10. Underleveranser (underleverandører).
11. Bestemmelser om opphør.
12. Lokasjoner.
13. Ansvarlige personer eller organer.
14. Avtaler om kritiske eller viktige funksjoner.
15. Avtaler med konsentrasjon (tredjepart innenfor konsernet).

Av disse femten dukker et WordPress-byrå vanligvis opp i tabell 4, 6, 8, 9, 10, 11, 12 og 14. Tabell 1-3, 5, 7 og 13 tilhører det finansielle foretaket. Tabell 15 forekommer sjelden og bare når byrået har et morselskap eller er en hyppig leverandør i foretakets konsern.

#Hvilke data WordPress-leverandøren leverer under DORA

Per IKT-tjeneste (tabell 4) og per avtale (tabell 6) leverer byrået kolonnene som det finansielle foretaket overfører til registeret. En praktisk, ikke uttømmende liste:

• Tjenestebeskrivelse: WordPress-hosting, utvikling av plugins, headless frontend, support, sikkerhetsrevisjoner, oppført per post og ikke i én felles sekk.
• Leverandørnavn og LEI: byråets Legal Entity Identifier. Et lite WordPress-byrå uten LEI må skaffe seg en før avtalen signeres.
• Registreringsland og forretningsadresse.
• Konsernstilhørighet: morselskap, datterselskaper, søsterselskaper.
• Leverte tjenester: hvilke produkter som berøres, med kritikalitetsflagg.
• Behandlede data: kundedata, transaksjonsdata, ansattdata, ingen.
• Datalokasjoner: land og datasenterleverandør per lagringslag (produksjon, backup, loggarkiv).
• Underleverandører: alle leverandører byrået bruker for å levere tjenesten (Cloudflare, Sentry, utrullingsplattform, overvåking, AI-API-er).
• Underleverandørenes jurisdiksjoner: land og gjeldende lov per underleverandør.

Tabell 11 (bestemmelser om opphør) krever at byrået opplyser om:

• Oppsigelsestid for det finansielle foretaket.
• Oppsigelsestid for byrået.
• Utløsere for tidlig opphør fra det finansielle foretakets side.
• Exitplan: hvordan det finansielle foretaket får tilbake data og drift.

Tabell 14 (avtaler om kritiske eller viktige funksjoner) krever ytterligere dokumentasjon dersom WordPress-tjenesten støtter en kritisk eller viktig funksjon. Vurdering av erstattbarhet, konsentrasjonsrisiko, exitplan med realistiske tidsfrister, fast testplan.

#Hva WordPress-byråer oftest mangler i DORA-registeret

Fem gjentakende hull fra leverandørgjennomganger 2025-2026:

Manglende LEI. Et WordPress-byrå uten Legal Entity Identifier forsinker både avtalen og registeret. En LEI koster omtrent like mye som en årlig domenefornyelse. Det finnes ingen unnskyldning for å mangle LEI når man betjener den regulerte finanssektoren.

Ufullstendig liste over underleverandører. Cloudflare er med, Sentry er med; AI-leverandøren for redaksjonelle verktøy, e-postreléleverandøren, utrullingsplattformen og målplasseringen for eksterne sikkerhetskopier blir glemt. Registeret består ikke gjennomgangen, og byrået må gjennom innkjøpsprosessen på nytt.

Exitplan i ett avsnitt. “Vi overleverer data på forespørsel” er ingen exitplan. Det finansielle foretaket trenger anslått antall dager for overlevering, format for datalevering, overlevering av kodelager, overlevering av runbook, liste over avhengigheter og prosedyre for nedleggelse av kontoer. Minst tre sider, helst et versjonert dokument.

Manglende bevis på backuptest. Artikkel 11 i DORA krever regelmessige tester av den operasjonelle motstandsdyktigheten, inkludert gjenoppretting. Et byrå uten kvartalsvis gjenopprettingslogg stryker på gjennomgangen ved første revisjon.

Manglende vurdering av kritisk funksjon. Byrået hevder “vi er ikke kritiske” fordi WordPress-nettstedet “bare er markedsføring”. Compliance-teamet hos det finansielle foretaket er uenig, fordi et merkevarebrudd skader kundenes tillit. Avklar dette tidlig i avtalen, ikke under revisjonen.

#Hvordan forberede den første registreringen i DORA-registeret

En praktisk sjekkliste for et WordPress-byrå som skal inn i sitt første register:

1. Skaff LEI hvis den mangler.
2. Kartlegg underleverandørene, med land og gjeldende lov per leverandør.
3. Skriv en versjonert exitplan: data, kode, runbook, kontoer.
4. Dokumenter datalokasjonene per lagringslag og per underleverandør.
5. Test en full gjenoppretting fra ekstern backup; logg tidsstempel, varighet og resultat.
6. Kartlegg de leverte tjenestene mot det finansielle foretakets funksjoner; flagg de kritiske eller viktige.
7. Utarbeid en erklæring om erstattbarhet: hvilke konkurrenter som kan erstatte tjenesten deres, og på hvor mange uker.
8. Innfør en kvartalsvis gjennomgangsrytme: oppdatering av data, signatur og arkivering hvert kvartal.

Gjort før den første avtalen betaler en slik forberedelse seg mange ganger tilbake. Gjort under den første revisjonen dobler den kostnaden for oppdraget.

#Hvordan lage en feltoversikt for DORA-registeret

Leveransen til registeret bør være et kontrollert datasett, ikke et spørreskjema fylt ut etter hukommelsen. Det opprettes en egen post for den juridiske enheten, avtalen, IKT-tjenesten, den støttede funksjonen, lokasjonen og hver vesentlig underleverandørrelasjon. Hvert objekt får en stabil intern identifikator. Navn og avtaler endrer seg; identifikatoren binder versjonene sammen uten at man må gjette om to oppføringer beskriver samme leverandør.

For hvert felt registrerer du definisjon, format, tillatte verdier, om feltet er obligatorisk i malen som brukes, kildesystem, eier og bevis. “Ikke relevant”, “ukjent” og et tomt felt er ulike tilstander. Datoer, landkoder og juridiske navn må følge det påkrevde formatet. Man skal aldri finne opp en LEI eller en annen identifikator. Det finansielle foretaket bør bekrefte hvilken type identifikator og hvilke valideringsregler som kreves i gjeldende mal og av den ansvarlige myndigheten.

#Hvor kommer dataene til DORA-registeret fra

Dataene kommer fra flere områder. Innkjøp oppbevarer avtalen og tilleggene. Juridisk avdeling har ansvaret for klausulene om oppsigelse, revisjon, underleveranser og exit. Økonomi fører leverandørregisteret. Sikkerhet og arkitektur kobler tjenester til systemer og funksjoner. Personvern beskriver datakategorier og behandlingssteder. Byrået leverer sin juridiske identitet, tjenesteomfang, underleverandører, driftslokasjoner og exitmateriell.

Hvert eksportfelt trenger opplysninger om opprinnelse: dokument eller system, kildefelt, uttrekksdato, transformasjonsregel og kontrollør. Hvis startdatoen kommer fra et tillegg og ikke fra rammeavtalen, bør posten forklare det. Hvis flere plugin-abonnementer utgjør én tjeneste, må godkjenningen av grupperingen tas vare på. Slik blir korrigeringer reproduserbare, og en verdi i et regneark blir ikke et faktum uten kilde.

Kildebevisene oppbevares sammen med posten: signert versjon av avtalen, leverandørerklæring, arkitekturdiagram, godkjent lokasjonsliste og endringsvarsel. Tilgangen bør begrenses, fordi pakken kan avsløre sikkerhetsarkitektur, kontakter og kommersielle vilkår.

#Hvem har ansvaret for DORA-registeret og når skal det oppdateres

Det finansielle foretaket forblir ansvarlig for sitt register. Registereieren kontrollerer skjemaet og kalenderen. Avtaleeierne verifiserer avtaler og funksjoner. Sikkerhet kontrollerer kartleggingen av tjenester og avhengigheter. Innkjøp følger opp leverandørsvarene. WordPress-byrået utpeker en dataeier og en stedfortreder for spørsmål og godkjenning av leveransen.

Gjennomgangen skjer periodisk og utløses av hendelser. Til slike hendelser hører en ny avtale eller et tillegg, oppstart eller avvikling av en tjeneste, endret juridisk navn, en ny underleverandør, endret hostingregion, oppkjøp, revisjon av exitplanen og en ny vurdering av kritisk funksjon. Den bindende rytmen følger av DORA, de tekniske gjennomføringsstandardene, foretakets prosedyrer og myndighetens instrukser. En kvartalsvis oppdatering kan være en intern kontroll, men presenteres her ikke som en universell lovfestet frist.

#Hvordan validere DORA-registerdata før eksport

Strukturelle kontroller sjekker obligatoriske felt, unike identifikatorer, datoer og koder, referanser og foreldreløse tjeneste- eller underleverandørposter. Semantiske kontroller sammenligner datoer med den signerte avtalen, rekkefølgen på start og slutt, lokasjoner med arkitekturen, underleverandøren med en konkret tjeneste og relasjonene for kritiske funksjoner med det finansielle foretakets beslutning.

Vesentlige endringer går gjennom firøyneprinsippet. En avvist post returneres med feilkode og forklaring, i stedet for å bli rettet i det stille. Resultatet, personen, tidspunktet og versjonen av datasettet tas vare på. Før innsending sammenlignes antall poster og sentrale summer med den forrige godkjente eksporten, og tillegg, slettinger og endrede identifikatorer forklares.

#Hva skal eksporten av DORA-registeret og bevispakken inneholde

Eksporten lages fra en frosset versjon, ikke fra et regneark som fortsatt redigeres. Den får dataversjon, opprettelsestidspunkt, skjemaversjon og kontrollsum. Den maskinlesbare filen, en lesbar kontrollrapport, valideringsresultatene, godkjenningene og en kildeindeks tas vare på. Finnes det et testmiljø, bør importen øves der. Tegnkoding, skilletegn og datoformat kan avvise data som er faglig korrekte.

Byråets overlevering omfatter enheten, avtalene, tjenestene, lokasjonene, underleverandørene, datoen for datagrunnlaget, endringer, kjente mangler og kontaktperson. Man bør ikke hevde at et slikt utsnitt sikrer at hele registeret er komplett. Konsolidering på konsernnivå, klassifisering av funksjoner og innsending forblir det finansielle foretakets oppgave.

#Slik verifiserer du leverandørens svar til DORA-registeret

Forespørselen til leverandøren bør peke på en konkret avtale og tjeneste. I stedet for en fri liste med spørsmål lønner det seg å sende en versjonert mal, feltdefinisjoner, eksempler, tillatte koder og en sikker returkanal. Leverandøren bekrefter datoen for datagrunnlaget og markerer data som avhenger av svar fra underleverandører. Spørsmålene føres på posten, ikke i flere uavhengige e-posttråder.

En endring skal ikke slette historikken. Ta vare på forrige verdi, ny verdi, gyldighetsdato, årsak, kilde og godkjenning. En ny hostingregion kan ha egne datoer for varsling, avtalemessig samtykke og teknisk oppstart. Historikken gjør det mulig å fastslå hvilken tilstand som gjaldt på datoen for en bestemt rapport.

Det trengs også en regel for duplikater. Ett konsern kan opptre som motpart, plattform og underleverandør gjennom ulike selskaper. Juridiske enheter føres hver for seg og kobles med en konsernrelasjon. Handelsnavn, produkt og avtalepart er ikke det samme feltet. Navnet på en plugin peker ikke automatisk på den juridiske leverandøren eller datalokasjonen.

Før godkjenning leser eieren posten som en fullstendig avhengighet: hvilken funksjon støttes av hvilken avtale, tjeneste, hvilket selskap og hvilken lokasjon, og hvordan exit foregår. Kan ikke dette forklares, trenger formelt utfylte felt fortsatt arbeid. Mangler føres på en kvalitetsliste med eier og frist, i stedet for å bli erstattet av antakelser.

#Begrensninger i denne veiledningen til DORA-registeret

#Hvordan oppdatere DORA-registeret etter endret hostingregion

Tenk deg at en administrert WordPress-installasjon flyttes mellom europeiske regioner hos den samme juridiske hostingleverandøren. Endringen består ikke i å overskrive ett landfelt. Dataeieren identifiserer avtaler, tjenester, støttede funksjoner, lokasjoner for produksjon, kopier og logger samt underleverandørrelasjoner. Avtaleeieren sjekker kravet om samtykke. Sikkerhet bekrefter datoen for teknisk oppstart, og personvern vurderer endringen i informasjonen om behandlingen.

Endringspakken inneholder forrige og ny verdi, varslingsdato, samtykke, gyldighetsdato, kilder og postidentifikatorer. Valideringen sjekker landkoden, relasjonen mellom lokasjon og tjeneste og at produksjon, backup og arkiv behandles hver for seg. Hvis den forrige regionen er i drift under migreringen, kan begge stedene trenge en gyldighetsperiode. En umiddelbar overskriving ville fjerne informasjonen om den faktiske tilstanden.

Kontrolløren sammenligner leverandørens erklæring, arkitekturbeviset og avtalen. Et avvik blir en datakvalitetsoppgave med eier, ikke en grunn til å velge den mest beleilige verdien. Godkjenning krever godkjente kilder, korrekt skjemavalidering, konsistente relasjoner, en forklart differanse mot forrige eksport og at endringen er overlevert til de øvrige eierne.

#Hvordan følge opp leverandøren og godkjenne dataene

Håndteringen av svar bør ha eksplisitte tilstander: sendt, mottatt, verifisering, krever avklaring, godkjent og utløpt. Forespørselen angir post, felt, format, sikker kanal og frist. En forespørsel om avklaring beskriver en konkret motsigelse, for eksempel et land for underleverandøren som ikke stemmer med lokasjonsvedlegget. Et generelt “sjekk alt på nytt” forbedrer ikke kvaliteten.

Godkjenning skjer på feltnivå. Den juridiske identiteten kan godkjennes mens lokasjonen fortsatt er åpen. Registereieren avgjør om en ufullstendig post kan gå inn i arbeidsdatasettet og hva som blokkerer eksporten. Avtalemessige eller operative data skal ikke gjettes ut fra et markedsføringsnettsted. Mangler et vesentlig bevis, eskaleres saken til avtaleeieren.

Før endelig godkjenning kontrollerer en annen person at kildene er oppdaterte, gyldighetsdatoene, koblingen mellom avtale, tjeneste og funksjon, dekningen av underleverandører og markeringen av ukjente verdier. Godkjenningsposten inneholder dataversjon, kontrollør, unntak og neste utløser for oppdatering. Dette er et internt kontrollspor, ikke en godkjenning fra tilsynsmyndigheten.

#Hva endres i DORA-registeret når tjenesteeieren byttes

Etter en omorganisering kan ansvaret for nettstedet gå fra markedsføring til teamet for digitale kanaler uten at leverandøren eller avtalen endres. Registeret må likevel oppdateres med ansvarlig person eller enhet, og det må kontrolleres om kartleggingen av funksjoner er endret. Den forrige eieren godkjenner overleveringen av åpne unntak, den nye bekrefter kontakter, gjennomgangsrytme og beslutningsmyndighet.

Verifiseringen omfatter en fungerende kontaktadresse, stedfortreder, samsvar med organisasjonskatalogen og overlevering av tilgang til bevisene. Det holder ikke å skrive inn et nytt navn hvis ingen har overtatt plikten til å oppdatere. Scenarioet viser at kvaliteten på registeret også avhenger av organisatoriske endringer, ikke bare av tekniske og kontraktsmessige.

Også en godkjent post eldes. Hver vesentlig kilde bør ha en dato for neste kontroll eller en hendelsesbasert utløser. Avtalen vurderes på nytt etter et tillegg eller en forlengelse, lokasjonen etter en infrastrukturendring, underleverandøren etter en melding fra leverandøren og kontakten etter en omorganisering. Fravær av meldte endringer erstatter ikke en planlagt bekreftelse. Også svaret “ingen endringer” bør registreres med dato og godkjenner, i stedet for at den gamle posten stilltiende blir stående.

Kan et felt ikke avklares før eksport, beskriver eieren konsekvensen, eskaleringen og beslutningen. En ukjent verdi kan ikke gjøres om til “ikke relevant” bare for å bestå valideringen. Det bør være tydelig om mangelen er akseptabel, krever utfylling eller blokkerer godkjenningen av posten.

Dette materialet er et kart over datastyring og erstatter ikke gjennomføringsforordning (EU) 2024/2956, gjeldende tilsynsinstrukser eller juridisk rådgivning. Malversjoner, taksonomier og valideringer kan endre seg. Klassifiseringen avhenger av konteksten, og levering av data garanterer ikke at registeret godtas.

Hvis du trenger å strukturere leveransen fra en WordPress-leverandør, send en skriftlig brief via tjenesten for NIS2- og DORA-beredskap. Oppgi perspektiv, jurisdiksjoner, enheter, avtaler og tjenester, registerformat, kildesystemer, underleverandørkjede, frist og kjente valideringsfeil. Ikke send avtaler, tilgangsdata eller sensitiv arkitektur i den første meldingen. Det første resultatet bør være et feltkart, en ansvarsmodell, en datakvalitetsliste og en bevisplan.

#Trenger et WordPress-byrå en LEI-kode under DORA

DORA krever at finansinstitusjoner har full oversikt over hele IKT-leverandørkjeden:

• Plikt til å ha en LEI-kode (Legal Entity Identifier): Et byrå som leverer programvare eller teknisk support til bank- og fintechsektoren må ha en aktiv LEI-kode som fornyes årlig. Uten denne identifikatoren kan det finansielle foretaket ikke rapportere avtalen korrekt til de europeiske tilsynsmyndighetene (EBA, ESMA, EIOPA).
• Identifisering av underleveransekjeden (tabell 10): Institusjonen må vite ikke bare hvem som drifter WordPress, men også på hvems fysiske infrastruktur serverne kjører (f.eks. AWS, Google Cloud, OVHcloud), hvem som leverer DDoS-beskyttelse (Cloudflare) og hvilke eksterne SaaS-biblioteker som deltar i behandlingen av forespørsler (Sentry, Postmark, Datadog).

#Hva må en exitplan for IKT-leverandøren inneholde etter DORA

Tabell 11 og 14 stiller strenge krav til avslutning av samarbeidet:

• Garanti for migrering av data og kode uten nedetid: Avtalen må presisere i hvilket format byrået overleverer MySQL-databasen, Git-repositoriene og utrullingsdokumentasjonen dersom kontrakten avsluttes (f.eks. innen 30 dager etter oppsigelse).
• Regelmessige tester av exitplanen: Finansielle foretak gjennomfører simuleringer av bytte av IKT-leverandør for å verifisere at overgangen fra det nåværende byrået ikke forstyrrer kritiske forretningsprosesser eller fører til tap av kundedata.

#Hvilken revisjonsrett må avtalen med IKT-leverandøren gi etter DORA

Artikkel 30 i DORA-forordningen krever ubetinget at avtaler med IKT-leverandører inneholder revisjonsklausuler:

• Uhindret tilgang for revisorer til infrastrukturen: Avtalen må gi både bankens internkontroll og inspektørene fra den nasjonale finanstilsynsmyndigheten og Den europeiske banktilsynsmyndigheten (EBA) full tilgang til logger, teknisk dokumentasjon og WordPress-hostingmiljøene.
• Samarbeid under avanserte penetrasjonstester (TLPT): Byrået er forpliktet til å delta aktivt i motstandsdyktighetstester basert på trusselscenarioer (Threat-Led Penetration Testing) og vise at det er forberedt på å forsvare seg mot avanserte angrep.
• Oppsummering: Eksemplarisk levering av data til informasjonsregisteret er et bevis på operasjonell modenhet, som bygger varig tillit hos finansinstitusjoner og åpner døren for flerårige bedriftskontrakter.

Pålitelig føring av registeret og vedvarende oppmerksomhet på samsvar med EU-regelverket er den beste beskyttelsen mot risikoen for økonomiske sanksjoner og omdømmetap i finansmarkedet. Profesjonalitet i sikkerhetsteknikk er nøkkelen til varig forretningssuksess.

Tillit bygges på fakta.

#Henvisninger

• NIS2 og DORA på WordPress: hovedsiden
• NIS2 vs DORA: overlapp i omfang for WordPress-byråer i 2026
• EU-samsvarsrevisjon for WordPress