Un tabletop de ciberseguridad es un simulacro de crisis basado en conversación: el equipo se sienta alrededor de una mesa (real o virtual), un facilitador plantea un escenario de incidente que avanza por fases y los participantes deben decidir, en voz alta y contra reloj, qué harían en cada momento. No se toca ningún sistema ni se lanza ningún exploit: lo que se pone a prueba son las decisiones, la coordinación y los planes de respuesta ante un ataque real. Este artículo explica qué es un tabletop, en qué se diferencia del Breach and Attack Simulation (BAS) y del red team, cómo se diseña un simulacro de ransomware o de brecha de datos y qué obligaciones de prueba imponen la NIS2 y DORA.
Lo esencial sobre el tabletop de ciberseguridad
- Es un ejercicio de discusión, no de ejecución: se prueban decisiones y planes, no sistemas.
- El marco de referencia es el NIST SP 800-84 y los paquetes CTEP de CISA, apoyados en la ISO 22398.
- Se ejecuta en dos niveles: comité de crisis (dirección) y equipo técnico de respuesta a incidentes.
- Se diferencia del BAS (automatizado y técnico) y del red team (adversario real) por su naturaleza conversacional.
- NIS2 y DORA lo tratan como una pieza obligatoria del programa de pruebas y de gestión de crisis.
Qué es un tabletop de ciberseguridad
Un tabletop, o TTX (tabletop exercise), es un ejercicio de discusión guiado por un facilitador en el que un grupo recorre un escenario de incidente hipotético para validar sus procedimientos de respuesta y su capacidad de tomar decisiones bajo presión. El NIST SP 800-84 (Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities) clasifica este tipo de pruebas dentro de los ejercicios basados en discusión, junto a seminarios, talleres y juegos, y los separa de los ejercicios basados en operaciones (drills, ejercicios funcionales y a escala completa), que sí movilizan sistemas y personal reales.
La clave es que en un tabletop nada se ejecuta de verdad. Cuando el facilitador anuncia que "el servidor de ficheros está cifrado y aparece una nota de rescate", nadie restaura una copia ni aísla una máquina: el participante que corresponda explica qué haría, con qué herramienta, a quién avisaría y en qué plazo. Ese formato permite ensayar la parte más frágil de cualquier respuesta a un incidente, la coordinación entre personas, sin riesgo para la operación y con un coste bajo. Organismos como CISA publican paquetes listos para usar (los Cybersecurity Tabletop Exercise Packages o CTEP) y la norma ISO 22398 ofrece directrices para diseñar y evaluar ejercicios de forma sistemática.
Tabletop, BAS y red team: tres pruebas distintas
Estas tres pruebas se mezclan a menudo en las propuestas comerciales, pero responden a preguntas diferentes y no se sustituyen entre sí.
| Prueba | Qué valida | Naturaleza | Quién participa |
|---|---|---|---|
| Tabletop (TTX) | Decisiones, planes y coordinación ante un incidente | Discusión, sin tocar sistemas | Dirección y equipo de respuesta |
| Breach and Attack Simulation | Si los controles detectan y bloquean técnicas conocidas | Automatizada y continua | Blue team y equipo de seguridad |
| Red team | Si un adversario real lograría sus objetivos sin ser detectado | Ejecución ofensiva contra el entorno real | Red team frente a defensa |
El Breach and Attack Simulation es una plataforma automatizada que lanza técnicas mapeadas a MITRE ATT&CK contra el entorno para comprobar, de forma continua, si el EDR, el SIEM y los controles las detectan y las bloquean. Es una prueba técnica y repetible, pero no dice nada sobre si el CEO sabría a quién llamar. El red team, por su parte, emula a un atacante real que persigue un objetivo concreto evadiendo la detección. El tabletop no compite con ninguno de los dos: se sitúa una capa por encima y prueba el músculo humano y organizativo que esas herramientas no tocan. Lo ideal es combinarlos, y ahí encaja bien el enfoque de purple team, porque un buen tabletop suele nacer de las lecciones de un ejercicio ofensivo previo.
Los dos niveles: comité de crisis y equipo técnico
Un simulacro serio no se dirige al mismo público: conviene distinguir dos tipos de tabletop, con objetivos y ritmo distintos.
El tabletop ejecutivo reúne al comité de crisis: dirección general, CISO, responsable legal, comunicación, delegado de protección de datos (DPO) y, según el sector, cumplimiento. Aquí no se discute qué comando lanzar, sino decisiones de negocio: si se paga o no un rescate, cuándo y cómo se notifica a la autoridad y a los afectados, qué se comunica a clientes y medios y cuándo se activa el ciberseguro. El objetivo es que esas decisiones se hayan pensado antes de la medianoche del día del incidente, no durante.
El tabletop técnico se dirige al equipo de respuesta a incidentes y al blue team. Aquí el guion baja al detalle: qué evidencia se captura primero respetando el orden de volatilidad, cómo se aísla un segmento sin perder telemetría, qué reglas del SIEM confirmarían el alcance y cómo se coordina con el proveedor de DFIR. Los mejores programas encadenan ambos niveles en el mismo escenario y descubren en directo dónde se rompe el flujo de información entre la sala técnica y el comité.
Cómo se diseña un simulacro: escenario, inyectos y roles
Escenario y objetivos
Todo empieza definiendo dos o tres objetivos medibles (por ejemplo, "verificar que el comité de crisis se convoca en menos de 60 minutos" o "comprobar que se identifica el plazo de notificación correcto"). A partir de ahí se construye un escenario verosímil y anclado en amenazas reales. Un buen escenario de 2026 no es genérico: parte de un vector plausible, como la explotación de una vulnerabilidad catalogada en el KEV de CISA (por ejemplo un fallo crítico de un servidor de correo del estilo de la CVE-2026-42897 de Microsoft Exchange), y escala hacia el objetivo del ejercicio.
Inyectos y guion
El escenario avanza mediante inyectos: mensajes que el facilitador introduce por fases para hacer evolucionar la crisis. Cada inyecto obliga a una nueva decisión. En los inyectos técnicos conviene mapear la actividad simulada del atacante a MITRE ATT&CK (por ejemplo, T1486 Data Encrypted for Impact para el cifrado o T1567 Exfiltration Over Web Service para la doble extorsión), de modo que el equipo relacione lo que ve con tácticas y técnicas concretas. Un guion de ransomware por fases podría verse así:
- T+0 min. El SOC detecta ejecuciones anómalas de
vssadmin delete shadowsen varios endpoints. - T+25 min. Aparecen notas de rescate; un actor tipo Akira o LockBit reclama pago y amenaza con publicar datos.
- T+60 min. Un periodista contacta a comunicación: dice tener una muestra de los datos.
- T+120 min. El backup principal figura como cifrado; solo queda una copia offline sin verificar.
Roles del ejercicio
Un tabletop bien montado reparte papeles claros: el facilitador conduce y lanza los inyectos, uno o varios evaluadores observan y anotan contra los objetivos, un recopilador de datos registra tiempos y decisiones, y los participantes responden desde su función real. Conviene ensayar también la comunicación fuera de banda, porque en un incidente real el correo corporativo o Teams pueden estar comprometidos y el comité no debería coordinarse por el mismo canal que controla el atacante.
Obligaciones de prueba en NIS2 y DORA
Los simulacros han dejado de ser una buena práctica opcional para convertirse en una expectativa regulatoria. La NIS2 (Directiva UE 2022/2555) exige en su artículo 21 medidas de gestión de riesgos que incluyen expresamente la gestión de incidentes, la continuidad de negocio y la gestión de crisis. Los ejercicios son la forma natural de evidenciar que esas medidas funcionan, y un tabletop debería ensayar los plazos de notificación de la directiva: alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes. Ensayar ese reloj en frío evita descubrir el día del ataque que nadie sabe quién firma la comunicación al CSIRT.
En el sector financiero, DORA (Reglamento UE 2022/2554) es más explícito. Su programa de pruebas de resiliencia operativa digital (artículos 24 a 27) incluye, entre las herramientas del artículo 25, las pruebas basadas en escenarios y la prueba de los planes de continuidad y de respuesta y recuperación, además del TLPT (threat-led penetration testing) para las entidades significativas al menos cada tres años. Un tabletop encaja de lleno en esa parte del programa, y DORA insiste en que la dirección se implique, justo lo que un tabletop ejecutivo pone a prueba. Toda esta capa conecta con la evaluación de resiliencia cibernética, donde los resultados del simulacro se traducen en métricas.
Métricas y el informe posterior
El valor de un tabletop no está en el día del ejercicio, sino en lo que se hace después. Durante la sesión se miden indicadores como el tiempo hasta convocar el comité, el tiempo hasta la primera decisión de contención y la adherencia a los plazos de notificación frente a un escenario de ransomware. Al terminar se hace una revisión en caliente (hot wash) y, en los días siguientes, se redacta un informe posterior a la acción (After-Action Report) con hallazgos, brechas del plan y acciones de mejora con responsables y fechas. Sin ese informe y su seguimiento, el simulacro se queda en una anécdota.
Preguntas frecuentes
¿En qué se diferencia un tabletop de un ejercicio funcional o de un red team?
Un tabletop es un ejercicio de discusión: se habla de lo que se haría, sin tocar sistemas. Un ejercicio funcional ya moviliza recursos reales (por ejemplo, restaurar de verdad una copia de seguridad) y un red team ejecuta un ataque real contra el entorno para medir la detección. El tabletop es el más barato y el de menor riesgo, y suele ser el punto de partida antes de pasar a pruebas operativas.
¿Cada cuánto se debe hacer un tabletop?
La recomendación habitual es al menos uno o dos al año a nivel ejecutivo y con mayor frecuencia a nivel técnico, además de repetirlo cuando cambie algo relevante: una fusión, un despliegue crítico o un incidente reciente con lecciones que ensayar. Bajo DORA, la cadencia forma parte del programa de pruebas documentado.
¿Quién debe participar en un simulacro de crisis?
Depende del nivel. El tabletop ejecutivo reúne a dirección, CISO, legal, comunicación y DPO, porque las decisiones son de negocio y de cumplimiento. El técnico reúne al equipo de respuesta, al blue team y al proveedor de DFIR. Los programas maduros conectan ambos en el mismo escenario para probar el traspaso de información.
¿Sirve un tabletop para cumplir NIS2 o DORA?
Es una pieza necesaria, pero no suficiente por sí sola. Ayuda a evidenciar las medidas de gestión de incidentes y de crisis de NIS2 y encaja en las pruebas basadas en escenarios de DORA, siempre que quede documentado con objetivos, participantes, hallazgos y plan de mejora. El cumplimiento se sostiene con todo el programa de pruebas, no con un ejercicio aislado.
Siguiente paso
Un tabletop solo aporta valor si el escenario es verosímil, el facilitador es exigente y el informe posterior se convierte en acciones concretas. En Secra diseñamos simulacros de crisis a medida de tu sector y tu perfil de amenaza, coordinamos el nivel ejecutivo y el técnico en el mismo escenario y entregamos un informe posterior a la acción con métricas y un plan de mejora priorizado. Si quieres saber cómo respondería hoy tu organización ante un ransomware, cuéntanos el contexto.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.