Nadie planifica un incidente de seguridad. Por eso, cuando ocurre, la calidad de la respuesta depende casi por completo de si existía un plan de respuesta a incidentes escrito antes de que pasara, o si el plan se está inventando en tiempo real, con el reloj corriendo.
Por qué esto es distinto a tener buenas medidas técnicas
Separar sistemas por sensibilidad, respaldar con verificación, controlar accesos: todo eso reduce la probabilidad de un incidente. Pero ninguna medida técnica lo hace imposible. La pregunta que casi nadie responde por adelantado es qué pasa exactamente en las primeras horas después de que alguien detecta que algo salió mal.
En la mayoría de las empresas medianas que revisamos, la respuesta es “improvisar con la gente disponible ese día”. Eso no es necesariamente un mal plan porque el equipo sea incompetente. Es un mal plan porque nadie decidió con calma, de antemano, quién hace qué, en qué orden, y con qué información se comunica hacia adentro y hacia afuera de la empresa.
Lo mínimo que un plan escrito debería responder
Quién es la primera persona a la que hay que avisar dentro de la empresa, y cómo se la contacta si el sistema de correo corporativo es parte de lo comprometido. Qué sistemas se aíslan primero para evitar que el problema se expanda, y quién tiene la autoridad para tomar esa decisión sin esperar una reunión. Qué información se necesita reunir para entender el alcance real del incidente, no solo la sensación inicial de qué tan grave es. Y quién decide, con qué criterio, si corresponde notificar a clientes, a un proveedor legal, o a la autoridad correspondiente.
Ninguna de estas preguntas requiere resolver primero un detalle legal complejo. Son decisiones operacionales que cualquier empresa mediana puede documentar en un par de páginas, sin depender de que el reglamento de ninguna ley termine de definirse.
Por qué esto es infraestructura, no solo un documento
Un plan de este tipo solo funciona si la infraestructura detrás lo permite: si existe un registro de accesos que muestre por dónde pudo haber entrado el problema, si el respaldo está probado y disponible para restaurar sin depender de que funcione a la primera, si hay trazabilidad de qué sistemas procesan qué datos. Sin eso, el plan más bien escrito del mundo se topa con la misma pregunta sin respuesta: ¿qué fue exactamente lo que pasó?
Si tu empresa está en un sector regulado, los plazos ya son concretos
Si tu empresa califica como prestadora de servicios esenciales u operador de importancia vital bajo la Ley 21.663 —telecomunicaciones, energía, salud, banca, transporte, agua, entre otros sectores—, ese plan de respuesta ya tiene plazos definidos: alerta temprana al CSIRT Nacional dentro de tres horas desde que se detecta el incidente, un segundo reporte a las 72 horas, y un informe final a los 15 días. Esos plazos no dan margen para improvisar un procedimiento a mitad de la crisis.
Si tu empresa no está en ese grupo, la Ley 21.719 igual exige notificar a la Agencia de Protección de Datos a la brevedad desde que se toma conocimiento de un incidente que afecte datos personales, sin el mismo nivel de detalle de plazos que fija la ley de ciberseguridad. En ambos casos el punto de partida es el mismo: un plan que el equipo ya conoce, no uno que se redacta mientras el incidente sigue abierto.
¿Existe hoy en tu empresa un documento, por breve que sea, que diga qué hacer en las primeras horas de un incidente?
