Cuando ocurre un incidente de TI —fallo, exfiltración de datos o sospecha de ransomware— surge, además de la recuperación técnica, una segunda tarea crítica: el control de la comunicación. Control de la comunicación en crisis significa aquí utilizar un núcleo de hechos versionado (Single Source of Truth, SSOT), roles definidos, una matriz de aprobación y fragmentos de texto predefinidos y conformes con la compliance. Para la dirección de TI, Cumplimiento y Seguridad no es algo prescindible: reduce los riesgos de responsabilidad, asegura los plazos de notificación y protege la operación y la reputación.
Por qué el control de la comunicación en crisis es un problema de cumplimiento y de operación
En las auditorías no importan las declaraciones redactadas con carga emocional, sino la trazabilidad y los procesos: ¿quién sabía qué y cuándo, quién autorizó y qué canal se utilizó? La falta de documentación aumenta el riesgo ante la autoridad de protección de datos, las aseguradoras y en disputas contractuales. Al mismo tiempo, las declaraciones contradictorias generan perturbaciones operativas: el Service Desk, la operación y la dirección dedican tiempo a correcciones en lugar de a la estabilización.
Principios básicos: informar rápido, no especular
Un buen control de la comunicación se basa en unas pocas reglas claras:
- SSOT: Un estado de hechos central y versionado que refleja la situación actual para todas las partes interesadas relevantes.
- Hechos vs. hipótesis: Señale claramente qué está confirmado y qué se está investigando —tanto internamente como ante las autoridades.
- Need‑to‑know: Las instrucciones internas están orientadas a la acción; se retienen los detalles que puedan perjudicar las investigaciones o ayudar a los atacantes.
- Aprobación antes del envío: La comunicación externa requiere al menos dos roles involucrados (p. ej. Responsable de incidentes + Cumplimiento/Comunicaciones).
- Orientación al destinatario: El personal necesita instrucciones de seguridad concretas; las autoridades, notificaciones estructuradas y verificables; la prensa, declaraciones cortas y claras.
Control de la comunicación en crisis: Gobernanza, roles y mandatos
Los roles definidos con claridad evitan la proliferación comunicativa descontrolada en la fase inicial. Un modelo práctico es:
- Responsable de incidentes (TI/Seguridad): Proporciona el estado técnico y actualiza el SSOT.
- Responsable de comunicaciones: Redacta los comunicados, gestiona los canales y coordina las solicitudes de prensa.
- Cumplimiento/Legal: Evalúa las obligaciones de notificación, los riesgos legales y las consecuencias de formulación.
- DPO: Decide sobre las notificaciones de protección de datos y la comunicación con las personas afectadas.
- HR: Es responsable de la comunicación con el personal y de los aspectos laborales.
- Dirección/C‑Level: Aprobación final en caso de altos riesgos reputacionales o de responsabilidad.
Es importante que estos roles tengan mandatos en el runbook —quién habla, quién representa a quién, quién puede aprobar en cada clase. Sin mandatos, en caso de emergencia se improvisa.
Matriz de aprobación según clases de riesgo
Los ciclos de aprobación se pueden acelerar si se categorizan según el riesgo:
- Clase A (interna, operativa): Instrucciones al personal — Aprobación: Responsable de incidentes + Seguridad/Cumplimiento.
- Clase B (externa, relacionada con el estado): Estado del servicio, afectaciones, soluciones alternativas — Aprobación: Responsable de incidentes + Comunicaciones.
- Clase C (declaraciones legales externas): Exfiltración de datos, personas afectadas, identificación de atacantes — Aprobación: Legal/Cumplimiento + Dirección (+ DPO en caso de datos personales).
Verificar rápidamente los puntos regulatorios clave
Qué obligaciones de notificación aplican depende del sector, del marco jurídico y del rol (responsable/procesador). Categorías relevantes son:
- RGPD: Violación de la protección de datos personales con plazos y requisitos de contenido.
- NIS2 / Derecho de seguridad informática: Vías de notificación para operadores de servicios críticos, contenidos mínimos y ventanas temporales.
- Obligaciones contractuales: SLA, contratos de tratamiento y requisitos de aseguradoras con plazos de notificación.
- Derecho bursátil: Obligaciones particulares de divulgación en caso de relevancia para el mercado de valores.
Pragmático es un breve template de checklist decisoria que Incident Lead y Legal completen en los primeros 60 minutos: comprobar la relevancia, registrar plazos, anotar canales de notificación y responsabilidades.
Núcleo informativo: hechos que necesita cada notificación
Un núcleo de hechos estructurado en el SSOT permite rellenar distintas plantillas de forma automatizada. Campos importantes:
- Descripción del incidente (sin especulaciones)
- Marcas temporales: detección, inicio de medidas
- Sistemas/servicios afectados
- Categorías de datos afectadas y alcance estimado
- Impacto en disponibilidad, integridad, confidencialidad
- Medidas adoptadas y siguiente momento de actualización
Paquete de plantillas: interno, autoridades, prensa — patrones pragmáticos
Las plantillas reducen el tiempo de aprobación y aseguran declaraciones consistentes. A continuación, patrones concentrados, listos para copiar.
Interno: información inicial (60–120 minutos)
Asunto: Incidente de seguridad TI – Estado actual y medidas
Breve: Estamos investigando un incidente de seguridad TI con posibles efectos en [..]. Por favor, siga las instrucciones obligatorias:
1) No abra archivos adjuntos/enlaces inesperados.
2) Informe mensajes sospechosos a: [Kanal].
3) Cambie contraseñas solo bajo indicación.
4) Utilice únicamente canales oficiales: [Intranet/Hotline].
5) Ante comportamiento inusual: aislar el dispositivo y notificar.
Hechos confirmados: [Palabras clave breves]
Sin aclarar: [Puntos pendientes]
Próxima actualización: [Hora]
Contacto: [Incident Lead | Communications]Autoridades supervisoras: notificación inicial (borrador estructurado)
Asunto: Notificación inicial incidente TI/protección de datos – [Organización]
1) Instancia de notificación: [Nombre, rol, contacto]
2) Descripción breve: [Tipo de incidente, detección, estado]
3) Sistemas/datos afectados: [Categoría/revisión]
4) Evaluación de riesgo provisional: [Valoración CIA]
5) Medidas: [Aislamiento, forense, mitigación]
6) Próximos pasos y momento para la actualización
Adjuntos: SSOT‑Snapshot, ID de incidente
Prensa: holding statement (primera declaración pública)
Estamos investigando un incidente de seguridad TI que afecta a [Services/Standorte]. Se han iniciado medidas de contención. Por el momento no podemos publicar detalles sobre el alcance y las causas. Información actual en: [Statuskanal].
Contacto de prensa: [Nombre, correo, teléfono]Implementación técnica: procesos, sistemas y evidencias
El control de comunicaciones no es una tarea separada — debe integrarse técnicamente en Incident‑Tracking, DMS y el control de canales:
- Incident‑Tracking: Vincule los eventos de comunicación con tareas en la herramienta IR o ITSM.
- Versionado: Utilice Wiki/DMS con historial o exporte snapshots como evidencia.
- RBAC: Permisos de escritura y aprobación para documentos y acciones de publicación.
Ejemplo de política: Aprobación y disciplina de canales (Resumen)
Política: Comunicación de crisis – Resumen
1) Canales oficiales: Interno [Intranet, IR‑Tool]; Externo [Statusseite, buzón de prensa]
2) No realizar declaraciones externas sin aprobación según la matriz
3) Las hipótesis deben marcarse como internas; externas solo con aprobación
4) Cada publicación recibe un ID y un registro de aprobaciones
5) Archivado de todas las publicaciones durante [Zeitraum]
Guía de decisión: Orden en la primera fase
- Inicializar y priorizar el SSOT
- Información inicial al personal con instrucciones de conducta
- Verificación regulatoria (DSGVO, NIS2, contratos)
- Holding Statement, cuando la visibilidad externa sea probable
- Establecer ritmo de actualizaciones (p. ej., interno 4h, externo 12–24h)
- Proveer al Service Desk con Q&A
Consecuencias de costes y operación
Las plantillas ahorran tiempo y reducen los costes posteriores: menos tickets, ciclos legales más cortos y menor comunicación errónea. Operativamente, la comunicación estructurada protege a los equipos técnicos frente a preguntas repetidas y a la descoordinación. Los principales impulsores de coste en la implementación son la integración de herramientas (IR‑Tool, Wiki, Statusseite), la formación de roles y los ejercicios tabletop. Los costes recurrentes afectan al mantenimiento de las plantillas y a las pruebas anuales.
Preparación para auditorías: Qué esperan los auditores
Los auditores analizan procesos, no solo declaraciones individuales. Debe poder demostrarse:
- Roles y mandatos documentados
- Registro de aprobaciones y comunicaciones vinculado al registro de incidentes
- Decisión justificable para/tras notificaciones regulatorias
- Lecciones aprendidas y actualización de las plantillas
Gestión de evidencias: Snapshot, hash y cadena de custodia
Para autoridades y auditores es importante que el snapshot del SSOT sea verificable, inalterado y enlazable. Un procedimiento práctico:
- Exportar el SSOT como PDF/JSON con sello temporal y Incident‑ID.
- Cálculo de una suma de comprobación criptográfica (p. ej., SHA256) y almacenamiento en un archivo compatible con WORM o en un DMS con seguridad de auditoría.
- Adjuntar versionado del registro de aprobaciones con nombre, rol y sello temporal.
- Si es necesario: notarización o timestamping mediante una TSP externa (Time Stamping Authority).
Ejemplo concreto: exportación vía Git/Wiki, archivado y suma de comprobación:
# SSOT exportieren (Beispiel für Git‑basiertes Wiki)
git archive --format=tar --output=/tmp/ssot_incident_123.tar HEAD:incidents/123
gzip /tmp/ssot_incident_123.tar
sha256sum /tmp/ssot_incident_123.tar.gz > /tmp/ssot_incident_123.sha256
# Archiv in revisionssichere Ablage verschieben
mv /tmp/ssot_incident_123.tar.gz /var/revsafe/archives/
mv /tmp/ssot_incident_123.sha256 /var/revsafe/archives/
Automatización: ¿Cuánto debería automatizarse?
La automatización reduce errores y acelera la comunicación, pero no debe sustituir la aprobación humana. Es recomendable:
- Rellenado automático de las plantillas desde el SSOT (reemplazo de variables).
- Disparadores para la notificación inicial interna tras la validación por el responsable del incidente.
- Archivado automático de la versión final con suma de comprobación y registro de aprobaciones.
Ejemplo: Llamada API breve a la página de estado externa que se ejecuta tras la aprobación:
curl -X POST "https://status.example.com/api/incidents"
-H "Authorization: Bearer $STATUS_API_TOKEN"
-H "Content-Type: application/json"
-d '{"incident_id":"INC-123","title":"Holding Statement","body":"Wir untersuchen...","status":"investigating"}'
Tabletop, Training und Messgrößen
Los ejercicios Tabletop son la forma más eficaz de validar la gobernanza y las plantillas. Los escenarios deben ser realistas (ransomware, fuga de datos, interrupción de servicio) y comprobar lo siguiente:
- Time‑to‑First‑Statement: tiempo desde el inicio del incidente hasta la primera comunicación.
- Vollständigkeit der Evidence: ¿estaba disponible y era inequívoco el SSOT‑Snapshot?
- Freigabezeiten: ¿cuánto duró el ciclo de aprobaciones en la clase B/C?
- Kommunikative Konsistenz: ¿utilizaron todos los canales la misma información aprobada?
Recomendación: Tabletop al menos una vez al año, idealmente cada seis meses si el riesgo es alto. Tras cada ejercicio: registro de acciones concreto con propietarios y plazos.
Implementierungsfahrplan (konkrete Schritte)
Un plan de implementación pragmático puede estructurarse en cuatro fases semanales:
- Semana 1: definir roles, esqueleto del Runbook, seleccionar lugar del SSOT (Wiki/Git/DMS).
- Semana 2: crear plantillas (internas, para autoridades supervisoras, prensa) y configurar la primera matriz de aprobaciones en la herramienta.
- Semana 3: integración de herramientas (IR‑Tool, página de estado, DMS), automatizaciones sencillas para snapshot/archivo.
- Semana 4: ejercicio Tabletop, integrar las lecciones aprendidas, poner en producción el proceso final de aprobaciones.
Según el tamaño de la empresa y la landscape de herramientas existente, la implementación puede ser más rápida o algo más lenta. Lo esencial es comenzar con un conjunto mínimamente funcional y mejorar de forma iterativa.
Verantwortlichkeiten und KPIs
Responsabilidades precisas evitan latencias. Posibles KPIs son:
- Time‑to‑First‑Statement (objetivo: < 2 horas, a nivel interno)
- Time‑to‑External‑Notification (objetivo: cumplimiento regulatorio, p. ej., DSGVO < 72 horas)
- Porcentaje de publicaciones con evidencia completa (objetivo: 100%)
- Ejecución de Tabletop: anual/semestral
Los KPIs deberían formar parte del panel de control de gobernanza de emergencias y reportarse regularmente a la dirección y a Compliance.
Post‑Incident: Lessons Learned und Vorlagenpflege
Tras la finalización de un incidente, el trabajo no ha terminado. El seguimiento incluye:
- Sesión formal de post‑mortem con documentación.
- Actualización del esquema SSOT y de las plantillas basándose en las brechas.
- Cambios en la matriz de aprobaciones si los ciclos fueron demasiado largos.
- Incorporación de nuevos procesos en los Runbooks y formación para los roles afectados.
Praktische Checkliste (erweitert, 15 Punkte)
- Definir SSOT, establecer formato y ubicación de almacenamiento
- Nombrar responsable de comunicaciones y su sustituto
- Incluir la matriz de aprobaciones A/B/C en el Runbook
- Proporcionar comunicación interna inicial + FAQ
- Preparar plantilla de primera notificación para autoridades
- Crear Holding Statement y bloques de Q&A
- Establecer y comunicar disciplina de canales
- Instruir al Service Desk con respuestas estandarizadas
- Definir estándar de evidencia (Snapshots, Freigaben, Versandnachweise)
- Implementar archivado automatizado con suma de comprobación
- Garantizar comunicación fuera de banda (teléfono, estado externo)
- Planificar y realizar ejercicio Tabletop
- Definir KPIs y reportarlos
- Revisión post‑incident con actualización de plantillas
Conclusión
El control de comunicaciones en crisis no es un proyecto editorial, sino una función de control que asegura la operación, el cumplimiento y el área jurídica. Un núcleo de hechos versionado, una gobernanza clara con mandatos y un conjunto de plantillas orientadas a los destinatarios reducen riesgos, aceleran los tiempos de respuesta y generan pruebas verificables. Empiece de forma pragmática: un conjunto pequeño compuesto por SSOT, tres plantillas, una matriz de aprobaciones y un ejercicio Tabletop proporciona la palanca más eficaz. Invierta a continuación en automatización y gestión de evidencias —eso se traduce directamente, en caso de emergencia, en capacidad de actuación y en resiliencia frente a auditorías.
Control de comunicaciones en crisis: aspectos de arquitectura y operación
Desde el punto de vista técnico, el control de comunicaciones se vuelve crítico cuando los sistemas que generan y publican las declaraciones fallan o están comprometidos. Planifique la infraestructura SSOT como un servicio de alta disponibilidad y con integridad de auditoría, con replicación georredundante y lógica append-only. Evite Single‑Point‑of‑Failure en páginas de estado, pipelines de lanzamiento y archivos de documentos: réplicas, copias de seguridad offline y un “Break‑Glass” probado para accesos de emergencia autorizados son necesarios.
Reglas operativas esenciales e indicaciones de integración:
- Firmado y sellado temporal: Firmar criptográficamente las aprobaciones finales (p. ej. GPG) y aplicar un sello de tiempo externo para contrarrestar alegaciones de manipulación.
- RBAC & separación de funciones: Los derechos técnicos de escritura, las aprobaciones y las publicaciones nunca deben corresponder a una sola persona; los audit‑logs deben vincularse automáticamente con las IDs de incidentes.
- Vías de reserva fuera de banda: Cadenas telefónicas, envíos masivos de SMS y un portal de estado alojado externamente como canales alternativos; realice pruebas de conmutación al menos cada seis meses.
- Integraciones: Vincule IR‑Tool, DMS, SIEM y la página de estado mediante APIs verificadas, pero asegure una ruta de aprobación manual por si fallan los servicios de autenticación.
- Riesgo del proveedor: Los contratos con proveedores de estado o de comunicaciones deben regular SLA, preservación de pruebas y acceso a datos en situaciones de emergencia.
- Seguridad de las evidencias: Archive los snapshots SSOT cifrados en un almacenamiento compatible con WORM y regule la gestión de claves, los accesos y la retención conforme a los requisitos legales.
Riesgo, costes y viabilidad: la redundancia y las firmas incrementan los esfuerzos iniciales, pero reducen de forma significativa los riesgos jurídicos y los tiempos de recuperación. Empiece de forma pragmática: una configuración HA mínima, aprobaciones firmadas y una ruta de reserva fuera de banda probada aportan un valor directo para la operación, el cumplimiento y la resiliencia ante auditorías.
En este tema también son relevantes la comunicación en crisis, la IT y las obligaciones de notificación ante las autoridades supervisoras. El artículo sitúa estos aspectos de forma comprensible y muestra en qué fijarse en el día a día.