Registro de información DORA para proveedores WordPress: campos obligatorios
El artículo 28, apartado 3, del Reglamento 2022/2554 obliga a cada entidad financiera a llevar y mantener actualizado un registro de información sobre los acuerdos con proveedores terceros de servicios TIC. El Reglamento de Ejecución (UE) 2024/2956 fija la estructura de los campos: quince tablas con columnas definidas. Una agencia WordPress que presta servicios a un banco, una aseguradora, una empresa de servicios de inversión o una entidad de pago entra en este registro y debe aportar los datos a tiempo y con el formato adecuado.
Este es un artículo de apoyo dentro del pilar sobre NIS2 y DORA en WordPress, con remisión a la explicación del artículo 28 de DORA sobre el riesgo de terceros.
Resumen
- Quince tablas establecidas por el Reglamento de Ejecución 2024/2956.
- Los acuerdos sobre funciones críticas o importantes tienen columnas adicionales (sustituibilidad, riesgo de concentración, plan de salida).
- Cadenas de subencargados transparentes hasta el nivel relevante para la entidad financiera.
- La agencia no presenta el registro; la agencia lo alimenta.
- La mayoría de las agencias omite cuatro de las quince tablas en la primera presentación.
¿Cuáles son las 15 tablas del registro de información DORA?
Conforme al artículo 28, apartado 3, cada entidad financiera debe comunicar el registro al menos una vez al año a su autoridad de supervisión y a la autoridad europea de supervisión mediante un marco común de presentación de información. El reglamento de ejecución de 2024 define el esquema. Las quince tablas:
- Información sobre la entidad.
- Información sobre la sucursal.
- Información sobre la filial.
- Servicios TIC.
- Identificación de funciones.
- Acuerdos.
- Funciones del acuerdo.
- Servicios TIC del acuerdo.
- Riesgo del acuerdo.
- Subcontratación (subencargados).
- Disposiciones sobre la resolución.
- Ubicaciones.
- Personas u órganos responsables.
- Acuerdos relativos a funciones críticas o importantes.
- Acuerdos con concentración (terceros dentro del grupo).
De estas quince, una agencia WordPress suele aparecer en las tablas 4, 6, 8, 9, 10, 11, 12 y 14. Las tablas 1-3, 5, 7 y 13 corresponden a la entidad financiera. La tabla 15 aparece rara vez y solo cuando la agencia tiene una sociedad dominante o es un proveedor habitual dentro del grupo de la entidad.
Qué datos entrega el proveedor WordPress en virtud de DORA
Por servicio TIC (tabla 4) y por acuerdo (tabla 6), la agencia aporta las columnas que la entidad financiera traslada al registro. Una lista práctica, no exhaustiva:
- Descripción del servicio: alojamiento WordPress, desarrollo de plugins, front-end headless, soporte, auditorías de seguridad, desglosados por partida y no en un único saco común.
- Nombre del proveedor y LEI: el Legal Entity Identifier de la agencia. Una agencia WordPress pequeña sin LEI debe obtenerlo antes de firmar el acuerdo.
- País de registro y domicilio social.
- Pertenencia a un grupo: sociedad dominante, filiales, sociedades hermanas.
- Servicios prestados: qué productos se ven afectados, con indicador de criticidad.
- Datos tratados: datos de clientes, datos de transacciones, datos de empleados, ninguno.
- Ubicaciones de los datos: país y proveedor de centro de datos por capa de almacenamiento (producción, copia de seguridad, archivo de registros).
- Subencargados: todo proveedor que la agencia utiliza para prestar el servicio (Cloudflare, Sentry, plataforma de despliegue, monitorización, API de IA).
- Jurisdicciones de los subencargados: país y ley aplicable por subencargado.
La tabla 11 (disposiciones sobre la resolución) exige que la agencia declare:
- El plazo de preaviso para la entidad financiera.
- El plazo de preaviso para la agencia.
- Los supuestos de resolución anticipada por parte de la entidad financiera.
- El plan de salida: cómo recupera la entidad financiera los datos y las operaciones.
La tabla 14 (acuerdos relativos a funciones críticas o importantes) exige pruebas adicionales si el servicio WordPress respalda una función crítica o importante. Evaluación de la sustituibilidad, riesgo de concentración, plan de salida con plazos realistas, calendario de pruebas periódico.
¿Qué suele faltarles a las agencias WordPress en el registro DORA?
Cinco lagunas recurrentes en las revisiones de proveedores de 2025-2026:
Falta de LEI. Una agencia WordPress sin Legal Entity Identifier retrasa el acuerdo y el registro. Un LEI cuesta más o menos lo mismo que la renovación anual de un dominio. No hay excusa para no tener LEI cuando se atiende al sector financiero regulado.
Lista de subencargados incompleta. Cloudflare está, Sentry está; el proveedor de IA de las herramientas editoriales, el proveedor de retransmisión de correo, la plataforma de despliegue y el destino de las copias de seguridad externas se olvidan. El registro no supera la revisión y la agencia vuelve a pasar por compras.
Plan de salida en un solo párrafo. “Entregaremos los datos cuando se soliciten” no es un plan de salida. La entidad financiera necesita los días estimados de traspaso, el formato de entrega de los datos, la entrega del repositorio de código, la entrega del runbook, la lista de dependencias y el procedimiento de cierre de cuentas. Un mínimo de tres páginas, preferiblemente un documento versionado.
Falta de prueba de restauración de copias. El artículo 11 de DORA exige pruebas periódicas de la resiliencia operativa, incluida la restauración. Una agencia sin un registro trimestral de restauraciones no supera la revisión en la primera auditoría.
Falta de evaluación de función crítica. La agencia sostiene “no somos críticos” porque el sitio WordPress es “solo marketing”. El equipo de cumplimiento de la entidad financiera no está de acuerdo, porque una caída de la marca daña la confianza de los clientes. Acláralo pronto en el acuerdo, no durante la auditoría.
¿Cómo preparar la primera inscripción en el registro DORA?
Una lista de comprobación práctica para una agencia WordPress que entra en su primer registro:
- Obtener el LEI, si falta.
- Inventariar los subencargados, con país y ley aplicable por proveedor.
- Redactar un plan de salida versionado: datos, código, runbook, cuentas.
- Documentar las ubicaciones de los datos por capa de almacenamiento y por subencargado.
- Probar una restauración completa desde la copia de seguridad externa; registrar la marca de tiempo, la duración y el resultado.
- Asignar los servicios prestados a las funciones de la entidad financiera; marcar las críticas o importantes.
- Elaborar una declaración de sustituibilidad: qué competidores podrían sustituir vuestro servicio y en cuántas semanas.
- Implantar un ritmo de revisión trimestral: cada trimestre, actualización de datos, firma y archivo.
Hecha antes del primer acuerdo, esta preparación se amortiza varias veces. Hecha durante la primera auditoría, duplica el coste del encargo.
¿Cómo crear un inventario de campos del registro DORA?
La alimentación del registro debe ser un conjunto de datos controlado, no un cuestionario rellenado de memoria. Se crea un registro independiente para la entidad jurídica, el acuerdo, el servicio TIC, la función respaldada, la ubicación y cada relación de subcontratación relevante. Cada objeto recibe un identificador interno estable. Los nombres y los acuerdos cambian; el identificador enlaza las versiones sin tener que adivinar si dos entradas describen al mismo proveedor.
Para cada campo, anota la definición, el formato, los valores admitidos, si es obligatorio en la plantilla utilizada, el sistema de origen, el responsable y la prueba. “No aplicable”, “desconocido” y un campo vacío son estados distintos. Las fechas, los códigos de país y las denominaciones jurídicas deben ajustarse al formato exigido. Nunca se debe inventar un LEI ni ningún otro identificador. La entidad financiera debe confirmar el tipo de identificador y las reglas de validación que exigen la plantilla vigente y la autoridad competente.
¿De dónde proceden los datos del registro DORA?
Los datos proceden de varias áreas. Compras guarda el acuerdo y sus adendas. El equipo jurídico responde de las cláusulas de resolución, auditoría, subcontratación y salida. Finanzas mantiene la ficha del proveedor. Seguridad y arquitectura vinculan los servicios con los sistemas y las funciones. Privacidad describe las categorías de datos y los lugares de tratamiento. La agencia aporta su identidad jurídica, el alcance del servicio, los subencargados, las ubicaciones operativas y los materiales de salida.
Cada campo de la exportación necesita información sobre su procedencia: documento o sistema, campo de origen, fecha de extracción, regla de transformación y revisor. Si la fecha de inicio procede de una adenda y no del acuerdo marco, el registro debe explicarlo. Si varias suscripciones de plugins forman un único servicio, hay que conservar la aprobación de esa agrupación. Así las correcciones son reproducibles y un valor en una hoja de cálculo no se convierte en un hecho sin fuente.
Las pruebas de origen se custodian junto al registro: versión firmada del acuerdo, declaración del proveedor, diagrama de arquitectura, lista de ubicaciones aprobada y notificación de cambios. El acceso debe estar restringido, porque el paquete puede revelar la arquitectura de seguridad, contactos y condiciones comerciales.
Quién responde del registro DORA y cuándo actualizarlo
La entidad financiera sigue siendo responsable de su registro. El responsable del registro controla el esquema y el calendario. Los responsables de los acuerdos verifican los acuerdos y las funciones. Seguridad comprueba la asignación de servicios y dependencias. Compras hace el seguimiento de las respuestas de los proveedores. La agencia WordPress designa un responsable de los datos y un suplente para las consultas y la aprobación de la alimentación.
La revisión es periódica y también se activa por eventos. Entre ellos figuran un nuevo acuerdo o adenda, la puesta en marcha o la retirada de un servicio, un cambio de denominación jurídica, un nuevo subencargado, un cambio de región de alojamiento, una adquisición, la revisión del plan de salida y una nueva evaluación de función crítica. El ritmo vinculante se deriva de DORA, de las normas técnicas de ejecución, de los procedimientos de la entidad y de las instrucciones de la autoridad. Una actualización trimestral puede ser un control interno, pero aquí no se presenta como un plazo legal universal.
¿Cómo validar los datos del registro DORA antes de exportarlos?
Los controles estructurales comprueban los campos obligatorios, la unicidad de los identificadores, las fechas y los códigos, las referencias y los registros huérfanos de servicios o subencargados. Los controles semánticos comparan las fechas con el acuerdo firmado, el orden entre inicio y fin, las ubicaciones con la arquitectura, el subencargado con un servicio concreto y las relaciones de función crítica con la decisión de la entidad financiera.
Los cambios relevantes pasan por el principio de los cuatro ojos. Un registro rechazado se devuelve con un código de error y una explicación, en lugar de corregirse en silencio. Se conservan el resultado, la persona, la hora y la versión del conjunto de datos. Antes del envío se comparan el número de registros y los totales clave con la última exportación aceptada, explicando altas, bajas e identificadores modificados.
¿Qué incluye la exportación del registro DORA y el paquete de pruebas?
La exportación se genera a partir de una versión congelada, no de una hoja de cálculo que sigue en edición. Recibe la versión de los datos, la hora de creación, la versión del esquema y una suma de verificación. Se conservan el archivo legible por máquina, un informe de control legible, los resultados de la validación, las aprobaciones y un índice de fuentes. Si existe un entorno de pruebas, conviene ensayar la importación. La codificación, los separadores y el formato de fecha pueden hacer que se rechacen datos correctos en cuanto al fondo.
La entrega de la agencia abarca la entidad, los acuerdos, los servicios, las ubicaciones, los subencargados, la fecha de referencia, los cambios, las carencias conocidas y el contacto. No se debe afirmar que este extracto garantiza la integridad de todo el registro. La consolidación a nivel de grupo, la clasificación de funciones y la presentación siguen correspondiendo a la entidad financiera.
Cómo verificar las respuestas del proveedor al registro DORA
La solicitud al proveedor debe señalar un acuerdo y un servicio concretos. En lugar de una lista libre de preguntas, conviene enviar una plantilla versionada, definiciones de los campos, ejemplos, códigos admitidos y un canal de respuesta seguro. El proveedor confirma la fecha de referencia y marca los datos que dependen de las respuestas de sus subencargados. Las consultas se gestionan junto al registro, no en varios hilos de correo independientes.
Un cambio no debe borrar el historial. Conserva el valor anterior, el nuevo valor, la fecha de efecto, el motivo, la fuente y la aprobación. Una nueva región de alojamiento puede tener fechas propias de anuncio, de consentimiento contractual y de puesta en marcha técnica. El historial permite establecer qué situación estaba vigente en la fecha de un informe concreto.
También hace falta una regla para los duplicados. Un mismo grupo puede aparecer como contraparte, plataforma y subencargado a través de sociedades distintas. Las entidades jurídicas se registran por separado y se vinculan mediante una relación de grupo. El nombre comercial, el producto y la parte del acuerdo no son el mismo campo. El nombre de un plugin no indica automáticamente el proveedor jurídico ni la ubicación de los datos.
Antes de la aprobación, el responsable lee el registro como una dependencia completa: qué función respalda qué acuerdo, servicio, sociedad y ubicación, y cómo se produce la salida. Si no se puede explicar, los campos formalmente completados siguen necesitando trabajo. Las carencias pasan a una lista de calidad con responsable y plazo, en lugar de sustituirse por suposiciones.
Limitaciones de esta guía sobre el registro DORA
¿Cómo actualizar el registro DORA tras cambiar de región de alojamiento?
Supongamos que una instalación WordPress gestionada se traslada entre regiones europeas del mismo proveedor de alojamiento como entidad jurídica. El cambio no consiste en sobrescribir un único campo de país. El responsable de los datos identifica los acuerdos, los servicios, las funciones respaldadas, las ubicaciones de producción, copias y registros y las relaciones de subcontratación. El responsable del acuerdo comprueba si se requiere consentimiento. Seguridad confirma la fecha de puesta en marcha técnica y privacidad evalúa el cambio en la información sobre el tratamiento.
El paquete de cambio contiene el valor anterior y el nuevo, la fecha del anuncio, el consentimiento, la fecha de efecto, las fuentes y los identificadores de los registros. La validación comprueba el código de país, la relación entre ubicación y servicio y el tratamiento separado de producción, copias de seguridad y archivo. Si la región anterior sigue funcionando durante la migración, ambos lugares pueden necesitar un periodo de vigencia. Sobrescribir de inmediato borraría la información sobre la situación real.
El revisor compara la declaración del proveedor, la prueba de arquitectura y el acuerdo. Una discrepancia se convierte en una tarea de calidad de datos con responsable, no en un motivo para elegir el valor más cómodo. La aprobación exige fuentes aprobadas, una validación correcta del esquema, relaciones coherentes, una diferencia explicada respecto a la exportación anterior y la comunicación del cambio a los demás responsables.
¿Cómo pedir aclaraciones al proveedor y aceptar sus datos?
La gestión de las respuestas debe tener estados explícitos: enviado, recibido, en verificación, aclaración necesaria, aceptado y caducado. La solicitud indica el registro, los campos, el formato, el canal seguro y el plazo. Una petición de aclaración describe una contradicción concreta, por ejemplo un país del subencargado que no coincide con el anexo de ubicaciones. Un genérico “revisadlo todo otra vez” no mejora la calidad.
La aceptación se hace a nivel de campo. La identidad jurídica puede aprobarse mientras la ubicación sigue abierta. El responsable del registro decide si un registro incompleto puede entrar en el conjunto de trabajo y qué bloquea la exportación. Los datos contractuales u operativos no deben deducirse de un sitio de marketing. La falta de una prueba relevante se escala al responsable del acuerdo.
Antes de la aprobación final, una segunda persona comprueba la vigencia de las fuentes, las fechas de efecto, el vínculo entre acuerdo, servicio y función, la cobertura de los subencargados y el marcado de los valores desconocidos. El registro de aprobación incluye la versión de los datos, el revisor, las excepciones y el siguiente desencadenante de actualización. Se trata de un rastro de control interno, no de una aprobación de la autoridad de supervisión.
¿Qué cambia en el registro DORA si cambia el responsable del servicio?
Tras una reorganización, la responsabilidad del sitio puede pasar de marketing al equipo de canales digitales sin que cambien el proveedor ni el acuerdo. Aun así, el registro debe actualizar la persona o unidad responsable y comprobar si ha cambiado la asignación de funciones. El responsable anterior aprueba el traspaso de las excepciones abiertas y el nuevo confirma los contactos, el ritmo de revisión y la capacidad de decisión.
La verificación abarca una dirección de contacto operativa, un suplente, la coherencia con el directorio de la organización y el traspaso del acceso a las pruebas. No basta con escribir un nombre nuevo si nadie ha asumido la obligación de actualizar. El escenario muestra que la calidad del registro depende también de los cambios organizativos, no solo de los técnicos y contractuales.
Un registro aceptado también envejece. Cada fuente relevante debe tener una fecha de próxima comprobación o un desencadenante por evento. El acuerdo se reevalúa tras una adenda o prórroga, la ubicación tras un cambio de infraestructura, el subencargado tras un aviso del proveedor y el contacto tras una reorganización. La ausencia de cambios comunicados no sustituye a una confirmación planificada. También la respuesta “sin cambios” conviene registrarla con fecha y aprobador, en lugar de dejar el registro antiguo en silencio.
Si un campo no puede aclararse antes de la exportación, el responsable describe el impacto, la escalada y la decisión. Un valor desconocido no puede convertirse en “no aplicable” solo para superar la validación. Debe quedar claro si la carencia es aceptable, requiere completarse o bloquea la aceptación del registro.
Este material es un mapa de gestión de datos y no sustituye al Reglamento de Ejecución (UE) 2024/2956, a las instrucciones supervisoras vigentes ni al asesoramiento jurídico. Las versiones de las plantillas, las taxonomías y las validaciones pueden cambiar. La clasificación depende del contexto y la entrega de los datos no garantiza la aceptación del registro.
Si necesitas ordenar la alimentación procedente de un proveedor WordPress, envía un briefing por escrito a través del servicio de preparación para NIS2 y DORA. Indica la perspectiva, las jurisdicciones, las entidades, los acuerdos y servicios, el formato del registro, los sistemas de origen, la cadena de subencargados, el plazo y los errores de validación conocidos. En el primer mensaje no envíes acuerdos, datos de acceso ni arquitectura sensible. El primer resultado debería ser un mapa de campos, un modelo de responsabilidades, una lista de calidad de datos y un plan de pruebas.
¿Necesita una agencia WordPress un código LEI con DORA?
DORA exige a las entidades financieras plena transparencia sobre toda la cadena de suministro TIC:
- Obligación de tener un código LEI (Legal Entity Identifier): Una agencia que suministra software o soporte técnico al sector bancario y fintech debe tener un código LEI activo y renovado cada año. Sin este identificador, la entidad financiera no puede comunicar correctamente el acuerdo a las autoridades europeas de supervisión (EBA, ESMA, EIOPA).
- Identificación de la cadena de subcontratación (tabla 10): La entidad debe saber no solo quién gestiona WordPress, sino también sobre qué infraestructura física funcionan los servidores (por ejemplo AWS, Google Cloud, OVHcloud), quién presta la protección anti-DDoS (Cloudflare) y qué bibliotecas SaaS externas intervienen en el procesamiento de las peticiones (Sentry, Postmark, Datadog).
¿Qué debe incluir el plan de salida del proveedor TIC según DORA?
Las tablas 11 y 14 imponen requisitos estrictos para el fin de la colaboración:
- Garantía de migración de datos y código sin interrupciones: El acuerdo debe precisar en qué formato entregará la agencia la base de datos MySQL, los repositorios Git y la documentación de despliegue si se resuelve el contrato (por ejemplo, en un plazo de 30 días desde el preaviso).
- Pruebas periódicas del plan de salida: Las entidades financieras realizan simulaciones de cambio de proveedor TIC para verificar que dejar a la agencia actual no interrumpe procesos de negocio críticos ni provoca pérdida de datos de clientes.
¿Qué derecho de auditoría debe recoger el acuerdo con el proveedor TIC?
El artículo 30 del Reglamento DORA exige de forma incondicional incluir cláusulas de auditoría en los acuerdos con proveedores TIC:
- Acceso sin trabas de los auditores a la infraestructura: El acuerdo debe garantizar tanto a los equipos de control interno del banco como a los inspectores de la autoridad nacional de supervisión financiera y de la Autoridad Bancaria Europea (EBA) acceso pleno a los registros, la documentación técnica y los entornos de alojamiento de WordPress.
- Colaboración en pruebas de penetración avanzadas (TLPT): La agencia está obligada a participar activamente en pruebas de resiliencia basadas en escenarios de amenaza (Threat-Led Penetration Testing) y a demostrar que está preparada para defenderse de ataques avanzados.
- Resumen: Una entrega ejemplar de datos al registro de información es prueba de madurez operativa, genera una confianza duradera en las entidades financieras y abre la puerta a contratos corporativos plurianuales.
Llevar el registro con rigor y cuidar de forma constante el cumplimiento de la normativa europea es la mejor protección frente al riesgo de sanciones económicas y de pérdida de reputación en el mercado financiero. La profesionalidad en ingeniería de seguridad es la clave de un éxito empresarial duradero.
La confianza se construye con hechos.
