El marco de gestión del riesgo TIC

El marco empieza por saber qué hay que proteger. DORA habla de funciones críticas o importantes: aquellas cuya interrupción deterioraría de forma material los resultados financieros, la solidez o la continuidad de los servicios de la entidad. La marca no la decide el área que usa la función, la decide la entidad con un criterio escrito, y de ella depende casi todo lo demás: pruebas más exigentes, contratos con más cláusulas, registro con más campos.

El marco exige identificar y clasificar las funciones y los activos que las soportan. La prueba más simple es cruzar dos listas: los sistemas que dice usar cada función y los que figuran en el inventario. Un sistema que sostiene una función crítica y no está inventariado no tiene dueño, ni clasificación, ni copias planificadas.

Abre funciones y inventario_de_activos.

El marco no es un solo documento: es un conjunto de elementos que cubren desde la estrategia hasta el aprendizaje tras un incidente. El comité de riesgos de Nimbora los revisa en una tabla de ocho. Un elemento en borrador está en camino; un elemento sin ningún documento ni siquiera ha empezado, y es el primero que debe subir.

Entre los elementos del marco están las copias de seguridad y la restauración. La política interna del banco, escrita en encargo, pide una restauración probada, con acta, al menos cada seis meses por sistema. Con el corte del 31 de marzo de 2027, esa fecha límite es el 30 de septiembre de 2026: una restauración anterior a ella ya no cuenta.

Un informe de copias que dice «ejecutadas sin error» prueba que el sistema copió, no que el banco pueda recuperarse. Lo que prueba la recuperación es haberla hecho: una restauración real, en un entorno de prueba, con su fecha, el sistema y el resultado.