DORA artículo 28, riesgo de terceros TIC: auditoría del proveedor de hosting y WAF para WordPress

#DORA artículo 28, riesgo de terceros TIC: auditoría del proveedor de hosting y WAF para WordPress

El artículo 28 del Reglamento 2022/2554 es la parte de DORA que decide si un cliente del sector financiero puede siquiera firmar un contrato de hosting o una suscripción de WAF. Se aplica a entidades de crédito, entidades de pago, aseguradoras, empresas de servicios de inversión, proveedores de servicios de criptoactivos y unas quince categorías más del artículo 2. Desde el 17 de enero de 2025 se aplica directamente, sin transposición.

Este es un artículo de apoyo dentro del pilar sobre NIS2 y DORA en WordPress, con remisiones a la ruta de evidencias del Anexo II de NIS2 y a la visión general de la pila CRA + NIS2 + DORA.

#TL;DR

• DORA artículo 28 = principios generales de la gestión del riesgo de terceros TIC.
• Artículo 30 = cláusulas contractuales obligatorias.
• Artículo 31 = régimen de designación de CTPP, gestionado por las Autoridades Europeas de Supervisión.
• Un encargo WordPress para un banco o una aseguradora activa la inscripción en el registro, la due diligence, las cláusulas y el plan de salida.
• En el registro entran el hosting, la CDN, el WAF, el plugin de pagos y el plugin de envío de correos.

#A quién se aplica DORA en el sector financiero

El artículo 2, apartado 1, enumera las entidades financieras en las letras a) a t). Las más habituales en encargos WordPress:

• Entidades de crédito y sus grupos.
• Entidades de pago y entidades de dinero electrónico.
• Empresas de servicios de inversión y centros de negociación.
• Proveedores de servicios de criptoactivos bajo MiCA.
• Empresas de seguros y reaseguros.
• Mediadores de seguros, salvo los que sean microempresas o pymes (artículo 2, apartado 3, letra e).
• Proveedores de servicios de financiación participativa.
• Gestores de fondos de inversión alternativos y sociedades de gestión.

A ellos se suman los proveedores terceros esenciales de servicios de TIC (CTPP), designados con arreglo al artículo 31 por las Autoridades Europeas de Supervisión (EBA, EIOPA y ESMA) a través del Comité Mixto, por recomendación del Foro de Supervisión. La primera lista se publicó el 18 de noviembre de 2025 y contiene 19 proveedores: nubes públicas (Amazon Web Services, Google Cloud, Microsoft, Oracle), consultoras y outsourcing de TI (Accenture, Capgemini, IBM, Kyndryl, NTT DATA, Tata Consultancy Services), operadores de telecomunicaciones y centros de datos (Colt, Deutsche Telekom, Equinix, InterXion, Orange), proveedores de datos financieros (Bloomberg, LSEG Data and Risk) y software (FIS, SAP). Ninguna empresa de hosting WordPress ni ninguna CDN figura en esa lista. Una agencia WordPress es un proveedor TIC ordinario, y las obligaciones de los artículos 28 a 30 le llegan a través del contrato con la entidad financiera.

#Requisitos del artículo 28 de DORA, apartado por apartado

El artículo 28 tiene diez apartados. Los ocho primeros obligan a la entidad financiera; los apartados 9 y 10 encargan normas técnicas a las Autoridades Europeas de Supervisión. Lo que cada uno significa para un encargo WordPress:

Artículo 28, apartado 1. La entidad financiera gestiona el riesgo relacionado con las TIC derivado de terceros como elemento integrante de su marco de gestión del riesgo TIC. La letra a) es la frase que más pesa en compras: la entidad sigue siendo en todo momento plenamente responsable del cumplimiento, aunque haya externalizado el servicio. La letra b) introduce la proporcionalidad según la naturaleza, la escala y la complejidad de las dependencias. El proveedor aporta evidencias; la responsabilidad no se traslada.

Artículo 28, apartado 2. Una estrategia sobre el riesgo relacionado con las TIC derivado de terceros, revisada periódicamente, que incluye una política sobre el uso de servicios de TIC que sustentan funciones esenciales o importantes. El órgano de dirección revisa periódicamente los riesgos de esos contratos. Las microempresas y las entidades del régimen simplificado del artículo 16 quedan fuera de este apartado.

Artículo 28, apartado 3. Un registro de información de todos los acuerdos contractuales sobre servicios de TIC, distinguiendo los que sustentan funciones esenciales o importantes. La entidad informa al menos una vez al año a la autoridad competente del número de acuerdos nuevos, las categorías de proveedores y los servicios prestados, pone el registro completo a su disposición cuando lo pide y le comunica a tiempo cualquier acuerdo previsto para una función esencial o importante. Para WordPress: hosting, CDN, WAF, pasarela de pago, correo transaccional, proveedor de IA, monitorización y destino de las copias de seguridad.

Artículo 28, apartado 4. Antes de firmar, la entidad evalúa si el contrato sustenta una función esencial o importante (letra a), si se cumplen las condiciones de supervisión (letra b), todos los riesgos pertinentes, incluido el riesgo de concentración del artículo 29 (letra c), hace las comprobaciones debidas sobre la idoneidad del proveedor (letra d) y evalúa los conflictos de intereses (letra e).

Artículo 28, apartado 5. Solo se contrata con proveedores que cumplan estándares adecuados de seguridad de la información. Para funciones esenciales o importantes, la entidad tiene en cuenta los estándares más actualizados y de mayor calidad. Un informe ISO/IEC 27001 o SOC 2 del hosting sirve como evidencia solo si su alcance cubre el servicio contratado.

Artículo 28, apartado 6. La entidad fija de antemano, con un enfoque basado en el riesgo, la frecuencia y los ámbitos de las auditorías e inspecciones del proveedor, y verifica que los auditores tienen la competencia técnica necesaria cuando el servicio es complejo.

Artículo 28, apartado 7. El contrato debe poder terminarse por incumplimiento importante del proveedor, por circunstancias que alteren el desempeño de las funciones (incluidos cambios importantes en la situación del proveedor), por debilidades demostradas en su gestión del riesgo TIC o cuando la autoridad competente ya no pueda supervisar eficazmente a la entidad por culpa del contrato.

Artículo 28, apartado 8. Estrategias de salida para los servicios de TIC que sustentan funciones esenciales o importantes. La salida no puede perturbar la actividad, limitar el cumplimiento normativo ni perjudicar a los clientes. Los planes de salida son globales, están documentados, se someten a suficientes pruebas y se revisan periódicamente.

Artículo 28, apartados 9 y 10. Mandatos para normas técnicas. El apartado 9 dio lugar al Reglamento de Ejecución (UE) 2024/2956, con las plantillas del registro. El apartado 10 dio lugar al Reglamento Delegado (UE) 2024/1773, sobre el contenido de la política del apartado 2.

#Cláusulas contractuales del artículo 30 de DORA en el contrato de hosting

El artículo 30, apartado 1, exige que el contrato completo, con los acuerdos de nivel de servicio, conste en un único documento escrito. El apartado 2 enumera los elementos mínimos de cualquier contrato TIC; el apartado 3 añade los de los contratos que sustentan funciones esenciales o importantes. La plantilla de agencia que entrego junto con los contratos de hosting y WAF sigue esta numeración:

El apartado 4 añade que las partes deben considerar las cláusulas contractuales tipo elaboradas por autoridades públicas. Mantengo esta matriz como un único archivo Markdown en la carpeta del encargo. Cada contrato se verifica contra ella antes de la firma.

#Registro de información DORA para proveedores WordPress

Un encargo WordPress para una entidad financiera toca más terceros TIC de los que el departamento de compras suele prever. El registro que monto el primer día del encargo:

• Proveedor de hosting. El operador real del centro de datos, el panel de gestión, el equipo de soporte. Crítico o importante si WordPress forma parte de la prestación de servicios a clientes.
• Proveedor de CDN. Cloudflare, Fastly, Akamai. Procesa el tráfico, ve el contenido de las peticiones, termina TLS. A menudo esencial o importante.
• Proveedor de WAF. A veces el mismo que la CDN, a veces otro (Sucuri, Imperva). Inspecciona payloads. Crítico o importante.
• Plugin de pagos. Stripe, Adyen, mollie, pasarelas locales. El autor del plugin es un proveedor; el operador de la pasarela es otro. Ambos van al registro.
• Correo transaccional. SES, Postmark, SendGrid. Transporta restablecimientos de contraseña, notificaciones KYC, alertas AML. A menudo esencial o importante.
• Monitorización y APM. New Relic, Datadog, Sentry. Recibe stack traces y fragmentos de payloads.
• Destino de las copias de seguridad. S3, Backblaze, Wasabi. Guarda la base de datos y las subidas. De él depende la recuperación, por lo que suele sustentar una función esencial o importante.
• Proveedor de IA. Si WordPress usa un LLM en funciones de cara al cliente (chat, resúmenes), el proveedor del LLM entra en el alcance.
• Marketplace de plugins. WordPress.org, marketplaces premium. Los canales de actualización forman parte de la cadena de suministro en el sentido de la cadena de suministro de servicios de TIC del artículo 1, apartado 2, del Reglamento de Ejecución 2024/2956.

El registro guarda para cada proveedor: denominación legal, referencia del contrato, descripción del servicio, flujos de datos, clasificación de criticidad, lugar de tratamiento, fecha de la última due diligence y remisión a la estrategia de salida.

#Plantillas del registro de información DORA según el Reglamento de Ejecución 2024/2956

El registro no es un formato libre. El Reglamento de Ejecución (UE) 2024/2956 fija las plantillas normalizadas que la entidad usa para mantener el registro del artículo 28, apartado 3. Tres de sus reglas cambian lo que una agencia WordPress tiene que entregar:

• Identificador del proveedor. El artículo 3, apartado 5, exige identificar a cada proveedor persona jurídica con un código LEI válido y activo o con el identificador único europeo EUID, y con ambos si existen. Para una sociedad de la UE, el EUID procede del registro mercantil; el LEI se solicita aparte. Las personas físicas que actúan como empresarios quedan exceptuadas.
• Rango en la cadena de suministro. El artículo 2 asigna a cada proveedor un rango: el proveedor directo siempre tiene rango 1 y cada subcontratista un número mayor. Si la agencia factura el hosting de un tercero, la agencia es rango 1 y el hosting rango 2.
• Subcontratistas que sustentan funciones esenciales o importantes. El artículo 3, apartado 2, letra b), obliga a incluir en el registro a todos los subcontratistas que sustentan efectivamente esos servicios, y el apartado 6 exige que también ellos aporten LEI o EUID, a través del proveedor directo.

El artículo 5 enumera las plantillas, entre ellas B_05.01 (proveedores directos y subcontratistas), B_05.02 (cadena de suministro de servicios TIC), B_06.01 (identificación de funciones) y B_07.01 (evaluación de los servicios que sustentan funciones esenciales o importantes). Con esa estructura, la ficha que entrego al cliente lleva por proveedor la denominación legal, el LEI o EUID, el rango, el servicio, los lugares de prestación y tratamiento, y la función que sustenta.

#Cómo evaluar el riesgo de concentración DORA con un solo proveedor de nube

El riesgo de concentración tiene su propio artículo. El artículo 28, apartado 4, letra c), remite al artículo 29, que obliga a la entidad a comprobar, para servicios que sustentan funciones esenciales o importantes, si el nuevo contrato la ata a un proveedor que no es fácilmente sustituible o acumula varios contratos con el mismo proveedor o con proveedores estrechamente relacionados. Un banco que usa Cloudflare para CDN, Cloudflare Workers para backend, Cloudflare R2 para almacenamiento de objetos y Cloudflare Stream para vídeo cae en el segundo supuesto. No es una conclusión propia de Cloudflare; funciona igual con pilas de AWS, Azure o GCP.

En WordPress suele verse así: hosting en AWS, copias de seguridad en S3, correo mediante SES, monitorización con CloudWatch. Cuatro dependencias de AWS, un solo proveedor. El artículo 29, apartado 1, pide ponderar los beneficios y los costes de alternativas, como usar proveedores distintos; no obliga a diversificar a cualquier precio. El registro de riesgos debe reconocer la concentración de forma explícita y justificarla o planificar la diversificación. El artículo 29, apartado 2, añade para los subcontratistas establecidos en un tercer país la ley de insolvencia aplicable, las restricciones a la recuperación urgente de los datos y el cumplimiento de la normativa de protección de datos de la Unión.

#Estrategia de salida DORA para hosting y WAF de WordPress

El artículo 28, apartado 8, exige que la estrategia de salida esté documentada y probada. Para el hosting y el WAF de WordPress, una estrategia de salida real incluye:

• Exportación de la base de datos en formato estándar. Volcado SQL compatible con MySQL o MariaDB estándar, sin extensiones propietarias.
• Exportación del sistema de archivos con las subidas. Archivo tar o zip, descargable fuera del panel del proveedor.
• Control del DNS. La cuenta del registrador de dominios pertenece a la entidad financiera, no a la agencia ni al proveedor de hosting.
• Portabilidad de las licencias de plugins y temas. Licencias a nombre de la entidad, transferibles al nuevo proveedor de hosting.
• Transición probada. Un entorno de staging en un proveedor de hosting alternativo que puede pasar a producción en un tiempo documentado. La prueba queda registrada y fechada.
• Ventana de transición contractual. El artículo 30, apartado 3, letra f), exige un periodo transitorio obligatorio durante el cual el proveedor sigue prestando el servicio mientras la entidad migra. El contrato de hosting fija su duración y el precio.
• Devolución de los datos. El artículo 30, apartado 2, letra d), exige que la entidad pueda acceder a sus datos, recuperarlos y recibirlos en un formato fácilmente accesible si el proveedor entra en insolvencia, cesa su actividad o termina el contrato.

El presupuesto de los encargos que incluyen el paquete de estrategia de salida es individual; el propio documento de salida lleva días, no horas, y es un resultado del encargo.

#Cómo cambia DORA la contratación de una agencia WordPress

Una agencia WordPress que llega con la matriz de cláusulas del artículo 30 completada, una plantilla de registro de proveedores lista y una estrategia de salida probada pasa antes por el proceso de compras. La entidad financiera no tiene que traducir el artículo 28 a un contrato; incorpora los materiales preparados por la agencia a su propio marco de gestión del riesgo TIC.

También por eso un cliente regulado filtra su lista corta de proveedores por jurisdicción. Una agencia de la UE sujeta al derecho de la Unión elimina una capa de fricción; una agencia de fuera de la UE obliga a la entidad a ponderar además lo que el artículo 29, apartado 2, exige para un tercer país: la ley de insolvencia aplicable, la recuperación urgente de los datos y el cumplimiento de la normativa de protección de datos de la Unión.

#Cómo clasificar una función esencial o importante en DORA

El artículo 3, punto 22, de DORA define la función esencial o importante como aquella cuya perturbación afectaría significativamente al rendimiento financiero de la entidad o a la solidez o continuidad de sus servicios y actividades, o cuya interrupción afectaría significativamente al cumplimiento de las condiciones de su autorización o de sus demás obligaciones con arreglo al Derecho de servicios financieros. La criticidad no la decide la marca ni el importe del contrato. El punto de partida es la función que soporta el servicio y el efecto de su indisponibilidad, degradación o vulneración. La web informativa de un banco puede ser importante para la comunicación sin soportar directamente un servicio financiero crítico. Un plugin barato que gestiona la autenticación o el estado de los pagos puede tener un impacto operativo mucho mayor de lo que sugiere el coste de la licencia.

La ficha de clasificación debe indicar el servicio de negocio, el responsable del proceso, los clientes afectados, los datos, los objetivos de recuperación, las posibles alternativas manuales y las dependencias de otros proveedores. También registra quién aprobó la calificación como función esencial o importante y la fecha de la próxima revisión. Esta decisión fija la profundidad de la due diligence y las condiciones adicionales del artículo 30. No es una etiqueta que el proveedor pueda ponerse a sí mismo. El artículo 3, apartado 2, del Reglamento Delegado 2024/1773 exige que la política de la entidad establezca la metodología para decidir qué servicios de TIC sustentan funciones esenciales o importantes y cuándo se revisa esa evaluación.

#Lista de evidencias para la due diligence del proveedor TIC

El departamento de compras debe recibir evidencias referidas al servicio concreto, no una carpeta genérica de seguridad. Para hosting, CDN, WAF o mantenimiento de WordPress, el paquete suele incluir:

• entidad jurídica, grupo propietario, lugares de prestación del servicio y subcontratistas;
• límites de la arquitectura y de los flujos de datos, incluidos el acceso administrativo y las vías de soporte;
• evidencias de MFA, revisiones de accesos privilegiados y retirada de accesos;
• procesos de vulnerabilidades, parches y cambios, con ejemplos recientes de su funcionamiento;
• vía de notificación de incidentes, contactos de escalado y preservación de evidencias;
• resultados de las pruebas de recuperación y continuidad propias del servicio contratado;
• informes independientes, su alcance, exclusiones y estado de las acciones correctivas;
• SLA propuesto, objetivos de recuperación, apoyo a la auditoría y asistencia al finalizar el contrato.

Un certificado respalda la evaluación, pero no demuestra automáticamente que cubra el panel de gestión de WordPress, el equipo de soporte y el destino de las copias de seguridad. En el registro de evidencias, anote la fecha, el periodo cubierto por la revisión, quién evaluó y las preguntas abiertas. Si el material es confidencial, se puede acordar una consulta controlada, un informe independiente o una cláusula concreta. Una carencia no debe marcarse como cumplida solo porque el proveedor se haya negado a entregar el documento.

#Subcontratación en DORA en los proveedores WordPress

La contraparte directa rara vez gestiona toda la pila. Una agencia de WordPress gestionado puede usar nube, CDN, un sistema de tickets, monitorización y soporte externo. El contrato y el registro deben distinguir a la parte contratante de las entidades que realmente almacenan datos, administran el sistema o sustentan una función esencial o importante.

El Reglamento Delegado (UE) 2025/532, que desarrolla el artículo 30, apartado 2, letra a), concreta estas condiciones. Según su artículo 3, la entidad decide antes de firmar si el proveedor puede subcontratar un servicio que sustenta una función esencial o importante, y solo firma si el proveedor sabe evaluar a sus subcontratistas y puede identificarlos a todos. El artículo 4 exige que el contrato diga qué servicios se pueden subcontratar y que el proveedor siga siendo responsable de los servicios prestados por sus subcontratistas y los supervise. El artículo 5 regula los cambios importantes: el proveedor los comunica con antelación suficiente, el contrato fija un plazo razonable para aprobarlos u oponerse y el cambio no se aplica antes de que la entidad lo apruebe o deje pasar el plazo sin oponerse.

La evaluación abarca también la concentración en el cuarto nivel. Dos proveedores en apariencia independientes pueden depender del mismo hyperscaler, del mismo operador de DNS o del mismo proveedor de identidad. Una lista recopilada en la firma y nunca actualizada no es un control eficaz.

#Cómo probar la salida de un proveedor TIC

Dos logotipos en un diagrama no garantizan la diversificación. Si el hosting de respaldo usa la misma región de nube, la cuenta de copias de seguridad el mismo sistema de identidad y el DNS sigue bajo el control del proveedor saliente, la alternativa puede fallar junto con el servicio principal. Mapee la propiedad compartida, la infraestructura, la geografía, las credenciales administrativas y el conocimiento especializado.

La prueba de salida debe confirmar que un equipo autorizado puede obtener los datos y la configuración actuales, comprobar la integridad, restaurar el servicio, redirigir el tráfico, conservar los registros exigidos y retirar el acceso antiguo. Mida el tiempo y compárelo con la tolerancia de negocio aceptada. Anote los pasos manuales, las limitaciones de licencias, los problemas de formato y las funciones que no se pudieron restaurar. El resultado puede ser un riesgo residual aceptado, un plan de mejora o un cambio de origen del servicio. El artículo 28 no obliga automáticamente a duplicar cada dependencia sin importar el coste.

#Revisión periódica del proveedor TIC y criterios de aceptación

La frecuencia de la reevaluación depende de la criticidad y de los cambios. El artículo 28, apartado 6, pide fijar de antemano la frecuencia y los ámbitos de las auditorías, y el artículo 3, apartado 1, del Reglamento Delegado (UE) 2024/1773 obliga al órgano de dirección a revisar al menos una vez al año la política sobre servicios de TIC que sustentan funciones esenciales o importantes. Una nueva revisión del proveedor debe activarse además por un incidente grave, una adquisición, un nuevo lugar de tratamiento, un cambio relevante de subcontratista, una reforma del servicio o incumplimientos repetidos del SLA. El responsable del servicio, compras, seguridad, el departamento jurídico y protección de datos necesitan funciones asignadas. Enviar un cuestionario anual sin evaluar las respuestas no constituye una supervisión eficaz.

Antes de la aceptación deben existir: un responsable del control, un registro de evidencias completo, carencias contractuales resueltas o excepciones aceptadas formalmente, la inscripción en el registro, un plan de salida viable y la fecha de la próxima revisión. La aceptación separa los hechos confirmados, las declaraciones del proveedor, los elementos fuera del alcance y el riesgo residual. La auditoría del proveedor reduce la incertidumbre, pero no certifica el cumplimiento de DORA por parte de la entidad financiera ni garantiza la continuidad del servicio.

Para fijar el alcance de un presupuesto, envíe un briefing por escrito con la función financiera, el proveedor y el servicio, la arquitectura, las clases de datos, los subcontratistas conocidos, los objetivos de recuperación, el estado del contrato y el plazo de compras. Una auditoría de preparación para NIS2 y DORA puede entonces ordenar el registro de proveedores, las carencias de evidencias, la checklist del contrato, el análisis de concentración y el plan de nueva prueba para la superficie WordPress.

#Textos relacionados sobre cumplimiento

• Pilar: NIS2 y DORA en WordPress: pila de cumplimiento 2026