Cyber
ESMA pone el foco en la custodia cripto: la resiliencia operativa de los CASPs entra en examen desde este año
Por Redacción CyberComplianceAI21 min lectura
Ultima revision
8 de julio de 2026
Fuente
ESMA
Imagen generada por IAUltima revision
8 de julio de 2026
Fuente
ESMAImagen generada por IAESMA ha decidido mirar donde más duele en cripto: la custodia. El supervisor europeo anunció el 8 de julio de 2026 una Common Supervisory Action (CSA) centrada en la resiliencia operativa digital de los proveedores de servicios de criptoactivos (CASPs), con énfasis específico en las actividades de custodia. No es una campaña cosmética ni una nota para rellenar agenda. Es una señal supervisora bastante nítida: en el negocio de custodiar criptoactivos, el riesgo tecnológico ya no se trata como un problema de ingeniería, sino como un problema de gobernanza, control interno y supervisión prudente.
El ejercicio se desarrollará desde la segunda mitad de 2026 hasta la primera mitad de 2027, sobre una muestra basada en riesgo de CASPs autorizados seleccionados por las autoridades nacionales competentes. Después, ESMA consolidará los resultados y elevará un informe final a su Board of Supervisors en la segunda mitad de 2027. Traducido al castellano llano: este año empieza la recogida de evidencias, en 2027 llegarán las comparaciones entre supervisores y, con alta probabilidad, también las preguntas incómodas para quienes hayan confundido “tenemos wallet infra” con “tenemos resiliencia operativa”.
La nota de ESMA menciona seis áreas de revisión que no están elegidas al azar: acuerdos de gobernanza, gestión de claves y almacenamiento, controles de transacciones, detección y respuesta ante incidentes, riesgos de smart contracts y dependencias de terceros. Ese listado merece leerse despacio. Resume casi todos los puntos donde una custodia cripto puede fallar sin necesidad de que exista un exploit de cine ni un malware con nombre pegadizo. A veces basta con una clave mal segregada, una política de aprobación mal diseñada o un proveedor crítico opaco.
La pregunta relevante no es si el mercado cripto tiene riesgo operacional. Esa discusión está agotada. La pregunta de verdad es otra: ¿qué va a considerar un supervisor europeo como un marco de resiliencia “maduro” en custodia de criptoactivos? Ahí está el partido.
Las Common Supervisory Actions no son simples comunicados de buenas intenciones. Son mecanismos de convergencia supervisora. ESMA los utiliza para alinear criterios entre autoridades nacionales sobre áreas donde la práctica de mercado avanza más rápido que la doctrina supervisora o donde existe riesgo de enfoques dispares. Y en cripto, ambas cosas ocurren a la vez.
El mercado europeo llega a 2026 con un ecosistema de CASPs ya autorizado o en proceso de estabilización bajo MiCA, pero con modelos operativos muy heterogéneos. Algunos operadores nacieron con estándares cercanos a mercados financieros tradicionales. Otros vienen de cultura puramente tecnológica. Otros, directamente, crecieron cuando el lema implícito era “muévete rápido y ya corregirás luego”. Eso puede funcionar para una app de fotos. Para custodia de activos de clientes, no.
La custodia concentra varios riesgos simultáneos. Primero, el de pérdida o compromiso de claves criptográficas. Segundo, el de ejecución indebida de transacciones, ya sea por fallo humano, fraude interno o explotación de debilidades en flujos de autorización. Tercero, el de dependencia de infraestructuras ajenas: cloud, HSM, proveedores de wallet-as-a-service, blockchain analytics, oráculos, librerías de firma, software de gestión de smart contracts y servicios de monitorización. Cuarto, el de detección tardía: en entornos DLT, el daño suele viajar deprisa y, una vez confirmado en cadena, no suele ofrecer demasiadas oportunidades para el romanticismo reparador.
ESMA está diciendo algo bastante concreto al poner el foco en custodia y no, por ejemplo, en marketing, conflictos de interés o disclosures. Está señalando que el riesgo sistémico reputacional del sector cripto europeo no vendrá solo de promesas infladas o tokenómicas dudosas, sino de un fallo más clásico y más serio: no poder proteger, controlar y recuperar activos de clientes cuando el sistema sufre estrés.
También hay una lectura institucional. MiCA ordena el mercado cripto europeo, pero no sustituye el trabajo supervisor fino sobre tecnología. Y DORA, aunque no se diseñó como norma exclusiva para cripto, ha cambiado el estándar de conversación sobre resiliencia digital en servicios financieros. Aunque la relación exacta entre regímenes depende del tipo de entidad y del encaje normativo aplicable, el lenguaje regulatorio europeo ya no acepta respuestas vagas del tipo “tenemos medidas apropiadas”. Quiere inventarios, pruebas, responsables, rutas de escalado, métricas y evidencias.
La lista de focos de revisión de ESMA tiene más sustancia de lo que parece. No es la típica enumeración burocrática para que nadie se ofenda. Cada punto apunta a una capa técnica y de control distinta.
Cuando un supervisor incluye “governance arrangements” en una revisión de custodia cripto, no está pidiendo un PowerPoint con tres líneas de defensa dibujadas en azul corporativo. Está preguntando, en esencia, quién tiene autoridad real sobre los activos, los cambios de configuración, las excepciones operativas y los incidentes críticos.
En términos prácticos, una gobernanza madura en custodia debería poder demostrar, como mínimo, segregación clara de funciones entre desarrollo, operaciones, seguridad y aprobación de transacciones; límites y umbrales formalizados; procedimientos de emergencia; registro de cambios; y supervisión por parte del órgano de dirección. Si la entidad no puede enseñar actas, matrices de delegación, evidencias de revisión y trazabilidad de excepciones, la palabra “gobernanza” se queda en decoración.
Aquí conviene cruzar con DORA. El Reglamento (UE) 2022/2554 exige un marco interno de gestión de riesgos de las TIC gobernado por el órgano de dirección. El artículo 5 atribuye a ese órgano la responsabilidad última de establecer, aprobar, supervisar y responder por la implantación del marco de gestión de riesgos TIC. El artículo 6 obliga a contar con un marco sólido, completo y bien documentado. La novedad es que el supervisor cripto ya está usando ese idioma, aunque el examen aterrice sobre operativas muy específicas de DLT.
En custodia tradicional, perder una clave de una cámara acorazada es una metáfora. En custodia cripto, perder o comprometer una clave privada puede ser el incidente. Fin de la historia. Por eso ESMA cita expresamente “key and storage management”.
El supervisor querrá ver cómo se generan las claves, dónde residen, qué controles protegen su uso, cómo se segmentan entre entornos, qué esquema de backup existe, qué procedimientos rigen la rotación, cómo se gestiona el acceso privilegiado y qué ocurre si una persona con conocimiento crítico desaparece, dimite o actúa de forma maliciosa. También interesará el uso de módulos de seguridad hardware, esquemas multi-signature o MPC, aunque la tecnología elegida no sustituye la necesidad de control. Un despliegue sofisticado mal gobernado sigue estando mal gobernado; solo cuesta más entenderlo.
El ángulo que muchas firmas subestiman es el de la evidencia. No basta con afirmar que se usan HSM certificados o firmas múltiples. Habrá que demostrar políticas, logs, pruebas de restauración, resultados de revisiones de acceso, inventario de claves, segregación entre claves operativas y de recuperación, y criterios de retiro seguro. La custodia cripto convierte un principio clásico de seguridad en algo brutalmente literal: si no puedes probar quién podía firmar qué, cuándo y bajo qué condiciones, tienes un problema.
“Transaction controls” suena anodino hasta que uno recuerda cuántos incidentes serios en cripto se explican por transferencias no autorizadas, direcciones mal verificadas, listas blancas mal administradas o flujos de aprobación con demasiada confianza y muy poca fricción.
Un supervisor razonable pedirá controles previos a la ejecución, no simples revisiones ex post. Eso incluye validación de direcciones, gestión de listas permitidas, umbrales por importe o tipología de activo, segregación de aprobadores, mecanismos de time-lock cuando proceda, alertas por comportamiento anómalo y procedimientos específicos para operaciones urgentes. Las excepciones son especialmente sensibles. Casi todas las organizaciones tienen un “camino rápido” para casos extraordinarios. Muchas descubren demasiado tarde que ese camino rápido era el camino principal del atacante.
Quien opere custodia con smart contracts tendrá, además, un problema añadido: no solo debe controlar la voluntad humana de transferir activos, sino también la lógica programable que puede disparar efectos automáticos. Y esa lógica no siempre tiene sentido del humor.
ESMA también cita “incident detection and response”. Esa parte conecta de forma natural con un marco regulatorio europeo mucho más amplio. GDPR, en su artículo 33, obliga a notificar violaciones de seguridad de datos personales a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas. NIS2, en su artículo 23, fija un régimen escalonado para incidentes significativos: alerta temprana en 24 horas, notificación de incidente en 72 horas e informe final en un mes, salvo ajustes del caso concreto. DORA, en sus artículos 17 a 23, establece un marco de gestión, clasificación y notificación de incidentes relacionados con las TIC para entidades financieras, desarrollado después por normas técnicas.
La lección es sencilla: en Europa, detectar tarde ya no es solo una mala práctica; puede convertirse en incumplimiento en cascada. En un custodio cripto, además, la respuesta a incidentes no puede limitarse a procedimientos genéricos de SOC. Tiene que contemplar escenarios muy específicos: drenado de wallets, compromiso de claves de firma, anomalías en nodos, manipulación de oráculos, actividad sospechosa de insiders, reorgs con impacto operativo, congestión de red que afecte a ventanas de respuesta, y fallos en smart contracts con exposición material.
Tu entidad tiene runbooks diferenciados para esos supuestos? ¿Los ha probado con equipos de operaciones, legal, compliance y atención al cliente? Si la respuesta es “estamos en ello”, la CSA llega en mal momento.
Que ESMA incluya expresamente “smart contract risks” es una pista importante. La supervisión europea está asumiendo que, en custodia y servicios asociados, el riesgo no termina en la custodia de claves. También vive en la lógica de contratos desplegados en cadena, en integraciones con protocolos, en funciones de upgrade, en dependencias de administradores y en permisos mal calibrados.
En la práctica, esto abre la puerta a que los supervisores pregunten por revisiones de código, auditorías externas, gestión de vulnerabilidades, inventario de contratos, procesos de despliegue, controles de cambios y mecanismos de pausa o contención. No sería extraño que una autoridad compare la madurez de una firma que sabe exactamente qué contratos soportan sus servicios con otra que depende de terceros y no puede explicar ni la superficie de exposición ni los derechos administrativos existentes. Una parece una entidad regulada. La otra parece un turista con licencia.
La última pieza del rompecabezas es la dependencia de terceros proveedores. Aquí el paralelismo con DORA es casi inevitable. El artículo 28 de DORA exige a las entidades financieras gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante de su marco de riesgo TIC, y mantener un registro de información respecto de todos los acuerdos contractuales sobre el uso de servicios TIC prestados por terceros. No hace falta estirar mucho el razonamiento para entender por qué el supervisor cripto quiere ver algo parecido: si tu custodia depende de varios terceros críticos y no tienes visibilidad contractual, técnica y operativa suficiente, tu resiliencia real está subcontratada.
La industria cripto ha convivido durante años con una paradoja encantadora: se vendía desintermediación mientras crecía la dependencia de infraestructuras centralizadas muy concretas. Custodia institucional, proveedores MPC, servicios cloud, herramientas de monitorización on-chain, KMS, APIs de broadcast, soluciones de compliance blockchain, auditorías de smart contracts, nodos gestionados. El resultado es una cadena de suministro tecnológica compleja, a veces más opaca de lo que admitiría cualquier banco sujeto a escrutinio prudencial serio.
La CSA no corrige por sí sola ese problema, pero lo vuelve examinable. Y cuando un problema se vuelve examinable, deja de ser teórico.
Aquí conviene evitar dos errores típicos. El primero es asumir que todo lo cripto entra de forma automática y homogénea en DORA. El segundo es creer que, si una entidad no cae de lleno bajo un régimen concreto, puede ignorar el estándar operativo que ese régimen está imponiendo de facto en el mercado europeo. Entre ambos extremos está la realidad.
MiCA ha establecido el marco de autorización y conducta para los CASPs en la Unión Europea, incluyendo exigencias organizativas, prudenciales y de salvaguarda según el servicio prestado. En custodia y administración de criptoactivos por cuenta de clientes, la separación de activos y la capacidad de proteger los derechos del cliente son centrales. Pero MiCA no agota el detalle técnico de cómo se gestiona el riesgo digital en cada componente operativo. Ahí entran la supervisión convergente y la contaminación regulatoria, por decirlo sin dramatismo.
DORA ha elevado el listón para entidades financieras en materia de gobernanza TIC, gestión de incidentes, pruebas de resiliencia, riesgo de terceros y, en determinados casos, intercambio de información. Aunque el perímetro exacto aplicable a CASPs dependerá de su naturaleza jurídica y de cómo se articule cada caso, el efecto de mercado es evidente: quien aspire a vender confianza en servicios financieros digitales en Europa ya no puede presentarse con controles propios de startup de Serie A.
NIS2 añade otra capa. Su artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información, incluyendo gestión de incidentes, continuidad de negocio, seguridad en la cadena de suministro, evaluación de eficacia de medidas y prácticas básicas de ciberhigiene, entre otras. No es una norma específica de custodia cripto, pero sí forma parte del ambiente regulatorio europeo en el que operan proveedores tecnológicos y entidades críticas o importantes. A efectos prácticos, muchas exigencias de NIS2 y DORA convergen en la misma sala de reuniones: inventario, clasificación de activos, detección, respuesta, continuidad, terceros, pruebas y rendición de cuentas.
La CSA de ESMA, por tanto, no debe leerse como una pieza aislada. Es una manifestación sectorial de una tendencia más amplia: el supervisor europeo quiere pruebas de resiliencia verificables, no narrativas tranquilizadoras. Y en cripto, donde la tentación de vender sofisticación tecnológica como sustituto de control es permanente, eso cambia bastante las reglas del juego.
ESMA no ha publicado en su nota la batería detallada de preguntas o plantillas que usarán las autoridades nacionales. Aun así, el alcance anunciado permite anticipar qué áreas van a ser sensibles. No hace falta inventar; basta con seguir la lógica supervisora.
Primero, consistencia documental. Un CASP que declare tener segregación de funciones, pero no pueda demostrarla con accesos, aprobaciones y evidencias de revisión, quedará expuesto. Lo mismo si presume de monitorización 24/7 y luego carece de métricas de cobertura, tiempos medios de detección o runbooks específicos.
Segundo, trazabilidad extremo a extremo. En custodia cripto, muchas organizaciones tienen controles aceptables de forma aislada y un caos total cuando se observa el recorrido completo: onboarding del activo, generación de la clave, política de almacenamiento, flujo de autorización, ejecución, reconciliación, monitorización y respuesta. El supervisor querrá recorrer ese circuito, no escuchar slogans.
Tercero, proporcionalidad real. Un operador pequeño no tiene que parecerse a un G-SIB, pero sí debe mostrar que su arquitectura de control es coherente con el volumen, el tipo de cliente, la complejidad tecnológica y la exposición a terceros. “Somos pequeños” no sirve de defensa si custodias activos de clientes y dependes de componentes críticos sin control contractual ni técnico suficiente.
Cuarto, madurez de continuidad y recuperación. En cripto se habla mucho de prevención y menos de recuperación. Sin embargo, la resiliencia operativa se demuestra también en escenarios de degradación: caída de un proveedor MPC, indisponibilidad regional cloud, corrupción de backups, error en software de firma, pérdida de conectividad con nodos, explotación de una dependencia open source o necesidad de congelar temporalmente ciertas operativas. Si el negocio no puede describir su tolerancia al impacto y sus opciones de recuperación, la conversación se volverá incómoda.
Quinto, control sobre terceros críticos. DORA ha hecho habitual la pregunta clave: ¿sabes qué servicios te presta cada tercero, con qué criticidad, dónde están los datos, qué subcontratistas participan y cómo saldrías de la relación si algo falla? En cripto, donde abundan integraciones veloces y proveedores nicho, esa pregunta suele revelar más de lo que a la entidad le gustaría.
Para España, la lectura es doble. Por un lado, afecta de forma directa a los CASPs autorizados o supervisados dentro del perímetro europeo que presten servicios de custodia. Por otro, interesa a bancos, entidades de pago, plataformas de inversión, gestoras y aseguradoras que estén explorando o utilizando infraestructuras cripto, tokenización o proveedores de custodia como parte de su oferta o de pilotos de mercado.
La Comisión Nacional del Mercado de Valores, como autoridad nacional competente en el ámbito correspondiente, participará previsiblemente en la lógica general de convergencia que impulsa ESMA. Eso significa que las entidades con presencia en España harían mal en tratar esta CSA como un ejercicio lejano de Bruselas. La muestra será basada en riesgo, y el riesgo supervisor rara vez se reduce solo al tamaño. También pesa la complejidad operativa, la criticidad del servicio, el tipo de cliente, el grado de tercerización y la calidad aparente del marco de control.
Para las entidades financieras españolas no cripto en sentido estricto, hay otra derivada menos evidente. Si trabajan con terceros que son CASPs, o si dependen de infraestructuras de custodia cripto para pilotos o líneas de negocio incipientes, esta CSA ofrece una referencia útil para due diligence de terceros. Las seis áreas citadas por ESMA funcionan casi como una lista mínima de preguntas que cualquier comprador de servicios debería hacer antes de firmar. No porque quede bonito, sino porque luego llegan los comités de riesgos y preguntan por qué nadie vio el agujero.
También entra en juego la coordinación interna. En muchas entidades españolas, las iniciativas sobre activos digitales han convivido en 2025 y 2026 entre innovación, negocio, tecnología y legal, a veces con compliance llegando al final para “revisar”. Esa coreografía deja de ser sostenible cuando el supervisor pasa de hablar de adopción a hablar de resiliencia. Si tu proyecto cripto no está integrado en la gobernanza de riesgo operacional, terceros, continuidad e incidentes, no tienes un proyecto industrializado; tienes una excepción elegante.
La reacción inteligente no es esperar a recibir un requerimiento formal. La reacción inteligente es tratar el anuncio de ESMA como una ventana para preparar evidencia antes de que empiece el cruce supervisor entre autoridades nacionales.
La primera tarea es delimitar el perímetro exacto de custodia y administración. Parece obvio, pero no siempre lo es. Muchas firmas mezclan en el discurso comercial servicios de custodia, staking, ejecución, liquidez, treasury interno y componentes de infraestructura compartida. El supervisor querrá entender qué parte del stack soporta la custodia de clientes, qué controles son específicos y cuáles son heredados de plataformas comunes. Si esa cartografía no existe, conviene construirla ya.
La segunda es revisar el modelo de claves. No a nivel aspiracional, sino componente por componente: generación, custodia, backup, recuperación, acceso privilegiado, rotación, segregación por activos o clientes, dual control, procedimientos break-glass y destrucción segura. Si el diseño depende de un proveedor MPC o wallet externo, la entidad debe poder explicar con precisión qué controla ella y qué controla el tercero. “Lo lleva el proveedor” no es una respuesta; es una confesión.
La tercera es examinar los flujos de autorización y ejecución de transacciones. Aquí suele aflorar deuda operativa: excepciones no documentadas, listas blancas gestionadas de manera manual, accesos heredados, alertas mal calibradas o reconciliaciones demasiado lentas. Conviene reconstruir el proceso real, no el dibujado en políticas, y medir tiempos, puntos de decisión y dependencias humanas.
La cuarta es probar la respuesta a incidentes con escenarios cripto de verdad. No sirve un tabletop genérico sobre “ciberataque”. Hace falta ensayar supuestos concretos: compromiso de una clave de firma, exfiltración de secretos, actividad anómala en un smart contract administrado, fallo prolongado del proveedor de infraestructura, transacción no autorizada en curso, manipulación de listas de direcciones permitidas, indisponibilidad de un tercero crítico o error de configuración en herramientas de policy engine. Si el ejercicio no obliga a decidir en minutos quién corta qué, no refleja la realidad operativa.
La quinta es hacer limpieza en terceros. Inventario completo, clasificación por criticidad, dependencia técnica, datos tratados, ubicación, subprocesadores o subcontratistas, SLA, derechos de auditoría, obligaciones de notificación, pruebas de resiliencia, salida ordenada y alternativas viables. Esta parte es ingrata y consume tiempo. Justamente por eso suele estar peor de lo que los equipos creen.
La sexta es preparar narrativa supervisora basada en hechos. Un buen marco de control no basta si la entidad no sabe explicarlo. Los supervisores comparan madurez, coherencia y capacidad de respuesta. La diferencia entre una revisión llevadera y otra dolorosa a menudo no está solo en los controles, sino en la claridad con la que la entidad puede demostrar diseño, implantación, seguimiento y remediación.
La parte más interesante de esta CSA es cultural. Durante años, muchas firmas cripto vendieron seguridad como una cualidad casi inherente de la tecnología subyacente: criptografía fuerte, inmutabilidad, descentralización, transparencia en cadena. Todo eso puede ser cierto y seguir sin resolver el riesgo operativo de una entidad concreta. Una blockchain no compensa una mala segregación de funciones. Un smart contract auditado no corrige una gobernanza débil sobre upgrades o permisos administrativos. Un sistema MPC no sustituye una gestión seria de terceros ni un proceso robusto de respuesta a incidentes.
La ironía del momento es evidente. El sector que más insistió en eliminar intermediarios se enfrenta ahora a una exigencia muy tradicional: demostrar disciplina operativa, controles internos y capacidad de supervisión. Bienvenido al sistema financiero regulado. Hay café, actas de comité y preguntas sobre logs.
Eso no significa que ESMA esté asfixiando innovación. Significa algo bastante más sensato: si custodias activos de clientes en un entorno tecnológicamente complejo, tienes que ser capaz de demostrar que tu resiliencia no depende de la esperanza ni del prestigio del proveedor. Y si no puedes demostrarlo, no basta con decir que la tecnología es nueva. En 2026, ese argumento ya caducó.
Entre la segunda mitad de 2026 y la primera mitad de 2027, las autoridades nacionales recopilarán información de una muestra de CASPs autorizados. Ese detalle temporal importa. No estamos ante una consulta abierta ni una promesa abstracta para “próximos años”. La maquinaria supervisora se pone en marcha ahora.
El informe final que ESMA presentará a su Board of Supervisors en la segunda mitad de 2027 probablemente servirá para tres cosas. Una, identificar prácticas convergentes y divergencias entre supervisores. Dos, detectar fallos recurrentes de mercado en custodia cripto. Tres, sentar la base para futuras expectativas supervisoras más explícitas, y quizá para medidas de seguimiento a nivel nacional. Sería ingenuo pensar que todo acabará en un PDF de conclusiones y un par de frases sobre cooperación. Cuando un supervisor organiza un ejercicio paneuropeo sobre un área de riesgo, suele hacerlo para aprender, comparar y luego apretar mejor.
También cabe esperar un efecto indirecto sobre proveedores tecnológicos. Aunque el sujeto formal de supervisión sea el CASP, la presión bajará por la cadena: proveedores MPC, custodios subyacentes, cloud, nodos gestionados, servicios de monitorización, herramientas de transacción y firmas de auditoría técnica. Si los clientes regulados necesitan más evidencias, los terceros tendrán que entregarlas o quedarse fuera de las compras serias.
Otra consecuencia será la profesionalización del lenguaje de mercado. Las promesas comerciales vagas sobre “seguridad institucional” o “custodia de grado bancario” se volverán menos útiles si los compradores y supervisores empiezan a pedir pruebas concretas: controles, métricas, pruebas, auditorías, tiempos de respuesta, procesos de recuperación, gestión de permisos y dependencia de terceros. Ya tocaba.
La CSA sobre resiliencia operativa digital de los CASPs en custodia es, en apariencia, una actuación supervisora acotada. En realidad, es una prueba de madurez para el mercado cripto europeo. ESMA ha elegido un punto neurálgico donde convergen protección del cliente, riesgo operacional, terceros, gobernanza y confianza de mercado. La elección no es casual y el calendario tampoco.
Para los CASPs, el mensaje es claro: este año ya no toca explicar por qué tu arquitectura es innovadora; toca demostrar por qué resiste, quién la gobierna, cómo responde y qué pasa cuando un tercero falla o una clave se compromete. Para bancos, inversores institucionales y compradores de servicios, la CSA ofrece una brújula práctica para separar operadores industrializados de operadores que todavía viven de presentaciones bonitas y controles implícitos.
Aquí está el quid. En custodia cripto, la resiliencia operativa no es una capa extra de cumplimiento. Es el producto. Si una entidad no puede garantizarla y probarla, lo demás —marca, crecimiento, promesa tecnológica— vale bastante menos de lo que su departamento comercial cree.
Resumen semanal gratis
Suscríbete al resumen semanal de regulación, vulnerabilidades explotadas y acciones para tu equipo.
¿Quieres un plan a medida? Modela tu organización con Agentic Digital Twin.
Es el proceso de vigilar de forma continua los cambios normativos y las vulnerabilidades relevantes, y traducirlos en acciones concretas para los equipos de seguridad, riesgo y compliance.
Una vulnerabilidad explotada puede activar obligaciones de notificación o gestión de riesgo (por ejemplo en DORA, NIS2 o el CRA). Mapear la amenaza al marco aplicable permite priorizar la respuesta.
Un GAP Assessment evalúa tu madurez por control frente al marco elegido (DORA, NIS2, ISO 27001, etc.) y produce un plan de acción con brechas priorizadas.