DORA para Fintech: Requisitos Técnicos que tu Equipo Implementa Hoy (2026)

Tu fintech tiene licencia EMI, pasarela de pagos sobre AWS, una app móvil con dos millones de transacciones al mes y un panel de operaciones en producción desde hace tres años. DORA lleva en vigor desde el 17 de enero de 2025 y, aunque al principio sonaba a problema de bancos sistémicos, los plazos de reporting que está empezando a exigir el supervisor no admiten una foto anual: requieren evidencia continua. Esa evidencia se genera con tooling, no con PowerPoint, y el peso recae en tu equipo técnico.

Esta guía no vuelve a explicar qué es DORA — ya lo cubrimos en el post de DORA para sector financiero y seguros. Aquí asumimos que ya conoces los cinco pilares y entras directamente al problema operativo: qué evidencia espera el regulador, qué tooling la genera y qué procesos la sostienen. Cada pilar de DORA se traduce en una combinación de las tres cosas. Si te falta cualquiera de las tres, no estás cumpliendo — estás "preparando una respuesta" para cuando llegue la inspección, que es exactamente lo que DORA quiso evitar.

El público objetivo de este artículo es el CTO, el lead engineer o el responsable de DevSecOps de una fintech entre 20 y 300 personas. Si eres entidad significativa con TLPT obligatorio, lo que sigue es la base; tu programa va más allá. Si eres una EMI o startup de pagos pequeña, el principio de proporcionalidad de DORA te alivia el alcance pero no te exime de la mayoría de controles técnicos. La diferencia entre cumplir y no cumplir es operativa, no documental.

El cambio de mentalidad: de auditoría a evidencia continua

Antes de entrar en cada pilar, conviene fijar el cambio cultural que DORA impone sobre la forma en la que muchos equipos venían trabajando.

En el modelo tradicional, cumplimiento es un proyecto: se contrata una consultora, se prepara documentación durante tres meses, se pasa la auditoría y se vuelve a la operación normal hasta el año siguiente. Ese modelo funciona razonablemente bien para ISO 27001, donde la evidencia puntual es aceptable. Con DORA no funciona porque varios de sus requisitos son inherentemente continuos: una notificación inicial de un incidente grave en una ventana corta tras su clasificación (las RTS finales fijan plazos en horas, con la clasificación como referencia, no el momento del incidente en sí) no se prepara la semana antes de la auditoría; el inventario de proveedores TIC críticos no se "revisa anualmente" si firmas un contrato nuevo cada mes; las pruebas de seguridad sobre sistemas críticos no son anuales si despliegas a producción cinco veces al día.

Lo que los reguladores europeos esperan ver, aunque cada autoridad nacional matice cómo lo materializa, es un sistema en el que los controles generan evidencia automáticamente como subproducto de la operación. Tu pipeline de CI/CD ya emite logs de las pruebas que ejecutó. Tu CSPM ya guarda histórico de las desviaciones que detectó. Tu plataforma de monitorización ya registra cuándo se generó cada alerta y quién la atendió. La pregunta del regulador deja de ser "enséñame que hiciste el control X" y se convierte en "enséñame el histórico continuo del control X durante los últimos doce meses". Si tu respuesta requiere reconstruir manualmente esa evidencia, has perdido.

A partir de aquí, cada pilar se trata con la misma estructura: qué evidencia se espera, qué tooling la genera y qué procesos hacen falta para que la evidencia sea creíble.

Pilar 1: Gestión de riesgos TIC (Art. 5–16) en la práctica

El primer pilar es el más extenso y el más peligroso de subestimar, porque suena genérico ("marco de gestión de riesgos") pero se traduce en un conjunto de controles muy concretos sobre tu infraestructura.

Evidencia que espera el regulador. Un inventario de activos TIC vivo, con clasificación de criticidad, dependencias documentadas y propietarios asignados. Un mapa de protecciones técnicas (cifrado en reposo y en tránsito, control de acceso, segmentación de red) con evidencia de su estado actual, no solo del documento que dice cómo deberían estar configurados. Un programa de gestión de vulnerabilidades con SLAs de remediación medibles y trazabilidad de hallazgos a fixes. Y procedimientos de backup y recuperación probados — no solo definidos en un documento, sino con resultados de pruebas de restore reales y firmados.

Tooling que la genera. El inventario de activos TIC no se mantiene a mano. En una fintech cloud-native lo realista es combinar tres fuentes:

• Un inventario interno alimentado por la API del proveedor cloud (aws resourcegroupstaggingapi get-resources, GCP Cloud Asset Inventory, Azure Resource Graph), idealmente serializado en una tabla de configuración como código que regenera diariamente.
• Una capa de descubrimiento externo con Attack Surface Management que reconstruye la vista que tiene un atacante: subdominios, IPs, certificados, servicios expuestos. Esto importa especialmente en fintechs porque la tasa de cambio de infraestructura externa (nuevos endpoints de API, dominios de marketing, sandboxes para integradores) supera la capacidad de cualquier inventario manual.
• Una capa de postura de configuración mediante CSPM que verifica continuamente que el estado real de tu cloud cumple con un conjunto de reglas (CIS Benchmark, controles propios alineados con DORA).

Para los controles de protección técnica (cifrado, acceso, red), el patrón es el mismo: AWS Config con conformance packs, GCP Security Command Center, o equivalentes, generan evidencia diaria. La gestión de vulnerabilidades se sostiene con escaneo de infraestructura (Inspector, Trivy para contenedores), escaneo de aplicaciones (DAST) y escaneo de dependencias (npm audit, Dependabot, Renovate) integrados en CI.

Procesos que necesitas. Una política de clasificación de activos por criticidad firmada y aplicada (no solo escrita). SLAs de remediación de vulnerabilidades por severidad — orientativamente: críticas en 24–72 horas, altas en una semana, medias en un mes — con trazabilidad real desde el hallazgo hasta el commit que lo arregla. Y un calendario de pruebas de restore al menos trimestral para sistemas críticos, con acta firmada del resultado.

Pilar 2: Gestión de incidentes TIC (Art. 17–23) sin improvisar

El segundo pilar es donde más fintechs se rompen, porque las ventanas de tiempo son agresivas y solo se cumplen si la maquinaria está montada antes del incidente.

Evidencia que espera el regulador. Un procedimiento de clasificación de incidentes alineado con los criterios técnicos del reglamento (basado en número de clientes afectados, impacto económico, duración, alcance geográfico, impacto reputacional, criticidad de los servicios afectados, pérdida de datos). Un registro completo de incidentes TIC, no solo los graves. Notificaciones al supervisor dentro de los plazos: una inicial tras la clasificación como grave, una intermedia y una final con análisis de causa raíz. Y pruebas de que el procedimiento se ha probado en simulacros documentados, no solo descrito en un PDF.

Tooling que la genera. La parte de detección requiere tres capas conectadas. Primera, monitorización de infraestructura y aplicación: APM (Datadog, New Relic), logs centralizados (CloudWatch, GCP Cloud Logging, ELK), y métricas de negocio (transacciones rechazadas, latencias por encima de umbral, picos de errores 5xx). Segunda, monitorización de seguridad: GuardDuty / Security Command Center / Microsoft Defender for Cloud para señales nativas; Falco o Tetragon para runtime en Kubernetes; Wazuh u otro SIEM para correlación. Tercera, observabilidad de la postura externa: ASM detectando cambios no esperados en tu superficie expuesta (un puerto nuevo, un certificado que cambia, un subdominio que aparece) que pueden ser síntoma temprano de un compromiso.

Sobre esa base, una plataforma de incident management (PagerDuty, Opsgenie, FireHydrant, incident.io) registra el ciclo de vida completo: detección → triage → clasificación DORA → notificación → resolución → post-mortem. La clasificación DORA se puede modelar como un campo estructurado en la herramienta, evaluado por el on-call con una matriz simple. Lo importante es que el timestamp de cada paso quede registrado de forma inmutable.

1# severity-classification.yaml
2# Aplicado por on-call durante triage; trigger DORA major si se cumplen >= 2 de los criterios reforzados.
3
4incident:
5# --- Datos básicos ---
6detected_at: "2026-05-12T09:14:00Z"
7service: "payments-gateway"
8symptom: "5xx > 5% durante > 10 min en /v1/charges"
9
10# --- Criterios DORA (evaluación rápida) ---
11clients_affected_pct: 12          # > 10% → señal fuerte
12duration_minutes: 35              # > 30 min en servicio crítico → señal fuerte
13data_loss: false
14external_attack_suspected: true   # señal fuerte
15geographic_scope: ["ES", "PT"]
16economic_impact_eur: 18000        # umbral interno: 10k → señal media
17reputational_impact: "medio"      # cobertura en redes sociales detectada
18
19# --- Resultado ---
20dora_classification: "major"
21notify_supervisor: true
22notification_deadlines:
23  initial: "2026-05-12T13:30:00Z"     # ventana inicial post-clasificación
24  intermediate: "2026-05-15T09:30:00Z" # ventana intermedia
25  final: "2026-06-12T09:30:00Z"        # informe final con RCA
26on_call: "[email protected]"
27comms_lead: "[email protected]"

Los plazos exactos del reglamento se han ido detallando en estándares técnicos (RTS) elaborados por las ESA. Mantén los valores anclados a tu documento interno de procedimiento y cita el RTS aplicable en lugar de hardcodearlos en el runbook — los detalles temporales finos pueden afinarse vía estándares delegados. Lo importante es que la matriz exista, esté operativa y se ejecute en cada incidente.

Procesos que necesitas. Un calendario de simulacros (al menos uno por semestre, preferentemente uno por trimestre) con escenarios distintos: caída de proveedor cloud, incidente de seguridad con exfiltración, fallo de un proveedor crítico de pagos. Un on-call rotation con guardias firmadas y compensadas. Una plantilla de notificación al supervisor preaprobada por el equipo legal. Y un proceso de RCA estructurado (los "5 porqués" como mínimo, mejor con metodología tipo Causal Analysis) para cada incidente clasificado como significativo.

Pilar 3: Pruebas de resiliencia digital (Art. 24–27) en CI/CD

Aquí es donde el pilar técnico se cruza más directamente con tu pipeline de desarrollo. Las "pruebas de resiliencia" del reglamento son escaneo de vulnerabilidades, evaluaciones de seguridad de red, análisis de código fuente cuando es viable, pruebas de penetración y, para entidades significativas, TLPT (Threat-Led Penetration Testing).

Evidencia que espera el regulador. Un programa de pruebas con frecuencia definida según criticidad. Resultados archivados de cada ejecución, con trazabilidad a las acciones de remediación. Evidencia de que las pruebas cubren la totalidad de los sistemas críticos, no solo una muestra. Y, para sistemas que operan continuamente, evidencia de que el programa de pruebas también es continuo — no un pentest anual y silencio.

Tooling que la genera. Un programa moderno de pruebas para fintech tiene varias capas que conviven:

Lo crítico es la integración con CI/CD: SAST, SCA, container scanning e IaC scanning deben ejecutarse en cada PR, fallar el build cuando aparezca un hallazgo crítico nuevo y dejar el reporte como artefacto de la pipeline. Esto hace que cada deploy a producción venga acompañado automáticamente de la evidencia de las pruebas que pasó.

1# .github/workflows/security-gates.yml
2name: security-gates
3
4on:
5pull_request:
6push:
7  branches: [main]
8
9jobs:
10static-checks:
11  runs-on: ubuntu-latest
12  steps:
13    - uses: actions/checkout@v4
14    - name: SAST (Semgrep)
15      uses: returntocorp/semgrep-action@v1
16      with:
17        config: p/owasp-top-ten p/javascript p/secrets
18    - name: SCA (npm audit + license check)
19      run: |
20        npm audit --audit-level=high --json > audit.json || true
21        jq '.vulnerabilities | to_entries | map(select(.value.severity=="critical"))' audit.json
22    - name: IaC (Checkov)
23      uses: bridgecrewio/checkov-action@master
24      with:
25        directory: infra/
26        framework: terraform
27        quiet: true
28    - name: Container scan (Trivy)
29      uses: aquasecurity/trivy-action@master
30      with:
31        image-ref: ghcr.io/tufintech/payments-api:${{ github.sha }}
32        severity: CRITICAL,HIGH
33        exit-code: 1
34    - name: Archivar evidencia DORA
35      if: always()
36      uses: actions/upload-artifact@v4
37      with:
38        name: dora-evidence-${{ github.sha }}
39        path: |
40          audit.json
41          semgrep-report.json
42          checkov-report.json
43          trivy-report.json
44        retention-days: 365

La retención de 365 días en los artefactos no es casual: es lo mínimo razonable para defender frente a una solicitud de evidencia retrospectiva. En la práctica, archivos de evidencia se exportan también a un bucket inmutable (object lock activado, MFA delete) para retención más larga.

Los pentests manuales y, en su caso, los TLPT, no se sustituyen con automatización — la complementan. La automatización cubre superficie y regresión; el pentest cubre lógica de negocio y cadenas de explotación. Las dos son obligatorias en sistemas críticos.

Procesos que necesitas. Un documento de "alcance de pruebas" actualizado al menos anualmente que liste cada sistema crítico y la frecuencia de prueba aplicada. Un proceso de retest tras remediación, no solo de "issue cerrado". Y, si te aplica TLPT, un programa multi-año coordinado con la autoridad supervisora — el ejercicio dura meses y requiere preparación seria.

Pilar 4: Riesgo de terceros TIC (Art. 28 ss.; supervisión por las ESAs en Art. 31 ss.) cuando dependes de SaaS

Este pilar es el que más fricción genera con el día a día de una fintech moderna, porque el modelo operativo natural es "todo es SaaS": Stripe para pagos, Plaid o Tink para open banking, Twilio para mensajería, Datadog para observabilidad, Auth0 para autenticación, Cloudflare para edge, AWS para todo lo demás. DORA no prohíbe esto, pero exige rigor.

Evidencia que espera el regulador. Un registro de proveedores TIC clasificados por criticidad, con identificación clara de los críticos. Contratos con cláusulas DORA específicas (niveles de servicio, derechos de auditoría, obligaciones de notificación de incidentes, planes de salida, localización de datos). Evidencia de due diligence en el alta de cada proveedor. Y planes de salida documentados y, en lo posible, ensayados, especialmente para concentraciones de riesgo (un solo proveedor cloud para toda la operación crítica).

Tooling que la genera. Aquí el componente más útil es un registro de proveedores TIC mantenido como código, no como un Excel en SharePoint. Una opción concreta: un repositorio Git con un YAML por proveedor y un workflow que valida en cada PR que se cumplen los campos obligatorios (clasificación, criticidad, contrato vigente, fecha de última revisión, plan de salida documentado).

1# providers/aws.yaml
2provider:
3name: "Amazon Web Services EMEA SARL"
4category: "cloud-iaas"
5service: "Compute, storage, network, gestionados"
6criticality: "critical"
7data_processed:
8  - "PII clientes"
9  - "Datos de pagos (PCI scope)"
10data_location: ["eu-west-1 (Irlanda)", "eu-west-3 (París)"]
11contract:
12  signed: "2024-11-04"
13  renewal: "2027-11-04"
14  dora_addendum: "addenda/aws-dora-2025-02.pdf"
15  audit_rights: true
16  exit_clause_months: 12
17monitoring:
18  sla_uptime: 99.95
19  incident_notification_sla_hours: 1
20  last_incident_review: "2026-04-22"
21exit_plan:
22  document: "exit-plans/aws-multi-region-failover.md"
23  last_test: "2026-02-18"
24  rto_hours: 24
25  rpo_minutes: 15
26  tested: true
27reviewed:
28  by: "[email protected]"
29  on: "2026-04-30"
30  next_review: "2026-10-30"

A esto se añaden controles más operativos: alertas cuando un proveedor crítico tenga un incidente público (status pages monitorizadas con statuspal-cli o similar), revisión periódica de SOC 2 Type II / ISO 27001 / PCI DSS de cada proveedor crítico (idealmente con un workflow que avise cuando el último informe disponible tenga más de doce meses), y monitorización del riesgo de concentración (qué porcentaje de tu operación crítica depende de un único proveedor).

Procesos que necesitas. Un proceso de onboarding de proveedores TIC con due diligence documentada antes de firmar el contrato. Un calendario de revisiones (al menos anual para críticos, más espaciado para no críticos). Un procedimiento de offboarding con borrado verificado de datos. Y un comité (formal o informal pero recurrente) que revise el riesgo de concentración y aprueba excepciones explícitas cuando no es viable diversificar.

Pilar 5: Intercambio de información (Art. 45) sin sobreingeniería

El quinto pilar es voluntario y, para la mayoría de fintechs no significativas, no requiere infraestructura propia.

Evidencia que espera el regulador. Si decides participar en algún esquema de intercambio de inteligencia de amenazas, evidencia de la participación. Si no, este pilar no te genera carga.

Tooling que la genera. Suscripción a feeds de threat intelligence (gratuitos como AlienVault OTX, MISP comunitarios sectoriales, comerciales como Recorded Future), participación en grupos sectoriales (FS-ISAC para fintech a nivel global, equivalentes nacionales), o intercambio bilateral con otras entidades del sector. La integración técnica suele ser un consumo de IoCs (indicators of compromise) que se ingieren en tu SIEM.

Procesos que necesitas. Si participas, una política que defina qué información compartes, qué no, y bajo qué reglas (clasificación de datos, autorizaciones internas). Si no participas, una decisión documentada del por qué no — sirve como evidencia de que se ha evaluado.

Mapeo pilar → control técnico → evidencia

Para cerrar el cuerpo técnico, una vista compacta que conviene tener visible cuando se prepara una hoja de ruta:

Errores que vemos en cada implantación DORA

A estas alturas hemos visto suficientes pre-evaluaciones DORA como para identificar los patrones que se repiten. Te ahorras meses si los reconoces antes.

El "estamos cubiertos porque tenemos ISO 27001". ISO 27001 cubre buena parte de la base, sí — y lo trabajamos en la guía de controles técnicos ISO 27001 en cloud. Pero DORA va más allá en pruebas de resiliencia, plazos de notificación de incidentes y exigencias contractuales sobre proveedores. Estimar el delta requiere un gap analysis específico, no asumir paridad.

El inventario de proveedores incompleto. El listado de SaaS reales que usa una fintech moderna casi siempre supera al listado oficial en un 30–60%. Herramientas que el equipo de marketing contrató, integraciones que data engineering levantó "para una prueba", servicios gratuitos cuya cuenta nadie supervisa. El primer paso técnico útil es conectar a vuestro SSO (si lo tenéis bien adoptado), revisar el listado de aplicaciones autorizadas y cruzar con el registro oficial. La diferencia es la deuda.

Pipeline de pruebas que pasa siempre. Si tu CI nunca ha bloqueado un deploy por un hallazgo de seguridad, lo más probable es que las puertas estén configuradas en modo "warning" en lugar de "fail". Eso genera evidencia inútil para el regulador (artefactos sin acción) y deuda silenciosa.

Runbook de incidentes que nadie ha probado. El primer simulacro siempre revela que el on-call no sabe quién clasifica DORA, que la plantilla de notificación no está accesible fuera del Notion del CISO, que el proceso de escalado tarda más que el plazo inicial. Mejor descubrirlo en un viernes de simulacro que un sábado real.

Concentración cloud sin plan de salida real. Si todo está en una región de un solo proveedor, el plan de salida tiene que ser creíble. La pregunta del regulador no es "¿podríais salir si quisierais?" sino "¿en cuánto tiempo y con qué impacto?". Si no tenéis una estimación basada en pruebas, la respuesta no es defendible.

Cómo encaja Vulnerabbit en tu programa DORA

DORA no se compra: se opera. Pero buena parte de la evidencia continua que pide el regulador se genera con tooling que ya está consolidado.

La plataforma de Vulnerabbit para fintech cubre la capa que más esfuerzo manual evita: descubrimiento continuo de superficie de ataque (Pilar 1, gestión de activos), CSPM sobre AWS, GCP y Azure (Pilar 1, postura de configuración), DAST y API security testing integrables en CI/CD (Pilar 3, pruebas de resiliencia continuas), y monitorización de cambios externos en tu infraestructura que sirve como señal temprana de incidentes (Pilar 2, detección). La evidencia de cada uno se exporta en formato pensado para auditorías DORA, con histórico retenido durante toda la vida del workspace.

Para el resto de pilares — gestión de incidentes, registro de proveedores, simulacros, plan de salida — el patrón es el mismo: combinar tooling especializado con procesos disciplinados. Lo que aporta Vulnerabbit es eliminar la fricción técnica de los pilares más intensivos en datos para que tu equipo dedique el esfuerzo a los procesos que solo pueden hacer humanos.

¿Necesitas evidencia DORA continua sin reconstruirla cada trimestre?

La plataforma para fintech de Vulnerabbit automatiza el descubrimiento, la postura cloud y las pruebas continuas con evidencia exportable lista para tu próxima inspección DORA.

Lanzar escaneo gratuito → · Ver /solutions/fintech →