Plantilla de informe de incidente

Un informe de incidente es un registro interno estructurado de un evento que interrumpió — o pudo haber interrumpido — el funcionamiento normal, la seguridad o la disponibilidad de un servicio. Una plantilla de informe de incidente de TI le da a ese registro una estructura fija, para que no se omita nada mientras el incidente sigue activo.

Para un equipo de TI o SaaS, eso puede incluir:

• Una interrupción total o parcial del servicio
• Tasas de error elevadas o una degradación severa del rendimiento
• Un despliegue fallido en producción
• Una falla de base de datos o de infraestructura
• Una interrupción o un incidente de seguridad de un proveedor externo
• Cualquier evento que haya puesto en riesgo la disponibilidad, incluso sin una interrupción total

El informe recoge los hechos conocidos, la respuesta operativa, el impacto, la cronología, las comunicaciones y el trabajo de seguimiento vinculado a ese incidente.

El término también puede referirse a accidentes laborales o incidentes de seguridad física — esta plantilla es para incidentes tecnológicos y de gestión de servicios, no físicos.

No toda advertencia, bug o interrupción breve necesita un informe formal — define tu propio umbral según el impacto en los clientes, el riesgo y la política interna. Un informe suele estar justificado cuando un incidente:

• Causa una interrupción significativa visible para los clientes
• Incumple o amenaza un SLA o SLO
• Requiere coordinación entre varios equipos, o comunicación con clientes o pública
• Involucra un posible problema de seguridad o privacidad
• Causa un impacto financiero u operativo material
• Repite una falla anterior o requiere un trabajo correctivo sustancial

Los incidentes de menor severidad pueden usar una versión más corta de la misma plantilla — solo resumen, impacto, cronología y acciones de seguimiento. Lo importante es que el umbral esté definido de antemano, no que se debata en medio del incidente.

Identificación del incidente

Dale al incidente un título claro y descriptivo que nombre el servicio y el síntoma visible para el cliente — "Tasas de error elevadas en la API por agotamiento de conexiones a la base de datos", no "Problema con la API". Un ID de incidente facilita cruzar referencias más adelante entre el ticket, la página de estado y el postmortem.

Severidad

La severidad comunica urgencia e impacto. Un modelo simple:

Los umbrales exactos importan más que las etiquetas — vincula cada nivel a criterios de impacto claros y a expectativas de respuesta.

Tiempos clave

Registra cuándo comenzó el incidente, cuándo se detectó, cuándo se mitigó y cuándo se resolvió. Estas marcas de tiempo te permiten medir el tiempo de detección, el tiempo de reconocimiento y el tiempo de resolución, y separar la ventana de impacto para los clientes del proceso interno de respuesta.

Resumen del incidente

Unas pocas frases factuales: qué pasó, qué se vio afectado, qué lo causó y cómo se restableció el servicio. Por ejemplo:

Entre las 14:03 y las 14:31 UTC, los clientes experimentaron tasas de error elevadas en la API pública. El incidente fue causado por conexiones a la base de datos que alcanzaron su límite configurado. El equipo restableció el servicio terminando las consultas afectadas y aumentando la capacidad de conexiones.

Deja la explicación técnica más profunda para la sección de causa.

Impacto en los clientes y en el negocio

Describe consecuencias, no solo síntomas — "los clientes no pudieron completar el pago", no "el uso de CPU llegó al 100%". Cubre qué servicios y clientes se vieron afectados, cuánto duró, si se perdieron o retrasaron datos y si se incumplió un SLA o SLO. Cuantifica donde puedas, y escribe "desconocido" en lugar de adivinar.

Detección

¿Cómo se enteró el equipo — una alerta, un reporte de un cliente, un ticket de soporte? Si los clientes lo notaron antes que el monitoreo, esa es una brecha de detección que vale la pena señalar aquí.

Respuesta y mitigación

Resume las acciones que cambiaron el curso del incidente — rollbacks, failovers, cambios de capacidad, soluciones alternativas — y el razonamiento detrás de las decisiones clave, especialmente donde quienes respondieron tuvieron que elegir entre opciones con distintos riesgos.

Cronología del incidente

Un relato cronológico y factual de lo que pasó, en una única zona horaria claramente indicada. No lo reescribas después para que parezca más ordenado de lo que fue, y no copies un registro de chat completo — resume lo que afectó materialmente la investigación, la respuesta o la comunicación.

Comunicaciones

Enlaza lo que se dijo y dónde — actualizaciones internas, página de estado, correos a clientes, indicaciones para soporte — en lugar de duplicarlo. Los informes internos pueden incluir detalles (infraestructura, nombres de empleados, teorías provisionales) que no deberían aparecer en una actualización pública.

Causa y factores contribuyentes

Separa claramente síntomas, causas sospechadas, causas confirmadas y factores contribuyentes — no fuerces una única "causa raíz" antes de terminar la investigación. Un despliegue fallido puede ser el detonante, mientras que unas pruebas débiles y la falta de alertas son lo que permitió que se convirtiera en una interrupción.

Acciones de seguimiento

Cada acción necesita un responsable y, para los elementos de alta prioridad, una fecha límite. "Mejorar el monitoreo" es una intención; "agregar una alerta para utilización del pool de conexiones por encima del 80%, a cargo de Ingeniería de plataforma, para el 15 de septiembre" es una acción.

El siguiente ejemplo simplificado muestra cómo podría completarse la plantilla para una interrupción de un SaaS.

Detalles del incidente

Título del incidente: Errores elevados en la API por agotamiento de conexiones a la base de datos ID del incidente: INC-2026-017 Severidad: SEV-2 Estado: Resuelto Responsable del incidente: Ingeniería de plataforma Líder del incidente: Líder de ingeniería on-call

Tiempos clave

Inicio del incidente: 14:03 UTC Detección del incidente: 14:07 UTC Reconocimiento del incidente: 14:09 UTC Inicio de la mitigación: 14:18 UTC Servicio restablecido: 14:31 UTC Incidente resuelto: 14:45 UTC

Resumen

Entre las 14:03 y las 14:31 UTC, los clientes experimentaron tasas de error elevadas al usar la API pública. Un grupo de consultas de larga duración a la base de datos agotó el pool de conexiones disponible. Quienes respondieron terminaron las consultas afectadas y aumentaron temporalmente la capacidad de conexiones, restableciendo el rendimiento normal de la API.

Impacto

Aproximadamente el 18% de las solicitudes a la API devolvieron errores durante el incidente. El acceso al panel y la disponibilidad de la página de estado no se vieron afectados. No se identificó pérdida ni corrupción de datos.

Detección

El incidente se detectó mediante una alerta por tasas de error elevadas en la API. El pool de conexiones de la base de datos no tenía una alerta de saturación dedicada.

Cronología

Causa

Un conjunto de consultas analíticas de larga duración consumió un gran porcentaje de las conexiones de la base de datos de producción. La capacidad restante fue insuficiente para atender el tráfico normal de la API.

Factores contribuyentes

• No existía una alerta para la saturación del pool de conexiones de la base de datos.
• Las cargas de trabajo analíticas compartían la capacidad de la base de datos con las solicitudes de los clientes.
• Los límites de tiempo de espera de las consultas eran más altos de lo necesario.
• El runbook operativo correspondiente no incluía diagnósticos de agotamiento de conexiones.

Acciones de seguimiento

Un informe de incidente no es el único registro que produce un incidente — normalmente es solo el primero.

Un postmortem se construye sobre el informe de incidente en lugar de reconstruir el evento desde cero, y un RCA suele ser un insumo del postmortem, no un reemplazo. Una actualización pública en la página de estado es una cuarta cosa, completamente distinta — escrita para los clientes, no para el equipo interno, y nunca el informe interno sin editar.

Consulta nuestra plantilla de análisis de causa raíz para el siguiente paso; la plantilla de postmortem estará disponible pronto.

• Registra los hechos a medida que ocurren, en una única zona horaria consistente. Reconstruir una cronología días después, o mezclar zonas horarias, produce un registro poco confiable.
• Separa los hechos de las suposiciones. Marca las causas sospechadas como sospechadas hasta que la evidencia las confirme.
• Describe el impacto en términos del cliente, no solo como síntomas técnicos. "Los clientes no pudieron pagar", no "la CPU llegó al 100%".
• Preserva el razonamiento detrás de las decisiones clave. Por qué se eligió un rollback, un failover o una solución alternativa, no solo que se eligió.
• Evita culpar. Enfócate en lo que permitió que el incidente ocurriera o lo empeoró, no en quién hizo el cambio.
• Asigna un responsable a cada acción de seguimiento, y una fecha objetivo a las de alta prioridad.
• Enlaza la evidencia en lugar de copiarla — paneles, logs, comunicaciones, despliegues, tickets.
• Revisa antes de cerrar. Confirma que el impacto, la cronología y las acciones sean precisos; consigue la aprobación para incidentes significativos.
• Trata un informe completado de forma consistente como tu registro de auditoría. Es evidencia útil para revisiones SOC 2, auditorías ISO 27001 y cuestionarios de seguridad de clientes, sin necesidad de un proceso de cumplimiento dedicado.

¿Cómo se escribe un informe de incidente?

Parte de una plantilla para que nada se omita bajo presión. Registra el título, la severidad y los tiempos clave tan pronto como se conozcan; completa el resumen, el impacto y la cronología a medida que los hechos se aclaran; y deja la causa, los factores contribuyentes y las acciones de seguimiento abiertos hasta que la investigación se ponga al día.

¿Cuál es el formato adecuado para un informe de incidente?

No hay un único formato obligatorio, pero uno útil cubre: identificación (título, ID, severidad), marcas de tiempo clave, un resumen factual, impacto en los clientes y en el negocio, detección, respuesta, una cronología, comunicaciones, causa y acciones de seguimiento. La plantilla de arriba usa esa estructura.

¿Cuáles son los elementos centrales de un informe de incidente?

Como mínimo: qué pasó, cuándo, cómo se detectó, quién y qué se vio afectado, cómo respondió el equipo, cómo se restableció el servicio, qué se comunicó y qué trabajo queda pendiente. Todo lo demás sirve para responder esas preguntas.

¿Se requiere un informe de incidente para cada interrupción?

No. Define los umbrales de antemano según el impacto en los clientes, la severidad y el riesgo — una interrupción breve puede necesitar solo un ticket, mientras que una interrupción mayor o un evento de seguridad suele justificar un informe completo.

¿Un informe de incidente reemplaza al postmortem?

No. El informe es el registro factual; el postmortem es el análisis más profundo de por qué pasó y qué cambiar. Los incidentes de baja severidad pueden necesitar solo el informe — los mayores o recurrentes suelen tener ambos.

El mejor momento para decidir cómo se documentarán los incidentes es antes de que ocurra uno. Define qué cuenta como incidente, qué severidades requieren un informe, quién es el responsable, dónde se guarda y cuándo se requiere un postmortem — para que quienes responden no estén debatiendo la documentación en medio del incidente.

Un informe de incidente bien diseñado no debería añadir carga administrativa durante una interrupción. Usado de forma consistente, se convierte en más que el registro de una falla — ayuda a los equipos a coordinarse, comunicarse y mejorar la confiabilidad con el tiempo.

La estructura de esta plantilla sigue lo que exigen en sus registros de incidentes los equipos con manuales de ingeniería públicos. Difieren sobre todo en quién mantiene el registro y qué incidentes reciben una revisión escrita después.