El runbook que usas a las tres de la madrugada, no el que le enseñas al auditor

Suele haber dos documentos. Uno es la política de respuesta a incidentes: veinte páginas, aprobada cada año, escrita para satisfacer un marco y jamás abierta durante un incidente. El otro es lo que la gente hace de verdad, que vive en la cabeza de tres ingenieros y cambia según quién esté despierto.

La distancia entre ambos es donde los incidentes salen mal. No porque la gente sea incompetente, sino porque a las tres de la madrugada, bajo presión y con información parcial, las personas necesitan una estructura que hayan practicado. Todo lo que tengan que leer por primera vez no se va a leer.

Severidad por criterios, no por sensación

El primer fallo en casi todos los incidentes es discutir cuánto de grave es. La severidad tiene que poder decidirse en treinta segundos por quien se dio cuenta, sin pedir permiso.

Escribe criterios, no adjetivos. Algo así: la severidad máxima significa que una funcionalidad de cara al cliente no está disponible, o que la confidencialidad o la integridad de los datos está comprometida, o que puede haber arrancado un reloj de notificación regulatoria. El nivel siguiente significa servicio degradado con solución alternativa, o un evento de seguridad contenido pero todavía no entendido. El más bajo significa impacto en un solo cliente o en un sistema interno.

Dos reglas lo mantienen honesto. Cualquiera puede declarar, y declarar no se castiga nunca. Es más barato desactivar una falsa alarma que gastar cuarenta minutos decidiendo si empezar. Y un incidente de seguridad con posible exposición de datos va a la severidad máxima por defecto, porque el reloj de notificación es implacable y bajarlo después es fácil.

Tres roles, y el primero no es técnico

El cambio más eficaz en la gestión de incidentes es separar a quien coordina de quienes investigan.

Mando del incidente. Es dueño del proceso, no del arreglo. Decide la severidad, reparte trabajo, mantiene la cronología, pide escalado y decide cuándo termina el incidente. Y lo decisivo: no depura. El modo de fallo más común en un equipo pequeño es que el mejor ingeniero está a la vez dirigiendo la respuesta y con la cabeza metida en un terminal, y la comunicación se detiene por completo.

Investigadores. Una o más personas haciendo el trabajo técnico, que reportan hallazgos al mando en vez de narrar en un canal que nadie está agregando.

Comunicación. Se encarga de la página de estado, de los mensajes a clientes y de las actualizaciones internas con una cadencia fija. En una empresa pequeña puede ser el propio mando, pero tiene que ser un sombrero explícito, porque "alguien debería avisar a los clientes" es una frase que se dice cuarenta minutos tarde.

Para un equipo pequeño, dos personas es el mínimo práctico. Si eres una, la estructura sigue ayudando: escribe la cronología sobre la marcha, porque no la vas a recordar.

Un canal, una cronología

Abre un canal dedicado por incidente en vez de usar el del equipo. Todo va ahí: qué se observó, qué se intentó, qué cambió, a quién se avisó, con marcas de tiempo.

Lleva la cronología sobre la marcha. Es la disciplina que la gente abandona bajo presión y lamenta después, porque la cronología es lo que necesita la revisión posterior, lo que pide un regulador, y lo que te dice si lo que cambiaste a las 02:14 causó la mejora de las 02:20 o coincidió con ella.

Actualiza con una cadencia aunque no haya nada nuevo. Cada treinta minutos, un mensaje que diga "seguimos investigando, sin cambios" evita que seis personas pidan una actualización por separado y aparten a los investigadores.

El escalado es una lista con nombres y teléfonos

Deja escrito, por sistema, a quién llamar y en qué orden, e incluye los caminos que se olvidan: el canal de soporte del proveedor de nube y el nivel de severidad que consigue una persona al otro lado, el proveedor cuya caída está causando la tuya, la persona que tiene las credenciales que no tiene nadie más, el contacto jurídico y el de protección de datos, y quien decide sobre la comunicación a clientes.

Incluye el procedimiento de emergencia. Si el proveedor de identidad está caído, ¿cómo entra alguien? Si esa respuesta no existe, has encontrado el próximo incidente y merece la pena parar a arreglarlo.

Prueba los contactos. Una lista de escalado donde dos personas ya no trabajan en la empresa es habitual y solo se descubre en el peor momento.

El reloj de notificación, y quién lo vigila

Aquí es donde un incidente técnico se convierte en uno regulatorio, y donde los equipos pierden tiempo que no pueden recuperar.

Las obligaciones difieren pero la forma es la misma: un plazo corto que arranca con el conocimiento y no con la resolución. El RGPD corre a 72 horas hacia la autoridad de control para una brecha de datos personales, con notificación a las personas cuando el riesgo para ellas es alto. NIS2 exige un aviso temprano en 24 horas y una notificación más completa después, para las entidades en ámbito. DORA fija su propio camino de reporte para las entidades financieras y sus proveedores críticos. Las leyes estatales estadounidenses de privacidad y las normas sectoriales añaden las suyas. Verifica el texto actual de las que te atan en vez de la versión que hay en el documento de política.

La consecuencia de ingeniería es que alguien tiene que quedar asignado, durante el incidente, a evaluar si ha arrancado un reloj. Ponlo en la lista de comprobación del mando como un punto explícito con un nombre al lado. Y ten en cuenta que el reloj corre haya pensado alguien en ello o no, que es la razón de que la detección y el registro de auditoría sean controles de cumplimiento: si no estabas registrando las lecturas, no puedes establecer a qué se accedió, y no poder acotar la brecha tiende a ampliar la notificación en vez de estrecharla. El lado de la obligación está en el ámbito y las obligaciones de NIS2 y en el RGPD como controles de ingeniería.

La revisión que cambia algo

Hazla dentro de la semana, con la memoria fresca, y hazla sin culpables en el sentido real: la pregunta es qué hizo que el error fuera razonable en ese momento, no quién lo cometió. Un ingeniero que teme la revisión no te va a contar qué hizo de verdad, y entonces no aprendes nada.

La salida es un número pequeño de acciones con dueño y fecha, en el backlog normal, revisadas como cualquier otro trabajo. Una revisión que produce catorce acciones produce cero completadas. Dos o tres, hechas, es un sistema que mejora.

Sigue un número a lo largo del tiempo: cuántos incidentes los causó algo que una revisión anterior identificó y nadie arregló. Si ese número no es cero, el problema es el proceso de revisión, no los sistemas.

Lo que se olvida

• Las alertas tienen que llegar al mando. La calidad de la detección decide cuán pronto empieza el proceso, y por eso esto depende de alertas que la gente atiende.
• La página de estado también es un sistema. Alojarla en la infraestructura que acaba de caerse es un error que todo el mundo comete exactamente una vez.
• Practícalo. Un ejercicio de mesa una vez por trimestre encuentra el contacto obsoleto y el enlace roto al runbook sin coste ninguno.
• Haz el traspaso bien. Los incidentes duran más que los turnos. Escribe un resumen de traspaso con el estado actual, lo que se ha descartado y lo que está en marcha.
• Preserva la evidencia en incidentes de seguridad. Toma la instantánea antes de remediar. Reconstruir la máquina comprometida destruye el rastro forense.

Qué hacer esta semana

Coge tu último incidente real e intenta reconstruir su cronología a partir de lo que se escribió en el momento. Si no puedes establecer cuándo empezó, cuándo lo supisteis y a quién se avisó, ese es el hallazgo. El arreglo es una plantilla de una página fijada en el canal de incidentes, y cuesta una tarde. Lo construimos con los equipos en la fase de resiliencia de un proyecto de seguridad.