Guía · Ciberseguridad · DORA
Seguridad de aplicaciones bajo DORA: SAST, DAST, SBOM y ciclo de vida seguro en banca y seguros
DORA (Reglamento (UE) 2022/2554) se aplica desde el 17 de enero de 2025 y convierte la seguridad del software en una obligación supervisada: las entidades financieras deben identificar, proteger, detectar y probar los sistemas TIC que sostienen sus funciones críticas o importantes, y demostrarlo con evidencia. Esta guía traduce esas obligaciones a prácticas concretas de seguridad de aplicaciones (SAST, DAST, SBOM, gestión de secretos, pruebas de resiliencia) y explica cómo las integramos en el ciclo de vida del software de bancos y aseguradoras.
No es asesoramiento legal: es una guía operativa para CISO, CTO, responsables de desarrollo y cumplimiento. Referencias normativas verificadas el 15 de septiembre de 2026; las obligaciones concretas dependen del tipo de entidad y de la criticidad de cada función.
Qué exige DORA al software y dónde lo dice
DORA no nombra herramientas ni metodologías: fija resultados. Su marco de gestión del riesgo relacionado con las TIC (artículos 5 a 16) obliga a inventariar los activos, protegerlos, detectar anomalías y recuperarse; el capítulo de incidentes (artículos 17 a 23) exige clasificar y notificar; el de pruebas de resiliencia operativa digital (artículos 24 a 27) exige un programa de pruebas anual; y el de terceros (artículos 28 a 30) extiende todo lo anterior al software y a los servicios que la entidad compra.
El Reglamento Delegado (UE) 2024/1774, que desarrolla el marco de gestión del riesgo TIC, baja al detalle que interesa a un equipo de desarrollo: la política de proyectos TIC debe cubrir la adquisición, el desarrollo y el mantenimiento de los sistemas, todos los requisitos, incluidos los de seguridad, deben probarse antes de aprobar el paso a producción, y los resultados de las pruebas de seguridad deben seguirse y traducirse en medidas actualizadas sin demora indebida cuando el sistema sostiene una función crítica o importante.
- Artículo 8 — identificación: inventario de activos TIC, dependencias y funciones que sostienen, mantenido al día.
- Artículo 9 — protección y prevención: políticas de seguridad, gestión de parches y actualizaciones, segmentación y control de accesos.
- Artículo 10 — detección: mecanismos de detección de anomalías con umbrales de alerta y monitorización continua.
- Artículo 11 — respuesta y recuperación: planes de continuidad TIC y de recuperación probados.
- Artículos 24 y 25 — pruebas: programa anual que incluye, entre otras, evaluación y escaneo de vulnerabilidades, análisis de código abierto, revisiones de código fuente cuando sea viable, pruebas basadas en escenarios, pruebas de extremo a extremo y pruebas de penetración.
- Artículo 26 — TLPT: pruebas de penetración guiadas por amenazas (marco TIBER-EU) al menos cada tres años para las entidades que designe la autoridad.
- Artículos 28 a 30 — terceros: el software y los servicios TIC contratados entran en el mismo marco, con cláusulas contractuales mínimas y registro de acuerdos.
De la norma a la práctica: nueve controles de seguridad de aplicaciones
Estos son los controles que cubren las obligaciones anteriores en un ciclo de vida de software moderno. El orden importa: cada uno genera la evidencia que el siguiente necesita y que el supervisor pedirá.
1. Inventario y clasificación por función crítica
Cada aplicación, servicio y componente vinculado a la función de negocio que sostiene y a su criticidad. Sin esto no se puede priorizar ni justificar el alcance de las pruebas (artículo 8).
2. Modelado de amenazas en el diseño
Antes de escribir código: qué activos maneja la aplicación, quién puede atacarla y por dónde. Es el control más barato y el que más defectos evita; alimenta los requisitos de seguridad que el RTS exige probar.
3. SAST en cada cambio de código
Análisis estático integrado en el pipeline, con puertas que bloquean el paso a producción por severidad. Es la forma práctica de cumplir la revisión de código fuente que DORA pide «cuando sea viable» (artículo 25) y de dejar rastro de cada hallazgo y su corrección.
4. SCA y SBOM: la cadena de suministro del software
Inventario de componentes de terceros (SBOM) y análisis de composición para conocer sus vulnerabilidades a lo largo del tiempo. Cubre el riesgo de terceros de los artículos 28 a 30 y la seguridad de la cadena de suministro que también exige NIS2.
5. Gestión de secretos e infraestructura como código
Ningún secreto en repositorios ni en imágenes; credenciales rotadas y gestionadas centralmente; la infraestructura declarada en código y analizada como el propio software (artículo 9).
6. DAST y pruebas de penetración antes de producción
Pruebas dinámicas contra el entorno de preproducción en cada versión relevante y pentest planificado dentro del programa anual (artículos 24 y 25). Los hallazgos entran en el mismo flujo de corrección que los de SAST.
7. Gestión de vulnerabilidades con plazos por criticidad
Un único registro de vulnerabilidades (código, componentes, infraestructura) con plazos de corrección según severidad y criticidad de la función, y evidencia del parcheo (artículo 9).
8. Registro, detección y respuesta
Logs centralizados, detección continua (SIEM/SOC) y manuales de respuesta ensayados (artículos 10 y 11). Los incidentes graves se clasifican y notifican a la autoridad en los plazos de las normas técnicas de DORA: notificación inicial en horas, informe intermedio y final después.
9. Pruebas de resiliencia y TLPT
Programa anual documentado para todos los sistemas críticos o importantes (artículo 24) y, para las entidades designadas, pruebas guiadas por amenazas cada tres años (artículo 26), con los hallazgos incorporados al plan de remediación.
Solapamientos útiles: NIS2 e ISO/IEC 27001
Para las entidades financieras DORA es la norma sectorial y prevalece sobre NIS2 (Directiva (UE) 2022/2555) en lo que regula, pero conviene conocer ambas: NIS2 aplica a otras empresas del grupo y a muchos proveedores, y su artículo 21 enumera medidas que coinciden punto por punto con los controles anteriores: seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas, gestión y divulgación de vulnerabilidades, seguridad de la cadena de suministro, criptografía, control de accesos y autenticación multifactor.
ISO/IEC 27001:2022 es la forma más eficiente de ordenar la evidencia: los controles del Anexo A sobre ciclo de vida de desarrollo seguro, requisitos de seguridad de aplicaciones, arquitectura segura, codificación segura, pruebas de seguridad en desarrollo y aceptación, desarrollo externalizado y separación de entornos (8.25 a 8.31) son exactamente lo que un inspector de DORA quiere ver documentado. Vermont Solutions opera bajo certificación ISO/IEC 27001:2022.
Checklist de doce puntos para el CISO y el CTO
- Inventario de aplicaciones vinculado a funciones críticas o importantes, revisado al menos cada año.
- Requisitos de seguridad definidos por aplicación y probados antes de cada paso a producción.
- SAST con puertas de calidad en el pipeline y evidencia de corrección por hallazgo.
- SBOM generado en cada build y análisis de composición con alertas de vulnerabilidades nuevas.
- Gestión centralizada de secretos y escaneo de infraestructura como código.
- DAST en preproducción y pentest anual documentados dentro del programa de pruebas.
- Registro único de vulnerabilidades con plazos de corrección por severidad y criticidad.
- Logs centralizados, detección continua y manuales de respuesta ensayados.
- Procedimiento de clasificación y notificación de incidentes graves con plazos y responsables.
- Cláusulas de seguridad, auditoría y salida en los contratos de software y servicios TIC.
- Programa anual de pruebas de resiliencia aprobado por la dirección y, si procede, TLPT planificado.
- Evidencia de todo lo anterior generada por el propio proceso, no recopilada a mano antes de la inspección.
Cómo lo hacemos en Vermont Solutions
Integramos los controles en el pipeline de entrega de la entidad, no en un proyecto aparte: SAST, análisis de composición y SBOM en cada build, DAST en preproducción, gestión de secretos y análisis de infraestructura como código, con puertas de calidad que dejan evidencia automática. Diseñamos modelos de identidad de mínimo privilegio (IAM/PAM, Zero Trust) y desplegamos visibilidad y detección continuas (SIEM/SOC) con procesos de respuesta alineados con la continuidad del negocio.
Trabajamos sobre plataformas críticas de banca y seguros que no pueden detenerse (cores heredados, grids de cálculo, Kubernetes híbrido) y bajo certificación ISO/IEC 27001:2022. En una aseguradora europea, el refuerzo de accesos (MFA en roles críticos y retirada de protocolos heredados) elevó la puntuación de seguridad de Microsoft 365 un 30 % sobre una base del 11,48 % sin fricción para los usuarios.
Preguntas frecuentes
¿DORA obliga a hacer SAST y DAST?
No nombra herramientas. Exige probar los requisitos de seguridad antes de producción, revisar el código fuente cuando sea viable y hacer pruebas de penetración dentro de un programa anual. SAST y DAST son la forma práctica y trazable de cumplirlo.
¿Cada cuánto hay que hacer pruebas de seguridad?
El programa de pruebas de resiliencia operativa digital es anual para los sistemas que sostienen funciones críticas o importantes (artículo 24), con evaluación de vulnerabilidades y pruebas de penetración dentro de él. Las entidades designadas por su autoridad hacen además pruebas guiadas por amenazas (TLPT) al menos cada tres años (artículo 26).
¿Qué pasa con el software que compramos a terceros?
Entra en el mismo marco: los artículos 28 a 30 exigen debida diligencia, cláusulas contractuales mínimas (seguridad, auditoría, incidentes, salida) y registro de acuerdos. En la práctica se cubre con SBOM, análisis de composición y cláusulas de seguridad en los contratos.
¿NIS2 también aplica a un banco o a una aseguradora?
Para las entidades financieras DORA es la norma sectorial y prevalece en lo que regula. NIS2 sigue siendo relevante para otras empresas del grupo y para muchos proveedores, y sus medidas del artículo 21 coinciden con los controles de esta guía.
¿Qué plazos hay para notificar un incidente grave?
Las normas técnicas de DORA fijan una notificación inicial en pocas horas desde la clasificación del incidente como grave, un informe intermedio a los pocos días y un informe final aproximadamente al mes. Los plazos exactos dependen de la norma técnica vigente y de la autoridad competente; el procedimiento interno debe fijarlos con nombres y horas.
Assessment de seguridad de aplicaciones bajo DORA
Revisamos su inventario de aplicaciones críticas, el pipeline de entrega y la evidencia disponible, y le entregamos el plan de controles con responsables y plazos. Sin cambiar nada en producción hasta que el plan esté aprobado.
Solicitar assessment →Contenido relacionado
Última actualización: 2026-09-15. Contenido editorial de Vermont Solutions, citable bajo atribución con enlace a esta página. No constituye asesoramiento legal.