Operaciones 2 de abril de 2026 April 2, 2026 7 min de lectura 7 min read

Runbook de remediación en 6 pasos: de detección a validación

Un runbook no resuelve vulnerabilidades, garantiza que cuando aparece una, el equipo sabe exactamente qué hacer. Sin uno, cada CVE genera una respuesta distinta: plazos diferentes, responsables distintos, evidencia inconsistente. Estos seis pasos cubren el ciclo completo.

Remediation runbook in 6 steps: from detection to validation

A runbook doesn't resolve vulnerabilities — it guarantees that when one appears, the team knows exactly what to do. Without one, every CVE generates a different response: different timelines, different owners, inconsistent evidence. These six steps cover the complete cycle.

Por qué los runbooks importan

La mayoría de los equipos no tienen problemas para detectar vulnerabilidades. El problema está en lo que ocurre después: quién es responsable, en qué plazo, qué constituye una remediación válida, y cómo se documenta para una auditoría futura.

Sin un proceso definido, la respuesta a una vulnerabilidad depende de quién esté disponible ese día, de si el ticket llega al equipo correcto y de cuánto ruido genera el CVE en ese momento. Un runbook cambia eso: convierte la respuesta en un proceso repetible, con responsables claros, criterios de cierre explícitos y evidencia generada en cada paso.

Antes de empezar: Un runbook de remediación necesita dos cosas previas: un inventario de activos actualizado y un sistema de ticketing o gestión de casos donde registrar el trabajo. Sin esas bases, los pasos siguientes no tienen dónde apoyarse.

Los 6 pasos

Paso 1
Detección y registro
La vulnerabilidad puede llegar de múltiples fuentes: output de un escáner, alerta de KEV de CISA, advisory del fabricante, notificación de un CERT o reporte interno. El origen no importa tanto como lo que se hace con ella en los primeros minutos.

Lo que hay que registrar en este paso: ID del CVE, puntuación CVSS, EPSS si está disponible, fecha y hora de detección, y fuente de la alerta. El objetivo es abrir un caso con suficiente información para que cualquier miembro del equipo pueda continuar desde aquí.

Output: ticket o caso abierto en el sistema de gestión con los metadatos del CVE.
Paso 2
Correlación con inventario
Antes de evaluar nada, hay que saber si el CVE afecta a activos propios. La correlación cruza el componente afectado (fabricante, producto, versión) contra el inventario de software y activos.

El resultado de este paso es una lista de activos afectados, clasificados por entorno: producción, staging, desarrollo. Un CVE que solo afecta a entornos de desarrollo tiene un perfil de riesgo muy diferente a uno que afecta a sistemas productivos.

Si la correlación no encuentra ningún activo afectado, el caso se cierra con justificación documentada. Eso también es evidencia: demuestra que el proceso se ejecutó.

Output: lista de activos afectados con entorno, o cierre justificado si no hay afectación.
Paso 3
Evaluación de riesgo por activo
El riesgo no es igual para todos los activos afectados. Este paso evalúa cada uno de forma independiente, considerando: exposición a internet, criticidad de negocio del activo, datos que maneja, y controles compensatorios ya existentes (WAF, segmentación de red, autenticación fuerte).

El resultado es una clasificación de riesgo por activo, no por CVE. Un mismo CVE puede ser crítico en un activo y bajo en otro, dependiendo de su contexto. Esta distinción es lo que hace posible priorizar con criterio.

Output: clasificación de riesgo (Crítico / Alto / Medio / Bajo) por activo, con la justificación de cada decisión.
Paso 4
Asignación de responsable y SLA
Cada activo afectado necesita un propietario para la remediación. Sin asignación explícita, el caso queda en tierra de nadie.

El SLA arranca en el momento de la asignación. Un esquema típico basado en la clasificación del paso anterior: Crítico → 24 horas, Alto → 72 horas, Medio → 2 semanas, Bajo → próximo ciclo de mantenimiento. Los plazos exactos dependen de la política de cada organización, pero tienen que existir y ser explícitos.

Si el CVE está en el KEV de CISA, el SLA se acorta automáticamente independientemente de la clasificación interna.

Output: tickets asignados con responsable y fecha límite documentados.
Paso 5
Remediación o mitigación
Existen dos caminos, y a veces hay que combinarlos:

Parche: Si existe una versión corregida del componente y el proceso de testing lo permite, es la opción de cierre definitivo. Documenta la versión antes y después del parche, y la fecha de aplicación.

Mitigación temporal: Cuando el parche no está disponible, no ha pasado un ciclo de testing suficiente, o el activo no puede caer en ese momento. Las mitigaciones típicas incluyen: regla de WAF, bloqueo a nivel de red, desactivación de la funcionalidad afectada, o aislamiento temporal del activo. Cada mitigación debe documentar su alcance exacto, sus limitaciones, y la fecha prevista de aplicación del parche definitivo.

Output: registro de cambio con la acción tomada, la persona responsable, la fecha y la evidencia (captura de versión, log de cambio, ticket de cambio en ITSM).
Paso 6
Validación y cierre
La remediación no está completa hasta que se verifica. Un parche aplicado sin validación posterior es una remediación a medias: sabes que lo aplicaste, pero no que funcionó.

Para parches: ejecutar un escaneo de confirmación o verificar manualmente la versión instalada del componente. El resultado del escaneo es la evidencia de cierre.

Para mitigaciones temporales: programar una revisión para la aplicación del parche definitivo. La mitigación cierra el caso de forma provisional, pero el caso no se cierra completamente hasta que se aplica la solución permanente.

Output: registro de cierre con evidencia de validación. Si es cierre provisional por mitigación, fecha comprometida para el cierre definitivo.

Qué evidencia generar en cada paso

Un runbook sin evidencia es un proceso sin trazabilidad. Para auditorías de NIS2, ENS o ISO 27001, la pregunta no es solo "¿lo parcheaste?" sino "¿puedes demostrar que lo parcheaste y cuándo?". Estos son los registros mínimos por paso:

Detección: fecha, fuente y metadatos del CVE.
Correlación: lista de activos comprobados y resultado de la correlación.
Evaluación: clasificación de riesgo por activo con justificación.
Asignación: responsable, fecha de asignación y SLA.
Remediación: acción tomada, versión antes/después o mitigación aplicada.
Validación: resultado del escaneo de confirmación o verificación de versión.

Errores habituales al implementar un runbook

Definir el runbook sin SLAs. Un proceso sin plazos explícitos no genera urgencia. El SLA es lo que convierte el runbook en un compromiso.
Cerrar casos sin validar. Marcar una vulnerabilidad como resuelta sin verificación posterior invalida el cierre. En una auditoría, "aplicamos el parche" sin evidencia de confirmación no es suficiente.
No documentar las mitigaciones temporales. Una mitigación sin fecha de cierre definitivo se convierte fácilmente en permanente. Si no está documentado, no hay presión para resolverlo.
Un único responsable para todos los activos. La asignación debe llegar al propietario real del activo, no a un buzón genérico de seguridad. El responsable tiene que poder ejecutar la remediación o escalarla.
No revisar el runbook tras un incidente. El runbook es un documento vivo. Cada vez que algo falla en el proceso —un activo que no estaba en el inventario, un plazo que no se cumplió— es una oportunidad de mejorarlo.

Remediación con trazabilidad desde el paso 1

vulloop integra correlación de inventario, asignación de responsable, seguimiento de SLA y evidencia auditable en un único flujo de trabajo.

Why runbooks matter

Most teams don't have trouble detecting vulnerabilities. The problem is what happens afterward: who is responsible, by when, what constitutes a valid remediation, and how it's documented for a future audit.

Without a defined process, the response to a vulnerability depends on who's available that day, whether the ticket reaches the right team, and how much noise the CVE is generating at the time. A runbook changes that: it turns the response into a repeatable process, with clear owners, explicit closure criteria, and evidence generated at each step.

Before you start: A remediation runbook needs two prerequisites: an up-to-date asset inventory and a ticketing or case management system where work can be recorded. Without those foundations, the following steps have nothing to build on.

The 6 steps

Step 1
Detection and registration
The vulnerability can arrive from multiple sources: scanner output, CISA KEV alert, vendor advisory, CERT notification, or internal report. The origin matters less than what's done with it in the first minutes.

What to record in this step: CVE ID, CVSS score, EPSS if available, date and time of detection, and alert source. The goal is to open a case with enough information that any team member can continue from here.

Output: ticket or case opened in the management system with CVE metadata.
Step 2
Inventory correlation
Before evaluating anything, you need to know if the CVE affects your own assets. The correlation cross-references the affected component (vendor, product, version) against the software and asset inventory.

The output of this step is a list of affected assets, classified by environment: production, staging, development. A CVE that only affects development environments has a very different risk profile from one that affects production systems.

If the correlation finds no affected assets, the case is closed with documented justification. That's also evidence: it demonstrates the process was executed.

Output: list of affected assets with environment, or documented closure if no impact.
Step 3
Per-asset risk assessment
Risk is not equal across all affected assets. This step evaluates each one independently, considering: internet exposure, asset business criticality, data it handles, and existing compensating controls (WAF, network segmentation, strong authentication).

The output is a risk classification per asset, not per CVE. The same CVE can be critical for one asset and low for another, depending on its context. This distinction is what makes it possible to prioritize with judgment.

Output: risk classification (Critical / High / Medium / Low) per asset, with the justification for each decision.
Step 4
Owner assignment and SLA
Each affected asset needs an owner for remediation. Without explicit assignment, the case falls through the cracks.

The SLA starts at the moment of assignment. A typical scheme based on the step 3 classification: Critical → 24 hours, High → 72 hours, Medium → 2 weeks, Low → next maintenance cycle. The exact deadlines depend on each organization's policy, but they must exist and be explicit.

If the CVE is in CISA's KEV, the SLA is automatically shortened regardless of the internal classification.

Output: assigned tickets with owner and documented deadline.
Step 5
Remediation or mitigation
There are two paths, and sometimes you need to combine them:

Patch: If a fixed version of the component exists and the testing process allows it, this is the definitive closure option. Document the version before and after the patch, and the date of application.

Temporary mitigation: When a patch isn't available, hasn't gone through sufficient testing, or the asset can't go down at that moment. Typical mitigations include: WAF rule, network-level block, disabling the affected functionality, or temporary asset isolation. Each mitigation must document its exact scope, its limitations, and the planned date for applying the definitive patch.

Output: change record with the action taken, the responsible person, the date, and the evidence (version screenshot, change log, ITSM change ticket).
Step 6
Validation and closure
Remediation is not complete until it's verified. A patch applied without subsequent validation is a half-done remediation: you know you applied it, but not that it worked.

For patches: run a confirmation scan or manually verify the installed version of the component. The scan result is the closure evidence.

For temporary mitigations: schedule a review for the definitive patch application. The mitigation provisionally closes the case, but the case isn't fully closed until the permanent solution is applied.

Output: closure record with validation evidence. If provisional closure by mitigation, committed date for definitive closure.

What evidence to generate at each step

A runbook without evidence is a process without traceability. For NIS2, ENS, or ISO 27001 audits, the question isn't just "did you patch it?" but "can you prove you patched it and when?" These are the minimum records per step:

Detection: date, source, and CVE metadata.
Correlation: list of assets checked and correlation result.
Assessment: risk classification per asset with justification.
Assignment: owner, assignment date, and SLA.
Remediation: action taken, before/after version or applied mitigation.
Validation: confirmation scan result or version verification.

Common mistakes when implementing a runbook

Defining the runbook without SLAs. A process without explicit deadlines doesn't generate urgency. The SLA is what turns the runbook into a commitment.
Closing cases without validation. Marking a vulnerability as resolved without subsequent verification invalidates the closure. In an audit, "we applied the patch" without confirmation evidence is not enough.
Not documenting temporary mitigations. A mitigation without a definitive closure date easily becomes permanent. If it's not documented, there's no pressure to resolve it.
A single owner for all assets. Assignment must reach the actual asset owner, not a generic security inbox. The owner must be able to execute the remediation or escalate it.
Not reviewing the runbook after an incident. The runbook is a living document. Every time something fails in the process — an asset not in inventory, a missed deadline — it's an opportunity to improve it.

Remediation with traceability from step 1

vulloop integrates inventory correlation, owner assignment, SLA tracking, and auditable evidence in a single workflow.