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. 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, incluidas las que gestionan un SMN o un SOC.
- Proveedores de servicios de criptoactivos bajo MiCA.
- Empresas de seguros y reaseguros.
- Mediadores de seguros por encima del umbral de tamaño.
- Proveedores de servicios de financiación participativa.
- Fondos de inversión (gestoras de OICVM, GFIA).
A ellos se suman los proveedores terceros críticos de servicios TIC (CTPP), designados con arreglo al artículo 31 conjuntamente por la EBA, la ESMA y la EIOPA. La primera ronda de designaciones tuvo lugar en 2025 y la dominan los hyperscalers (la lista pública está en el portal de las Autoridades Europeas de Supervisión). Es poco probable que una agencia WordPress llegue a ser CTPP. Una plataforma de hosting WordPress gestionado con una gran cartera de clientes financieros sí puede serlo.
Requisitos del artículo 28 de DORA, apartado por apartado
El artículo 28 tiene ocho apartados. Los operativos para un encargo WordPress:
Artículo 28, apartado 1. La entidad financiera gestiona el riesgo de terceros TIC como parte integrante de todo su marco de gestión del riesgo TIC. El marco, las políticas y la supervisión corresponden a la entidad, no al proveedor. El proveedor aporta las evidencias que sostienen ese marco.
Artículo 28, apartado 2. Una estrategia sólida, completa y bien documentada sobre el riesgo de terceros TIC. La entidad lleva la documentación. El proveedor debe estar preparado para alimentarla.
Artículo 28, apartado 3. Un registro de todos los contratos con proveedores terceros de servicios TIC, distinguiendo los que soportan funciones críticas o importantes. El registro debe poder comunicarse al regulador. Para WordPress: hosting, CDN, WAF, pasarela de pago, correo transaccional, proveedor de IA, herramienta de monitorización y destino de las copias de seguridad.
Artículo 28, apartado 4. Due diligence precontractual. Identificación y evaluación de todos los riesgos relevantes. Análisis del riesgo de concentración al añadir otro contrato con el mismo proveedor o con un proveedor del mismo grupo.
Artículo 28, apartado 5. Evaluación de conflictos de intereses. El órgano de dirección aprueba la política de uso de servicios TIC que soportan funciones críticas o importantes.
Artículo 28, apartado 7. Reevaluación periódica del contrato.
Artículo 28, apartado 8. Estrategia de salida para los servicios TIC que soportan funciones críticas o importantes. Documentada, probada y con plan de transición.
Cláusulas contractuales del artículo 30 de DORA en el contrato de hosting
El artículo 30, apartado 2, enumera las cláusulas mínimas de cualquier contrato. El artículo 30, apartado 3, añade cláusulas para los contratos que soportan funciones críticas o importantes. La plantilla de agencia que entrego junto con los contratos de hosting y WAF las cubre todas:
| Cláusula | Apdo. art. 30 | Qué figura en el contrato WordPress |
|---|---|---|
| Descripción clara del servicio | 30(2)(a) | Nivel de hosting, conjunto de reglas WAF, plugins incluidos en el precio, tiempos de respuesta |
| Ubicación de los datos | 30(2)(b) | Centro de datos en la UE/EEE, soporte desde la UE, sin subcontratistas fuera de la UE sin notificación |
| Requisitos de disponibilidad y seguridad | 30(2)(c) | SLA de disponibilidad, RPO, RTO, cifrado en reposo y en tránsito |
| Protección de datos personales | 30(2)(d) | Contrato de encargo del tratamiento según el artículo 28 del RGPD, registro de actividades de tratamiento |
| Derecho de acceso, inspección y auditoría | 30(2)(e) | Auditoría presencial o remota, frecuencia, plazos |
| Descripciones de los niveles de servicio | 30(2)(f) | Matriz de SLA, mecanismo de descuentos por incumplimiento |
| Cooperación con las autoridades de supervisión | 30(2)(g) | El proveedor coopera con el regulador cuando se le solicita |
| Derechos de resolución | 30(2)(h) | Incumplimiento grave, resolución impuesta por el regulador, cambio de control |
| Participación en concienciación y formación | 30(2)(i) | Briefing anual de seguridad, persona de contacto designada |
| Subcontratación | 30(3)(c) | Consentimiento previo para subcontratar funciones críticas |
| Pruebas de penetración basadas en amenazas | 30(3)(g) | Cooperación en las TLPT del artículo 26 |
| Apoyo a la estrategia de salida | 30(3)(f) | Formato de exportación de datos, asistencia en la transición, periodo de funcionamiento en paralelo |
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 crítico 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 crítico 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. Siempre crítico 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 según el art. 28, apartado 2, letra d.
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.
¿Cómo evaluar el riesgo de concentración DORA con un solo proveedor de nube?
El artículo 28, apartado 4, introduce una prueba que atrapa a las agencias WordPress más a menudo de lo que se cree: no concentrar funciones críticas en proveedores del mismo grupo propietario. Un banco que usa Cloudflare para CDN, Cloudflare Workers para backend, Cloudflare R2 para almacenamiento de objetos y Cloudflare Stream para vídeo tiene un riesgo de concentración alto en un solo proveedor. 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 registro de riesgos debe reconocerlo de forma explícita y justificarlo o planificar la diversificació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 contrato de hosting obliga al proveedor a mantener los servicios durante la migración, al mismo precio, al menos durante un periodo documentado.
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 una due diligence adicional según el artículo 28, apartado 4, sobre el riesgo jurisdiccional.
Cómo clasificar una función crítica o importante en DORA
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 crítica 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.
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 soportan una función crítica o importante.
Hay que determinar qué cambios en la subcontratación requieren notificación, qué contiene el aviso, cómo funcionan la oposición o la resolución y qué ocurre con los datos existentes. 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. Una nueva revisión debe activarse 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.
