Cómo preparar un plan de respuesta a incidentes para una pyme

Un empleado abre un archivo malicioso, varios ordenadores empiezan a funcionar de forma extraña y las carpetas compartidas dejan de estar disponibles. El responsable de la empresa llama al proveedor informático, pero nadie sabe si debe apagar los equipos, desconectar el servidor, avisar a los empleados o comprobar primero las copias de seguridad.

Ese momento no es adecuado para decidir quién manda, dónde están los contactos de emergencia o qué sistemas deben recuperarse primero. Un plan de respuesta a incidentes para una pyme debe resolver esas preguntas antes de que ocurra el problema.

No tiene que ser un manual de cien páginas. Debe ser un procedimiento claro, accesible y practicable que permita detectar el incidente, reducir su impacto, mantener las funciones esenciales y recuperar la actividad con el menor riesgo posible.

Qué es un plan de respuesta a incidentes

Es el documento que establece cómo debe actuar la empresa ante un suceso que pueda afectar a la confidencialidad, integridad o disponibilidad de sus sistemas y datos.

Puede activarse ante situaciones diferentes:

• Infección por malware o ransomware.
• Robo de una contraseña corporativa.
• Acceso no autorizado al correo, servidores o aplicaciones.
• Pérdida o robo de un portátil o teléfono de empresa.
• Envío de información confidencial a un destinatario equivocado.
• Caída prolongada de un servidor, aplicación o servicio en la nube.
• Modificación fraudulenta de datos bancarios o facturas.
• Ataques contra la página web, la red o los sistemas de acceso remoto.

El plan no sustituye las medidas preventivas. Las complementa. Un sistema de seguridad puede bloquear numerosos ataques, pero la empresa también debe estar preparada para aquellos que no se detecten a tiempo, para errores humanos y para fallos técnicos.

Por qué una lista de teléfonos no es suficiente

Muchas pymes consideran que su procedimiento consiste en llamar al técnico informático. Eso puede servir para una avería sencilla, pero resulta insuficiente ante un incidente que afecte a varios sistemas, datos personales, clientes, proveedores o a la continuidad del negocio.

El proveedor técnico puede investigar y contener el problema, pero otras decisiones corresponden a la empresa:

• Qué procesos deben mantenerse activos.
• Quién puede ordenar la desconexión de un sistema.
• Qué empleados deben ser informados.
• Quién se comunica con clientes o proveedores.
• Qué responsable valora las implicaciones legales.
• Cuándo se activa el plan de continuidad.
• Qué nivel de interrupción puede aceptar el negocio.

Un plan que depende de localizar a una sola persona no es un plan operativo. Es una dependencia que puede bloquear la respuesta.

Qué información debes recopilar antes de redactarlo

El primer paso no consiste en descargar una plantilla. Consiste en entender cómo funciona la empresa y de qué sistemas depende.

Procesos críticos

Identifica las actividades que no pueden detenerse durante demasiado tiempo: facturación, atención al cliente, producción, preparación de pedidos, acceso a expedientes, comunicaciones, cobros o gestión de proveedores.

Después relaciona cada proceso con los sistemas que necesita. La facturación puede depender de una aplicación, una base de datos, el correo, el servidor de documentos y el acceso a Internet. Recuperar solo uno de esos elementos puede no ser suficiente para volver a trabajar.

Activos y responsables

El inventario debe incluir, al menos, equipos, servidores, aplicaciones, cuentas administrativas, servicios en la nube, conexiones remotas, dispositivos móviles y copias de seguridad.

Cada activo crítico debe tener un responsable técnico y un responsable de negocio. El primero conoce el sistema. El segundo puede decidir qué prioridad tiene y qué consecuencias tendría mantenerlo detenido.

Proveedores externos

Incluye los datos de contacto del soporte informático, alojamiento, telecomunicaciones, aplicaciones de gestión, copias de seguridad, ciberseguro y asesoramiento legal o de protección de datos cuando corresponda.

Conviene registrar también horarios de atención, procedimientos de apertura de incidencias y posibles vías de escalado. Descubrir durante un ataque que el proveedor solo atiende por correo puede ser un problema si precisamente el correo corporativo ha sido comprometido.

Los siete elementos que debe contener el plan

1. Criterios para declarar un incidente

No toda anomalía técnica es un incidente de seguridad. El plan debe explicar qué señales justifican activarlo.

Algunos ejemplos son la aparición de archivos cifrados, accesos desde ubicaciones desconocidas, cambios de contraseña no solicitados, envío masivo de mensajes, desactivación de herramientas de protección, pérdida de datos o interrupciones sin una causa técnica identificada.

También debe indicarse quién puede declarar oficialmente el incidente. En una pyme puede ser el responsable de sistemas, la dirección o el proveedor autorizado, dependiendo de la organización.

2. Clasificación por gravedad

Clasificar el incidente ayuda a evitar tanto la inacción como una reacción desproporcionada. Puede utilizarse una escala sencilla:

• Bajo: afecta a un usuario o equipo, sin indicios de propagación ni pérdida de información.
• Medio: afecta a varios usuarios, un servicio relevante o una cuenta con permisos elevados.
• Alto: interrumpe procesos críticos, compromete información sensible o presenta riesgo de propagación.
• Crítico: paraliza una parte importante de la actividad, afecta a múltiples sistemas o puede tener consecuencias graves para clientes, empleados o terceros.

La clasificación debe considerar el alcance, el tipo de información afectada, la duración prevista, la posibilidad de propagación y el impacto sobre el negocio.

3. Equipo de respuesta y sustituciones

No hace falta crear un gran comité. Sí es necesario asignar funciones concretas:

• Coordinación general del incidente.
• Investigación y contención técnica.
• Decisiones sobre continuidad de negocio.
• Comunicación interna y externa.
• Valoración legal y protección de datos.
• Registro de actuaciones y evidencias.

Cada función debe tener un sustituto. También es recomendable conservar una copia de los contactos fuera de los sistemas corporativos, porque durante el incidente podrían no estar disponibles el correo, el servidor o la aplicación donde se guardan habitualmente.

4. Procedimiento de contención

Contener significa impedir que el problema continúe extendiéndose mientras se investiga. Las medidas dependerán del incidente y pueden incluir aislar equipos, bloquear cuentas, revocar sesiones, desactivar accesos remotos o segmentar temporalmente una parte de la red.

El plan debe diferenciar entre desconectar un equipo de la red y apagarlo por completo. Apagarlo sin criterio puede eliminar información útil para analizar lo ocurrido. Mantenerlo conectado, por otro lado, puede permitir que el ataque se propague.

5. Conservación de evidencias

Es necesario registrar qué se ha observado, a qué hora, en qué equipo, quién intervino y qué cambios se realizaron. También conviene conservar mensajes sospechosos, alertas, registros, capturas y cualquier otro elemento que pueda ayudar a determinar el origen y alcance del incidente.

Este registro permite coordinar mejor a los técnicos, evitar actuaciones repetidas y justificar posteriormente las decisiones tomadas. En determinados casos también puede resultar necesario para una investigación, una reclamación al seguro o una posible denuncia.

6. Comunicación y notificación

El plan debe establecer quién puede comunicar información sobre el incidente y qué canales se utilizarán si el correo o la telefonía corporativa no funcionan.

Los empleados necesitan instrucciones concretas. Por ejemplo, no encender determinados equipos, no utilizar cuentas comprometidas, no responder a mensajes sospechosos o trabajar temporalmente mediante un procedimiento alternativo.

También debe valorarse si corresponde informar a clientes, proveedores, aseguradoras, autoridades o profesionales especializados. Las obligaciones y los plazos dependerán del tipo de entidad, la información afectada, el sector y la normativa aplicable. Por eso conviene dejar definido quién realizará esa valoración, en lugar de improvisarla durante la crisis.

7. Recuperación y vuelta a la actividad

Recuperar no consiste únicamente en restaurar una copia de seguridad. Antes es necesario comprobar que la causa del incidente ha sido controlada y que las credenciales, equipos o configuraciones comprometidas no volverán a introducir el problema.

El orden de recuperación debe seguir las prioridades del negocio. Puede ser más urgente restablecer el acceso al sistema de pedidos que recuperar todos los archivos históricos de un departamento.

El plan debe indicar:

• Qué servicios se recuperan primero.
• De qué copias o sistemas alternativos dependen.
• Quién valida que la información restaurada es correcta.
• Qué pruebas deben realizarse antes de abrir el sistema a todos los usuarios.
• Cómo se mantendrá la actividad mientras dura la recuperación.

Ejemplo práctico: ataque de ransomware

Una pyme de veinte empleados detecta que varios documentos compartidos han cambiado de extensión y no pueden abrirse. Dos usuarios ven un mensaje de rescate en sus equipos.

Sin un plan, cada empleado actúa por su cuenta. Algunos reinician el ordenador, otros siguen trabajando y uno conecta un portátil que llevaba varios días apagado. La empresa tarda en localizar al proveedor, no sabe si las copias están afectadas y pierde tiempo decidiendo qué comunicar.

Con un procedimiento definido, el primer usuario avisa por el canal de emergencia y deja de utilizar el equipo. El responsable activa el nivel alto, el soporte aísla los dispositivos afectados y revisa si existe propagación. Dirección prioriza los sistemas necesarios para atender pedidos. Se bloquean las cuentas sospechosas, se conservan los registros y se comprueba una copia antes de restaurarla.

El plan no garantiza que el incidente sea pequeño. Sí evita que la falta de coordinación lo agrave.

Prepara fichas de actuación para los escenarios más probables

El documento general debe complementarse con fichas breves. Cada ficha puede ocupar una o dos páginas y responder a cinco preguntas: cómo reconocer el incidente, a quién avisar, qué no debe hacerse, qué medidas iniciales están autorizadas y cuándo debe escalarse.

Para una pyme suelen resultar útiles las siguientes fichas:

• Ransomware o infección generalizada.
• Cuenta de correo comprometida.
• Fraude mediante cambio de cuenta bancaria.
• Pérdida o robo de un dispositivo.
• Caída de un servidor o aplicación crítica.
• Acceso no autorizado a información.
• Envío accidental de datos.

Estas fichas facilitan que una persona no técnica realice correctamente las primeras actuaciones sin entrar en procedimientos demasiado complejos.

Cómo probar si el plan funciona

Un documento no probado puede contener teléfonos antiguos, responsables que ya no trabajan en la empresa, accesos que nadie conoce o copias que no pueden restaurarse.

La prueba más sencilla es un ejercicio de mesa. Se plantea un escenario y cada participante explica qué haría. No es necesario interrumpir los sistemas reales.

Durante el ejercicio conviene comprobar:

• Cuánto se tarda en detectar y escalar el incidente.
• Si todos conocen su responsabilidad.
• Si los contactos están actualizados.
• Si existen canales alternativos de comunicación.
• Si pueden localizarse las copias y credenciales necesarias.
• Si el orden de recuperación coincide con las prioridades del negocio.
• Qué decisiones no están suficientemente definidas.

Después debe actualizarse el plan con los problemas detectados. También conviene revisarlo cuando cambien los sistemas, proveedores, responsables, centros de trabajo o procesos críticos.

Cuándo puede bastar un plan sencillo

Una empresa pequeña, con pocos sistemas y un proveedor técnico estable, puede empezar con un procedimiento breve: responsables, teléfonos, niveles de gravedad, inventario de servicios esenciales, instrucciones iniciales y fichas para los escenarios principales.

No es necesario implantar una plataforma compleja si el volumen de alertas es reducido y los sistemas pueden supervisarse adecuadamente con las herramientas existentes.

La prioridad debe ser eliminar dependencias, comprobar las copias, proteger las cuentas críticas, documentar los accesos y conseguir que todos sepan cómo comunicar una sospecha.

Cuándo necesitas un procedimiento más avanzado

Conviene ampliar el plan cuando la empresa tiene varios centros, empleados en remoto, numerosos proveedores tecnológicos, servicios disponibles fuera del horario laboral, datos especialmente sensibles o una elevada dependencia de sistemas que no pueden permanecer detenidos.

En estos casos puede ser necesario definir guardias, monitorización, herramientas centralizadas de registro, procedimientos técnicos por sistema, tiempos máximos de recuperación, acuerdos de escalado y simulacros más completos.

También debe revisarse con mayor detalle la coordinación entre el plan de respuesta, las copias de seguridad, la continuidad de negocio, la protección de datos y las condiciones del ciberseguro.

Errores habituales al preparar el plan

• Copiar una plantilla sin adaptarla a los sistemas reales.
• Asignar todas las decisiones a una sola persona.
• Guardar el único ejemplar dentro de la red corporativa.
• No diferenciar una avería de un incidente de seguridad.
• Restaurar sistemas sin comprobar antes la causa del ataque.
• No documentar las actuaciones realizadas.
• Dar por hecho que tener copias significa poder recuperar la actividad.
• No probar el procedimiento con empleados y proveedores.
• Olvidar los canales de comunicación alternativos.

Cómo puede ayudar Mafosan a preparar el plan

El trabajo debe comenzar revisando el entorno actual, no imponiendo una herramienta. Mafosan puede analizar los procesos críticos, los sistemas de los que dependen, los responsables, los proveedores y las excepciones que podrían bloquear la respuesta.

A partir de esa revisión se pueden identificar tareas no documentadas, accesos concentrados en una persona, copias que conviene comprobar, canales de comunicación insuficientes y sistemas que necesitan una prioridad de recuperación clara.

Después se define un procedimiento proporcionado al tamaño y al riesgo de la empresa: niveles de gravedad, funciones, vías de escalado, fichas de actuación, coordinación con proveedores y criterios para volver a poner los sistemas en servicio.

Cuando sea necesario, el plan puede complementarse con medidas técnicas de protección, monitorización, copias, control de accesos, segmentación y continuidad. La implantación debe quedar documentada y acompañada de una explicación práctica para las personas que tendrán que actuar.

Antes de ampliar herramientas o contratar nuevos servicios, conviene comprobar una cuestión básica: si mañana se bloquean el correo, el servidor o la aplicación principal, ¿sabría cada responsable qué hacer durante la primera hora? Mafosan puede revisar ese escenario, localizar los bloqueos y determinar qué nivel de preparación necesita realmente la empresa.