DORA Article 28 ICT third-party risk: WordPress hosting and WAF supplier audit

#DORA Article 28 ICT third-party risk: WordPress hosting and WAF supplier audit

Article 28 of Regulation 2022/2554 is the part of DORA that decides whether a financial-entity client can sign a hosting contract or a WAF subscription at all. It applies to credit institutions, payment institutions, insurers, investment firms, crypto-asset service providers and around fifteen more categories listed in Article 2. From 17 January 2025 it applies directly without national transposition.

This is a supporting article in the NIS2 and DORA on WordPress pillar, with cross-references to the NIS2 Annex II evidence trail and the CRA + NIS2 + DORA stack overview.

#TL;DR

• DORA Article 28 = general principles for managing ICT third-party risk.
• Article 30 = the mandatory contractual clauses.
• Article 31 = the CTPP designation regime, run by the European Supervisory Authorities.
• A WordPress engagement with a bank or insurer triggers a register entry, due diligence, mandatory clauses and an exit strategy.
• Hosting, CDN, WAF, payment gateway plugin and email-sending plugin all enter the register.

#Who DORA covers

Article 2(1) of DORA enumerates the financial entities. The most common in WordPress engagements:

• Credit institutions and their groups.
• Payment institutions and electronic money institutions.
• Investment firms, including those running an MTF or OTF.
• Crypto-asset service providers under MiCA.
• Insurance and reinsurance undertakings.
• Insurance and reinsurance intermediaries above the size threshold.
• Crowdfunding service providers.
• Investment funds (UCITS managers, AIFMs).

Plus the Critical ICT Third-Party Providers (CTPP) designated under Article 31 by the European Banking Authority, ESMA and EIOPA jointly. The first batch of designations ran in 2025 and is dominated by hyperscale cloud providers (the public list lives on the European Supervisory Authorities portal). A WordPress agency is unlikely to be a CTPP. A managed WordPress hosting platform with a large financial-services book might be.

#What Article 28 actually demands

Article 28 has eight paragraphs. The operative ones for a WordPress engagement:

Article 28(1). The financial entity manages ICT third-party risk as an integral part of its overall ICT risk-management framework. The framework, the policies and the governance are at the entity, not the supplier. The supplier provides evidence that supports the entity’s framework.

Article 28(2). Sound, comprehensive and well-documented strategy on ICT third-party risk. The entity must keep documentation. The supplier must be ready to feed it.

Article 28(3). A register of all contractual arrangements with ICT third-party providers, distinguishing those supporting critical or important functions from the rest. The register must be reportable to the regulator. For WordPress: hosting, CDN, WAF, payment gateway, transactional email, AI provider, monitoring tool, backup destination.

Article 28(4). Pre-contractual phase due diligence. Identification and assessment of all relevant risks. Concentration risk analysis when adding another contract with the same provider or a provider in the same group.

Article 28(5). Conflicts of interest assessment. The board approves the policy on the use of ICT services supporting critical or important functions.

Article 28(7). Periodic reassessment of the contractual arrangement.

Article 28(8). Exit strategy for ICT services supporting critical or important functions. Documented, tested, with a transition plan.

#Article 30 mandatory clauses

Article 30(2) lists the minimum clauses for any contract. Article 30(3) adds clauses for contracts supporting critical or important functions. The agency template I ship with hosting and WAF contracts covers all of them:

I keep this matrix as a single Markdown file in the engagement folder. Every contract gets reviewed against it before signing.

#The supplier register, populated for WordPress

A WordPress engagement for a financial entity touches more ICT third-parties than the procurement team usually anticipates. The register I produce on day one of an engagement:

• Hosting provider. The actual data-centre operator, the management plane, the support team. Critical-or-important if the WordPress site is part of customer-facing service delivery.
• CDN provider. Cloudflare, Fastly, Akamai. Treats traffic, can see request bodies, terminates TLS. Often classified as critical-or-important.
• WAF provider. Sometimes the same entity as the CDN, sometimes separate (Sucuri, Imperva). Inspects payloads. Critical-or-important.
• Payment gateway plugin. Stripe, Adyen, mollie, regional gateways. The plugin author is one supplier; the gateway operator is another. Both go into the register.
• Transactional email provider. SES, Postmark, SendGrid. Carries password resets, KYC notifications, AML alerts. Often critical-or-important.
• Monitoring and APM. New Relic, Datadog, Sentry. Receives stack traces and partial request payloads.
• Backup destination. S3, Backblaze, Wasabi. Holds the database and the uploads. Always critical-or-important.
• AI provider. If the WordPress site uses an LLM for any customer-touching function (chat, summarisation), the LLM provider is in scope.
• Plugin marketplace. WordPress.org, premium marketplaces. Update channels are part of the supply chain under Article 28(2)(d).

For each provider the register holds: legal name, contract reference, services description, data flows, criticality classification, location of processing, last due-diligence date, exit strategy reference.

#Concentration risk and the same-group test

Article 28(4) introduces a test that catches WordPress agencies more often than expected: do not concentrate critical functions in providers that share an ownership chain. A bank that uses Cloudflare for CDN, Cloudflare Workers for backend, Cloudflare R2 for object storage and Cloudflare Stream for video has high concentration risk on a single provider. This is not a Cloudflare-specific finding; the same applies to AWS, Azure or GCP stacks.

For WordPress this often surfaces as: hosting on AWS, backups to S3, email through SES, monitoring through CloudWatch. Four AWS dependencies, one provider. The risk register has to acknowledge it explicitly and either justify it or plan diversification.

#Exit strategies that actually work

Article 28(8) requires the exit strategy to be documented and tested. For WordPress hosting and WAF a real exit strategy includes:

• Database export in standard format. SQL dump compatible with stock MySQL or MariaDB, no proprietary extensions.
• Filesystem export including uploads. Tar or zip archive, downloadable from outside the provider’s console.
• DNS control. Domain registrar account owned by the financial entity, not the agency, not the host.
• Plugin and theme licence portability. Licences in the entity’s name, transferable to a new host.
• Tested transition. A staging environment on an alternative host that can be promoted in a documented timeframe. The test is logged and dated.
• Contractual transition window. The hosting contract obliges the provider to continue services during the migration, paid at the same rate, for at least a documented period.

Pricing for engagements that include the exit-strategy package is individual; the exit document itself adds days, not hours, and it is a deliverable.

#What this changes for the procurement conversation

A WordPress agency that arrives with the Article 30 clause matrix already populated, the supplier register template ready, and a proven exit strategy passes procurement faster. The financial entity does not have to translate Article 28 into a contract; it pastes the agency’s deliverables into its own ICT risk-management framework.

This is also the reason why a regulated client filters supplier shortlists by jurisdiction. An EU-based agency operating under EU contract law removes a layer of friction; an agency outside the EU triggers extra Article 28(4) due diligence on jurisdictional risk.

#Cluster reading

• Pillar: NIS2 and DORA on WordPress: 2026 compliance stack
• NIS2 Annex II for WordPress agencies: scope, deadlines, evidence trail
• WordPress incident response under NIS2: 24-hour early warning playbook
• Cyber Resilience Act + NIS2 + DORA: the 2026 compliance stack for headless WordPress