Plan de respuesta a incidentes para empresas: cómo actuar sin detener la operación

Qué riesgos reduce un protocolo de incidentes informáticos

Un plan bien diseñado reduce cuatro tipos de impacto: operativo, financiero, legal y reputacional. El primero es el más visible: servicios caídos, usuarios sin acceso, aplicaciones fuera de línea, correo comprometido o sucursales sin conectividad. El segundo aparece rápido: horas hombre improductivas, ventas perdidas, multas contractuales, costos de contención, horas extra y proveedores de emergencia. El tercero se relaciona con obligaciones de reporte, resguardo de evidencia y diligencia razonable. El cuarto golpea la confianza de clientes, socios y dirección.

Desde el punto de vista gerencial, la pregunta correcta no es “¿vamos a tener un incidente?”, sino “¿qué tan preparados estamos para limitarlo?”. NIST plantea la preparación, la detección y análisis, la contención con erradicación y recuperación, y la actividad posterior al incidente como un ciclo continuo. CISA, además, recomienda ejercicios tipo tabletop para validar contactos, flujos de decisión y brechas del plan antes de una emergencia. NIST SP 800-61r3 y Incident Response Plan Basics refuerzan esa lógica.

En empresas medianas y grandes, además, el incidente técnico rara vez se queda en TI. Una credencial privilegiada comprometida puede afectar ERP, archivos, acceso remoto y operación comercial. Un error en la contención puede interrumpir procesos legítimos. Una comunicación tardía puede hacer que usuarios sigan abriendo correos maliciosos o que un proveedor externo mantenga una conexión vulnerable. Por eso el plan debe contemplar dependencias críticas, responsables alternos, escalamiento fuera de horario y reglas mínimas para actuar sin autorización informal.

Una buena práctica es clasificar incidentes por severidad y por impacto al negocio. No todo evento de seguridad requiere comité de crisis, pero sí conviene establecer umbrales objetivos: cantidad de usuarios afectados, exposición de datos, indisponibilidad de un sistema crítico, compromiso de cuentas privilegiadas, propagación lateral o sospecha de filtración. Eso evita sobrerreaccionar ante alertas menores y, al mismo tiempo, reduce la parálisis cuando el caso es grave.

También conviene diferenciar plan y playbooks. El plan define gobierno, roles, decisiones, comunicaciones, criterios y métricas. Los playbooks bajan ese marco a escenarios específicos: ransomware, phishing con toma de cuenta, fuga de datos, caída de firewall, compromiso de VPN o malware en endpoints. Esa combinación hace que la respuesta sea repetible y menos dependiente de personas aisladas.