La gestión de vulnerabilidades tradicional se ha quedado corta para muchas empresas. Ejecutar un escaneo mensual, exportar un informe con cientos de CVEs y asignar tickets por severidad CVSS ya no es suficiente cuando la superficie de ataque cambia a diario, los atacantes automatizan la explotación y las áreas de negocio despliegan nuevos activos, APIs, servicios cloud e identidades no humanas de forma continua.
Aquí aparece CTEM, siglas de Continuous Threat Exposure Management o Gestión Continua de Exposición a Amenazas.
CTEM no es una herramienta concreta. Es un modelo operativo para identificar, priorizar, validar y reducir de forma continua las exposiciones que realmente pueden convertirse en incidentes. Su valor está en conectar piezas que muchas organizaciones ya tienen separadas: inventario de activos, gestión de vulnerabilidades, exposición externa, pentesting, red team, threat intelligence, SOC, cumplimiento normativo y reporting ejecutivo.
En empresas sujetas a NIS2, DORA, ENS o ISO 27001, CTEM puede convertirse en el puente entre la seguridad técnica y la evidencia de cumplimiento.
Qué es CTEM
CTEM es un programa continuo de gestión de exposición que permite descubrir activos, identificar debilidades, priorizar riesgos explotables, validar si son realmente aprovechables y movilizar acciones de remediación medibles.
La diferencia frente a un enfoque clásico es importante:
- La gestión tradicional de vulnerabilidades suele centrarse en CVEs.
- El escaneo de superficie de ataque suele centrarse en activos expuestos.
- El pentesting suele centrarse en una validación puntual.
- El SOC suele centrarse en detección y respuesta.
- El compliance suele centrarse en controles, evidencias y auditoría.
CTEM intenta unir todo eso en un ciclo operativo común.
Su pregunta principal no es:
¿Cuántas vulnerabilidades tenemos?
Sino:
¿Qué exposiciones reales podrían comprometer el negocio si un atacante las explotara hoy?
Esa diferencia cambia por completo la forma de priorizar.
Por qué CTEM está ganando importancia en 2026
El mercado internacional está evolucionando desde la gestión de vulnerabilidades hacia la gestión de exposición. Gartner ha definido CTEM como un camino para pasar de un modelo tradicional de vulnerability management a un programa más amplio, dinámico y continuo de exposición a amenazas.
Al mismo tiempo, CISA mantiene el catálogo Known Exploited Vulnerabilities — KEV como una referencia práctica para priorizar vulnerabilidades que ya están siendo explotadas. Aunque la directiva BOD 22-01 aplica a agencias federales estadounidenses, CISA recomienda a todas las organizaciones reducir su exposición priorizando la remediación de vulnerabilidades presentes en KEV.
En Europa, NIS2 y DORA están llevando a las empresas a demostrar una gestión del riesgo más continua, documentada y basada en evidencias. ENISA también ha publicado orientación técnica para ayudar a implementar medidas de gestión de riesgos de ciberseguridad bajo NIS2.
La conclusión es clara: la presión internacional no va hacia más informes aislados, sino hacia programas capaces de demostrar visibilidad, priorización, validación y mejora continua.
CTEM no sustituye la gestión de vulnerabilidades: la amplía
Un error frecuente es pensar que CTEM reemplaza al vulnerability management. No es así.
La gestión de vulnerabilidades sigue siendo una pieza esencial. Sin escaneo, inventario, detección de CVEs, análisis de configuración y gestión de parches, CTEM no tiene materia prima.
La diferencia es que CTEM añade más contexto:
- Qué activo está afectado.
- Si el activo está expuesto a Internet.
- Si pertenece a un proceso crítico.
- Si tiene datos sensibles.
- Si existe explotación activa.
- Si hay credenciales comprometidas asociadas.
- Si existen controles compensatorios.
- Si el camino de ataque es viable.
- Si la remediación reduce riesgo real o solo baja una métrica técnica.
Por eso, CTEM debe apoyarse en una buena base de gestión de vulnerabilidades, pero no limitarse a ella.
Las cinco fases de un programa CTEM
Aunque cada organización puede adaptarlo, un programa CTEM maduro suele organizarse en cinco fases: alcance, descubrimiento, priorización, validación y movilización.
1. Alcance: decidir qué exposición importa
La primera fase consiste en definir qué parte del negocio se va a analizar y con qué objetivo. No se trata de escanearlo todo sin criterio, sino de delimitar el alcance en función del impacto.
Ejemplos de alcances útiles:
- Aplicaciones expuestas a Internet.
- Infraestructura cloud crítica.
- Microsoft 365 y entornos de identidad.
- APIs públicas y privadas.
- Entornos industriales u OT.
- Sistemas que soportan procesos regulados por DORA.
- Plataformas que tratan datos personales.
- Servicios dentro del alcance ENS.
- Activos de terceros conectados a la organización.
Esta fase es clave para evitar ruido. Un CTEM mal planteado puede convertirse en otro repositorio de alertas. Un CTEM bien planteado empieza por las preguntas de negocio correctas.
Por ejemplo:
- ¿Qué sistemas provocarían interrupción operativa si se vieran comprometidos?
- ¿Qué activos están incluidos en el alcance de ISO 27001?
- ¿Qué servicios son esenciales o importantes bajo NIS2?
- ¿Qué procesos TIC críticos están sujetos a DORA?
- ¿Qué activos están publicados en Internet sin una justificación clara?
Esta fase conecta directamente con servicios como consultoría de ciberseguridad, ISO 27001, ENS y DORA.
2. Descubrimiento: construir una visión real de la exposición
La segunda fase consiste en descubrir qué existe realmente.
Aquí muchas empresas encuentran el primer problema: el inventario oficial no coincide con la realidad técnica. Hay subdominios olvidados, servicios temporales que se quedaron publicados, buckets mal configurados, APIs no documentadas, cuentas de servicio antiguas, aplicaciones SaaS conectadas y activos que nadie reconoce como propios.
Un descubrimiento CTEM debería incluir, como mínimo:
- Activos externos expuestos.
- Subdominios.
- Direcciones IP públicas.
- Certificados.
- Puertos y servicios accesibles.
- Aplicaciones web.
- APIs.
- Repositorios y secretos expuestos.
- Identidades privilegiadas.
- Cuentas de servicio.
- Integraciones SaaS.
- Configuraciones cloud.
- Dependencias críticas de terceros.
Aquí encajan disciplinas como External Attack Surface Management, revisión de postura cloud, auditoría de identidad, escaneo de vulnerabilidades y threat intelligence.
El objetivo no es solo encontrar vulnerabilidades, sino entender la exposición completa: activos, identidades, configuraciones, rutas de ataque y dependencias.
Si la empresa ya dispone de un servicio de gestión de superficie de ataque, esta fase puede integrarse dentro del ciclo CTEM.
3. Priorización: separar ruido de riesgo real
La priorización es la fase donde CTEM aporta más valor.
En muchos programas tradicionales, la prioridad se decide con una regla simple:
- Crítico: corregir primero.
- Alto: corregir después.
- Medio y bajo: cuando se pueda.
El problema es que esa lógica no siempre refleja el riesgo real. Una vulnerabilidad crítica en un sistema aislado puede ser menos urgente que una vulnerabilidad media en un servicio expuesto, con exploit público, credenciales filtradas y acceso a datos sensibles.
Una priorización CTEM debería combinar varias señales:
- Criticidad del activo.
- Exposición externa.
- Existencia de exploit público.
- Presencia en CISA KEV.
- EPSS u otros indicadores de probabilidad de explotación.
- CVSS, pero sin usarlo como único criterio.
- Controles compensatorios.
- Sensibilidad de los datos.
- Relación con procesos críticos.
- Facilidad de explotación.
- Impacto regulatorio.
- Riesgo de movimiento lateral.
- Evidencia de actividad maliciosa.
- Relación con terceros o cadena de suministro.
Por ejemplo, una vulnerabilidad con CVSS 7.5 puede ser prioritaria si afecta a una VPN expuesta, aparece en KEV, tiene explotación activa y da acceso inicial a la red. En cambio, una vulnerabilidad CVSS 9.8 en un entorno no expuesto, segmentado y con controles compensatorios puede tener menor urgencia operativa.
Esta lógica está muy alineada con un enfoque moderno como KEV, EPSS y SSVC para priorizar vulnerabilidades explotables.
4. Validación: comprobar si la exposición es explotable
CTEM no debería quedarse en “hemos detectado una vulnerabilidad”. Debe responder a una pregunta más útil:
¿Puede un atacante explotarla en nuestro contexto real?
La validación puede adoptar distintos niveles de profundidad:
- Confirmación no intrusiva.
- Revisión manual.
- Prueba controlada de explotación.
- Pentesting focalizado.
- Simulación de adversario.
- Validación de controles defensivos.
- Purple teaming.
- Comprobación de detección en SIEM, EDR o SOC.
- Pruebas de movimiento lateral en entorno autorizado.
Esta fase es especialmente importante para reducir falsos positivos y justificar inversión. También permite comprobar si los controles funcionan de verdad.
Ejemplos:
- Un escáner detecta una versión vulnerable, pero el servicio no es explotable por configuración.
- Una aplicación no tiene una CVE crítica, pero permite abuso de lógica de negocio.
- Una cuenta de servicio no tiene MFA, pero además tiene permisos excesivos y acceso a datos críticos.
- Una vulnerabilidad fue parcheada, pero el sistema sigue expuesto por una mala configuración.
- Un control existe en la política, pero no genera alerta en el SOC.
Aquí CTEM conecta directamente con pentesting, hacking ético, red team y SOC gestionado.
5. Movilización: convertir hallazgos en reducción de riesgo
La fase final es la más difícil: conseguir que la organización corrija.
Muchas empresas ya saben qué tienen mal. El problema es que no consiguen cerrar el ciclo. Los tickets se acumulan, los equipos no tienen contexto, las excepciones no caducan y dirección recibe métricas técnicas que no explican impacto.
CTEM exige que cada hallazgo priorizado tenga:
- Propietario.
- Acción recomendada.
- Fecha objetivo.
- Evidencia esperada.
- Riesgo asociado.
- Impacto de no corregir.
- Control compensatorio si no puede corregirse.
- Criterio de aceptación del riesgo.
- Validación posterior.
El objetivo no es “cerrar tickets”, sino demostrar reducción de exposición.
Ejemplo de mala movilización:
Vulnerabilidad crítica detectada. Pendiente de parcheo.
Ejemplo de movilización CTEM:
Servicio VPN expuesto a Internet con vulnerabilidad incluida en catálogo de explotación conocida. Activo asociado a acceso remoto corporativo. Riesgo: acceso inicial no autorizado. Acción: actualizar versión, revisar logs de acceso, invalidar sesiones activas y validar detección en SOC. Fecha objetivo: 72 horas. Propietario: Infraestructura. Evidencia: versión corregida, captura de configuración, ticket SOC y resultado de validación.
La diferencia es enorme.
CTEM y cumplimiento: NIS2, DORA, ENS e ISO 27001
CTEM no es una norma, pero ayuda a demostrar controles exigidos por varias normas y marcos regulatorios.
CTEM y NIS2
NIS2 exige una gestión del riesgo de ciberseguridad más estructurada para entidades esenciales e importantes. CTEM puede ayudar a demostrar:
- Gestión continua de riesgos.
- Seguridad de redes y sistemas.
- Gestión de incidentes.
- Continuidad de negocio.
- Seguridad de la cadena de suministro.
- Políticas de control de acceso.
- Evaluación de la eficacia de medidas de seguridad.
- Prácticas básicas de higiene cibernética.
Un programa CTEM bien documentado permite mostrar evidencias de descubrimiento, priorización, remediación y validación.
Más información relacionada: cómo cumplir NIS2 en España y servicio NIS2.
CTEM y DORA
En entidades financieras y proveedores TIC del sector financiero, DORA exige una gestión sólida del riesgo TIC, pruebas de resiliencia, gestión de terceros y respuesta ante incidentes.
CTEM puede aportar valor en:
- Identificación de activos TIC críticos.
- Priorización de exposiciones que afecten a funciones críticas.
- Validación de controles técnicos.
- Evidencia de mejora continua.
- Gestión del riesgo de terceros tecnológicos.
- Relación entre vulnerabilidades, incidentes y continuidad operativa.
Más información relacionada: DORA y NIS2 vs DORA.
CTEM y ENS
En el Esquema Nacional de Seguridad, CTEM puede reforzar la gestión de la seguridad en sistemas de información, especialmente cuando se necesita demostrar control de activos, gestión de vulnerabilidades, protección frente a amenazas, monitorización y mejora continua.
Es especialmente útil en organizaciones que deben preparar o mantener una certificación ENS, porque permite transformar hallazgos técnicos en evidencias de control.
Más información relacionada: ENS, preparación de auditoría ENS y gestión de vulnerabilidades ENS.
CTEM e ISO 27001
En ISO 27001, CTEM puede integrarse con el sistema de gestión de seguridad de la información como una fuente continua de riesgos, controles y evidencias.
Puede apoyar:
- Inventario de activos.
- Evaluación y tratamiento de riesgos.
- Gestión de vulnerabilidades técnicas.
- Control de acceso.
- Registro y monitorización.
- Seguridad en desarrollo y cambios.
- Gestión de proveedores.
- Mejora continua.
Más información relacionada: ISO 27001 y proceso de implantación de ISO 27001.
Arquitectura mínima para implantar CTEM
Una empresa no necesita comprar una plataforma nueva para empezar con CTEM. Puede comenzar integrando capacidades existentes.
Una arquitectura mínima debería incluir:
1. Inventario de activos
Debe cubrir activos internos, externos, cloud, SaaS, identidades, aplicaciones, APIs, proveedores y servicios críticos.
Sin inventario, no hay CTEM. Solo hay escaneos parciales.
2. Descubrimiento externo
Permite identificar qué ve un atacante desde Internet: dominios, subdominios, IPs, servicios, certificados, tecnologías y exposiciones.
Esto se relaciona con superficie de ataque y gestión de superficie de ataque.
3. Escaneo de vulnerabilidades
Sigue siendo una base imprescindible. Debe incluir sistemas, aplicaciones, infraestructura, cloud, contenedores y dependencias.
Para profundizar: gestión de vulnerabilidades: qué incluye.
4. Contexto de amenaza
Aquí entran KEV, EPSS, inteligencia de amenazas, actividad sectorial, campañas activas y exposición de credenciales.
Para ampliar: threat intelligence.
5. Validación ofensiva
Debe comprobar si los hallazgos son explotables y si los controles defensivos funcionan.
Puede apoyarse en pentesting, red team o pruebas más acotadas de validación.
6. Integración con SOC
CTEM debe conectar con detección y respuesta. Si una exposición crítica no se puede corregir de inmediato, el SOC debe saber qué vigilar.
Más información: qué es un SOC y qué servicios puede incluir y SOC gestionado.
7. Gestión de remediación
Debe haber propietarios, plazos, evidencias, excepciones, aceptación de riesgo y validación posterior.
8. Reporting ejecutivo
El comité de dirección no necesita ver 400 CVEs. Necesita entender:
- Qué exposiciones críticas existen.
- Qué riesgo de negocio representan.
- Qué se ha corregido.
- Qué sigue abierto.
- Qué decisiones requieren presupuesto o aceptación formal.
- Qué indicadores demuestran mejora.
Para esto puede ayudar un cuadro de mando de ciberresiliencia.
KPIs útiles para medir CTEM
Un CTEM debe medirse con indicadores que ayuden a tomar decisiones. Algunos KPIs útiles son:
Errores habituales al implantar CTEM
Error 1: convertir CTEM en otro dashboard
Un dashboard no es CTEM. Si no hay decisiones, remediación y validación, solo es visualización.
Error 2: priorizar solo por CVSS
CVSS es útil, pero insuficiente. CTEM necesita contexto de negocio, exposición, explotación real y validación.
Error 3: no integrar identidad
Muchas rutas de ataque actuales no empiezan por una CVE, sino por una identidad mal protegida, una cuenta de servicio, un token, una API key o una credencial comprometida.
Más información: identidades no humanas en 2026 y IAM y postura cloud.
Error 4: separar compliance y seguridad técnica
Si CTEM se queda en el equipo técnico y compliance trabaja por separado, se pierde gran parte del valor. Las evidencias de CTEM pueden alimentar auditorías, análisis de riesgos y planes de tratamiento.
Más información: por qué separar ciberseguridad y compliance es un error.
Error 5: no validar la remediación
Cerrar un ticket no significa cerrar el riesgo. CTEM exige comprobar que la exposición ha desaparecido o que el control compensatorio es eficaz.
Error 6: intentar hacerlo todo desde el primer mes
CTEM debe implantarse de forma progresiva. Es mejor empezar por un alcance crítico y medir resultados que intentar cubrir toda la organización sin capacidad de remediación.
Roadmap práctico de implantación CTEM en 90 días
Días 1 a 15: alcance y activos críticos
Objetivo: definir el primer alcance CTEM.
Acciones recomendadas:
- Seleccionar una unidad de negocio, entorno o proceso crítico.
- Identificar activos principales.
- Revisar dependencias externas.
- Definir propietarios.
- Mapear relación con NIS2, DORA, ENS o ISO 27001.
- Acordar criterios de severidad y priorización.
Resultado esperado: alcance CTEM inicial aprobado.
Días 16 a 30: descubrimiento y exposición
Objetivo: obtener visibilidad real.
Acciones recomendadas:
- Descubrimiento de superficie externa.
- Inventario de servicios publicados.
- Revisión de dominios y subdominios.
- Escaneo de vulnerabilidades.
- Revisión básica de identidad y accesos.
- Identificación de activos sin propietario.
Resultado esperado: mapa inicial de exposición.
Días 31 a 45: priorización por riesgo
Objetivo: reducir ruido.
Acciones recomendadas:
- Cruzar vulnerabilidades con criticidad de activos.
- Marcar activos expuestos a Internet.
- Incorporar KEV, EPSS o inteligencia de amenazas.
- Identificar exposiciones con posible impacto regulatorio.
- Separar hallazgos técnicos de riesgos accionables.
Resultado esperado: lista priorizada de exposiciones críticas.
Días 46 a 60: validación
Objetivo: comprobar qué riesgos son explotables.
Acciones recomendadas:
- Validación manual de hallazgos críticos.
- Pruebas controladas de explotación cuando proceda.
- Revisión de controles compensatorios.
- Comprobación de alertas en SOC.
- Confirmación de falsos positivos.
Resultado esperado: riesgos validados y priorizados.
Días 61 a 75: movilización
Objetivo: convertir hallazgos en acciones.
Acciones recomendadas:
- Asignar propietarios.
- Crear tickets con contexto de negocio.
- Definir fechas objetivo.
- Establecer evidencias de cierre.
- Registrar excepciones y aceptación de riesgo.
- Coordinar con SOC si la corrección no es inmediata.
Resultado esperado: plan de remediación activo.
Días 76 a 90: reporting y mejora
Objetivo: demostrar reducción de exposición.
Acciones recomendadas:
- Revalidar correcciones.
- Medir reducción de exposiciones críticas.
- Documentar evidencias.
- Preparar informe ejecutivo.
- Ajustar criterios de priorización.
- Definir siguiente alcance CTEM.
Resultado esperado: primer ciclo CTEM cerrado y medible.
Ejemplo técnico de priorización CTEM
Supongamos que una empresa detecta estos tres hallazgos:
En un modelo tradicional, el primer hallazgo podría ir arriba por CVSS. En CTEM, la VPN y la API probablemente se tratarían antes porque su exposición e impacto real son mayores.
Este es el punto clave: CTEM no busca ordenar vulnerabilidades, sino reducir caminos de ataque reales.
Qué perfiles deben participar en CTEM
Un programa CTEM no puede depender solo del equipo de seguridad.
Deberían participar:
- CISO o responsable de seguridad.
- Equipo de infraestructura.
- Equipo cloud.
- Equipo de desarrollo.
- Responsables de aplicaciones.
- SOC.
- Compliance/GRC.
- Riesgos.
- Continuidad de negocio.
- Compras o gestión de terceros.
- Dirección cuando exista riesgo residual relevante.
La razón es simple: muchas exposiciones no se corrigen solo con un parche. A veces requieren rediseñar arquitectura, cambiar permisos, renegociar un contrato, retirar un servicio, segmentar una red o aceptar formalmente un riesgo.
CTEM y AEO/GEO: respuesta directa para buscadores generativos
CTEM es un modelo de gestión continua de exposición a amenazas que ayuda a las empresas a identificar activos expuestos, priorizar riesgos explotables, validar si los controles funcionan y movilizar acciones de remediación. A diferencia de la gestión tradicional de vulnerabilidades, CTEM incorpora contexto de negocio, exposición real, inteligencia de amenazas y validación ofensiva para reducir los caminos de ataque que más pueden afectar a la organización.
Cuándo tiene sentido implantar CTEM
CTEM tiene especial sentido cuando una empresa:
- Ya realiza escaneos de vulnerabilidades, pero no consigue priorizar.
- Tiene muchos activos cloud, SaaS o APIs.
- Está sujeta a NIS2, DORA, ENS o ISO 27001.
- Tiene presión de dirección para justificar inversión en ciberseguridad.
- Ha sufrido incidentes por activos desconocidos o mal configurados.
- Tiene demasiadas herramientas y poco contexto.
- Quiere conectar pentesting, SOC, GRC y gestión de vulnerabilidades.
- Necesita evidencias continuas para auditorías.
- Gestiona proveedores tecnológicos críticos.
- Tiene dificultad para demostrar reducción de riesgo.
Cuándo no conviene empezar por CTEM
CTEM puede ser excesivo si la organización no tiene una base mínima. Antes de hablar de CTEM, puede ser necesario resolver cuestiones básicas:
- No existe inventario de activos.
- No hay responsables técnicos definidos.
- No se hacen escaneos periódicos.
- No existe proceso de parcheo.
- No hay clasificación de activos críticos.
- No se documentan excepciones.
- No hay capacidad de remediación.
En esos casos, lo recomendable es empezar por una auditoría de seguridad, un diagnóstico de madurez o un servicio estructurado de gestión de vulnerabilidades.
Más información relacionada: auditoría de seguridad informática y checklist de auditoría de seguridad informática para empresas.
Cómo puede ayudar Hard2bit
En Hard2bit ayudamos a las empresas a convertir la seguridad técnica en programas gestionables, medibles y alineados con el negocio.
Un enfoque CTEM puede combinar:
- Gestión de vulnerabilidades
- Gestión de superficie de ataque
- Pentesting
- Red Team
- SOC gestionado
- Threat Intelligence
- Consultoría de ciberseguridad
- ISO 27001
- ENS
- NIS2
- DORA
La clave no está en añadir más herramientas, sino en ordenar la información, priorizar por riesgo real, validar técnicamente y generar evidencias útiles para dirección, auditoría y operación.
Si tu empresa necesita pasar de informes aislados a un programa continuo de reducción de exposición, podemos ayudarte a diseñar e implantar un modelo CTEM adaptado a tu realidad técnica y regulatoria.
CTEM representa una evolución natural de la gestión de vulnerabilidades. No basta con saber qué CVEs existen. Las empresas necesitan saber qué exposiciones son explotables, qué impacto tienen en el negocio, qué controles funcionan y qué acciones reducen riesgo real.
Para organizaciones sujetas a NIS2, DORA, ENS o ISO 27001, CTEM puede convertirse en una pieza estratégica: conecta seguridad técnica, cumplimiento, SOC, pentesting, superficie de ataque y reporting ejecutivo en un ciclo continuo.
La pregunta ya no es si una empresa debe escanear vulnerabilidades. La pregunta es si puede demostrar, de forma continua, que está reduciendo las exposiciones que realmente importan.