Plan de Respuesta ante Incidentes en alemán: ¿Qué debemos incluir para que funcione en una crisis real?

Pasamos por un proceso similar con un proveedor de la industria automotriz en Stuttgart. Los auditores no solo miran el texto, comprueban si se puede contactar con la persona de guardia (Rufbereitschaft) durante una crisis. Define sin falta en el documento un único canal de contacto en alemán disponible 24/7, como un correo de emergencia y una línea telefónica centralita.

Utiliza exactamente la terminología de los estándares alemanes de la BSI: Eindämmung (contención), Beseitigung (erradicación) y Wiederherstellung (recuperación). Si dejas entre paréntesis el equivalente en inglés para tu equipo técnico, el auditor no lo verá mal; al contrario, lo considerará un estándar de ingeniería internacional.

El año pasado nos pidieron 6.500 EUR en una consultora de Fráncfort para prepararnos este plan desde cero. Como nos pareció caro, hicimos el borrador nosotros mismos y le pagamos 1.200 EUR a un abogado local de TIC por una revisión legal de 4 horas. Pasamos la auditoría sin problemas así.

¿Tu cliente solo quiere el plan en papel o también espera el acta de un simulacro de escritorio (Tabletop Exercise) hecho en el último año? Las grandes corporaciones suelen preguntar cuándo fue la última vez que se probó este plan.

Lo primero que debes hacer es añadir al plan las plantillas de notificación preparadas para el DSGVO. Ten a mano en el archivo los datos de la empresa y el enlace al formulario de notificación que se enviará a la autoridad de protección de datos del estado correspondiente en caso de brecha. Cuando hay una crisis nadie tiene tiempo de ponerse a buscar formularios.

Hace dos años, en un caso de acceso sospechoso, mientras nuestro equipo técnico escribía en inglés, el directivo del cliente alemán no paraba de llamar en pánico hablando en alemán. Ninguna de las partes se entendía y por un retraso de 3 horas casi nos rescinden el contrato. Desde ese día asignamos al plan un único portavoz de crisis que habla alemán y el proceso se resolvió por completo.

q no os asusten los terminos en aleman pero ni se os ocurra entregarlo con traduccion de internet q el auditor se da cuenta en la primera pagina... lo mas limpio es hacer las notificaciones legales en aleman y los pasos de servidor y codigo en ingles como runbook.

Es importante que en dicho documento definan los roles por cargos y no por nombres propios. Para que el documento no pierda validez con los cambios de personal, les recomiendo apegarse al principio de responsabilidad basada en cargos y mantener de forma exhaustiva la tabla del historial de revisiones del documento.

Este hilo es para archivar.

Estoy de acuerdo.

Soy una pequeña empresa os lo cuento desde mi lado... Si no lo pones por escrito desde el principio, luego surgen discusiones.

Os explico cómo se hace en la práctica. Las decisiones apresuradas son las que hay que corregir seis meses después.

Yo pasé por esto, déjenme contarlo. Un informe de escaneo automático no es lo mismo que una prueba de penetración.

Eso es todo, disculpa si me he extendido demasiado.

Os cuento lo que me pasó a mí, a ver si os sirve de ayuda. Los primeros tres meses todo va bien, los problemas aparecen en el cuarto.

Espero que le sea útil.

Rara vez se encuentra un texto que lo explique tan claro. Las soluciones que funcionan a pequeña escala se rompen al crecer aprendí esto tarde.

Ánimo.

Lo que se dice aquí es exactamente lo que nos pasó. La gente no defiende el proceso, defiende la costumbre... La resistencia viene de ahí.

Si el permiso y el alcance no están por escrito, que no empiece la prueba.

Me pasó lo mismo. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

También me gustaría saber si alguien lo hace de otra manera.

¿Creen que esto funciona a cualquier escala? Antes de decidir, mirad qué datos tenéis en la mano.