Plantilla de Respuesta a Incidentes de Seguridad

Resumen

Una plantilla de respuesta a incidentes de seguridad te da un playbook estructurado para responder a eventos de seguridad. Cubre detección, clasificación, contención, erradicación, recuperación, comunicación y revisión post-incidente. La plantilla define acciones específicas, puntos de decisión y criterios de escalamiento para cada fase de la respuesta.

He visto equipos quedarse paralizados durante su primer incidente real porque no tenían un playbook — todos sabían qué hacer en teoría, pero bajo presión, con alertas disparando y el CEO pidiendo actualizaciones, la teoría se cae. Una plantilla convierte el pánico en proceso.

Las seis fases fluyen secuencialmente, aunque en la práctica la contención y la erradicación suelen superponerse:

Cuándo Usar

• Respondiendo a un incidente de seguridad activo
• Preparando playbooks de respuesta a incidentes para diferentes tipos de ataque
• Entrenando a miembros del equipo de respuesta a incidentes
• Realizando ejercicios de simulación (tabletop exercises)
• Documentando procedimientos de respuesta a incidentes para cumplimiento

Para un marco más amplio, ver Plantilla de Plan de Respuesta a Incidentes. Para prácticas de revisión post-incidente, ver Guía de Postmortems.

Solución

# Plantilla de Respuesta a Incidentes de Seguridad — `<Nombre de Organización>`

## Metadatos del Incidente

| Campo | Valor |
|-------|-------|
| ID del Incidente | SEC-INC-2026-001 |
| Tipo de Incidente | <Fuga de Datos / Malware / Phishing / DDoS / Insider / Acceso No Autorizado> |
| Severidad | <SEV-0 / SEV-1 / SEV-2 / SEV-3> |
| Estado | <Detectado / Investigando / Contenido / Erradicado / Recuperado / Cerrado> |
| Detectado | <AAAA-MM-DD HH:MM TZ> |
| Reportado por | <nombre / sistema> |
| Comandante de Incidente | <nombre> |
| Líder Técnico | <nombre> |
| Sistemas afectados | <lista> |
| Usuarios afectados | <cantidad o "desconocido"> |
| Datos involucrados | <tipo, clasificación, volumen> |

## 1. Clasificación del Incidente

### Matriz de Tipos de Incidente

| Tipo | Descripción | Severidad por Defecto | Escalamiento |
|------|-------------|----------------------|-------------|
| Fuga de Datos | Acceso no autorizado o exfiltración de datos sensibles | SEV-0 | CEO, CISO, Legal, PR |
| Malware / Ransomware | Software malicioso en sistemas de la organización | SEV-0/SEV-1 | CISO, VP Eng, IT |
| Phishing | Intentos engañosos de obtener credenciales o datos | SEV-2 | Líder de Seguridad |
| Ataque DDoS | Denegación de servicio distribuida | SEV-1 | DevOps, CISO |
| Acceso No Autorizado | Entrada no autorizada a sistemas o datos | SEV-1 | CISO, VP Eng |
| Amenaza Interna | Actividad maliciosa por personal autorizado | SEV-1 | CISO, HR, Legal |
| Ataque a App Web | Ataque dirigido a vulnerabilidades de aplicaciones web | SEV-1 | Líder de Seguridad, Líder de Dev |
| Abuso de API | Abuso o explotación de endpoints de API | SEV-2 | Líder de Seguridad, Líder de API |
| Ataque a Cadena de Suministro | Compromiso vía proveedor o dependencia de terceros | SEV-0 | CEO, CISO, Legal |
| Seguridad Física | Acceso físico no autorizado a instalaciones | SEV-2 | Seguridad, Instalaciones |

### Evaluación de Severidad

| Factor | SEV-0 (Crítica) | SEV-1 (Alta) | SEV-2 (Media) | SEV-3 (Baja) |
|--------|-----------------|--------------|---------------|--------------|
| Sensibilidad de datos | PII/PHI/financieros | Interno confidencial | Interno no sensible | Datos públicos |
| Sistemas afectados | Producción crítico | Producción no crítico | Staging | Desarrollo |
| Usuarios afectados | Todos | Múltiples equipos | Un equipo | Un usuario |
| Explotación activa | Confirmada activa | Probablemente activa | Sospechada | Sin evidencia |
| Impacto de negocio | Interrupción total | Degradación mayor | Degradación menor | Sin impacto |

## 2. Detección y Evaluación Inicial

Para prácticas más amplias de respuesta a incidentes, ver la [Guía de Respuesta a Incidentes](/es/guides/observability/incident-response-guide/).

### Fuentes de Detección

| Fuente | Señal | Método de Alerta | Tiempo de Respuesta |
|--------|-------|------------------|---------------------|
| Correlación SIEM | Múltiples logins fallidos + login exitoso desde IP nueva | Auto-page on-call | 15 min |
| Alerta IDS/IPS | Firma de ataque conocida detectada | Auto-page on-call | 15 min |
| Alerta WAF | Patrón de SQL injection o XSS detectado | Auto-page on-call | 15 min |
| EDR de endpoint | Malware detectado en estación de trabajo | Auto-page on-call | 15 min |
| Reporte de usuario | Usuario reporta email o actividad sospechosa | Ticket de help desk | 1 hora |
| Reporte externo | Investigador de seguridad o notificación de vendor | Email a security@ | 4 horas |
| Feed de threat intel | IOCs coinciden con tráfico interno | SIEM auto-alert | 30 min |
| Alerta de seguridad cloud | Alerta de AWS GuardDuty / Azure Sentinel | Auto-page on-call | 15 min |

### Checklist de Evaluación Inicial

| Verificación | Pregunta | Acción si Sí | Acción si No |
|--------------|----------|--------------|--------------|
| ¿Es un evento de seguridad real? | ¿La alerta indica actividad maliciosa real? | Clasificar tipo de incidente | Cerrar como falso positivo |
| ¿Está la amenaza activa? | ¿El atacante sigue en el sistema? | Iniciar contención | Investigar timeline |
| ¿Hay datos sensibles involucrados? | ¿Podrían PII, PHI o datos financieros estar expuestos? | Notificar a Legal + CISO | Continuar investigación |
| ¿Está producción afectada? | ¿Hay sistemas de producción impactados? | Notificar a VP Engineering | Continuar investigación |
| ¿Es un patrón de ataque conocido? | ¿Se ha visto este tipo de ataque antes? | Aplicar playbook conocido | Investigar desde cero |

## 3. Procedimientos de Contención

Para medidas de control de acceso a implementar antes de un incidente, ver la [Plantilla de Política de Control de Acceso](/es/docs/access-control-policy-template/).

### Acciones Inmediatas de Contención

| Tipo de Incidente | Acción | Comando/Procedimiento | Aprobación | Duración |
|-------------------|--------|----------------------|------------|----------|
| Fuga de Datos | Aislar sistemas afectados | `kubectl cordon <node>; kubectl drain <node>` | Líder Técnico | 5 min |
| Fuga de Datos | Bloquear IP de exfiltración | Actualizar reglas de WAF / firewall | Líder Técnico | 5 min |
| Malware | Aislar host infectado | Aislamiento de red vía cambio de VLAN | Líder Técnico | 10 min |
| Malware | Deshabilitar cuenta afectada | `aws iam update-access-key --status Inactive` | Líder Técnico | 5 min |
| Ransomware | Desconectar shares afectados | Deshabilitar shares SMB, aislar segmento de red | IC | 10 min |
| Phishing | Deshabilitar URLs de phishing | Añadir URLs a blocklist, reglas WAF | Líder Técnico | 15 min |
| Phishing | Revocar tokens comprometidos | Forzar re-autenticación vía IdP | Líder Técnico | 10 min |
| DDoS | Activar protección DDoS | Activar AWS Shield Advanced / Cloudflare | DevOps | 5 min |
| DDoS | Rate limit de tráfico entrante | Actualizar load balancer / reglas WAF | DevOps | 10 min |
| Acceso No Autorizado | Revocar tokens de sesión | Forzar logout vía API admin del IdP | Líder Técnico | 5 min |
| Acceso No Autorizado | Resetear contraseñas comprometidas | Forzar reset de contraseña vía IdP | Líder Técnico | 10 min |
| Amenaza Interna | Suspendar acceso de usuario | Deshabilitar cuenta AD, revocar tokens | IC + HR | 15 min |
| Amenaza Interna | Preservar evidencia | Capturar imagen de disco, memory dump | Líder Técnico | 30 min |
| Ataque a App Web | Bloquear IP atacante | Regla WAF: denegar IP | Líder Técnico | 5 min |
| Ataque a App Web | Deshabilitar endpoint vulnerable | `kubectl scale deployment <name> --replicas=0` | IC | 5 min |
| Abuso de API | Aplicar rate limiting | Actualizar reglas de throttling del API gateway | Líder Técnico | 10 min |
| Abuso de API | Revocar API keys abusadas | Eliminar o rotar API keys | Líder Técnico | 10 min |
| Cadena de Suministros | Deshabilitar dependencia afectada | Revertir a versión anterior, fijar dependencia | DevOps | 30 min |
| Cadena de Suministros | Revocar credenciales CI/CD | Rotar todas las credenciales de pipeline | DevOps | 1 hora |

### Preservación de Evidencia

| Tipo de Evidencia | Método de Recolección | Almacenamiento | Retención |
|-------------------|----------------------|----------------|-----------|
| Logs del sistema | Exportar a bucket seguro | S3 con legal hold | 7 años |
| Tráfico de red | Captura PCAP | S3 con legal hold | 90 días |
| Imagen de disco | `dd` o snapshot | S3 cifrado | 7 años |
| Memory dump | Volatility / LiME | S3 cifrado | 90 días |
| Logs de aplicación | Exportar del sistema de logging | S3 con legal hold | 7 años |
| Logs de acceso | Exportar del IdP / cloud | S3 con legal hold | 7 años |
| Registros de comunicación | Exportar emails, chat logs | S3 con legal hold | 7 años |

### Log de Decisiones de Contención

| Hora | Decisión | Justificación | Aprobado Por | Impacto |
|------|----------|---------------|--------------|---------|
| 14:05 | Aislado web-server-03 | Malware confirmado beaconing a C2 | Líder Técnico | App web offline |
| 14:10 | Bloqueado 185.220.101.5 | IP C2 de threat intel | Líder Técnico | Sin impacto |
| 14:15 | Deshabilitado usuario jsmith | Cuenta usada para movimiento lateral | IC + HR | Usuario bloqueado |
| 14:20 | Rotados todos los tokens CI/CD | Posible exposición de tokens | DevOps | Pipeline pausado |

## 4. Procedimientos de Erradicación

Para gestión proactiva de vulnerabilidades que previene incidentes, ver la [Plantilla de Proceso de Gestión de Vulnerabilidades](/es/docs/vulnerability-management-process-template/).

### Pasos de Erradicación por Tipo de Incidente

| Tipo de Incidente | Paso 1 | Paso 2 | Paso 3 | Paso 4 |
|-------------------|--------|--------|--------|--------|
| Fuga de Datos | Identificar punto de entrada | Parchear vulnerabilidad explotada | Remover herramientas/backdoors del atacante | Rotar todas las credenciales |
| Malware | Ejecutar scan completo anti-malware | Remover archivos maliciosos | Parchear vector de infección | Reconstruir sistemas afectados |
| Ransomware | Identificar strain de ransomware | Remover de todos los sistemas | Restaurar desde backups limpios | Parchear vector de infección |
| Phishing | Identificar todos los emails de phishing | Remover de los buzones | Resetear credenciales comprometidas | Desplegar reglas de seguridad de email |
| DDoS | Identificar vector de ataque | Implementar protección DDoS permanente | Optimizar configuración de red | Monitorear recurrencia |
| Acceso No Autorizado | Identificar método de acceso | Cerrar vector de acceso | Auditar todos los cambios del atacante | Rotar todas las credenciales potencialmente expuestas |
| Amenaza Interna | Identificar alcance de acceso | Revocar todo el acceso | Auditar todas las acciones tomadas | Coordinar con HR/Legal |
| Ataque a App Web | Identificar vulnerabilidad explotada | Desplegar fix | Remover web shells del atacante | Auditar persistencia |
| Abuso de API | Identificar endpoint abusado | Implementar rate limiting adecuado | Auditar logs de acceso a API | Rotar keys abusadas |
| Cadena de Suministros | Identificar componente comprometido | Reemplazar con versión limpia | Auditar todos los sistemas que usan el componente | Implementar scanning de dependencias |

### Verificación de Erradicación

| Verificación | Método | Criterio de Aprobación | Responsable |
|--------------|--------|----------------------|-------------|
| Sin malware activo | Scan completo con EDR | 0 amenazas detectadas | Seguridad |
| Sin acceso no autorizado | Auditar logs de acceso | Sin anomalías en 72 horas | Seguridad |
| Sin backdoors | Port scan + auditoría de procesos | Sin servicios inesperados | Seguridad |
| Sin comunicación C2 | Análisis de tráfico de red | Sin beaconing detectado | Seguridad |
| Vulnerabilidades parcheadas | Re-scan de sistemas afectados | 0 hallazgos críticos/altos | Seguridad |
| Credenciales rotadas | Verificar todas las credenciales cambiadas | Todas las credenciales actualizadas | DevOps |
| Estado limpio del sistema | Comparar con baseline conocido | Coincide con baseline | DevOps |

## 5. Procedimientos de Recuperación

### Pasos de Recuperación

| Paso | Acción | Verificación | Duración | Aprobación |
|------|--------|--------------|----------|------------|
| 1 | Restaurar desde backup limpio | Integridad de backup verificada | 1-4 horas | IC |
| 2 | Reconstruir sistemas afectados | Configuración coincide con baseline | 2-12 horas | DevOps |
| 3 | Desplegar versiones parcheadas | Smoke tests pasan | 1-2 horas | Líder de Dev |
| 4 | Restauración gradual de tráfico | Health checks pasan, monitoreo normal | 30 min - 2 horas | IC |
| 5 | Comunicación a usuarios | Usuarios notificados de restauración | 30 min | Líder de Comms |
| 6 | Monitoreo intensivo 72h | Sin anomalías detectadas | 72 horas | Seguridad |
| 7 | Restauración completa del servicio | Todos los servicios operacionales | Después de 72h limpio | IC |

### Validación de Recuperación

| Verificación | Método | Criterio de Aprobación | Responsable |
|--------------|--------|----------------------|-------------|
| Todos los servicios online | Endpoints de health check | 100% healthy | DevOps |
| Rendimiento normal | Comparar con métricas baseline | Dentro del 10% del baseline | DevOps |
| Sin pérdida de datos | Verificación de integridad de datos | Todos los registros intactos | Líder de Base de Datos |
| Acceso de usuario restaurado | Test de autenticación | Todos los usuarios pueden log in | DevOps |
| Monitoreo activo | Verificar todas las alertas configuradas | Todos los monitores activos | Seguridad |
| Backups actualizados | Verificar backup completado | Backup dentro de 24 horas | DevOps |

## 6. Plan de Comunicación

### Comunicación Interna

| Audiencia | Canal | Frecuencia | Contenido | Responsable |
|-----------|-------|------------|-----------|-------------|
| Equipo IR | Canal de incidente en Slack | Tiempo real | Actualizaciones técnicas | Scribe |
| Engineering | Slack #incidents | Cada 30 min | Estado, impacto | Líder de Comms |
| Todos los empleados | Email | Cada 2 horas | Estado de alto nivel | Líder de Comms |
| Equipo ejecutivo | Teléfono / Slack | Cada 1 hora | Impacto de negocio, riesgo | IC |
| Junta | Email vía CEO | Dentro de 24 horas | Resumen, acciones tomadas | CEO |

### Comunicación Externa

| Audiencia | Canal | Momento | Contenido | Aprobación |
|-----------|-------|---------|-----------|------------|
| Clientes | Status page | Dentro de 30 min | Impacto del servicio | IC + Comms |
| Clientes | Email | Dentro de 24 horas | Notificación detallada | IC + Legal |
| Cuerpos regulatorios | Notificación oficial | Según regulación | Divulgación requerida | Legal |
| Law enforcement | Teléfono / email | Si actividad criminal | Reporte de incidente | Legal |
| Medios | Comunicado de prensa | Si visible públicamente | Declaración aprobada | CEO + Comms |

### Plantillas de Comunicación

#### Status Page Inicial

[INVESTIGATING] Estamos investigando un incidente de seguridad que afecta a . Impacto: <descripción del impacto>. Inicio: . Estamos trabajando para identificar la causa y actualizaremos dentro de 30 minutos.

#### Actualización de Contención

[IDENTIFIED] Hemos identificado la causa del incidente de seguridad y estamos implementando medidas de contención. Causa: <descripción breve>. Impacto: . Próxima actualización: .

#### Actualización de Resolución

[RESOLVED] El incidente de seguridad ha sido resuelto. Duración: a . Causa raíz: <descripción breve>. Acciones tomadas: . Se publicará un reporte post-incidente detallado dentro de 2 semanas.

## 7. Notificación Regulatoria

| Regulación | Plazo | Destinatario | Disparador | Responsable |
|------------|-------|--------------|------------|-------------|
| GDPR | 72 horas | Autoridad supervisora | Fuga de datos personales | Legal |
| GDPR | Sin demora indebida | Sujetos de datos | Alto riesgo a derechos | Legal |
| CCPA | Sin demora irrazonable | Consumidores afectados | Fuga de PII | Legal |
| HIPAA | 60 días | Secretario de HHS | Fuga de PHI (500+) | Legal |
| HIPAA | 60 días | Individuos afectados | Fuga de PHI | Legal |
| PCI-DSS | Inmediatamente | Marcas de tarjetas / adquirente | Fuga de datos de tarjetas | Legal |
| SOC 2 | Según acuerdo | Clientes | Incidente de seguridad | Account Mgr |
| Leyes estatales | 1-90 días (varía) | AG estatal + residentes | Según ley estatal | Legal |

## 8. Revisión Post-Incidente

### Proceso de Revisión

| Paso | Acción | Responsable | Duración |
|------|--------|-------------|----------|
| 1 | Programar reunión de revisión | IC | Dentro de 5 días |
| 2 | Recolectar toda la evidencia | Scribe | Antes de la reunión |
| 3 | Escribir timeline del incidente | Scribe | Antes de la reunión |
| 4 | Conducir revisión blameless | Todos los stakeholders | 1-2 horas |
| 5 | Identificar causa raíz | Líder Técnico | Durante la revisión |
| 6 | Definir acciones correctivas | Equipo | Durante la revisión |
| 7 | Asignar items de acción | IC | Durante la revisión |
| 8 | Publicar post-mortem | Scribe | Dentro de 2 semanas |
| 9 | Hacer seguimiento de items de acción | IC | Hasta completación |

### Plantilla de Timeline del Incidente

| Hora | Evento | Fuente | Acción Tomada |
|------|--------|--------|---------------|
| 14:00 | Alerta SIEM: brute force desde 185.220.101.5 | SIEM | Auto-page on-call |
| 14:05 | On-call reconoce alerta | On-call | Iniciar investigación |
| 14:10 | Confirmado acceso no autorizado a web-server-03 | On-call | Clasificar como SEV-1 |
| 14:15 | Comandante de Incidente asignado | IC | Crear canal de incidente |
| 14:20 | Sistema afectado aislado | Líder Técnico | kubectl cordon + drain |
| 14:30 | IP del atacante bloqueada en WAF | Líder Técnico | Actualización de regla WAF |
| 14:45 | Imagen forense capturada | Líder Técnico | dd a S3 cifrado |
| 15:00 | Causa raíz: vulnerabilidad RCE sin parchear | Líder Técnico | Documentar hallazgo |
| 15:30 | Parche desplegado a todos los sistemas | DevOps | kubectl rollout restart |
| 16:00 | Sistemas verificados limpios | Seguridad | Scan completo, 0 hallazgos |
| 16:30 | Servicios restaurados | DevOps | Health checks pasan |
| 17:00 | Monitoreo intensivo activado | Seguridad | Vigilancia de 72 horas |

### Plantilla de Acciones Correctivas

| ID | Acción | Prioridad | Responsable | Fecha Límite | Estado |
|----|--------|-----------|-------------|---------------|--------|
| CA-001 | Parchear vulnerabilidad RCE en todos los servidores | P0 | DevOps | 2026-06-17 | Abierto |
| CA-002 | Implementar gestión automatizada de parches | P1 | DevOps | 2026-07-01 | Abierto |
| CA-003 | Añadir regla WAF para patrón de ataque | P1 | Seguridad | 2026-06-20 | Abierto |
| CA-004 | Actualizar reglas de correlación SIEM | P2 | Seguridad | 2026-06-30 | Abierto |
| CA-005 | Conducir entrenamiento de seguridad para equipo de dev | P2 | Seguridad | 2026-07-15 | Abierto |

Explicación

Esta plantilla sigue el ciclo de vida de respuesta a incidentes de seis fases definido en NIST SP 800-61 y alineado con SANS incident response. Cada fase tiene acciones específicas, puntos de decisión y criterios de escalamiento incorporados.

La clasificación determina la respuesta. Una fuga de datos que involucra PII dispara SEV-0 — escalamiento completo a CEO, CISO, Legal y PR. Un email de phishing dirigido a un solo usuario es SEV-2 — el equipo de seguridad lo maneja sin escalar. La matriz de clasificación pesa sensibilidad de datos, sistemas afectados, impacto en usuarios y si el atacante sigue activo para determinar la severidad. En mi experiencia, los equipos que clasifican demasiado bajo son los que terminan en primera plana — cuando hay duda, escala.

La contención detiene el sangrado. Las acciones inmediatas aíslan sistemas afectados, bloquean IPs del atacante, deshabilitan cuentas comprometidas y revocan sesiones activas — cada tipo de incidente tiene su propio procedimiento de contención. Cada tipo de incidente tiene procedimientos de contención específicos — malware requiere aislamiento de host, DDoS requiere filtrado de tráfico, amenazas internas requieren revocación discreta de acceso. La preservación de evidencia ocurre durante la contención — imágenes de disco, memory dumps y exports de logs se capturan antes de que los sistemas se reconstruyan. He visto equipos saltarse la preservación de evidencia porque tenían prisa, solo para darse cuenta tres días después de que habían destruido la evidencia forense necesaria para procedimientos legales.

La erradicación remueve la amenaza completamente. Esto involucra identificar el punto de entrada, parchear vulnerabilidades explotadas, remover herramientas y backdoors del atacante, y rotar todas las credenciales potencialmente expuestas. Cada tipo de incidente tiene pasos de erradicación específicos. La verificación confirma que la amenaza se fue — scans completos del sistema, análisis de tráfico de red y auditorías de configuración todos deben pasar antes de pasar a recuperación.

La recuperación restaura el servicio a la normalidad. Los sistemas se reconstruyen desde backups limpios, se despliegan versiones parcheadas, el tráfico se restaura gradualmente con health checks, y el monitoreo intensivo vigila recurrencia por 72 horas. La recuperación no está completa hasta que el sistema ha estado estable bajo monitoreo intensivo — he visto atacantes volver 48 horas después de la “recuperación” porque la erradicación pasó por alto un mecanismo de persistencia.

La comunicación es la parte que más se rompe durante los incidentes — cada fase la necesita, y el silencio genera pánico. Los stakeholders internos necesitan actualizaciones regulares — el equipo IR recibe actualizaciones técnicas en tiempo real, engineering recibe estado cada 30 minutos, los ejecutivos reciben impacto de negocio cada hora. La comunicación externa sigue requisitos regulatorios — GDPR requiere notificación en 72 horas, HIPAA requiere notificación en 60 días. Las plantillas pre-aprobadas ahorran tiempo valioso cuando cada minuto cuenta. Los peores incidentes que he visto no fueron las brechas mismas — fueron las fallas de comunicación que convirtieron un problema técnico en una crisis de confianza.

La revisión post-incidente es donde ocurre el aprendizaje. Una revisión blameless identifica qué pasó, por qué pasó y cómo prevenirlo. El timeline documenta cada evento y acción — sin él, el post-mortem es solo opinión. Las acciones correctivas se asignan con responsables y fechas límite. El post-mortem se publica para que la organización pueda aprender del incidente. Para una guía más profunda sobre cómo conducir post-mortems blameless, ver la Guía de Postmortems.

Variantes

Contexto	Enfoque	Notas
Equipo pequeño	Playbook simplificado, roles compartidos	Equipo IR de 2-3 personas
Enterprise	Playbook completo con SOC dedicado	Monitoreo 24/7, respuesta automatizada
Salud	Añadir notificación de brecha HIPAA	Notificación a 60 días, reporte a HHS
Financiero	Añadir PCI-DSS y notificación regulatoria	Notificación a marcas de tarjetas, reguladores bancarios estatales
Cloud-native	Enfoque en contención cloud	Aislar VPC, revocar roles IAM, rotar credenciales cloud
Retail	Añadir respuesta PCI-DSS	Aislamiento de datos de tarjetas, investigación forense
Gobierno	Añadir reporte obligatorio	Notificación CISA (US), GCHQ (UK)

Lo que funciona

1. Clasificar temprano — la severidad dirige toda la respuesta
2. Contener antes de investigar — detén el sangrado primero
3. Preservar evidencia durante la contención — no podés analizar forensemente un sistema reconstruido
4. Comunicar frecuentemente — el silencio genera pánico y rumores
5. Usar plantillas pre-aprobadas — ahorra tiempo durante el incidente
6. Conducir revisiones post-incidente blameless — enfocarse en sistemas, no en personas
7. Hacer seguimiento de acciones correctivas hasta completarlas — lecciones sin acción son desperdicio

Errores Comunes

1. Investigar antes de contener — el atacante sigue operando mientras investigás
2. Destruir evidencia durante la contención — reconstruir sistemas antes de capturar imágenes
3. No tener plan de comunicación — los stakeholders se enteran de incidentes desde fuentes externas
4. No hacer seguimiento de notificaciones regulatorias — perder el plazo de 72 horas del GDPR significa multas
5. No hacer revisión post-incidente — el mismo incidente se repite
6. Revisiones enfocadas en culpa — la gente oculta problemas en vez de reportarlos
7. Acciones correctivas sin seguimiento — identificadas pero nunca implementadas