En las primeras horas de un incidente de seguridad, no puede completar un panorama técnico de lo que sucedió. Es posible que su equipo todavía esté tratando de entender qué cuenta se comprometió, a qué datos se accedió, hasta dónde llegó el atacante o si el incidente sigue activo.
Junto con su investigación, la presión para actuar comienza de inmediato. Los empleados escuchan fragmentos y necesitan saber qué hacer. Mientras tanto, los clientes pueden notar interrupciones del servicio, actividad sospechosa o solicitudes inusuales de restablecimiento de contraseñas. Los socios comerciales pueden preguntar si sus sistemas o datos están involucrados, y los líderes deben decidir quién habla, qué se puede confirmar y cuándo el silencio se convierte en un riesgo por sí mismo.
La comunicación de incidentes de seguridad es difícil porque una empresa debe ser transparente antes de tener todas las respuestas, pero lo suficientemente informada como para no adivinar. Los mensajes enviados demasiado pronto pueden generar confusión, pero si se envían demasiado tarde pueden dañar la confianza, retrasar la acción protectora y plantear dudas regulatorias.
Es poco probable que las pequeñas y medianas empresas hayan creado o ensayado su plan de respuesta a incidentes, y esto puede causar caos adicional. Incluso para las empresas más grandes con un plan, los pasos técnicos pueden estar documentados: contener el incidente, restablecer el acceso, preservar la evidencia, restaurar los sistemas. La comunicación puede dejarse para después, hasta que de repente el incidente escala o cambia.
Parte de prepararse para un incidente significa saber quién necesita saber de usted, qué necesita saber, quién aprueba el mensaje y cómo comunicar los hechos con claridad mientras la investigación sigue en curso.
La planificación de la comunicación pertenece a la respuesta a incidentes
La estructura de dos vías para su respuesta
Comience por la audiencia, no por el anuncio
Cómo notificar a los clientes sobre una vulneración
Cuándo notificar a los organismos reguladores
Prepare los mensajes antes de necesitarlos
Cómo puede ayudar Proton Pass for Business
La planificación de la comunicación pertenece a la respuesta a incidentes
A la respuesta a incidentes a menudo se la describe como un proceso técnico, pero un incidente real se vuelve rápidamente interfuncional. Los equipos de TI pueden contener la amenaza, pero los líderes, el área legal, el soporte al cliente, recursos humanos, comunicaciones y operaciones necesitan saber qué está sucediendo y qué se les permite decir.
La guía del NCSC sobre comunicaciones efectivas en un incidente cibernético(nueva ventana) —una buena práctica general que se aplica mucho más allá del Reino Unido— deja claro este punto: las organizaciones a menudo priorizan la respuesta técnica y dejan la comunicación en segundo plano, aunque la comunicación da forma a cómo el personal, los clientes, las partes interesadas y los medios perciben a la organización durante una crisis.
No todos los incidentes necesitan una declaración pública. Pero la empresa debe saber de antemano quién decide qué comunicar, quién aprueba los mensajes externos, quién habla con los clientes y quién se encarga de los informes regulatorios.
Un sólido plan de respuesta a vulneraciones de datos debe incluir una capa de comunicación. Esto debe incluir detalles prácticos:
- Listas de contactos
- Plantillas de borradores
- Rutas de aprobación
- Revisión legal
- Puntos de conversación para el soporte al cliente
- Responsabilidades de notificación al regulador
- Registros de lo que se envió, cuándo y a quién.
La estructura de dos vías para su respuesta
La respuesta a incidentes necesita dos vías: la respuesta técnica y la respuesta de comunicación. Se ejecutan en paralelo y el responsable del incidente o líder de respuesta conecta ambas.
| Vía izquierda: respuesta técnica | Vía derecha: respuesta de comunicación |
| Contener el incidente | Actualizar al equipo interno |
| Proteger las cuentas afectadas | Notificar a los clientes o socios afectados |
| Preservar la evidencia | Evaluar la notificación al regulador |
| Restaurar los sistemas | Mantener los mensajes coherentes a medida que cambian los hechos |
Esto le permite estructurar su respuesta y garantizar que la colaboración continúe a medida que los miembros del equipo asumen diferentes tareas.
Comience por la audiencia, no por el anuncio
La comunicación de incidentes de seguridad falla cuando un solo mensaje intenta servir a todos. Los empleados, los clientes, los socios y los reguladores necesitan diferentes niveles de detalle porque tienen diferentes decisiones que tomar.
Su equipo interno necesita claridad primero
No necesitan cada detalle —especialmente mientras la investigación está en curso—, pero sí necesitan claridad sobre qué está confirmado, qué hacer en este momento y quién lidera la respuesta. Eso significa saber qué sistemas o cuentas evitar, qué acción tomar de inmediato y qué preguntas siguen abiertas.
Los empleados también necesitan saber qué no hacer. Por ejemplo:
- No hablar del incidente en público
- No restablecer credenciales fuera del proceso aprobado
- No contactar a los clientes con explicaciones improvisadas
- No reenviar mensajes sospechosos sin orientación.
Los clientes y socios necesitan saber cómo les afecta
Quieren saber si sus datos, su acceso, sus pagos, su servicio o sus operaciones se ven afectados. Una buena notificación al cliente debe explicar:
- Qué se sabe
- Qué tipo de datos podrían estar involucrados
- Qué está haciendo la empresa
- Qué deben hacer los clientes ahora, si es que deben hacer algo
- Dónde pueden obtener actualizaciones.
El tono debe ser sencillo y directo. El cliente tampoco necesita detalles forenses, solo necesita la información suficiente para protegerse.
Los reguladores necesitan un registro fáctico
Una notificación de vulneración conforme al GDPR a la autoridad de control correspondiente (la ICO(nueva ventana) en el Reino Unido, la autoridad nacional de protección de datos de cada Estado miembro de la UE) no es un mensaje de marketing ni una nota de tranquilidad para el cliente. Debe ser un registro fáctico de lo que ocurrió, quién se vio afectado y qué está haciendo al respecto. En la sección sobre la notificación a los reguladores que aparece a continuación, detallamos exactamente qué debe incluir.
Qué comunicar internamente
Sus empleados forman parte de la respuesta, incluso cuando no integran el equipo de incidentes. Un equipo confundido puede generar más ruido sin querer, compartir información inexacta o retrasar la contención. En cambio, un equipo bien informado puede ayudar a proteger cuentas, dirigir a los clientes al canal correcto y evitar que crezcan las especulaciones.
Un anuncio interno de incidente de seguridad debe incluir:
- Un resumen claro de lo que se ha confirmado hasta ahora, en lenguaje sencillo
- Qué sistemas, cuentas, equipos o datos podrían estar afectados
- Qué está haciendo la empresa ahora
- Qué deben hacer los empleados de inmediato
- Quién puede comunicarse con el exterior
- Dónde se publicarán las actualizaciones
- Cómo reportar actividad sospechosa relacionada
Hay aspectos que no deberían incluirse: los vectores de ataque, el análisis de la causa raíz y las vulnerabilidades específicas por lo general no se comparten internamente mientras un incidente está activo, y a menudo tampoco después, ya que esos detalles pueden ayudar a otros atacantes, generar exposición legal o dejar al descubierto brechas que aún no se han cerrado.
El primer mensaje interno no necesita responder todas las preguntas, necesita crear orden. Por ejemplo, es posible que los empleados deban restablecer contraseñas únicamente mediante un proceso aprobado, evitar usar un sistema específico, conservar correos electrónicos sospechosos o dejar de usar credenciales compartidas hasta que el equipo de respuesta termine la revisión.
También es esencial evaluar los controles de acceso existentes frente a las mejores prácticas para la gestión de contraseñas. Durante un incidente, compartir credenciales de forma desactualizada o informal puede dificultar la comprensión de lo que quedó expuesto.
Las guías de Proton sobre protección contra vulneraciones de datos y prevención de vulneraciones de datos para empresas explican cómo los controles por capas reducen la exposición antes de que ocurra una vulneración. Una gestión segura de credenciales es una de esas capas, porque ayuda a la empresa a saber qué cuentas existen, quién puede acceder a ellas y qué debe cambiarse rápidamente.
Cómo notificar a los clientes sobre una vulneración
Una notificación de vulneración de datos a los clientes es más difícil porque conlleva un peso reputacional y legal. Es posible que las personas estén preocupadas por el robo de identidad, la toma de control de cuentas, el fraude financiero o la exposición de información privada. También pueden sentirse frustradas porque la empresa no evitó el incidente.
Un buen mensaje para el cliente debe ser honesto sin ser alarmante. Debe evitar la jerga técnica, pero ser claro. Los clientes necesitan entender qué datos estuvieron involucrados, qué riesgo genera eso y qué deben hacer a continuación.
Una estructura útil es:
- Qué ocurrió, con un nivel de detalle apropiado para los clientes
- Cuándo se enteró la empresa
- Qué información o servicios podrían verse afectados
- Qué medidas ha tomado la empresa
- Qué deben hacer los clientes ahora
- Cómo proporcionará la empresa las actualizaciones
- Con quién pueden comunicarse los clientes si tienen preguntas
Cuando la investigación aún está en curso, esto debe divulgarse. La precisión y la transparencia ayudan a restaurar la confianza. Ser abierto sobre el impacto no requiere divulgar detalles técnicos que ayudarían a alguien a repetir el ataque.
En incidentes graves, es posible que los clientes necesiten instrucciones prácticas: cambiar una contraseña, activar el MFA, estar atentos a los correos electrónicos de suplantación, comunicarse con su banco e ignorar los mensajes que afirman provenir de la empresa a menos que lleguen por un canal oficial. La notificación debe hacer que esos pasos sean fáciles de entender.
Cuándo y cómo notificar a los organismos reguladores
No todos los incidentes de seguridad deben reportarse a las autoridades de control. Una vulneración notificable según el GDPR del Reino Unido y de la UE depende de si es probable que una vulneración de datos personales genere un riesgo para los derechos y las libertades de las personas.
La guía de la ICO sobre vulneraciones de datos personales(nueva ventana) refleja un requisito común al GDPR del Reino Unido y de la UE: las organizaciones deben reportar una vulneración notificable sin dilación indebida y a más tardar 72 horas después de tener conocimiento de ella. Un reporte tardío necesita justificar la demora.
Esa ventana de 72 horas puede generar presión, sobre todo cuando la investigación aún está incompleta. El GDPR reconoce que es posible que las organizaciones no tengan todos los detalles dentro de las primeras 72 horas, por lo que la información puede proporcionarse por fases, siempre que se den más actualizaciones sin dilación indebida.
Una notificación a la autoridad de control correspondiente (la ICO en el Reino Unido o la autoridad nacional de protección de datos en la UE) por lo general debe incluir:
- La naturaleza de la vulneración de datos personales
- Las categorías y el número aproximado de personas afectadas
- Las categorías y el número aproximado de registros de datos personales afectados
- El nombre y los detalles de contacto del DPO u otro punto de contacto
- Las posibles consecuencias de la vulneración
- Las medidas adoptadas o propuestas para abordarla
La ICO también ofrece una página central para reportar una vulneración(nueva ventana) y dirigir a las organizaciones al proceso de reporte correspondiente.
Para las personas afectadas, el umbral es diferente. Cuando es probable que una vulneración de datos personales genere un riesgo alto para los derechos y las libertades de las personas, se les debe informar sin dilación indebida. Esta es una situación en la que los equipos legal, de privacidad y de liderazgo deben participar desde el principio, incluso en una pequeña empresa.
Prepare los mensajes antes de necesitarlos
El peor momento para diseñar un proceso de comunicación es durante un incidente. No es útil emitir declaraciones u orientaciones que luego deban actualizarse y modificarse.
Por eso es útil preparar la estructura de sus mensajes antes de necesitarlos. No el texto final, porque cada incidente será diferente, sino la estructura: quién debe aprobar el mensaje, qué detalles deben incluirse, dónde se registrarán las actualizaciones y quién es responsable de cada audiencia.
Un kit de comunicación sencillo es suficiente para que la primera hora sea menos caótica. Puede incluir:
- Una plantilla de anuncio interno de incidente
- Una plantilla de notificación a clientes
- Una plantilla de actualización para socios o proveedores
- Puntos de conversación para el soporte al cliente
- Una lista de verificación para la notificación a la autoridad supervisora
- Una lista de portavoces autorizados
- Contactos de escalamiento para asuntos legales, TI, privacidad, liderazgo y comunicaciones
- Un lugar para registrar todas las actualizaciones y decisiones
La preparación brinda al equipo un punto de partida seguro cuando la velocidad y la precisión son importantes. Una plantilla preparada deja más atención para los hechos del incidente: qué ocurrió, quiénes se vieron afectados, qué se ha hecho ya y qué deben hacer las personas a continuación.
Cómo puede ayudar Proton Pass for Business
La comunicación de incidentes de seguridad depende de los hechos. Cuanto más claramente gestione una empresa el acceso antes de un incidente, más fácil será explicar qué ocurrió, qué puede verse afectado y qué se ha cambiado.
Un gestor de contraseñas para empresas como Proton Pass for Business ayuda a los equipos a reducir la exposición relacionada con las credenciales. Los empleados pueden generar contraseñas seguras, almacenarlas en bóvedas de contraseñas cifradas, usar el completado automático, compartir credenciales de forma segura, gestionar claves de acceso y usar la autenticación de dos factores integrada. Los administradores pueden aplicar políticas de contraseñas, revisar los registros de actividad, gestionar el acceso con controles basados en roles y admitir el aprovisionamiento mediante integraciones de SCIM y SSO.
Durante un incidente, estas funciones pueden ayudar a las empresas a actuar con más confianza. Si la cuenta de un empleado se ve comprometida, los administradores pueden revisar el acceso, identificar credenciales compartidas que quizá deban rotarse, aplicar una autenticación más estricta y reducir la dependencia de contraseñas copiadas por chat u hojas de cálculo.
Esté preparado para responder antes de que ocurra una vulneración con un gestor de contraseñas para empresas.
