DORA coloca la supervisión del marco de riesgo TIC en el nivel de dirección.
No para que el consejo configure sistemas. Para que gobierne las decisiones que dependen de ellos.
Qué decisiones de riesgo TIC pertenecen a dirección y cuáles se delegan operativamente.
Qué información recibe, con qué frecuencia y qué decisiones quedan registradas.
Que riesgos, desviaciones y acciones relevantes llegan a un nivel con autoridad para decidir.
| Clave | Qué revisar | Qué debería demostrar |
|---|---|---|
| DIR-01 | Funciones críticas con exposición relevante | Qué decisión se pide y qué impacto podría materializarse. |
| DIR-02 | Riesgo de concentración TIC | Proveedor, servicios dependientes, alternativas y estrategia de salida. |
| DIR-03 | Incidentes y tendencias | Severidad, causa, servicios afectados y aprendizaje. |
| DIR-04 | Pruebas de resiliencia | Hallazgos, cobertura, retrasos y acciones correctivas. |
| DIR-05 | Excepciones y riesgo residual | Qué se acepta, por quién, hasta cuándo y con qué compensación. |
| Ref. | Evidencia | Qué debería demostrar |
|---|---|---|
| DG-01 | Términos de referencia y roles | Quién decide, supervisa, ejecuta y controla el riesgo TIC. |
| DG-02 | Actas y decisiones | Qué riesgos y acciones han sido conocidos y aprobados. |
| DG-03 | Cuadro de mando TIC | Tendencias, umbrales, excepciones y capacidad de recuperación. |
| DG-04 | Formación de dirección | Contenido relacionado con riesgo TIC y modelo de negocio. |
| DG-05 | Seguimiento de acciones | Responsables, fechas, escalado y cierre verificable. |
| DG-06 | Revisión del marco | Cambios introducidos tras incidentes, pruebas o cambios relevantes. |
DORA no convierte al consejo en un equipo técnico, pero sí exige que sus decisiones sobre riesgo TIC sean informadas, trazables y coherentes con la estrategia de negocio. Aprobar una política anual no basta. El órgano de dirección debe entender qué funciones son críticas, qué exposiciones se aceptan, qué inversiones se aplazan y qué dependencia existe de proveedores o tecnologías difíciles de sustituir.
Una buena agenda de gobierno no debería empezar por el número de vulnerabilidades. Debería empezar por decisiones: qué servicio puede detenerse, qué riesgo supera el apetito aprobado, qué excepción lleva demasiado tiempo abierta, qué proveedor concentra una capacidad esencial y qué prueba de recuperación ha fallado. La información técnica debe llegar resumida, pero sin perder la relación con la evidencia.
También es importante separar tres niveles. El primero es la supervisión: conocer el estado y exigir explicación. El segundo es la decisión: aprobar estrategia, presupuesto, tolerancia y prioridades. El tercero es la verificación: confirmar que las medidas acordadas se implantaron y que las desviaciones se cerraron. Cuando estos niveles se mezclan, el comité recibe información, pero nadie asume la decisión.
| Decisión | Información mínima | Evidencia de gobierno |
|---|---|---|
| Aceptar riesgo | Escenario, impacto, duración, control compensatorio y fecha límite. | Acta, propietario, condición de aceptación y revisión programada. |
| Priorizar inversión | Función afectada, exposición, dependencia y alternativa disponible. | Presupuesto aprobado, roadmap y criterio de priorización. |
| Autorizar excepción | Motivo, alcance, riesgo residual y monitorización reforzada. | Excepción firmada, caducidad y evidencia de seguimiento. |
| Escalar proveedor | Servicio crítico, incumplimiento, concentración y capacidad de salida. | Plan de remediación, comunicación contractual y decisión de continuidad. |
Un sistema legacy que procesa operaciones críticas no puede actualizarse porque el fabricante dejó de certificar nuevas versiones. El equipo técnico mantiene EDR, segmentación y monitorización reforzada. Durante meses, el cuadro de mando muestra la excepción como un dato operativo más, sin cuantificar qué función depende del sistema ni cuánto costaría su sustitución.
La cuestión para el órgano de dirección no es si falta un parche. La cuestión es si acepta mantener una función crítica sobre una plataforma sin soporte, durante cuánto tiempo, con qué controles compensatorios y con qué plan de salida. Para decidir necesita conocer impacto potencial, probabilidad de explotación, capacidad de detección, tiempo de recuperación, dependencia de personal clave y coste de modernización.
La evidencia correcta incluiría la decisión formal, el riesgo residual, la fecha de revisión, el presupuesto o iniciativa asociada y las condiciones que obligarían a adelantar la sustitución. Así se demuestra gobierno: no escondiendo la deuda técnica, sino convirtiéndola en una decisión consciente y revisable.
Si un indicador empeora durante tres comités y no cambia presupuesto, prioridad, responsable o tratamiento, probablemente no es un mecanismo de gobierno.
Empezaría por seleccionar tres decisiones recientes: una inversión, una excepción y un incidente relevante. Para cada una reconstruiría qué información recibió el órgano de dirección, qué alternativas se presentaron, qué decisión adoptó y cómo se verificó su ejecución.
Después revisaría si los indicadores tienen umbral y consecuencia. Un KPI sin criterio de escalado solo informa; no gobierna. También comprobaría que los responsables de negocio participan en riesgos que afectan a sus funciones y que la formación del órgano de dirección no se limita a una sesión genérica anual.
Por último, contrastaría actas, presupuestos, registro de riesgos y planes técnicos. Si el comité declara prioridad alta, pero el presupuesto no cambia y la excepción sigue renovándose, existe una diferencia entre gobierno declarado y gobierno real.
La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.
En DORA y el órgano de dirección: el riesgo TIC ya no se puede delegar, el análisis debería cubrir al menos servicios financieros, acuerdos contractuales, funciones TIC, proveedores directos, subcontratistas, países de prestación, criticidad y dependencia. Esto exige coordinar a Dirección, Riesgo TIC, Continuidad, Seguridad, Operaciones, Compras, Legal y propietarios del servicio y trabajar sobre servicios, funciones TIC, contratos, proveedores, subcontratistas, ubicaciones, datos, dependencias y estrategias de salida. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.
Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.
Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.
La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.
| Dimensión | Qué debe quedar definido | Evidencia esperada |
|---|---|---|
| Alcance | Procesos, servicios, sistemas y terceros incluidos en «DORA y el órgano de dirección: el riesgo TIC ya no se puede delegar». | Alcance aprobado, inventario y exclusiones justificadas. |
| Responsabilidad | Quién decide, ejecuta, valida y acepta desviaciones. | RACI, actas, aprobaciones y propietarios nominativos. |
| Operación | Actividades repetibles, entradas, salidas, plazos y escalados. | Procedimiento, tickets, registros, alertas y métricas. |
| Eficacia | Cómo se comprueba que el control cambia el riesgo o el resultado. | Pruebas, tendencias, incidencias, muestreo y acciones. |
Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.
El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.