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.

#Classify the function before scoring the supplier

Procurement cannot classify a provider from its brand name or annual spend. Start with the function the arrangement supports and the effect of its disruption, degradation or compromise. A brochure site hosted by a bank may be important to communications without supporting a critical financial service. A small plugin that controls customer authentication or payment status may have a much higher operational impact than its contract value suggests.

The assessment record should identify the business service, process owner, affected customers, data handled, recovery objectives, tolerated manual workarounds and dependencies on other providers. It should also state who approved the critical-or-important-function decision and when it will be revisited. This classification drives the depth of due diligence and the additional Article 30 terms. It is not a reusable label that the supplier can award itself.

#A due-diligence evidence pack that procurement can test

Ask for evidence tied to the proposed service rather than a generic security brochure. For a WordPress host, CDN, WAF or managed-service agency, the review pack normally includes:

• legal entity, ownership group, service locations and named subcontractors;
• architecture and data-flow boundaries, including administrative access and support paths;
• access-control, MFA, privileged-access review and personnel offboarding evidence;
• vulnerability, patch and change-management procedures with recent operating samples;
• incident-notification route, escalation contacts and evidence-preservation capability;
• backup, restoration and continuity test results relevant to the contracted service;
• independent assurance reports, their scope, exclusions and remediation status;
• proposed service levels, recovery objectives, audit support and termination assistance.

A certificate can support the review, but it does not answer whether the certified boundary includes the WordPress management plane, support team or backup destination. Record evidence date, period covered, reviewer and unresolved questions. Where the provider cannot disclose sensitive material, agree a controlled review, independent report or specific contractual assurance instead of silently marking the item complete.

#Subcontractors and changes below the first contract

The direct supplier rarely operates the whole stack. A managed WordPress agency may use a cloud platform, CDN, ticketing system, monitoring service and offshore support provider. The contract and register need enough detail to distinguish the contracting party from the entities that actually store data, administer systems or support a critical or important function.

Define which subcontracting changes require notice, what information the notice contains, the objection or termination path and how existing data will be handled. Procurement should also identify fourth-party concentration: two apparently independent suppliers can rely on the same hyperscaler, identity platform or DNS operator. A list that is never updated after signature is not an effective control.

#Test concentration and exit as one scenario

Concentration is not solved merely by having two logos in the architecture. If the secondary host uses the same cloud region, the backup account shares the same identity provider, or DNS remains under the outgoing supplier’s control, the alternative may fail with the primary service. Map common ownership, infrastructure, geography, administrative credentials and specialist knowledge.

An exit test should prove that authorised staff can obtain current data and configuration, validate integrity, rebuild the service, switch traffic, preserve required records and revoke the old supplier’s access. Measure the elapsed time and compare it with the approved business tolerance. Document any manual steps, licence constraints, data-format problems and functions that cannot be reproduced. The result can be an accepted residual risk, a remediation plan or a sourcing change. Article 28 does not imply that every dependency must be diversified regardless of cost.

#Ongoing review and acceptance criteria

Set the review cadence according to criticality and change. Trigger reassessment after a material incident, acquisition, new processing location, important subcontractor change, significant service redesign or deterioration against agreed levels. The service owner, procurement, security, legal and data-protection functions need defined roles; sending an annual questionnaire without evaluating the answers is not sufficient governance.

Before approval, require a named control owner, completed evidence log, resolved contractual gaps or formally accepted exceptions, a register entry, an actionable exit plan and a date for the next review. Acceptance should distinguish facts verified by evidence, supplier assertions, matters outside scope and residual risks. A supplier audit reduces uncertainty; it does not certify the financial entity’s DORA compliance or guarantee uninterrupted service.

For a scoped review, send a written brief with the financial function, proposed supplier and service, architecture, data classes, subcontractors already known, recovery objectives, contract status and procurement deadline. The NIS2 and DORA readiness service can then structure the supplier inventory, evidence gaps, contract checklist, concentration analysis and retest plan for the WordPress surface.

#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