En gestión de incidentes, casi todas las organizaciones tienen algún documento: un “plan”, un procedimiento, una presentación, una carpeta en el gestor documental. El problema es que, bajo presión, esos artefactos suelen fallar por una razón simple: no fueron diseñados como una capacidad operativa, sino como un entregable.
Este artículo usa ISO/IEC 27035 como guía de trabajo para construir una capacidad que funcione en el momento en que más la necesitas: cuando hay incertidumbre, urgencia, ruido interno y riesgo real. La documentación importa, sí, pero como subproducto verificable de una operación real, no como sustituto.
Mensaje central: ISO/IEC 27035 sirve si la tratas como capacidad operativa: roles mínimos, rutinas, decisiones trazables y aprendizaje sistemático; la documentación vale solo en la medida en que demuestra que el proceso se ejecuta.
2. Alcance y reglas del texto (para no “inventar norma”)
Este contenido separa explícitamente tres tipos de afirmaciones:
- Según ISO/IEC 27035 (referencia general): hablamos del enfoque por fases y de la lógica de gestión del incidente.
- Interpretación: cómo aterrizar esa lógica a operación diaria (sin afirmar que sea un “requisito” literal).
- Buena práctica recomendada (no normativa): prácticas ampliamente usadas en la industria (por ejemplo, NIST SP 800-61 Rev. 2) para hacer el sistema más accionable, sin presentarlas como ISO.
Límites intencionales:
- No se citan cláusulas específicas ni se afirma “esto es requisito ISO” sin texto oficial reproducido/verificado.
- No se promete “cumplimiento”, “certificabilidad” o aprobación de auditoría como resultado garantizado.
- No se cubren obligaciones legales por país/industria; solo se reconoce que existen y deben mapearse aparte.
- No se listan playbooks exhaustivos por escenario; se muestra cómo estructurarlos y, sobre todo, cómo probarlos.
- No se generan datos “reales” (tiempos, volúmenes, tasas). Los ejemplos son plantillas o escenarios hipotéticos marcados como tales.
3. ISO/IEC 27035 como sistema que funciona bajo presión
Según ISO/IEC 27035 (referencia general): la serie se entiende como un proceso de gestión de incidentes por fases (preparar/planificar, detectar/reportar, evaluar/decidir, responder, aprender).
La diferencia entre un “proceso escrito” y un “proceso vivo” se ve en tres componentes que deben operar juntos:
- Personas: roles mínimos claros, aunque sean “sombreros” en una PyME.
- Procesos: rutinas repetibles, decisiones trazables, criterios simples.
- Tecnología: herramientas que soportan registro, evidencias y ejecución (no solo “visibilidad”).
Interpretación: si cualquiera de los tres falla, el sistema se convierte en teatro. La documentación puede estar perfecta, pero si no hay cadena de decisiones, canales de comunicación alternos y práctica real, se rompe cuando más importa.
4. El anti-patrón: “teatro documental” y “teatro de incidentes”
Dos fallas comunes:
4.1 Teatro documental
- Plan PDF largo que nadie abre.
- Presentaciones bonitas que describen una respuesta ideal.
- Procedimientos con pasos imposibles de ejecutar con el equipo real.
Señal: el material “suena profesional” pero no tiene trazas de uso: no hay tickets reales, no hay bitácoras, no hay ejercicios, no hay revisiones post-incidente.
4.2 Teatro de incidentes
- Roles nominales (“Incident Manager” en org chart) sin práctica.
- Simulacros simbólicos sin decisiones difíciles.
- Métricas como adorno, sin impacto en mejoras.
Señal: los ejercicios no cambian nada: misma confusión de comunicaciones, mismos accesos rotos, mismas demoras de escalamiento.
5. La salida práctica: operar ISO/IEC 27035 con evidencias vivas
La idea no es “crear documentos”, sino crear rutinas que dejan evidencia natural. Esa evidencia es el rastro que demuestra capacidad operativa.
Evidencias típicas (no exhaustivas):
- Tickets y registros del incidente (herramienta ITSM, sistema de casos, o repositorio simple).
- Bitácoras operativas (línea de tiempo, decisiones, acciones).
- Informes de cierre y aprendizajes.
- Revisión Post-Incidente (PIR) (Post-Incident Review): análisis de lo que pasó y qué cambiar.
- Registros de ejercicios (tabletop, simulacros técnicos) y planes de mejora.
- Métricas internas de detección y respuesta.
6. Preparación: lo mínimo viable que sí funciona
6.1 Roles mínimos (aunque sean “sombreros”)
Según ISO/IEC 27035 (referencia general): se requiere coordinación y gestión del incidente a través de fases.
Interpretación: en una organización pequeña, no necesitas un “equipo de 12”. Necesitas claridad en estas funciones mínimas:
- Liderazgo del incidente: decide prioridades, aprueba acciones disruptivas (aislar sistemas, cortar accesos), coordina.
- Operación técnica: ejecuta contención, erradicación y recuperación.
- Custodia de evidencias y registro: asegura trazabilidad (qué se hizo, cuándo, por qué).
- Comunicaciones internas: reduce ruido, alinea a negocio, gestiona expectativas.
- Enlace con terceros (si aplica): proveedor cloud, MSSP (Proveedor de Servicios de Seguridad Gestionada), forense, etc.
Si una persona cubre dos o tres roles, se documenta y se practica así.
6.2 Canales y “modo degradado”
Buena práctica recomendada (no normativa): asume que el correo o el chat corporativo pueden estar comprometidos o caídos.
Define:
- Un canal alterno (ej.: grupo de mensajería fuera del dominio corporativo, teléfono, puente de conferencia).
- Un directorio de contactos offline (mínimo: liderazgo, TI, seguridad, proveedor crítico).
- Reglas para “quién declara incidente” y “quién convoca”.
6.3 Criterios de severidad simples
Evita matrices que nadie entiende.
Interpretación: define 3–4 niveles con criterios claros:
- Impacto en negocio (servicio caído, datos expuestos, operación degradada).
- Alcance (un equipo, un segmento, múltiples sistemas).
- Urgencia (ataque activo vs hallazgo histórico).
- Obligaciones externas (si existen, se activan por separado).
6.4 Playbooks que se puedan ejecutar
No necesitas 40 playbooks. Necesitas pocos, bien practicados.
Ejemplos de familias (hipotéticos):
- Ransomware / cifrado.
- Compromiso de credenciales / acceso indebido.
- Exfiltración sospechosa.
- Caída por ataque de denegación de servicio.
- Malware en endpoint crítico.
Cada playbook debe responder a: qué detectar, qué decidir, qué hacer en 15/60/240 minutos, y qué evidencia guardar.
7. Detección y reporte: reducir el “tiempo hasta saber”
Según ISO/IEC 27035 (referencia general): la fase de detectar y reportar inicia el flujo formal.
Interpretación: aquí se gana o se pierde capacidad. Si tu “detección” depende de que alguien “se dé cuenta”, el resto del proceso llega tarde.
7.1 “Señales” operables
Define qué señales crean un caso:
- Alertas de EDR (Detección y Respuesta en Endpoints).
- Alertas de SIEM (Gestión de Información y Eventos de Seguridad).
- Reportes de usuario (phishing, comportamiento extraño).
- Hallazgos de auditoría o monitoreo (cambios no autorizados, logs ausentes).
- Indicadores de compromiso (IoC) (Indicador de Compromiso): hash, dominio, IP, etc.
No necesitas perfección: necesitas consistencia en qué se registra y cómo.
7.2 Registro desde el minuto cero
El registro no es “para el final”. Empieza desde el primer aviso.
Plantilla mínima de ticket:
- Fecha/hora de detección y de apertura.
- Fuente (alerta, usuario, tercero).
- Sistemas afectados (si se sabe).
- Hipótesis inicial (si la hay).
- Acciones realizadas y decisiones (con responsable y hora).
8. Evaluación y decisión: cuando el proceso se vuelve real
Esta es la fase donde aparece la presión: aislar o no aislar, parar un servicio o no, rotar credenciales o no, comunicar o no.
Interpretación: si tu proceso no incluye decisiones difíciles, no está listo.
8.1 Triángulo de decisión (simple y ejecutable)
- Qué tan confiable es la señal (evidencia actual).
- Qué tan grande es el impacto (real o potencial).
- Qué cuesta actuar (interrupción, riesgo operacional, pérdida de datos).
El objetivo no es “acertar siempre”, sino decidir rápido con trazabilidad y ajustar con nueva evidencia.
8.2 “Semáforo” de acciones disruptivas
Define de antemano qué acciones requieren aprobación (y de quién):
- Aislar segmentos.
- Deshabilitar cuentas privilegiadas.
- Detener servicios.
- Revocar tokens/llaves.
- Forzar resets masivos.
Esto evita que, en crisis, la gente discuta “quién puede autorizar” mientras el atacante se mueve.
9. Respuesta: contención, erradicación y recuperación (sin héroes)
Según ISO/IEC 27035 (referencia general): la respuesta incluye acciones para manejar el incidente y restaurar operación.
Buena práctica recomendada (no normativa): separar mentalmente:
- Contención: frenar daño y expansión (aislar, bloquear, segmentar).
- Erradicación: eliminar causa (remediar vulnerabilidad, limpiar malware, cerrar accesos).
- Recuperación: restaurar servicios con controles (backups verificados, validaciones).
9.1 Evidencia como disciplina operativa
No se trata de “forense perfecto” para todos los casos, sino de no destruir tu propia trazabilidad.
Prácticas simples:
- Capturar línea de tiempo (qué se vio y cuándo).
- Guardar logs relevantes (o al menos referencias).
- Registrar comandos/acciones importantes.
- Mantener versiones de configuraciones antes/después.
Límite: esto no garantiza validez legal universal; es evidencia operativa para aprender y demostrar ejecución.
9.2 Comunicación para reducir caos
Interpretación: el silencio crea rumores; el exceso crea ruido. Define cadencias:
- Actualización breve cada X tiempo (aunque sea “sin cambios”).
- Un solo canal para estado oficial.
- Mensajes centrados en impacto, acciones y próximos hitos.
10. Aprendizaje: la parte que convierte respuesta en capacidad
Según ISO/IEC 27035 (referencia general): el aprendizaje y la mejora cierran el ciclo.
El objetivo de una Revisión Post-Incidente (PIR) no es “culpar”, es mejorar el sistema.
10.1 PIR mínimo viable (plantilla)
- Qué pasó (hechos, no opiniones).
- Línea de tiempo (detectar → decidir → contener → recuperar).
- Qué funcionó.
- Qué falló (técnico y organizacional).
- Acciones correctivas (con responsable y fecha).
- Cambios en playbooks, monitoreo, accesos, backups, entrenamiento.
10.2 De hallazgos a cambios reales
Señal de madurez: el PIR produce cambios verificables:
- Ajustes en alertas o reglas.
- Endurecimiento de accesos privilegiados.
- Corrección de configuración.
- Mejoras en backups (pruebas de restauración).
- Actualización de playbooks.
- Nuevos ejercicios basados en el incidente.
Si el PIR termina en “se recomienda mejorar”, es teatro.
11. Métricas: señales internas, no trofeos
Métricas frecuentes:
- Tiempo Medio de Detección (MTTD) (Mean Time To Detect).
- Tiempo Medio de Recuperación/Resolución (MTTR) (Mean Time To Recover/Respond).
Riesgo de mala interpretación: convertirlas en KPI de vanidad o comparación externa.
Interpretación correcta: son señales internas de capacidad y de tendencia. Úsalas para:
- Ver si mejoras tu detección (MTTD baja con el tiempo).
- Ver si recuperas con menos fricción (MTTR baja o se estabiliza).
- Identificar cuellos de botella (aprobaciones, accesos, backups, comunicación).
Acompáñalas con métricas cualitativas:
- Porcentaje de incidentes con PIR completado.
- Porcentaje de acciones correctivas cerradas a tiempo.
- Número de ejercicios ejecutados y mejoras aplicadas.
No inventes metas “universales”. Usa tu propia línea base.
12. Cómo “probar” que la capacidad existe (sin auditoría ficción)
Si tu objetivo es demostrar capacidad operativa (internamente o frente a terceros), no empieces por “el documento final”. Empieza por evidencias vivas.
12.1 Paquete de evidencias (ejemplo)
- 3–5 tickets de incidentes (sanitizados) con trazabilidad.
- 1–2 bitácoras completas (línea de tiempo y decisiones).
- 1–2 PIR con acciones correctivas cerradas.
- Registro de 2 ejercicios tabletop (qué se simuló, decisiones, mejoras).
- Tendencia de MTTD/MTTR (sin compararte con otros).
- Lista de playbooks vigentes y fecha de última prueba.
Interpretación: esto muestra operación real bajo presión, no solo intención.
12.2 “Rituales” que sostienen el sistema
- Revisión mensual de incidentes y casi-incidentes.
- Ejercicio tabletop trimestral (o más frecuente si el riesgo lo exige).
- Revisión de contactos y canales alternos.
- Pruebas de restauración de backups (con evidencia de éxito/fallo).
- Refresco de playbooks tras cambios grandes (migración, nueva app crítica).
13. Lo que NO debes prometer (y por qué)
- “Con esto cumples ISO” → No. Esto construye capacidad, no garantiza certificación.
- “Evidencia = cobertura legal” → No. La legalidad depende de jurisdicción, contratos y regulaciones.
- “MTTD/MTTR demuestran seguridad” → No. Solo muestran señales de detección/respuesta, no ausencia de riesgo.
- “Un simulacro anual basta” → Depende. Sin práctica real y mejora, el simulacro es ritual vacío.
14. Cierre: documentación como rastro, no como sustituto
ISO/IEC 27035 funciona cuando deja de ser “un documento” y se convierte en una forma de operar: roles mínimos, decisiones registradas, comunicación en modo degradado, playbooks practicados y aprendizaje que cambia el sistema.La prueba más clara de preparación no es un PDF perfecto. Es poder responder bajo presi