En las primeras horas de un incidente de seguridad, no es posible completar una visión técnica de lo ocurrido. Puede que tu equipo siga tratando de entender qué cuenta se ha comprometido, a qué datos se ha accedido, hasta dónde ha llegado el atacante o si el incidente sigue activo.
Paralelamente a la investigación, la presión por actuar empieza de inmediato. Los empleados oyen fragmentos y necesitan saber qué hacer. Mientras tanto, los clientes pueden notar interrupciones del servicio, actividad sospechosa o solicitudes inusuales de restablecimiento de contraseña. Los socios comerciales pueden preguntar si sus sistemas o sus datos están implicados, y la dirección necesita decidir quién habla, qué se puede confirmar y cuándo el silencio se convierte en un riesgo en sí mismo.
La comunicación de un incidente de seguridad es difícil porque una empresa tiene que ser transparente antes de tener todas las respuestas, pero estar lo bastante informada como para no especular. Los comunicados enviados demasiado pronto pueden generar confusión, pero si se envían demasiado tarde pueden dañar la confianza, ralentizar las medidas de protección y suscitar 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 provocar un caos adicional. Incluso en empresas más grandes que cuentan con un plan, los pasos técnicos pueden estar documentados: contener el incidente, restablecer el acceso, preservar las pruebas, restaurar los sistemas. La comunicación puede quedar para después, hasta que de repente el incidente se agrava o cambia.
Parte de la preparación para un incidente consiste en saber quién necesita recibir información de tu parte, qué necesita saber, quién aprueba el mensaje y cómo comunicar los hechos con claridad mientras la investigación sigue avanzando.
La planificación de la comunicación forma parte de la respuesta a incidentes
La estructura de dos vías para tu respuesta
Empieza por el público, no por el anuncio
Cómo notificar una vulneración a los clientes
Cuándo notificar a los organismos reguladores
Prepara los mensajes antes de necesitarlos
Cómo puede ayudar Proton Pass for Business
La planificación de la comunicación forma parte de la respuesta a incidentes
La respuesta a incidentes suele describirse como un proceso técnico, pero un incidente real se convierte rápidamente en una cuestión interdepartamental. Los equipos de TI pueden contener la amenaza, pero la dirección, el departamento legal, la atención al cliente, recursos humanos, comunicación y operaciones necesitan saber qué está pasando y qué se les permite decir.
La guía del NCSC sobre comunicaciones eficaces en un ciberincidente(ventana nueva) —buenas prácticas generales que se aplican mucho más allá del Reino Unido— deja claro este punto: las organizaciones suelen dar prioridad a la respuesta técnica y relegan la comunicación a un segundo plano, aunque la comunicación determina cómo perciben a la organización el personal, los clientes, las partes interesadas y los medios durante una crisis.
No todos los incidentes requieren una declaración pública. Pero la empresa debería 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 las notificaciones regulatorias.
Un buen plan de respuesta a vulneraciones de datos debe incluir una capa de comunicación. Debe incluir detalles prácticos:
- Listas de contactos
- Plantillas de borradores
- Rutas de aprobación
- Revisión legal
- Puntos clave para la atención al cliente
- Responsabilidades de notificación a los reguladores
- Registros de lo que se envió, cuándo y a quién.
La estructura de dos vías para tu respuesta
La respuesta a incidentes necesita dos vías: la respuesta técnica y la respuesta comunicativa. Avanzan en paralelo y el responsable del incidente o de la respuesta conecta ambas.
| Vía izquierda: respuesta técnica | Vía derecha: respuesta comunicativa |
| Contener el incidente | Actualizar al equipo interno |
| Proteger las cuentas afectadas | Notificar a los clientes o socios afectados |
| Preservar las pruebas | Evaluar la notificación a los reguladores |
| Restaurar los sistemas | Mantener los mensajes coherentes a medida que cambian los hechos |
Esto te permite estructurar tu respuesta y garantizar que la colaboración continúe a medida que los miembros del equipo asumen distintas tareas.
Empieza por el público, no por el anuncio
La comunicación de un incidente de seguridad fracasa cuando un solo mensaje intenta servir a todos. Los empleados, los clientes, los socios y los reguladores necesitan distintos niveles de detalle porque tienen que tomar decisiones diferentes.
Tu equipo interno necesita claridad antes que nada
No necesitan cada detalle —especialmente mientras la investigación está en curso—, pero sí necesitan claridad sobre qué está confirmado, qué hacer ahora mismo y quién lidera la respuesta. Eso significa saber qué sistemas o cuentas evitar, qué medidas tomar de inmediato y qué preguntas siguen sin respuesta.
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 con los clientes con explicaciones improvisadas
- No reenviar mensajes sospechosos sin instrucciones.
Los clientes y los 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 a los clientes debería explicar:
- Qué se sabe
- Qué tipo de datos pueden verse afectados
- Qué está haciendo la empresa
- Qué deben hacer los clientes ahora, si es que deben hacer algo
- Dónde pueden consultar las actualizaciones.
El tono debe ser claro y directo. El cliente tampoco necesita detalles forenses, solo la información suficiente para protegerse.
Los reguladores necesitan un registro fáctico
Una notificación de vulneración al RGPD dirigida a la autoridad de control competente (la ICO(ventana nueva) en el Reino Unido, la autoridad nacional de protección de datos en cada Estado miembro de la UE) no es un mensaje de marketing ni una nota tranquilizadora para el cliente. Debe ser un registro fáctico de lo ocurrido, de quién se ha visto afectado y de lo que se está haciendo al respecto. En la sección sobre cómo notificar a los reguladores, que aparece más abajo, explicamos exactamente qué debe incluir.
Qué comunicar internamente
El personal forma parte de la respuesta, aunque no forme parte del equipo que gestiona el incidente. Un equipo confundido puede generar más ruido sin querer, compartir información inexacta o ralentizar la contención. En cambio, un equipo bien informado puede ayudar a proteger las cuentas, dirigir a los clientes al canal adecuado y evitar que crezcan las especulaciones.
Un anuncio interno de incidente de seguridad debe incluir:
- Un resumen claro de lo confirmado hasta el momento, en lenguaje sencillo
- Qué sistemas, cuentas, equipos o datos pueden estar afectados
- Qué está haciendo la empresa ahora
- Qué debe hacer el personal de inmediato
- Quién puede comunicarse con el exterior
- Dónde se publicarán las actualizaciones
- Cómo notificar actividad sospechosa relacionada
Hay aspectos que no deben incluirse: los vectores de ataque, el análisis de la causa raíz y las vulnerabilidades concretas, por lo general, no se comparten internamente mientras el incidente está activo y, a menudo, tampoco después, ya que esos detalles pueden ayudar a otros atacantes, generar exposición legal o revelar brechas que aún no se han cerrado.
El primer mensaje interno no tiene que responder a todas las preguntas, sino crear orden. Por ejemplo, puede que el personal deba restablecer las contraseñas solo mediante un proceso aprobado, evitar usar un sistema concreto, conservar los 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 buenas prácticas para la gestión de contraseñas. Durante un incidente, compartir credenciales de forma obsoleta o informal puede dificultar la comprensión de lo que quedó expuesto.
Las guías de Proton sobre protección frente a 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 se produzca 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 una vulneración a los clientes
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 apropiación 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 los clientes debe ser honesto sin ser alarmista. Debe evitar la jerga técnica, pero ser claro. Los clientes deben entender qué datos se han visto implicados, qué riesgo supone eso y qué deben hacer a continuación.
Una estructura útil es:
- Qué ocurrió, con un nivel de detalle adecuado para los clientes
- Cuándo se enteró la empresa
- Qué información o servicios pueden verse afectados
- Qué medidas ha tomado la empresa
- Qué deben hacer los clientes ahora
- Cómo facilitará la empresa las actualizaciones
- Con quién pueden contactar los clientes para resolver dudas
Cuando la investigación siga activa, debe indicarse. La precisión y la transparencia ayudan a recuperar la confianza. Ser abierto sobre el impacto no exige revelar detalles técnicos que podrían ayudar a alguien a repetir el ataque.
En incidentes graves, los clientes pueden necesitar instrucciones prácticas: cambiar una contraseña, activar la MFA, estar atentos a los correos electrónicos de suplantación, contactar con su banco e ignorar los mensajes que afirmen proceder 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 notificarse a las autoridades de control. Una vulneración notificable según el RGPD del Reino Unido y de la UE depende de si es probable que una vulneración de datos personales suponga un riesgo para los derechos y las libertades de las personas.
La guía de la ICO sobre vulneraciones de datos personales(ventana nueva) refleja un requisito común al RGPD del Reino Unido y al de la UE: las organizaciones deben notificar una vulneración notificable sin dilación indebida y a más tardar 72 horas después de tener conocimiento de ella. Una notificación tardía requiere explicar los motivos del retraso.
Ese plazo de 72 horas puede generar presión, sobre todo cuando la investigación aún está incompleta. El RGPD reconoce que las organizaciones pueden no disponer de todos los detalles en las primeras 72 horas, por lo que la información puede facilitarse por fases, siempre que se aporten nuevas actualizaciones sin dilación indebida.
Una notificación a la autoridad de control competente (la ICO en el Reino Unido o la autoridad nacional de protección de datos en la UE) suele 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 resolverla
La ICO también ofrece una página central para notificar una vulneración(ventana nueva) y dirigir a las organizaciones al proceso de notificación adecuado.
Para las personas afectadas, el umbral es distinto. Cuando es probable que una vulneración de datos personales suponga un alto riesgo para los derechos y las libertades de las personas, debe informárseles sin dilación indebida. Esta es una situación en la que los equipos legal, de privacidad y de dirección deben participar desde el principio, incluso en una pequeña empresa.
Prepara 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 o instrucciones que haya que actualizar y cambiar.
Por eso es útil preparar la estructura de los mensajes antes de necesitarlos. No el texto final, porque cada incidente será distinto, 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 público.
Un kit de comunicación sencillo basta 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 clave para la atención al cliente
- Una lista de verificación para la notificación a la autoridad de control
- Una lista de portavoces autorizados
- Contactos de escalado para asuntos legales, TI, privacidad, dirección y comunicación
- Un espacio donde registrar todas las actualizaciones y decisiones
La preparación ofrece al equipo un punto de partida seguro cuando la rapidez y la precisión son igual de importantes. Una plantilla preparada deja más atención para los hechos del incidente: qué ha pasado, a quién afecta, qué se ha hecho ya y qué debe hacer la gente a continuación.
Cómo puede ayudar Proton Pass for Business
La comunicación de un incidente de seguridad depende de los hechos. Cuanto más claro tenga una empresa el acceso antes de un incidente, más fácil será explicar qué ha pasado, 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, guardarlas en cajas fuertes cifradas, usar el relleno automático, compartir credenciales de forma segura, administrar llaves 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, administrar 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 se compromete la cuenta de un empleado, los administradores pueden revisar el acceso, identificar las credenciales compartidas que deban rotarse, aplicar una autenticación más sólida y reducir la dependencia de contraseñas copiadas por chat u hojas de cálculo.
Prepárate para responder antes de que se produzca una vulneración con un gestor de contraseñas para empresas.
