La temida constatación de que ha ocurrido algo, de que se ha accedido a los datos y de que ahora hay que informar a los clientes y al mundo. Años de duro trabajo para generar confianza y reputación ahora están en juego en la forma en que se aborda y comunica el incidente. Cuando esto sucede, si es que sucede, hay pasos clave que se deben tomar para mantener la confianza y mitigar el daño potencial. Según mi propia experiencia, el elemento número uno es la transparencia. Incluso si no se tiene toda la información, reconocer el incidente, aceptar la responsabilidad (y, al mismo tiempo, mostrar empatía, que es crucial) y compartir lo que se sabe permite a los clientes y a las autoridades hacer sus propias evaluaciones y brindar asistencia para reducir el riesgo. Es importante tener claro qué sucedió, qué sistemas se vieron afectados, a qué datos se accedió y qué significa eso para los clientes. Las investigaciones iniciales son clave para poder articular claramente los detalles a los clientes que pueden verse afectados. El shock inicial de que se le diga que ha ocurrido un incidente pronto pone en modo de acción al cerebro del cliente; Qué, cuándo, cómo y quién son preguntas válidas que los clientes tienen en relación con un incidente, y poder explicar esos detalles puede brindar cierta seguridad de que comprende lo que sucedió y cómo se asegurará de que no vuelva a suceder. Muchos clientes esperan y solicitan que se contrate a un equipo independiente de seguridad cibernética para garantizar que el incidente se comprenda y gestione por completo, por lo que es importante tener un acuerdo para poder recurrir a esa experiencia, mantener la confianza y brindar esa seguridad. Es este compromiso con los clientes y la comunidad lo que permite que las partes interesadas hagan preguntas, y poder lidiar con esa afluencia es algo que debería ser parte del plan de comunicación de respuesta a incidentes de cada organización. Quién programa las llamadas, cómo se programan las llamadas, quién las atiende, quién está autorizado a hacer declaraciones, cómo nos adaptamos las 24 horas del día, los 7 días de la semana, los 365 días del año, todo debe tenerse en cuenta a medida que se disponga de nueva información o se hagan declaraciones públicas. Compartir actualizaciones periódicas sobre el incidente y la investigación garantiza que una organización pueda controlar la narrativa y explicar las acciones tomadas, los próximos pasos y definir el final del incidente. Esto puede incluir a menudo recomendaciones para los clientes, como compartir los IoC, las TTP o los procesos que se deben seguir para proteger aún más los datos de los clientes. Por el contrario, la falta de información hará que las partes desinformadas formulen hipótesis y propaguen información errónea. A medida que el incidente y la investigación concluyen, es importante pensar en el cierre del incidente, cuáles son las acciones pendientes y los próximos pasos y cómo comunicamos las actualizaciones futuras. Herramientas como la revisión posterior al incidente, las lecciones aprendidas y la incorporación de los cambios necesarios para mejorar continuamente los procesos de respuesta y comunicación ante incidentes son pasos vitales para garantizar que se mantengan las mejores prácticas y que los procesos sigan evolucionando. Según nuestra propia experiencia, de aquí es de donde nacieron Project Bedrock y el Compromiso de Identidad Segura de Okta. Mecanismos que nos permitieron definir esas acciones pero, lo que es más importante, cómo nos aseguraríamos, como empresa, de que nuestro enfoque se mantendría, y podría mantenerse, en las mejoras definidas y los cambios culturales que necesitábamos hacer. Es fundamental que aprendamos de cada incidente de seguridad y, si bien ocurrirán incidentes, la forma en que la organización responda será la medida definitoria para los clientes y nuestro éxito. Stephen McDermid es el director de estrategia de Okta para EMEA