October 30, 2026
Autor: Joao Lages
Las auditorías y controles de tokenización para la preparación ante DORA deben demostrar que una plataforma puede mantener los servicios regulados disponibles, exactos, seguros y recuperables cuando falla la tecnología. El trabajo va más allá de una revisión de ciberseguridad. Conecta el gobierno, los permisos de los contratos inteligentes, los registros de inversores, los pagos, las interfaces de custodia, la notificación de incidentes, las pruebas de resiliencia y las dependencias de terceros con responsables identificados y pruebas auditables.
El Reglamento (UE) 2022/2554, conocido como Reglamento de Resiliencia Operativa Digital (DORA), es aplicable desde el 17 de enero de 2025. Establece requisitos de riesgo de TIC directamente aplicables a entidades financieras, incluidas, entre otras, empresas de servicios de inversión, centros de negociación y proveedores de servicios de criptoactivos autorizados. Un emisor de tokens o una empresa tecnológica no queda automáticamente sujeto a todas las obligaciones de DORA. Sin embargo, una entidad financiera incluida en su ámbito sigue siendo responsable cuando utiliza una plataforma de tokenización u otro proveedor de TIC, por lo que el proveedor debe aportar con frecuencia las pruebas, los derechos contractuales y la cooperación operativa necesarios para hacer posible el cumplimiento.
Esta guía se dirige a entidades financieras, empresas de servicios de inversión, fundadores de fintech, emisores, gestores de activos y profesionales de la tokenización que operan en Europa. Distingue los requisitos vinculantes de DORA de las buenas prácticas de control. Las obligaciones concretas dependen de las entidades jurídicas, las actividades reguladas, los servicios, las jurisdicciones, la escala y el nivel de criticidad implicados. No constituye asesoramiento jurídico, de inversión ni de ciberseguridad.
Un marco de control preparado para DORA debe permitir que un revisor cualificado responda con pruebas a cinco preguntas: qué servicios empresariales dependen de la tecnología; qué puede interrumpirlos; qué controles previenen, detectan y permiten recuperarse de una interrupción; quién es responsable de cada decisión; y si las deficiencias identificadas se corrigen a tiempo. Una declaración de política sin registros operativos no responde a estas preguntas.
En los productos tokenizados, el perímetro de auditoría debe seguir el servicio y no la cadena de bloques. Puede abarcar el portal del inversor, los controles de identidad y elegibilidad, el flujo de órdenes, los medios de pago, la emisión de tokens, las restricciones de transferencia, las conexiones con monederos o custodios, el registro jurídico de inversores, los datos de administración del activo, la conciliación, las operaciones societarias, la información periódica y el reembolso. Una deficiencia en cualquiera de estas interfaces puede interrumpir el servicio regulado aunque el contrato inteligente funcione conforme a su diseño.
DORA aplica el principio de proporcionalidad, pero la proporcionalidad no exime de comprender el sistema. Las empresas de menor tamaño pueden utilizar documentación y controles más sencillos cuando la normativa lo permita, aunque siguen necesitando una visión defendible de las funciones críticas, los activos de TIC, los incidentes, los proveedores y las prioridades de recuperación. El diseño de los controles debe reflejar el riesgo real, no el tamaño del equipo de cumplimiento.
Comience con un mapa de entidades y servicios. Identifique al emisor, la empresa de servicios de inversión, el agente vinculado, el proveedor de pagos, el custodio, el registrador, el operador de la plataforma, los proveedores de nube y los proveedores relacionados con la cadena de bloques. Registre qué entidad desempeña cada función regulada u operativa y qué autoridad competente la supervisa. Las obligaciones de DORA se aplican a determinadas entidades financieras, no a un producto por el mero hecho de utilizar tecnología de registro distribuido.
El emisor de un bono tokenizado ordinario puede estar fuera del ámbito de DORA mientras que la empresa de servicios de inversión que lo distribuye sí está incluida. Un proveedor de servicios de criptoactivos autorizado puede estar incluido, pero un token que representa un instrumento financiero MiFID no se convierte en un criptoactivo de MiCA por el simple hecho de registrarse en una cadena de bloques. Por tanto, la clasificación del instrumento y del servicio debe preceder al mapa de controles de DORA.
Para cada servicio, identifique los procesos, datos, aplicaciones, infraestructuras, empleados y proveedores que lo sustentan. Pregunte qué fallo perjudicaría de forma sustancial el rendimiento financiero, la continuidad del servicio, el cumplimiento normativo o la protección de los clientes. El resultado debe ser un mapa vivo de dependencias que conecte los servicios empresariales con los activos de TIC y los acuerdos contractuales.
Una plataforma de tokenización también debe indicar qué registro prevalece cuando difieren la cadena de bloques, la base de datos de la plataforma, el registro del custodio y el registro jurídico. Esta decisión afecta a la evaluación inicial del incidente, la conciliación y la recuperación. El mapa europeo de infraestructuras de valores tokenizados explica por qué la emisión, la distribución, los pagos, la custodia, la liquidación y la administración deben tratarse como una única cadena operativa conectada.
DORA atribuye al órgano de dirección la responsabilidad sobre el marco de gestión del riesgo de TIC. La alta dirección debe aprobar la estrategia de resiliencia operativa digital, la tolerancia al riesgo, las responsabilidades, las prioridades de continuidad, los acuerdos materiales con proveedores y la corrección de las deficiencias significativas. Los comités tecnológicos pueden preparar las decisiones, pero la responsabilidad debe quedar visible en actas, aprobaciones y registros de escalado.
Para las empresas sujetas al marco general, DORA exige una función independiente de control del riesgo de TIC y una separación adecuada entre la gestión de riesgos, las funciones de control y la auditoría interna. La misma persona no debe diseñar un proceso de acceso privilegiado, aprobar su propio acceso, operar el control y aportar la única garantía de que funcionó. Las organizaciones pequeñas pueden necesitar acuerdos proporcionales, pero los conflictos siguen requiriendo salvaguardias expresas.
Un paquete de gobierno práctico incluye una matriz de responsabilidades sobre TIC, los términos de referencia de los comités, los umbrales de aprobación, los criterios de aceptación de riesgos, un registro de excepciones y una vía formal para elevar las correcciones vencidas. También debe identificar las decisiones que requieren intervención jurídica o de cumplimiento, como suspender transferencias, notificar a inversores, comunicar un incidente o ejercer un derecho de salida frente a un proveedor.
Los controles de acceso deben abarcar a empleados, contratistas, cuentas de servicio, funciones de administrador y accesos de emergencia. Aplique el mínimo privilegio, autenticación fuerte, recertificación periódica y retirada inmediata del acceso cuando cambien las funciones. La actividad privilegiada debe registrarse y revisarse de forma independiente. Las credenciales de administrador compartidas debilitan tanto la seguridad como la atribución de responsabilidades.
La gestión de claves exige controles adicionales porque una clave de firma comprometida puede modificar la oferta de tokens, las transferencias o la configuración administrativa. Documente la generación, el almacenamiento, la autoridad de firma, las reglas de quórum, la recuperación, la rotación, la copia de seguridad y la destrucción de claves. Separe la capacidad de proponer una transacción de la capacidad de aprobarla. Compruebe qué ocurre cuando un firmante no está disponible o se sospecha que una clave ha sido comprometida.
Todo contrato inteligente en producción debe tener un responsable, un registro de versiones, permisos documentados y una vía de despliegue aprobada. Los cambios deben superar una revisión del código, pruebas de seguridad, una revisión de su impacto jurídico cuando proceda, un despliegue controlado y una verificación posterior. Los cambios de emergencia necesitan una vía más rápida, pero no una vía sin pruebas.
Los auditores deben comparar los términos jurídicos con las reglas ejecutables. La oferta de tokens, la elegibilidad para transferir, los periodos de bloqueo, los derechos de suspensión, la acuñación, la quema, la recuperación y las actualizaciones deben coincidir con los documentos del producto y las aprobaciones operativas. Un contrato técnicamente correcto puede crear riesgo normativo o de protección del inversor si ejecuta una regla jurídica equivocada.
Defina qué sistemas constituyen los libros y registros oficiales y con qué frecuencia se concilian los saldos, el efectivo y las posiciones de los inversores. Las excepciones deben entrar en una cola controlada que registre su materialidad, responsable, antigüedad, causa raíz y prueba de resolución. Los operadores no deben poder cerrar su propia diferencia sin explicar y sin revisión.
Los controles deben abarcar los pagos fallidos, las instrucciones duplicadas, las suscripciones sin correspondencia, las direcciones de monedero incorrectas, las operaciones societarias, los inversores restringidos y las transferencias que infringen las reglas del producto. La lista de comprobación de Lympid para incorporar emisores a plataformas de tokenización sitúa estos controles tecnológicos dentro de un proceso más amplio de aprobación jurídica, financiera y operativa.
DORA exige que el marco de gestión del riesgo de TIC esté documentado y se revise al menos una vez al año para las entidades financieras sujetas al marco general, así como después de incidentes importantes, instrucciones supervisoras o conclusiones relevantes de pruebas y auditorías. También exige auditorías internas periódicas realizadas por auditores independientes con conocimientos suficientes sobre riesgo de TIC. La frecuencia y el enfoque de la auditoría deben ser proporcionales al riesgo de TIC.
El universo de auditoría debe abarcar el gobierno, el inventario de activos, los accesos, los cambios, la gestión de incidentes, la continuidad, las pruebas, la integridad de los datos, el riesgo de proveedores y la corrección de deficiencias. Los temas específicos de la tokenización deben incluir la administración de contratos inteligentes, la custodia de claves, las transferencias autorizadas, las dependencias de nodos o redes, los datos de oráculos, las integraciones con monederos y la conciliación entre registros dentro y fuera de la cadena.
Una auditoría útil examina el diseño y el funcionamiento del control. La prueba de diseño pregunta si el control podría responder al riesgo declarado. La prueba de eficacia operativa examina muestras y pruebas durante un periodo. Por ejemplo, una política que exige revisiones trimestrales de accesos demuestra poco si los revisores no pueden mostrar la población examinada, las decisiones adoptadas, los accesos retirados y las excepciones elevadas.
Los hallazgos de auditoría deben indicar el servicio afectado, el fallo de control, las pruebas, el riesgo, la causa raíz, el responsable, la fecha objetivo y el método de validación. Los hallazgos críticos necesitan un proceso formal de seguimiento y corrección a tiempo. Cerrar una incidencia no basta. Un revisor independiente debe confirmar que el control funciona y que se ha reducido el riesgo subyacente.
DORA exige un programa de pruebas de resiliencia operativa digital basado en el riesgo. Las entidades financieras sujetas al marco general deben garantizar que se realicen pruebas adecuadas al menos una vez al año sobre los sistemas y aplicaciones de TIC que sustenten funciones críticas o importantes. Las pruebas pueden incluir análisis de vulnerabilidades, evaluaciones de red, revisión del código fuente cuando sea posible, pruebas de escenarios, compatibilidad, rendimiento, extremo a extremo y penetración. Las pruebas de penetración basadas en amenazas cada tres años solo se aplican a las entidades financieras identificadas conforme a los criterios pertinentes de DORA.
Las pruebas de tokenización deben abarcar las operaciones normales y las situaciones de fallo. Pruebe picos de suscripciones, congestión de la cadena de bloques, fallo de nodos, confirmaciones demoradas, tratamiento incorrecto de eventos, pérdida de conexión con un proveedor, fallo en la liquidación del efectivo, importaciones de datos dañadas, firmantes no disponibles y restauración a partir de copias de seguridad. Los ejercicios de recuperación deben demostrar que los registros pueden reconstruirse y que los servicios pueden reanudarse dentro de los objetivos de recuperación aprobados.
El plan de pruebas debe identificar el alcance, las hipótesis, los datos, la independencia del verificador, los resultados esperados, los criterios de gravedad y las pruebas obtenidas. Los hallazgos deben incorporarse al mismo proceso de corrección utilizado para las auditorías. Repetir una prueba sin resolver la causa solo documenta una debilidad recurrente.
La gestión de incidentes debe unir las señales técnicas con el impacto empresarial. La supervisión debe detectar accesos privilegiados inusuales, intentos de firma fallidos, cambios inesperados en la oferta de tokens, diferencias de conciliación, patrones anómalos de transacciones, servicios no disponibles y alertas de proveedores. El equipo debe saber cuándo un evento se convierte en un incidente relacionado con las TIC y cuándo cumple los criterios de incidente grave.
DORA y sus normas de desarrollo establecen fases estructuradas de notificación y plazos para los incidentes graves. Por tanto, el proceso debe registrar la hora de conocimiento, la hora de clasificación, las funciones afectadas, los clientes, los países, la duración, el impacto sobre los datos, el impacto económico y el estado de recuperación. Las plantillas, los contactos de los reguladores y las vías de aprobación deben prepararse antes de que ocurra un incidente. Las obligaciones y los portales concretos dependen de la entidad y de la autoridad competente.
Los protocolos de respuesta deben asignar la contención técnica, la evaluación jurídica, la notificación regulatoria, la comunicación a inversores y la conservación de pruebas. También deben abordar decisiones propias de la cadena de bloques, como suspender transferencias, rotar claves de administrador, coordinarse con custodios y determinar si la actividad dentro de la cadena es definitiva, reversible mediante controles administrativos o solo corregible con asientos compensatorios.
La recuperación debe probarse frente a un análisis de impacto empresarial. Defina objetivos de tiempo y punto de recuperación para cada servicio crítico y compruebe después que las copias de seguridad, los proveedores alternativos, los procedimientos manuales y las comunicaciones pueden cumplirlos. Las políticas y procedimientos detallados de TIC del Reglamento Delegado (UE) 2024/1774 de la Comisión convierten estos principios en expectativas de control más específicas.
Una empresa regulada no puede externalizar su responsabilidad en virtud de DORA. Debe mantener un registro de los acuerdos contractuales de TIC, distinguir los servicios que sustentan funciones críticas o importantes, evaluar el riesgo de concentración y sustitución, supervisar el rendimiento y planificar las salidas. Un inventario de proveedores que omita subcontratistas, regiones de alojamiento o infraestructuras compartidas infravalorará el riesgo de dependencia.
Los contratos relativos a funciones críticas o importantes requieren disposiciones detalladas, incluidas las descripciones y ubicaciones de los servicios, la seguridad y recuperación de datos, la asistencia durante incidentes, la cooperación con autoridades, las reglas de terminación y salida, y los derechos de acceso, inspección y auditoría. Conforme al Reglamento Delegado (UE) 2024/1773 de la Comisión, la revisión independiente y la planificación de auditorías también son elementos centrales de la política aplicable a estos acuerdos.
Los derechos de auditoría deben poder ejercerse y no limitarse a figurar en el contrato. La respuesta conjunta de las Autoridades Europeas de Supervisión sobre la frecuencia de auditoría confirma que los límites contractuales no deben impedir que una entidad financiera aplique un enfoque basado en el riesgo o realice una auditoría específica cuando sea necesario. Las certificaciones y auditorías conjuntas pueden respaldar las garantías, pero la empresa debe evaluar su alcance, actualidad, excepciones y pertinencia para el servicio contratado.
Los planes de salida deben identificar los datos portables, los formatos, la asistencia durante la transición, los proveedores de sustitución, la transferencia de claves y accesos, las necesidades de funcionamiento en paralelo y el momento en que el servicio puede terminarse de forma segura. Pruebe el plan sobre el papel y, cuando sea proporcionado, mediante ejercicios técnicos. Una salida del proveedor que no pueda preservar los registros de inversores o las instrucciones de pago no es una salida ordenada.
La selección de una plataforma debe considerar el modelo de pruebas y responsabilidades, no solo las funcionalidades. Entre los enfoques disponibles se encuentran:
Un proceso de diligencia debida debe solicitar diagramas de arquitectura, políticas de seguridad, informes de auditoría, resúmenes de pruebas de penetración, historial de incidentes, resultados de continuidad de negocio, listas de subcontratistas, niveles de servicio, información sobre la ubicación de los datos y ejemplos de procedimientos de salida. Las afirmaciones comerciales como «cumple con DORA» no deben sustituir una evaluación control por control del servicio realmente contratado.
La plataforma de inversión de marca blanca de Lympid puede respaldar un recorrido controlado del inversor y un conjunto coordinado de proveedores. La entidad financiera contratante debe seguir documentando cómo encaja la solución en su marco de riesgo de TIC, registro de proveedores, plan de auditoría, proceso de incidentes y estrategia de continuidad.
La información de gestión debe ser concisa y facilitar decisiones. Entre las medidas útiles se incluyen los hallazgos críticos sin resolver, las correcciones vencidas, las excepciones de acceso privilegiado, las conciliaciones fallidas, la disponibilidad del servicio, los resultados de las pruebas de recuperación, los incidentes por gravedad, los incumplimientos del nivel de servicio por proveedores, la exposición a concentraciones y la antigüedad de los planes de salida no probados. Las métricas necesitan responsables, umbrales y medidas de escalado definidos.
En 2026, los supervisores prestan mayor atención a la resiliencia operativa digital en las actividades tokenizadas y de criptoactivos. La actuación supervisora común de ESMA sobre la resiliencia de la custodia de los proveedores de servicios de criptoactivos destaca específicamente el gobierno de DLT, la gestión de claves, los controles de transacciones, la respuesta a incidentes, el riesgo de contratos inteligentes y las dependencias de terceros. El ejercicio se refiere a proveedores de servicios de criptoactivos autorizados y a la custodia, pero los temas de riesgo enumerados son indicadores útiles de la atención supervisora para el mercado más amplio de activos digitales.
Las auditorías y controles de tokenización para la preparación ante DORA son eficaces cuando conectan la responsabilidad jurídica con la realidad técnica. La empresa regulada debe saber qué servicios son importantes, qué activos y proveedores los sustentan, cómo operan los controles, cómo se detectan y notifican los fallos, cómo funciona la recuperación y cómo se corrigen las deficiencias. El proveedor de tokenización debe poder aportar pruebas fiables y cooperar durante todo ese ciclo.
El programa más sólido no es el que tiene más políticas. Es el que puede demostrar, mediante registros actuales y procedimientos probados, que los servicios a inversores y los registros oficiales siguen controlados durante los cambios, las interrupciones y los fallos de proveedores.
Si está considerando lanzar un producto de inversión tokenizado, hable con Lympid.
Book a call with us today and get a free assessment.
