Cuando aparece una alerta extraña —un acceso desconocido, una cuenta bloqueada, archivos cifrados o un sitio que redirige a otra página— el problema no es solo técnico. También hay que decidir quién actúa, qué se desconecta, qué evidencia se conserva, cuándo se informa y cómo se recupera la operación.
Un plan de respuesta ante incidentes no evita por sí solo todos los ataques. Su función es reducir la improvisación: establece decisiones anticipadas para que el equipo pueda contener el problema sin perder de vista a clientes, datos y procesos críticos. La guía NIST SP 800-61r3 plantea la respuesta a incidentes como parte de la gestión continua del riesgo, no como un documento aislado que se consulta demasiado tarde.
La mejor respuesta no es la que parece más sofisticada en un archivo: es la que las personas correctas pueden activar con calma y criterio cuando algo falla.
Qué debe resolver el plan antes de que ocurra un incidente
El plan debe ser breve, localizable y comprensible para quienes tendrán que usarlo. No hace falta empezar con decenas de páginas. Para una organización pequeña, una versión inicial puede resolver estas seis preguntas:
- ¿Qué situaciones activan el plan? Por ejemplo: acceso no autorizado, fraude desde una cuenta, malware, caída sospechosa de un servicio, exposición de datos o modificación no autorizada de un sitio.
- ¿Quién toma las decisiones? Definí un responsable principal y un suplente con autoridad para aprobar medidas urgentes, como revocar accesos o detener temporalmente un proceso.
- ¿Qué activos son prioritarios? Listá cuentas administrativas, correo corporativo, sitio web, tienda, copias de seguridad, sistemas de cobro, datos de clientes y proveedores críticos.
- ¿Cómo se escala el caso? Establecé cuándo participa dirección, un proveedor técnico, asesoría legal, comunicación o atención al cliente.
- ¿Dónde se registra lo que ocurre? Usá un registro de incidente separado del sistema comprometido: fecha y hora, hallazgo, decisiones, responsables, evidencias y próximos pasos.
- ¿Cómo se vuelve a operar? Indicá los criterios mínimos para restaurar un servicio y quién valida que el riesgo inmediato fue tratado.
CISA señala que incluso equipos pequeños pueden comenzar con un plan sencillo de acciones inmediatas y contactos, y luego mejorarlo mediante prácticas periódicas. También recomienda ejercitarlo al menos una vez al año, aunque sea mediante una conversación guiada sobre un escenario realista. Ver la recomendación de CISA.
Armá una ficha de incidente de una página
En una emergencia, una ficha operativa suele ser más valiosa que un manual extenso. Guardala en un lugar que siga disponible si el correo, el gestor de contraseñas o el sistema de archivos tienen problemas. Puede ser un documento protegido con acceso alternativo y una copia offline actualizada.
Datos mínimos para incluir
- Canal de activación: teléfono, mensajería o correo alternativo para informar un posible incidente.
- Responsables y suplentes: dirección, referente técnico, proveedor, comunicación y responsable de datos o asuntos legales si corresponde.
- Inventario prioritario: URL de administración, proveedor de dominio, nube, correo, copias de seguridad, pasarelas de pago y contactos de soporte.
- Acciones iniciales permitidas: cambiar o revocar credenciales, cerrar sesiones, aislar un equipo, pausar integraciones o poner un sitio en mantenimiento.
- Reglas de evidencia: no borrar mensajes ni archivos sospechosos; registrar horas, capturas, nombres de cuentas, direcciones IP y cambios realizados.
- Criterios de escalamiento: afectación de datos personales, interrupción de ventas, múltiples cuentas comprometidas, posible fraude o imposibilidad de recuperar el control.
- Recuperación y cierre: qué revisar antes de reactivar el servicio y cuándo realizar la reunión de lecciones aprendidas.
La priorización no debería basarse solo en qué alerta parece más llamativa. NIST recomienda ponderar el alcance, el impacto probable, la urgencia y los recursos disponibles; también advierte que investigar más a fondo y restaurar más rápido pueden ser decisiones en tensión. Consultar la publicación de NIST.
Separá contención, investigación y recuperación
Mezclar estas tres tareas produce errores frecuentes. Un equipo puede restaurar un sitio demasiado pronto sin haber corregido la vía de acceso; o puede conservar una investigación perfecta mientras la operación queda detenida sin necesidad. El plan debe indicar el objetivo de cada etapa.
1. Contener: limitar el daño
La primera pregunta es qué medida reduce el riesgo ahora. Según el caso, puede ser revocar una sesión, deshabilitar una cuenta, aislar un dispositivo de la red, pausar una integración o desactivar temporalmente una función expuesta. Antes de actuar, registrá el motivo y la hora. Si la situación lo permite, preservá una captura o exportación de los datos relevantes.
2. Investigar: entender qué pasó
Reconstruí una línea de tiempo: primera señal detectada, cuentas usadas, activos afectados, cambios realizados y acciones del equipo. El objetivo no es atribuir culpables con rapidez, sino determinar qué ocurrió, qué pudo quedar expuesto y qué condición permitió el incidente. NIST incluye entre sus recomendaciones analizar la secuencia de eventos, los recursos involucrados y las causas de fondo. Fuente: NIST.
3. Recuperar: volver con verificaciones
Restaurar no es simplemente encender de nuevo. Antes de reactivar, verificá que las credenciales comprometidas fueron reemplazadas, que se retiraron accesos no necesarios, que las actualizaciones o correcciones fueron aplicadas y que las copias utilizadas son confiables. Definí una persona responsable de aprobar la vuelta a producción y un período de monitoreo reforzado.
Los logs y las evidencias deben estar previstos
Sin registros, muchas conclusiones se convierten en suposiciones. No es necesario almacenar todo sin criterio, pero sí saber dónde consultar la actividad relevante: inicio de sesión, acciones administrativas, cambios de permisos, eventos de servidores, accesos a aplicaciones, red y servicios en la nube.
CISA recomienda habilitar registros en servidores, firewalls, dispositivos, endpoints y servicios cloud; también sugiere centralizarlos, revisarlos con regularidad y protegerlos frente a accesos o borrados no autorizados. Consultar las prácticas de logging de CISA.
Como decisión editorial práctica, definí antes del incidente:
- qué sistemas generan evidencia importante;
- quién puede acceder a ella;
- cuánto tiempo se retiene;
- cómo se guarda una copia del registro del incidente;
- qué proveedor puede aportar información técnica si el servicio es externo.
Prepará la comunicación sin anunciar conclusiones prematuras
La comunicación también necesita un circuito. El equipo técnico no debería confirmar causas, alcance o exposición de datos antes de contar con evidencia suficiente. A la vez, la dirección debe saber cuándo se enterará y qué decisión necesita tomar.
Creá plantillas breves para comunicaciones internas, clientes y proveedores. Deben indicar qué se sabe, qué se está haciendo, qué acción se solicita —si corresponde— y cuándo habrá una actualización. Para incidentes que puedan involucrar datos personales, contratos o notificaciones obligatorias, definí la consulta temprana con asesoría legal local: los requisitos aplicables dependen de la jurisdicción y del tipo de información afectada.
La guía #StopRansomware de CISA recomienda que el plan de respuesta y el de comunicaciones incluyan procedimientos de respuesta y notificación, estén revisados por la cadena de mando y contemplen cómo circulará la información.
Probalo con un simulacro de 30 minutos
Un plan sin práctica revela sus vacíos en el peor momento. Elegí un escenario probable para tu operación: un administrador recibe un aviso de inicio de sesión desconocido, la web muestra contenido modificado, una cuenta de correo envía mensajes extraños o un colaborador pierde un dispositivo con acceso corporativo.
- Leé el escenario y anotá la hora de inicio.
- Pedí a cada participante que diga qué haría primero y a quién avisaría.
- Buscá contactos, accesos alternativos y evidencias como si el incidente fuera real.
- Tomá nota de decisiones confusas, dependencias no documentadas y permisos excesivos.
- Actualizá la ficha operativa con tres mejoras concretas y asignales responsable y fecha.
Conclusión: empezá por una ficha de una página, no por un documento perfecto. Definí responsables, activos críticos, acciones de contención, registro de evidencias, comunicación y criterios de recuperación. Después ensayala. Un plan breve que se prueba y se corrige protege mucho más que una política extensa que nadie sabe activar.
