Modelado de amenazas para ISO 27001, NIS2 y DORA

A Anya, directora de seguridad de la información (CISO) de una fintech en rápido crecimiento, le pidieron aprobar el plan de lanzamiento de una nueva plataforma B2B de riesgo de pagos. El consejo de administración quería entrar en el mercado antes de que terminara el trimestre. El equipo comercial ya había alineado a clientes bancarios. Ingeniería había esbozado una arquitectura nativa en la nube con atributos de identidad, señales de dispositivo, metadatos de transacciones, puntuaciones de riesgo conductual, una base de datos gestionada y un proveedor externo de analítica.

Sobre el papel, la plataforma parecía un avance comercial importante. Para Anya, parecía la llegada simultánea de cinco conversaciones de cumplimiento.

Como proveedor de tecnología financiera, la empresa estaba sometida a presión de DORA. Como proveedor de servicios en la nube y plataforma digital, necesitaba comprender su exposición a NIS2. Dado que la plataforma trataba datos personales relativos a personas de la UE, aplicaba GDPR. Los clientes corporativos esperaban certificación ISO/IEC 27001:2022. Si el servicio pasaba a formar parte de un producto de software conectado, las expectativas de la Ley de Ciberresiliencia añadirían evidencias de producto con seguridad desde el diseño.

El equipo de desarrollo propuso el plan de seguridad habitual: analizar dependencias, ejecutar un escaneo de vulnerabilidades, reservar una prueba de penetración y corregir los hallazgos críticos antes de la puesta en producción. Anya sabía que eso no bastaba. Esas actividades prueban lo que ya se ha construido. No demuestran que la arquitectura se haya diseñado de forma segura, que se hayan comprendido los límites de confianza, que los flujos de datos personales se hayan minimizado, que se hayan revisado los supuestos sobre proveedores ni que los escenarios de interrupción del servicio se hayan considerado antes del lanzamiento.

Así que ralentizó la reunión con cuatro preguntas:

1. ¿Dónde están los límites de confianza?
2. ¿Qué casos de abuso podrían causar fraude, exposición de datos o interrupción del servicio?
3. ¿Qué decisiones de diseño reducen el riesgo antes de escribir código?
4. ¿Qué evidencias satisfarán a los revisores de ISO 27001, NIS2, DORA, CRA y GDPR dentro de seis meses?

Esa cuarta pregunta es donde fallan muchas organizaciones. El modelado de amenazas suele tratarse como un taller útil de ingeniería y después queda enterrado en una página wiki. En 2026, eso no es suficiente. Para proveedores SaaS, fintechs, plataformas en la nube, MSP, MSSP, operadores de infraestructura digital y fabricantes de software, el modelado de amenazas se ha convertido en un generador de evidencias de cumplimiento.

Un proceso maduro de modelado de amenazas convierte los hallazgos de STRIDE, los casos de abuso y las decisiones de arquitectura en entradas del registro de riesgos, requisitos de seguridad, planes de tratamiento, casos de prueba, tareas de aseguramiento de proveedores, evidencias de privacidad desde el diseño y trazabilidad de la Declaración de Aplicabilidad.

Por qué ahora importan las evidencias de seguridad desde el diseño

Las regulaciones modernas convergen en una misma expectativa: las organizaciones deben identificar de forma temprana los riesgos de seguridad y privacidad, asignar responsables, implantar controles proporcionados y conservar evidencias.

ISO/IEC 27001:2022 exige un Sistema de Gestión de la Seguridad de la Información basado en riesgos. Las cláusulas 6.1.2 y 6.1.3 exigen evaluación de riesgos de seguridad de la información y tratamiento de riesgos. La cláusula 8.1 exige planificación y control operacional. El Anexo A proporciona controles que deben seleccionarse mediante la Declaración de Aplicabilidad en función del riesgo, los requisitos legales y las necesidades de la organización.

NIS2 incorpora el mismo principio a la gobernanza de la ciberseguridad. El Article 20 exige que los órganos de dirección aprueben las medidas de gestión del riesgo de ciberseguridad y supervisen su implantación. El Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento, gestión de vulnerabilidades, higiene cibernética, cifrado, control de acceso, gestión de activos y autenticación multifactor cuando proceda.

DORA aplica una perspectiva de resiliencia operativa del sector financiero desde el 17 de enero de 2025. Exige que las entidades financieras cubiertas mantengan un marco de gestión del riesgo de las TIC sólido, integral y documentado; identifiquen activos y dependencias de las TIC; apliquen medidas de protección y prevención; detecten actividad anómala; prueben la resiliencia operativa digital; gestionen el riesgo de terceros de TIC; y preparen capacidades de respuesta y recuperación. Para las entidades financieras cubiertas, DORA es el acto jurídico sectorial de la Unión aplicable a las obligaciones que se solapan con NIS2.

GDPR añade responsabilidad proactiva y protección de datos desde el diseño y por defecto. Todo sistema que trate datos personales debe poder demostrar un tratamiento lícito, leal, transparente, limitado a la finalidad, minimizado, limitado en conservación y seguro. Un modelo de amenazas que mapea flujos de datos personales, rutas de acceso, registros de eventos, conservación, supresión y transferencias a terceros es directamente pertinente para los Articles 5, 25, 32 y 35 de GDPR.

La Ley de Ciberresiliencia añade presión para productos con elementos digitales. Los equipos de producto necesitan evidencias de ciclo de vida que demuestren que los riesgos de ciberseguridad, el uso indebido previsible, las interfaces, los mecanismos de actualización, los flujos de autenticación y los supuestos de gestión de vulnerabilidades se consideraron desde el inicio.

La conclusión es clara: si una revisión de arquitectura no puede trazarse hasta riesgos, controles, responsables, mitigaciones y pruebas, será difícil defenderla en una auditoría o revisión regulatoria de 2026.

El modelo de Clarysec: un modelo de amenazas, múltiples resultados

El enfoque de Clarysec parte de un principio práctico: un modelo de amenazas no está completo hasta que produce decisiones auditables.

En Zenith Blueprint: hoja de ruta de 30 pasos para auditores [ZB], la fase de gestión de riesgos, paso 9, ofrece a los equipos un formato sencillo para convertir observaciones técnicas en lenguaje de riesgo:

“Ahora combine Activo + Amenaza + Vulnerabilidad en una descripción concisa del escenario de riesgo. En esencia, describa el incidente potencial. Más adelante será una línea del Registro de Riesgos. Use un formato sencillo: ‘[Amenaza] explota [vulnerabilidad] en [activo], lo que da lugar a [impacto]’.”

Esa frase es el puente entre ingeniería y cumplimiento.

Una nota en pizarra como “riesgo de suplantación de la API del socio” se convierte en:

“Un atacante explota una autenticación débil de la API del socio en la API de riesgo de transacciones, lo que da lugar a acceso no autorizado a decisiones de riesgo de pagos y exposición de datos personales.”

Ahora el hallazgo tiene activo, amenaza, vulnerabilidad e impacto. Puede evaluarse, asignarse, tratarse, probarse y aceptarse.

La capa de políticas hace que esto sea repetible. La P24 Política de Desarrollo Seguro [P24] establece:

“Todas las aplicaciones nuevas y los cambios mayores deben someterse a una revisión de arquitectura segura y a modelado de amenazas antes de que comience el desarrollo.”
De la sección “Requisitos de implementación de la política”, cláusula de la política 6.1.1.

También exige:

“Las revisiones de diseño deben documentar diagramas de flujo de datos, límites de confianza y medidas de mitigación para los riesgos identificados.”
De la sección “Requisitos de implementación de la política”, cláusula de la política 6.1.2.

Estas dos cláusulas son anclajes de auditoría potentes. Demuestran que el modelado de amenazas no es opcional y que las evidencias de diseño deben incluir diagramas, límites y decisiones de mitigación.

La P06 Política de Gestión de Riesgos [P06] conecta el modelado de amenazas con la gestión de riesgos empresarial:

“Todas las unidades de negocio deberán identificar riesgos de forma proactiva mediante técnicas estructuradas derivadas de ISO/IEC 27005:2024, incluido el modelado de amenazas, el mapeo de dependencias de activos y la identificación basada en escenarios.”
De la sección “Requisitos de implementación de la política”, cláusula de la política 6.1.1.

También establece:

“Los riesgos identificados deberán documentarse con referencia al propietario del activo, actor de amenaza, vulnerabilidad e impacto potencial sobre la Confidencialidad, Integridad y Disponibilidad (CID).”
De la sección “Requisitos de implementación de la política”, cláusula de la política 6.1.4.

Esta es la cadena de evidencias que los auditores quieren ver: requisito de política, actividad de diseño, escenario de riesgo, selección de controles, implantación, pruebas y aprobación.

STRIDE hace sistemática la cobertura; los casos de abuso la hacen real

STRIDE sigue siendo uno de los métodos más útiles para el modelado de amenazas en fase de diseño porque obliga a los equipos a considerar seis modos comunes de fallo:

• Suplantación
• Manipulación
• Repudio
• Divulgación de información
• Denegación de servicio
• Elevación de privilegios

Para la plataforma de riesgo de pagos de Anya, el equipo aplicó STRIDE a cada componente, flujo de datos y límite de confianza.

La suplantación planteó si un cliente de API de un socio podría hacerse pasar por un cliente bancario si la autenticación mutua era débil. La manipulación expuso el riesgo de que las señales de dispositivo o los importes de transacciones se alterasen antes de la ingesta. El repudio destacó la necesidad de registros de auditoría de administradores y transacciones. La divulgación de información se centró en fugas a través de registros de eventos, exportaciones analíticas, herramientas de soporte e interfaces de programación de aplicaciones de informes. La denegación de servicio obligó al equipo a considerar picos de transacciones e inundaciones de solicitudes malformadas. La elevación de privilegios expuso riesgos en roles de soporte, tokens de sesión y funciones administrativas.

Los casos de abuso convirtieron esas categorías en historias reales:

• Un defraudador carga señales de dispositivo manipuladas para influir en una puntuación de riesgo.
• Una credencial de socio comprometida inunda la API con solicitudes fraudulentas.
• Un desarrollador usa datos personales de producción en un entorno de prueba.
• Una amenaza interna maliciosa exporta identificadores de clientes y lógica de puntuación de riesgos.
• La indisponibilidad de un proveedor de analítica en la nube bloquea decisiones de riesgo durante una ventana de pagos.
• Una configuración incorrecta de almacenamiento expone documentos de identidad cargados.
• Un flujo de trabajo de supresión elimina el registro de la aplicación, pero deja copias de seguridad y copias del proveedor.

Cada caso de abuso se convirtió en un registro de riesgo de diseño con el activo afectado, actor de amenaza, vulnerabilidad, impacto, supuestos existentes, mitigación requerida, propietario del riesgo residual, evidencias de prueba y relevancia regulatoria.

Esa estructura evita hallazgos vagos como “riesgo de seguridad de API”. Produce declaraciones de riesgo con calidad de evidencia, como:

“Un atacante utiliza credenciales de socio robadas para enviar solicitudes fraudulentas de puntuación a través de la API de riesgo de transacciones, lo que provoca el compromiso de la integridad de las decisiones de riesgo, posibles pérdidas financieras para los clientes y tratamiento no autorizado de datos personales.”

Mapeo del modelado de amenazas a ISO/IEC 27001:2022 e ISO/IEC 27002:2022

ISO/IEC 27001:2022 no exige el modelado de amenazas por su nombre. Exige una evaluación de riesgos y un tratamiento de riesgos coherentes y documentados. El modelado de amenazas es uno de los métodos más sólidos para generar esas evidencias en entornos de software, nube y producto.

La clave es la trazabilidad. En ZB, la fase de gestión de riesgos, paso 13, recomienda mapear controles con riesgos y cláusulas, incluidas referencias al Anexo A en los planes de tratamiento, y señalar dónde los controles dan soporte a GDPR, NIS2 o DORA.

Zenith Controls: guía de cumplimiento cruzado [ZC] ayuda a estructurar esa trazabilidad mediante el mapeo de controles de ISO/IEC 27002:2022 con controles relacionados, expectativas de auditoría y marcos externos.

Para el modelado de amenazas, el control 5.8 de ISO/IEC 27002:2022, Seguridad de la información en la gestión de proyectos, es el anclaje de gobernanza de proyectos. Demuestra que la seguridad se integra en el inicio, la planificación, la ejecución y la aceptación del proyecto.

El control 8.25, Ciclo de vida de desarrollo seguro, es el anclaje del SDLC. ZC conecta 8.25 con controles de apoyo como 8.26 requisitos de seguridad de las aplicaciones, 8.27 arquitectura segura del sistema y principios de ingeniería, 8.28 codificación segura, 8.29 pruebas de seguridad en desarrollo y aceptación, 8.30 desarrollo externalizado y 8.31 separación de entornos de desarrollo, prueba y producción.

Este mapeo ayuda a convertir un taller de diseño en evidencias de la Declaración de Aplicabilidad. También respalda las cláusulas 4 a 6 de ISO/IEC 27001:2022 porque los requisitos de las partes interesadas, el alcance del SGSI, los compromisos de liderazgo y las decisiones de tratamiento de riesgos quedan visibles.

Un mapa de cumplimiento cruzado para NIS2, DORA, CRA, GDPR y NIST CSF

Un modelo de amenazas bien ejecutado no debería producir cinco líneas de trabajo de cumplimiento desconectadas. Debería producir un único paquete de evidencias de riesgo de diseño reutilizable entre marcos.

NIST CSF 2.0 es especialmente útil para la comunicación con la alta dirección. Su función GOVERN respalda obligaciones legales, regulatorias, contractuales y de privacidad, mientras que sus resultados de cadena de suministro ayudan a conectar criticidad de proveedores, requisitos contractuales, diligencia debida, supervisión y planificación de incidentes con las mismas evidencias del modelo de amenazas.

GDPR requiere atención especial porque el trabajo de modelado de amenazas y EIPD debe reforzarse mutuamente. La P17 Política de Protección de Datos y Privacidad [P17] establece:

“El modelado de amenazas y las Evaluaciones de Impacto relativas a la Protección de Datos (EIPD) son obligatorios para sistemas de tratamiento de alto riesgo.”
De la sección “Requisitos de implementación de la política”, cláusula de la política 6.3.4.

Para equipos más pequeños, la P17S Política de Protección de Datos y Privacidad - pyme [P17S] establece:

“La privacidad desde el diseño y por defecto debe aplicarse en todos los sistemas y servicios nuevos.”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.3.1.

El resultado es un modelo operativo práctico: usar los mismos diagramas de flujo de datos, límites de confianza y casos de abuso para el riesgo de seguridad, el riesgo de privacidad, la revisión de proveedores y la evidencia regulatoria.

Un sprint de 90 minutos sobre riesgo de diseño para funcionalidades de alto riesgo

El modelado de amenazas no tiene que empezar como un programa pesado. Para una nueva API de pagos, un flujo de alta, una funcionalidad habilitada por IA, un servicio de identidad, una migración a la nube o una integración externa, un sprint de 90 minutos sobre riesgo de diseño puede producir evidencias valiosas.

1. Abrir un punto de control de seguridad del proyecto

Use la cláusula 6.1.1 de P24 como desencadenante. Para cada nueva aplicación o cambio mayor, cree una carpeta de evidencias con:

• Diagrama de arquitectura
• Diagrama de flujo de datos
• Mapa de límites de confianza
• Lista de activos
• Notas sobre datos personales
• Lista de dependencias de proveedores y TIC
• Requisitos iniciales de seguridad
• Hoja de trabajo del modelo de amenazas
• Entradas del registro de riesgos
• Trazabilidad de mitigaciones y pruebas
• Registro de aprobación

Para organizaciones más pequeñas, la P24S Política de Desarrollo Seguro - pyme [P24S] respalda la misma disciplina al vincular los procesos de desarrollo seguro con el control de acceso de desarrolladores, las pruebas, el modelado de amenazas y la documentación. También exige la conservación centralizada de listas de comprobación, aprobaciones de revisión, informes de pruebas e inventarios de componentes con fines de auditoría. La cláusula 11.3.1 referencia SA-3 a SA-15 para definir procesos de desarrollo seguro, incluido el modelado de amenazas.

2. Dibujar el flujo de datos mínimo viable

No empiece con un diagrama pulido. Empiece con los flujos que crean riesgo:

• El usuario carga documentos de identidad o datos de transacciones.
• La aplicación web envía solicitudes a la API.
• La API escribe en almacenamiento gestionado o en una base de datos.
• El proveedor recibe datos de verificación o analítica.
• El portal interno de analistas muestra resultados.
• El sistema del cliente recupera estados o decisiones.
• Los registros de eventos, las herramientas de supervisión y las copias de seguridad reciben copias.

Marque cada límite de confianza: de internet a la aplicación, de la aplicación a la API, del servicio interno al proveedor, del sistema de producción a la analítica, del administrador a la función privilegiada y de producción a un entorno no productivo.

3. Ejecutar STRIDE y casos de abuso conjuntamente

Para cada límite, formule las preguntas de STRIDE y redacte casos de abuso en lenguaje de negocio claro. El objetivo no es enumerar todos los ataques imaginables. El objetivo es identificar escenarios plausibles y sustanciales que afecten a la confidencialidad, la integridad, la disponibilidad, la privacidad, la resiliencia o la seguridad física.

4. Convertir hallazgos en escenarios de riesgo

Use la fórmula del paso 9 de ZB:

“[Amenaza] explota [vulnerabilidad] en [activo], lo que da lugar a [impacto].”

Por ejemplo:

“Un atacante explota controles de acceso débiles en el almacenamiento de objetos del repositorio de documentos de identidad, lo que da lugar a una divulgación no autorizada de datos personales y exposición a notificaciones regulatorias.”

Después añada propietario, probabilidad, impacto, riesgo inherente, opción de tratamiento, control objetivo, riesgo residual y evidencias.

5. Derivar requisitos y pruebas

Un modelo de amenazas no termina cuando se listan los riesgos. Termina cuando las mitigaciones se han implantado, probado o aceptado formalmente.

La Política de Gestión de Cambios - pyme proporciona un desencadenante práctico:

“Si un cambio implica datos sensibles, derechos de acceso al sistema o integraciones externas, se requiere una revisión del impacto en la seguridad. El responsable designado de seguridad o cumplimiento debe evaluar si el cambio introduce riesgos adicionales y recomendar salvaguardas adicionales.”
De la sección “Tratamiento de riesgos y excepciones”, cláusula de la política 7.5.1.

Los datos sensibles, los derechos de acceso y las integraciones externas son precisamente los cambios que exigen una revisión del riesgo de diseño.

Qué preguntarán los distintos auditores

Un auditor de ISO/IEC 27001:2022 preguntará si el modelado de amenazas forma parte de un proceso definido de evaluación de riesgos, si los criterios son coherentes, si los propietarios del riesgo aprobaron los riesgos residuales, si los planes de tratamiento se vinculan con la SoA y si se conservan evidencias. Buscará repetibilidad, historial de versiones, visibilidad en la revisión por la dirección y cobertura de auditoría interna.

Respecto del Anexo A, conectará sus evidencias con 5.8, 8.25, 8.26, 8.27 y 8.29. El paso 21 de ZB, Controles en acción, destaca la arquitectura segura del sistema y los principios de ingeniería preguntando qué principios guían la arquitectura segura. Los auditores pueden preguntar si el modelado de amenazas se realiza durante el diseño mediante métodos como STRIDE o árboles de ataque, y si las decisiones arquitectónicas se revisan antes de la implantación.

Un revisor de NIS2 se centrará en la gobernanza y la proporcionalidad. Puede preguntar si la dirección aprobó el enfoque de gestión del riesgo de ciberseguridad, si se cubren la adquisición, desarrollo y mantenimiento seguros, si se consideran las vulnerabilidades de proveedores, si los escenarios de incidentes se vinculan a flujos de trabajo de notificación y si se analizan escenarios de continuidad. La notificación escalonada del Article 23 de NIS2 para incidentes significativos, incluida la alerta temprana en 24 horas, la notificación en 72 horas y un informe final en el plazo de un mes, hace que la claridad de escenarios sea especialmente valiosa.

Un examinador de DORA se centrará en la gobernanza del riesgo de las TIC, las funciones críticas, los activos de TIC, las dependencias externas, las pruebas de resiliencia y los servicios de terceros de TIC. Si el sistema respalda una función crítica o importante, esperará evidencias más sólidas que vinculen escenarios de amenazas con inventarios de activos, mapas de dependencias, planes de prueba, contratos con terceros y medidas de recuperación.

Un revisor de privacidad inspeccionará los flujos de datos y preguntará si el tratamiento de datos personales es necesario, lícito, minimizado y protegido. Preguntará si intervienen categorías especiales de datos, si se utiliza seudonimización o cifrado, si la conservación está justificada y si se requiere una EIPD. El modelado de amenazas y la EIPD son actividades distintas, pero deben compartir diagramas, escenarios y mitigaciones.

Un revisor orientado a NIST CSF o COBIT 2019 buscará gobernanza, propiedad del proceso, desempeño, responsabilidad proactiva y mejora continua. Puede darle menos importancia a la hoja de trabajo STRIDE en sí y más a si el proceso es fiable, medido, aprobado y mejorado.

Fallos comunes en las evidencias de modelado de amenazas

Los fallos más comunes no son técnicos. Son fallos de evidencia.

Los equipos realizan el modelado de amenazas demasiado tarde, después de que el sistema ya esté construido. En ese momento, el taller se convierte en una sesión informativa previa a la prueba de penetración en lugar de un control de diseño.

Los hallazgos no se convierten a lenguaje de riesgo. “Añadir autenticación” o “problema de registro de eventos” puede ayudar a los ingenieros, pero los auditores necesitan activo, amenaza, vulnerabilidad, impacto, propietario, tratamiento y riesgo residual.

La privacidad y la seguridad se separan. Un equipo documenta riesgos de suplantación e inyección mientras otro documenta conservación y base jurídica. La responsabilidad proactiva de GDPR funciona mejor cuando los flujos de datos, los casos de abuso y los criterios de activación de EIPD están conectados.

Los supuestos sobre proveedores permanecen sin documentar. NIS2, DORA y NIST CSF elevan las expectativas sobre el riesgo de la cadena de suministro de TIC. Si una mitigación depende del cifrado, registro de eventos, supresión, resiliencia o respuesta a incidentes de un proveedor, recopile las evidencias.

Las pruebas no se mapean de vuelta con las amenazas. Un informe de prueba de penetración puede ser útil, pero puede no demostrar que los riesgos de diseño específicos fueron mitigados. Cada hallazgo de amenaza importante debe contar con evidencia de validación.

La aceptación del riesgo residual es informal. “Aceptamos esto para el MVP” no basta. ISO/IEC 27001:2022 espera aceptación del riesgo residual por los propietarios de riesgo adecuados como información documentada.

Su paquete de evidencias de modelado de amenazas para 2026

Para cada sistema principal o cambio significativo, mantenga un paquete estándar de evidencias que pueda respaldar ISO 27001, NIS2, DORA, CRA, GDPR y el aseguramiento ante clientes.

La Política de Gestión de Riesgos - pyme captura bien el modelo operativo:

“Garantiza que la gestión de riesgos sea un componente activo de la planificación, la ejecución de proyectos, la selección de proveedores y la respuesta a incidentes, en consonancia con ISO 27001, ISO 31000 y los requisitos regulatorios aplicables.”
De la sección “Finalidad”, cláusula de la política 1.2.

Ese es el objetivo correcto. El modelado de amenazas debe influir en la planificación, la ingeniería, la selección de proveedores, la respuesta a incidentes y la preparación para auditorías.

Prepare el modelado de amenazas para auditoría antes de su próxima liberación

Las organizaciones que gestionarán mejor la presión de cumplimiento de 2026 no serán las que tengan más diagramas. Serán las que puedan demostrar una cadena sencilla:

Se identificó el riesgo de diseño. Se evaluó el riesgo. Se seleccionaron controles. Se implantaron mitigaciones. Las pruebas validaron las mitigaciones. Se aprobó el riesgo residual. Las evidencias se mapean con los marcos relevantes.

Empiece con un cambio de alto riesgo: una integración de pagos, una nueva API, un flujo de trabajo habilitado por IA, una funcionalidad de identidad, una migración a la nube, una liberación de producto orientado al cliente o un servicio conectado a proveedores. Ejecute un sprint de 90 minutos sobre riesgo de diseño. Use ZB para convertir hallazgos en escenarios de riesgo, planes de tratamiento y trazabilidad de la SoA. Use ZC para mapear controles de ISO/IEC 27002:2022 como 5.8, 8.25, 8.26, 8.27 y 8.29 con controles de apoyo, riesgo de proveedores, privacidad, pruebas y evidencias de auditoría. Alinee P24, P06, P17, P24S y su procedimiento de gestión de cambios para que el modelado de amenazas sea obligatorio, repetible y revisable.

Si quiere que Clarysec le ayude, empiece con una revisión de evidencias de modelado de amenazas. Evaluaremos un proyecto real, identificaremos deficiencias frente a las expectativas de ISO/IEC 27001:2022, NIS2, DORA, CRA y GDPR, y le proporcionaremos una hoja de ruta práctica de remediación que sus ingenieros, auditores y consejo de administración puedan entender.