DORA Register of Information for WordPress vendors: required fields

#DORA Register of Information for WordPress vendors: required fields

Article 28(3) of Regulation 2022/2554 obliges every financial entity to maintain and update a Register of Information on contractual arrangements with ICT third-party service providers. The Implementing Regulation (EU) 2024/2956 sets the field structure: fifteen tables, each with named columns. A WordPress agency supplying a bank, an insurer, an investment firm or a payment institution lands inside this register and must provide the data, on time, in the right shape.

This is a supporting article inside the NIS2 and DORA on WordPress pillar, with a cross-reference to the DORA Article 28 third-party risk explainer.

#TL;DR

• Fifteen tables, set by Commission Implementing Regulation 2024/2956.
• Critical or important function arrangements have extra columns (substitutability, concentration risk, exit plan).
• Sub-processor chains are transparent up to the level relevant to the financial entity.
• The agency does not file the Register; the agency feeds it.
• Most agencies miss four of the fifteen tables on first submission.

#What the financial entity files

Per Article 28(3), each financial entity must report the Register at least annually to its competent authority and the European Supervisory Authority via the joint reporting framework. The 2024 Implementing Regulation defines the schema. The fifteen tables are:

1. Entity information.
2. Branch information.
3. Subsidiary information.
4. ICT services.
5. Functions identification.
6. Contractual arrangements.
7. Functions of contractual arrangement.
8. ICT services of contractual arrangement.
9. Risk of contractual arrangement.
10. Subcontracting arrangements (sub-processors).
11. Termination provisions.
12. Locations.
13. Persons or bodies responsible.
14. Critical or important function arrangements.
15. Concentration arrangements (group-wide third party).

Of these fifteen, a WordPress agency typically appears in tables 4, 6, 8, 9, 10, 11, 12, 14. Tables 1-3, 5, 7, 13 belong to the financial entity. Table 15 is rare for a small agency and only appears if the agency has a parent or is a frequent supplier across the entity’s group.

#What the WordPress agency must supply

Per ICT services (table 4) and per contractual arrangement (table 6), the agency must provide the columns the financial entity copies into the Register. The non-exhaustive practical list:

• Service description: WordPress hosting, plugin development, headless front-end, support, security audits - itemised, not a single bucket.
• Provider name and LEI: the agency’s legal entity identifier. A small WordPress agency without an LEI must obtain one before signing the contract.
• Country of registration and headquarters.
• Group affiliation: parent, subsidiaries, sister companies if any.
• Services rendered to the financial entity: which products are touched, with criticality flag.
• Data processed: customer data, transactional data, employee data, none.
• Data locations: country and data centre vendor for each storage tier (production, backup, log archive).
• Sub-processors: every supplier the agency uses to deliver the service (Cloudflare, Sentry, deployment platform, monitoring, AI APIs).
• Sub-processor jurisdictions: country and applicable law for each sub-processor.

Table 11 (termination provisions) requires the agency to disclose:

• Notice period for the financial entity.
• Notice period for the agency.
• Triggers for early termination by the financial entity.
• Exit plan: how the financial entity gets data and operations back.

Table 14 (critical or important function arrangements) demands extra evidence if the WordPress service supports a critical or important function. Substitutability assessment, concentration risk, exit plan with realistic timelines, regular testing schedule.

#What most WordPress agencies miss

Five recurring gaps from supplier reviews in 2025-2026:

LEI not obtained. A WordPress agency without a Legal Entity Identifier delays the contract and the Register. LEIs cost approximately the price of a domain renewal per year. There is no excuse not to have one when working with regulated finance.

Sub-processor list incomplete. Cloudflare is listed; Sentry is listed; the AI provider for editorial tools, the email-relay vendor, the deployment platform and the off-site backup target are forgotten. The Register fails review and the agency goes back through procurement.

Exit plan is one paragraph. “We will hand over data on request” is not an exit plan. The financial entity needs estimated handover days, format of data delivery, source code repository handover, runbook handover, dependency list and shut-down procedure for accounts. Three pages minimum, ideally a versioned document.

Backup test evidence missing. Article 11 of DORA requires regular testing of operational resilience, including restore. The agency without a quarterly restore log fails the supplier review on the first audit pass.

No critical-function flag judgement. The agency claims “we are not critical” because the WordPress site is “just marketing”. The financial entity’s compliance team disagrees because brand outage damages customer trust. Settle this early in the contract, not during the audit.

#How to prepare for first inclusion

A practical checklist for a WordPress agency entering its first Register:

1. Obtain an LEI if missing.
2. Inventory sub-processors, with country and applicable law per provider.
3. Write a versioned exit plan covering data, code, runbook, accounts.
4. Document data locations per storage tier and per sub-processor.
5. Test a full restore from off-site backup; log timestamp, duration and outcome.
6. Map services rendered to the financial entity’s functions; flag critical or important.
7. Draft a substitutability statement: which competitors can replace your service, in how many weeks.
8. Ship a quarterly review cadence: every quarter, refresh the data, sign off, store.

Done before the first contract, this preparation pays back many times over. Done during the first audit, it doubles the engagement cost.

#Build a field inventory with stable identifiers

Treat the register feed as controlled data, not a questionnaire completed from memory. Create one row per legal supplier, contractual arrangement, supplied ICT service, supported function, location and relevant subcontracting relationship. Give each object a stable internal identifier. Names change and contracts are renewed; the identifier lets the financial entity connect versions without guessing whether two spellings describe the same supplier.

For every field record its definition, format, permitted values, whether it is mandatory in the applicable template, source system, owner and evidence. Separate “not applicable” from “unknown” and from an empty value. Record dates in the required format, countries with the required codes and legal entities under their registered names. Do not invent an LEI or other identifier. The entity should confirm the identifier type and validation rules required by its reporting template and competent authority.

#Source systems and data lineage

Register data normally comes from several systems. Procurement owns the signed agreement and amendments. Legal owns notice, audit, subcontracting and termination clauses. Finance holds the vendor master and legal payee. Security and architecture map services to systems and functions. Privacy records data categories and processing locations. The agency supplies its corporate identity, delivery scope, subcontractors, operational locations and exit artefacts.

For each output field, store a lineage note: source document or system, source field, extraction date, transformation rule and reviewer. If “service start date” comes from the effective date of an amendment rather than the original master agreement, the rule must say so. If several plugin subscriptions are grouped into one service, record who approved the aggregation. Lineage makes corrections repeatable and prevents spreadsheet values from becoming unsupported facts.

Keep source evidence close to the record: signed contract version, supplier declaration, architecture diagram, approved location list and change notice. Restrict access because the pack may expose security architecture, personal contacts and contractual terms.

#Ownership and change cadence

Use a simple responsibility model. The financial entity remains accountable for its register. A register owner controls the schema and submission calendar. Contract owners verify arrangements and functions. Security validates service and dependency mappings. Procurement follows up with suppliers. The WordPress agency names one data owner and a deputy who can answer structured questions and approve its feed.

Review is both periodic and event-driven. A scheduled review catches ordinary drift; event triggers should include a new agreement or amendment, service launch or retirement, supplier legal-name change, new subcontractor, hosting-region change, acquisition, exit-plan revision and a new critical-function assessment. The exact reporting and update cadence must follow DORA, the implementing standards, the entity’s procedures and competent-authority instructions. A quarterly supplier refresh can be an internal control, but it is not presented here as a universal statutory deadline.

#Validation before an export

Run structural checks first: required fields present, identifiers unique, dates valid, country and currency codes accepted, parent-child references resolvable and no orphan service or subcontractor rows. Then run semantic checks. Contract dates must agree with the signed agreement; termination dates cannot precede start dates; locations must align with the architecture; subcontractors must support a named service; and critical-function relationships must be approved by the financial entity.

Use a four-eye review for material changes. Return rejected rows with an error code and explanation instead of silently correcting supplier data. Keep validation results, reviewer, time and dataset version. Before submission, reconcile row counts and key totals with the previous accepted export and explain additions, removals and changed identifiers.

#Export and evidence package

Freeze a release candidate rather than exporting a live spreadsheet that continues to change. Give it a dataset version, creation time, schema version and checksum. Retain the machine-readable file, a human-readable control report, validation output, approvals and the source-evidence index. Test import in the financial entity’s reporting workflow where a test facility exists. Encoding, separators and decimal or date formats can invalidate otherwise correct data.

The agency’s handoff should include its covered legal entity, arrangements, services, locations and subcontractors, the “as of” date, changes since the last delivery, known gaps and a named contact. It should not claim that its subset makes the financial entity’s entire register complete. Group consolidation, function classification and regulatory submission remain with the financial entity.

#Limitations and written brief

#Worked QA scenario: a hosting-region change

Assume the agency moves a managed WordPress workload from one European hosting region to another while retaining the same legal hosting provider. The change is not captured by replacing a country cell and closing the ticket. The data owner first identifies every affected arrangement, service, supported function, production location, backup location and subcontracting relationship. The contract owner confirms whether the move was already permitted or required advance approval. Security confirms the technical activation date, while privacy confirms whether the processing record also changes.

The proposed register update carries the old and new values, announcement date, approval date, effective date, source documents and affected record identifiers. Validation checks that the new country code is allowed, that the location row is connected to the correct service, and that backup and log locations were not incorrectly assumed to move with production. If the old region remains during migration, both locations may need a defined validity period rather than an immediate overwrite.

The reviewer then compares the supplier statement, architecture evidence and contract. A disagreement becomes an open data-quality item with an owner; it is not resolved by choosing the most convenient value. Acceptance requires approved source evidence, successful schema validation, consistent linked records, an explained difference from the prior export and confirmation that downstream owners received the change.

#Supplier follow-up and acceptance workflow

Supplier follow-up works best as a small queue with explicit states: requested, received, under review, clarification required, accepted and expired. Each request names the record identifiers, fields in question, expected format, secure return route and response date. A clarification cites the exact inconsistency, for example a subcontractor country that conflicts with the location attachment. It does not ask the supplier to “check everything again”.

Acceptance is field-specific. Corporate identity may be approved while a location remains open. The register owner decides whether an incomplete record can enter an internal working dataset and what prevents regulatory export. No one should infer an answer from a marketing website when contractual or operational evidence is required. Escalation goes to the contract owner when the supplier cannot or will not provide a material field.

Before final acceptance, a reviewer confirms source recency, effective dates, links between agreement, service and function, subcontractor coverage, and treatment of unknown values. The resulting acceptance record identifies dataset version, reviewer, exceptions and next refresh trigger. This creates a defensible trail without implying that an internal approval is supervisory approval.

This guide is a practical data-governance map, not a replacement for Commission Implementing Regulation (EU) 2024/2956, current supervisory instructions or legal advice. Template versions, taxonomies and authority validation rules may change. Classification of a service or function is contextual, and supplying data does not guarantee that a register will pass regulatory validation.

For help organising a WordPress supplier feed, send a written brief through the NIS2 and DORA readiness service. Include the financial entity or supplier perspective, jurisdictions, relevant legal entities, agreements and services, current register format, source systems, subcontractor chain, reporting deadline and validation errors already received. Do not send contracts, credentials or sensitive architecture in the first message. The initial outcome should be a scoped field map, ownership model, data-quality backlog and evidence plan.

#Cross-references

• DORA Article 28 ICT third-party risk for WordPress
• NIS2 Annex II for WordPress agencies: evidence trail
• NIS2 incident reporting timeline 24h/72h/1M
• NIS2 and DORA on WordPress pillar
• NIS2 vs DORA scope overlap for WordPress agencies in 2026
• EU compliance audit for WordPress