Recover y mejora continua

Recover agrupa dos cosas: ejecutar la parte de recuperación del plan de respuesta una vez que la inicia el proceso de respuesta (RC.RP-01) y comunicar la recuperación (RC.CO). Para decidir cuándo empezar, el marco tiene un resultado en Respond: se aplican los criterios para iniciar la recuperación (RS.MA-05).

La Rev 3 recomienda empezar los procedimientos de recuperación durante o después de la respuesta, no necesariamente cuando todo lo demás terminó. Y describe ejecutar el plan como seleccionar, priorizar y hacer acciones de forma segura, verificar la integridad de lo recuperado, declarar el fin de la recuperación y completar la documentación.

Abre cronologia-de-recuperacion.csv. Cuatro sistemas se restauraron tras el incidente del 3 de diciembre. Uno de ellos se dio por restaurado sin que nadie verificara la integridad de lo restaurado, que es el paso que evita volver a poner en producción algo dañado o manipulado.

La categoría Improvement de Identify nombra de dónde sale una mejora: ID.IM-01, de evaluaciones (autoevaluaciones, evaluaciones de terceros, auditorías independientes); ID.IM-02, de pruebas y ejercicios, también con proveedores; ID.IM-03, de la ejecución de los procesos reales; e ID.IM-04 es el resultado que cuida que los planes de respuesta se mantengan y se mejoren. Están en mejora-id-im.txt.

Ahora lee acciones-de-mejora.csv: cada acción trae su origen. Una sola nace de una evaluación del programa.

En el incidente de Nereo, la acción M1 (anotar quién puede ordenar desconectar un servidor) nació de la retrospectiva del incidente de agosto y sigue abierta con su fecha límite vencida. Una lección que tarda más de lo que dura una crisis en convertirse en un cambio escrito no se ha aprendido todavía: se ha anotado.

La fecha de esta revisión está en lee-primero.txt: el 10 de diciembre de 2026. Cuenta las acciones de la lista que siguen abiertas y cuya fecha límite ya pasó. Una acción cerrada no cuenta, ni una abierta que todavía está en plazo.