Cuando una pyme detecta un correo malicioso abierto por un empleado o un acceso no autorizado al servidor, el tiempo deja de medirse en horas y empieza a medirse en minutos. Tener un ejemplo de plan de respuesta a incidentes no es un documento decorativo: es la diferencia entre una interrupción controlada y una crisis que afecta ventas, operación y confianza del cliente.
Muchas empresas sí cuentan con antivirus, copias de seguridad o controles básicos, pero no siempre tienen claro qué hacer cuando el incidente ya está en curso. Ahí es donde falla la mayoría. No por falta de tecnología, sino por falta de orden, responsables definidos y criterios de escalado.
Qué debe resolver un plan de respuesta a incidentes
Un plan útil no intenta prever absolutamente todo. Su función real es dar una estructura clara para detectar, contener, investigar, erradicar y recuperar ante eventos de seguridad o fallos operativos relevantes. También debe definir cómo se comunica el incidente, quién toma decisiones y qué evidencias se conservan.
Para una pyme, esto es especialmente importante porque el impacto de una parada suele ser más directo. Si el ERP no funciona, si el correo se ve comprometido o si una carpeta compartida queda cifrada por ransomware, la afectación llega a contabilidad, ventas, atención al cliente y dirección al mismo tiempo.
Un buen plan tampoco se limita a ciberataques. Puede activarse por fuga de información, error humano, indisponibilidad de sistemas críticos, borrado accidental de datos o accesos indebidos por parte de terceros. El enfoque cambia según el caso, pero la disciplina de respuesta es la misma.
Ejemplo de plan de respuesta a incidentes para una pyme
A continuación, planteamos un ejemplo práctico pensado para una empresa mediana con 40 a 80 empleados, correo corporativo, archivos en red, un ERP y soporte TI interno reducido o externalizado.
1. Objetivo del plan
Establecer el proceso para identificar, clasificar, contener, erradicar y recuperar incidentes que afecten a la confidencialidad, integridad o disponibilidad de la información y de los sistemas críticos del negocio.
2. Alcance
Este plan aplica a equipos de usuario, servidores, cuentas de correo, servicios en la nube, red corporativa, accesos remotos, dispositivos móviles corporativos y proveedores con acceso a sistemas de la empresa.
3. Definición de incidente
Se considera incidente cualquier evento que comprometa o pueda comprometer la seguridad, continuidad o correcto funcionamiento de la operación tecnológica. Por ejemplo, malware, phishing exitoso, pérdida de portátil con datos sensibles, caída del servidor principal, acceso no autorizado, filtración de información o manipulación indebida de archivos.
4. Roles y responsables
El Director de Operaciones o Gerencia autoriza decisiones de impacto alto, como desconexión de servicios críticos o comunicación a clientes. El responsable de TI coordina la respuesta técnica. El proveedor de soporte o ciberseguridad ejecuta análisis, contención y recuperación si aplica. Recursos Humanos interviene cuando hay acciones de empleados involucradas. Legal o asesoría externa participa si existe riesgo regulatorio o contractual.
Aquí conviene una aclaración práctica: en muchas pymes una sola persona cubre varios sombreros. No pasa nada, siempre que quede por escrito quién decide, quién ejecuta y quién informa. La ambigüedad durante un incidente suele costar más que la carencia de herramientas.
5. Clasificación por severidad
Severidad alta: afecta operación crítica, datos sensibles o varios usuarios a la vez. Ejemplo: ransomware, compromiso del correo de dirección, caída total del ERP.
Severidad media: afecta a un área concreta sin detener toda la operación. Ejemplo: infección en un equipo, acceso sospechoso a una cuenta no privilegiada, fallo de red parcial.
Severidad baja: evento aislado con impacto limitado y controlable. Ejemplo: intento de phishing reportado a tiempo, error de configuración sin impacto extendido.
6. Tiempos objetivo
Para incidentes de severidad alta, la revisión inicial debe empezar en menos de 15 minutos y la contención en menos de 60. En severidad media, revisión inicial en 30 minutos y contención en 4 horas. En severidad baja, análisis el mismo día laborable.
No todas las empresas pueden cumplir estos tiempos con recursos internos. Si ese es el caso, conviene definir una cobertura externalizada. Es preferible reconocer una limitación y cubrirla bien que asumir tiempos irreales que nadie podrá sostener.
Fases de actuación del plan
Detección y registro
Cualquier empleado que detecte actividad extraña debe reportarla al canal definido: mesa de ayuda, teléfono de urgencia o correo específico. El responsable de TI abre un registro con fecha, hora, sistema afectado, usuario relacionado, síntomas observados y primera clasificación.
El objetivo en esta fase no es tener todas las respuestas. Es evitar que el evento quede disperso entre mensajes de chat, llamadas y suposiciones. Un incidente mal documentado se complica tanto en la investigación como en el aprendizaje posterior.
Análisis inicial
Se valida si el evento es real, su alcance preliminar y el posible vector de entrada. Se revisan logs, alertas del antivirus, actividad de correo, accesos remotos y cambios recientes. Si hay dudas sobre compromiso activo, se asume el escenario más prudente hasta descartar riesgo.
Este punto exige equilibrio. Sobrerreaccionar puede frenar la operación sin necesidad, pero reaccionar tarde suele salir más caro. Por eso la clasificación debe apoyarse en criterios definidos, no en intuición.
Contención
La contención busca detener la propagación. Las acciones típicas incluyen aislar el equipo afectado de la red, bloquear cuentas comprometidas, forzar cambio de contraseñas, deshabilitar accesos VPN, detener procesos sospechosos o segmentar servicios temporalmente.
Ejemplo: si un usuario hizo clic en un archivo malicioso y el equipo empieza a comportarse de forma anómala, se desconecta de la red de inmediato, se bloquea su sesión y se revisa si hubo movimiento lateral. Si el incidente afecta al correo, se revocan sesiones activas y se buscan reglas de reenvío no autorizadas.
Erradicación
Una vez contenido el impacto, se elimina la causa. Esto puede implicar limpieza de malware, borrado de persistencias, parcheo de vulnerabilidades, corrección de configuraciones erróneas o sustitución de credenciales expuestas. Si no hay garantías suficientes sobre el estado del sistema, la reinstalación controlada suele ser más segura que una limpieza parcial.
Aquí aparece un error frecuente: volver a poner el sistema en marcha demasiado pronto. Si la causa raíz sigue presente, el incidente regresa. En pymes con presión operativa, esta tentación es habitual.
Recuperación
La recuperación consiste en restaurar servicios de forma segura y monitorizada. Se recuperan datos desde copias verificadas, se valida el funcionamiento del sistema, se comprueba que no persisten indicadores de compromiso y se informa a las áreas afectadas del restablecimiento.
No todo debe volver al mismo tiempo. A veces conviene recuperar primero correo y sistemas comerciales, y dejar para una segunda fase servicios secundarios. El orden depende del impacto en negocio, no solo de la prioridad técnica.
Comunicación
Durante todo el proceso debe existir un esquema de comunicación. Internamente, la dirección necesita saber qué ha pasado, qué impacto existe, qué medidas se han tomado y qué decisiones están pendientes. Hacia empleados, el mensaje debe ser concreto y útil. Si procede informar a clientes o proveedores, la comunicación debe ser coherente, prudente y basada en hechos confirmados.
Improvisar mensajes durante una crisis crea ruido y puede agravar el daño reputacional. Por eso el plan debe incluir plantillas breves y responsables de aprobación.
Qué no debería faltar en un ejemplo de plan de respuesta a incidentes
Además del flujo técnico, hay elementos que marcan la diferencia. Uno es el inventario de activos críticos, porque sin saber qué sistemas sostienen la operación es difícil priorizar. Otro es el directorio de contactos de emergencia, incluyendo proveedor TI, internet, software de gestión, nube y responsables internos.
También es clave definir qué evidencias se preservan. Logs, correos sospechosos, capturas, hashes de archivos, hora exacta de eventos o registros de acceso pueden ser necesarios para análisis forense, reclamaciones o decisiones legales.
Si la empresa trabaja con datos personales o información de clientes, conviene añadir un criterio de evaluación regulatoria. No todos los incidentes obligan a notificar, pero algunos sí exigen una revisión rápida del posible impacto sobre datos.
Un mini caso práctico
Imaginemos una empresa de distribución en Madrid con 55 empleados. Un lunes a las 8:20, varios usuarios no pueden abrir archivos compartidos y aparece una nota de rescate. El plan se activa como severidad alta. El responsable de TI ordena aislar el servidor de archivos y desconectar equipos con actividad anómala. Gerencia aprueba la parada temporal del acceso remoto.
Mientras el proveedor de ciberseguridad analiza el alcance, se comprueba que el ERP sigue operativo en otro entorno. Se bloquean cuentas con actividad inusual durante la madrugada y se verifica el estado de las copias. A las 11:30 se confirma que la copia de seguridad de la noche anterior es íntegra. Se inicia recuperación controlada, se emite comunicación interna con instrucciones precisas y se registra toda la secuencia.
El aprendizaje posterior revela que el acceso inicial vino de una contraseña reutilizada en una cuenta VPN sin segundo factor. La corrección no solo fue técnica. También se revisaron políticas de acceso, formación al usuario y monitorización. Ese es el valor real del plan: responder hoy y reducir la probabilidad de repetir mañana.
Cómo mantener vivo el plan
Un plan que no se prueba acaba fallando en el peor momento. Lo razonable para una pyme es revisarlo cada seis o doce meses, o antes si cambian sistemas clave, proveedores o procesos críticos. Un simulacro breve puede descubrir vacíos muy concretos: números de contacto obsoletos, accesos que nadie recuerda, responsables no disponibles o tiempos imposibles.
Si la empresa no dispone de equipo especializado, apoyarse en un socio externo aporta criterio, velocidad y continuidad. En entornos donde cada hora de parada afecta directamente a facturación y servicio, esa diferencia pesa mucho. Ahí es donde una firma con experiencia operativa, como LaNet, puede ayudar a convertir un documento genérico en un proceso aplicable al negocio real.
La mejor respuesta a un incidente no empieza cuando salta la alerta, sino bastante antes, cuando alguien decide que improvisar ya no es una opción.