SLA de remediación de vulnerabilidades para NIS2 y DORA
A las 08:17 de un martes por la mañana, a comienzos de 2026, Anna, la CISO de una fintech en rápido crecimiento, recibe el primer mensaje antes de terminar el café.
El SOC ha detectado conversaciones sobre explotación activa en torno a una vulnerabilidad en una pasarela de API orientada al cliente. Ingeniería indica que el parche está disponible, pero que aplicarlo implica riesgo porque la pasarela se sitúa delante de los flujos de pago. El responsable de cumplimiento reenvía una solicitud formal de una autoridad nacional competente que pide evidencias de “gestión y divulgación de vulnerabilidades” y prueba de que el proceso ha sido eficaz durante los últimos 12 meses. Compras añade un tercer problema: la pasarela está gestionada por un MSP, y el contrato solo indica que el proveedor aplicará “actualizaciones de seguridad en un plazo razonable”.
A las 09:00, esto ya no es solo un problema de aplicación de parches. Es un problema de evidencias de ISO/IEC 27001:2022, un problema de ciberhigiene NIS2, un problema de gestión del riesgo TIC DORA, un problema de gobierno de proveedores y, potencialmente, un problema de notificación de incidentes si la explotación afecta a la continuidad del servicio o a datos personales.
Esta es la brecha práctica de cumplimiento a la que se enfrentarán muchas organizaciones en 2026. Tienen escáneres, cuadros de mando, tickets y herramientas de gestión de parches, pero no pueden responder con claridad a las preguntas de auditoría:
- ¿Quién aprobó el SLA de remediación?
- ¿Cómo se basa el SLA en el riesgo?
- ¿Qué ocurre cuando un parche crítico supera el plazo?
- ¿Cómo se priorizan los activos expuestos a internet?
- ¿Cómo se exige a los proveedores cumplir los mismos plazos?
- ¿Dónde está el registro de aceptación del riesgo para un sistema sin parchear?
- ¿Qué evidencias prueban que el control funcionó, y no solo que existía?
La respuesta no es otra hoja de cálculo con fechas límite. Los SLA de remediación de vulnerabilidades deben gestionarse como un sistema vivo de controles que conecte la propiedad de activos, la calificación de vulnerabilidades, la inteligencia de amenazas, la gestión de cambios, los SLA de proveedores, la gestión de excepciones, la supervisión, la respuesta a incidentes y la revisión por la dirección.
Ahí es donde la Política de gestión de vulnerabilidades y parches (VPMP) empresarial de Clarysec, la Política de gestión de vulnerabilidades y parches para pymes (VPMP-SME), la Política de seguridad de terceros y proveedores para pymes (TPSSP-SME), Zenith Blueprint (ZB) y Zenith Controls resultan útiles. En conjunto, convierten “parchear más rápido” en un proceso de gobierno defendible, capaz de resistir el escrutinio de auditorías de estilo ISO, NIS2, DORA, GDPR, NIST e ISACA.
Por qué los SLA de remediación de vulnerabilidades se convirtieron en evidencias para el consejo
La remediación de vulnerabilidades solía tratarse como una métrica de higiene de TI. En 2026, se aproxima más a un compromiso regulado de resiliencia operativa.
NIS2 convierte la ciberseguridad en una cuestión de responsabilidad proactiva de la dirección. Las entidades esenciales e importantes deben hacer que sus órganos de dirección aprueben medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación para comprender los riesgos y el impacto de las prácticas de seguridad en los servicios. NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluido el análisis de riesgos, la gestión de incidentes, la continuidad del negocio, la seguridad de la cadena de suministro, la adquisición y el mantenimiento seguros, la gestión y divulgación de vulnerabilidades, la higiene cibernética, la formación, el control de acceso, la gestión de activos y la autenticación.
Para las entidades financieras, DORA es el régimen especializado de resiliencia operativa. Exige acuerdos de gobierno y control para el riesgo TIC, en los que el órgano de dirección define, aprueba, supervisa y mantiene la responsabilidad sobre la gestión del riesgo TIC. También exige la identificación de activos TIC y dependencias, controles de protección y prevención como la aplicación de parches y la gestión de cambios, gestión de incidentes relacionados con las TIC, pruebas de resiliencia operativa digital y gestión del riesgo de terceros de TIC.
El impacto práctico es significativo. El incumplimiento del plazo de un parche puede indicar un fallo de:
- Gobierno, si la dirección no ha aprobado SLA basados en riesgos
- Gestión de activos, si se desconoce el propietario del sistema afectado
- Gestión de cambios, si la aplicación de parches de emergencia no está controlada
- Gestión de proveedores, si los plazos del proveedor son ambiguos
- Respuesta a incidentes, si no se realiza el triaje de indicios de explotación
- Gestión de evidencias, si los tickets y los registros no pueden probar el cierre
- Tratamiento de riesgos, si las excepciones no se aprueban ni se revisan
ISO/IEC 27001:2022 proporciona la columna vertebral del sistema de gestión. Las cláusulas 4.1 a 4.3 exigen que las organizaciones comprendan las cuestiones internas y externas, los requisitos de las partes interesadas, las obligaciones legales y contractuales y las interfaces con otras organizaciones. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, una Declaración de Aplicabilidad y la aprobación del riesgo residual por parte del propietario del riesgo. Las cláusulas 9.1, 9.2, 9.3, 10.1 y 10.2 exigen supervisión, auditoría interna, revisión por la dirección, mejora continua, acción correctiva y evidencias conservadas.
En términos sencillos, si quiere que los SLA de remediación de vulnerabilidades estén preparados para auditoría, deben formar parte del SGSI, no ser solo una métrica de DevOps.
El modelo de SLA que los auditores esperan ver
Un SLA de remediación de vulnerabilidades debe responder a tres preguntas:
- ¿Con qué rapidez debemos actuar?
- ¿Quién rinde cuentas?
- ¿Qué evidencias prueban el resultado?
La Política de gestión de vulnerabilidades y parches define un punto de partida práctico para plazos de remediación basados en riesgos:
La organización debe clasificar todas las vulnerabilidades detectadas utilizando una metodología normalizada (por ejemplo, CVSS v3.x) y aplicar plazos de remediación alineados con la criticidad para las operaciones de la organización: 5.2.1 Crítica (CVSS 9.0-10.0): revisión inmediata; plazo máximo de aplicación del parche de 72 horas. 5.2.2 Alta (7.0-8.9): respuesta en un plazo de 48 horas; plazo de aplicación del parche de 7 días naturales. 5.2.3 Media (4.0-6.9): respuesta en un plazo de 5 días; plazo de aplicación del parche de 30 días naturales. 5.2.4 Baja (<4.0): respuesta en un plazo de 10 días; plazo de aplicación del parche de 60 días naturales.
Esta cláusula es eficaz porque separa el tiempo de respuesta del plazo de aplicación del parche. Una vulnerabilidad alta no debería permanecer sin revisar durante seis días y parchearse el día siete. El reloj de respuesta confirma el triaje, la propiedad, la evaluación de impacto y la planificación de la remediación. El plazo de aplicación del parche confirma el cierre técnico o una excepción aprobada.
Para organizaciones más pequeñas, la Política de gestión de vulnerabilidades y parches para pymes utiliza un lenguaje más sencillo, pero igualmente auditable:
Los parches críticos deben aplicarse en un plazo de 3 días desde su publicación, especialmente en sistemas expuestos a internet
Y para el conjunto más amplio de parches:
Todos los demás parches deben aplicarse en un plazo de 30 días, salvo que se documente una excepción válida
La cuestión no es que todas las organizaciones deban usar plazos idénticos. ISO/IEC 27001:2022, NIS2 y DORA admiten la proporcionalidad. La cuestión es que los SLA de remediación deben estar definidos, aprobados, basados en riesgos, supervisados y evidenciados.
| Clase de vulnerabilidad | SLA habitual | Decisión requerida | Evidencia mínima |
|---|---|---|---|
| Crítica explotada o expuesta a internet | 72 horas o menos | Cambio de emergencia, triaje de incidentes, visibilidad del CISO | Hallazgo del escáner, ticket, registro de cambio, registro de parches, escaneo de validación |
| Alta en un sistema crítico para las operaciones de la organización | 7 días naturales | Aceptación de indisponibilidad por el propietario o plan de mitigación | Puntuación de riesgo, criticidad del activo, ticket, evidencias de despliegue |
| Media en sistema interno | 30 días naturales | Cambio estándar y despliegue programado | Informe de parches, ticket de cierre, resultado de validación |
| Severidad baja | 60 días naturales o ciclo planificado | Propiedad del backlog y supervisión rutinaria | Estado del ticket, entrada en el registro de riesgos si hay retraso |
| Sistema heredado no parcheable | Revisión de excepción dentro de un intervalo definido | Aceptación del riesgo y controles compensatorios | Registro de excepción, prueba de segmentación, regla de supervisión, fecha de revisión |
Aquí es donde muchas empresas fallan. Definen el SLA, pero no definen las evidencias. Desde la perspectiva de un auditor, una política sin registros operativos es una promesa, no un control.
La propiedad de los activos es la dependencia oculta
Un escáner puede indicar que existe una CVE en un servidor. No puede decir si ese servidor da soporte a un proceso crítico de pago, almacena datos personales de categorías especiales, se conecta a un proveedor de liquidación o está programado para su retirada.
Ese contexto procede de la gestión de activos, la clasificación de datos, el inventario de proveedores y la evaluación de riesgos.
El control 8.8 del Anexo A de ISO/IEC 27001:2022, Gestión de vulnerabilidades técnicas, es central, pero no opera de forma aislada. Depende en gran medida de la gestión de configuraciones, la gestión de cambios, la supervisión de proveedores, el gobierno de la nube, el registro de eventos, la supervisión y el tratamiento de riesgos.
NIST CSF 2.0 expresa el mismo problema en lenguaje de resultados. La función GOVERN espera que se comprendan y gestionen los requisitos legales, reglamentarios y contractuales de ciberseguridad, que se documenten el apetito de riesgo y la tolerancia al riesgo, que se asignen roles y recursos, y que las políticas de ciberseguridad se establezcan, apliquen, revisen y actualicen. Los resultados de IDENTIFY incluyen inventarios de hardware, software, servicios, sistemas, datos y ciclo de vida, junto con procesos de identificación de vulnerabilidades, análisis de riesgos, gestión de excepciones y divulgación de vulnerabilidades.
En el escenario del martes por la mañana de Anna, la primera pregunta técnica es “¿dónde está el componente vulnerable?”. La primera pregunta de gobierno es “¿a qué servicio y a qué riesgo afecta?”.
Zenith Blueprint, fase de gestión de riesgos, paso 13: planificación del tratamiento de riesgos y Declaración de Aplicabilidad, aborda esto conectando riesgos con controles, propietarios y plazos:
Además, asigne un Propietario y un Plazo para cada acción (quizá en una columna separada o en los comentarios). Por ejemplo: “Propietario: Responsable de TI, Plazo: antes del tercer trimestre de 2025”. Esto lo convierte en un plan real.
Eso es exactamente lo que exige la remediación de vulnerabilidades. Un hallazgo sin propietario se convierte en ruido de backlog. Un hallazgo con propietario, plazo, decisión de tratamiento del riesgo y rastro de evidencias se convierte en un control auditable.
Cómo Zenith Controls mapea las relaciones entre controles
Zenith Controls trata el control 8.8 de ISO/IEC 27002:2022, Gestión de vulnerabilidades técnicas, como un control preventivo que apoya la confidencialidad, la integridad y la disponibilidad. Lo conecta con los conceptos de ciberseguridad Identificar y Proteger, la capacidad operativa de gestión de amenazas y vulnerabilidades, y los dominios de seguridad de gobierno, ecosistema, protección y defensa.
Esto importa porque los SLA de remediación no son solo un mecanismo de protección. También son un mecanismo de gobierno y un mecanismo de ecosistema. Su exposición está determinada por proveedores, plataformas en la nube, servicios gestionados, componentes de código abierto y dependencias expuestas a internet.
Zenith Controls mapea 8.8 con varios controles de apoyo:
| Relación de control ISO/IEC 27002:2022 | Por qué importa para los SLA de remediación |
|---|---|
| 8.7 Protección contra el software malicioso | El malware suele explotar debilidades conocidas sin parchear, por lo que la aplicación de parches y la telemetría antimalware deben reforzarse mutuamente. |
| 8.9 Gestión de configuraciones | Las configuraciones de referencia seguras y los registros de configuración ayudan a verificar si los sistemas están parcheados y siguen en estados aprobados. |
| 8.32 Gestión de cambios | Los parches son cambios controlados, incluida la aprobación de emergencia, las pruebas, el despliegue, la reversión y la revisión posterior al cambio. |
| 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores | Los proveedores de SaaS, MSP, PaaS y nube deben ser supervisados respecto de vulnerabilidades, parches, cambios de servicio e incidentes. |
| 5.23 Seguridad de la información para el uso de servicios en la nube | El uso de servicios en la nube debe incluir requisitos de seguridad, claridad sobre la responsabilidad compartida y aseguramiento sobre la aplicación de parches controlada por el proveedor. |
| 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información | Las vulnerabilidades explotadas pueden convertirse en incidentes, por lo que deben estar preparados el triaje, el escalado, la preservación de evidencias y la notificación. |
Zenith Controls también vincula la gestión de vulnerabilidades con ISO/IEC 27005:2024, especialmente la identificación de vulnerabilidades y los escenarios de riesgo que implican sistemas sin parchear. Esto refuerza el argumento de que los plazos de aplicación de parches deben basarse en riesgos, no ser arbitrarios. También conecta la supervisión de proveedores con ISO/IEC 27036-4:2016 para niveles de seguridad en acuerdos de servicios en la nube e ISO/IEC 20000-1:2018 para planificación de la prestación del servicio y gestión de cambios.
Esa estructura transversal entre normas importa durante la auditoría. Si una organización afirma que “las vulnerabilidades críticas se parchean en 72 horas”, el auditor comprobará si esa declaración está respaldada por la evaluación de riesgos, la clasificación de activos, las obligaciones de proveedores, los registros de cambios y las evidencias de supervisión.
Ciberhigiene NIS2: de la gestión de vulnerabilidades a la acción correctiva
NIS2 Article 21 exige un enfoque frente a todos los riesgos para las redes y los sistemas de información. Para los SLA de remediación de vulnerabilidades, varios elementos de Article 21 son directamente relevantes:
- Análisis de riesgos y políticas de seguridad de los sistemas de información
- Gestión de incidentes
- Continuidad del negocio y gestión de crisis
- Seguridad de la cadena de suministro
- Adquisición, desarrollo y mantenimiento seguros, incluida la gestión y divulgación de vulnerabilidades
- Procedimientos para evaluar la eficacia de la ciberseguridad
- Higiene cibernética básica y formación
- Control de acceso y gestión de activos
- Autenticación multifactor o autenticación continua cuando proceda
NIS2 Article 20 responsabiliza a los órganos de dirección de aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad. Eso significa que las métricas de remediación de vulnerabilidades no pueden permanecer únicamente dentro de un cuadro de mando de ingeniería. Deben aparecer en informes de dirección, paquetes del comité de riesgos o registros de revisión por la dirección del SGSI.
Article 21 también espera que las entidades que identifiquen incumplimientos de las medidas exigidas adopten acciones correctivas sin demora indebida. Esa expresión importa. Si su cuadro de mando muestra vulnerabilidades críticas vencidas, la evidencia de cumplimiento no debe detenerse en “lo sabemos”. Debe mostrar escalado, revisión del riesgo, visibilidad para la dirección, acción correctiva y reevaluación.
NIS2 Article 23 añade otra dimensión. Si la explotación de una vulnerabilidad sin parchear causa o puede causar una interrupción operativa grave, pérdidas financieras o daños a otras personas, puede convertirse en un incidente significativo. El ciclo de notificación incluye una alerta temprana en un plazo de 24 horas desde que se tenga conocimiento del incidente significativo, una notificación del incidente en un plazo de 72 horas, informes intermedios a solicitud y un informe final en el plazo de un mes desde la notificación del incidente. Ese informe final debe incluir la severidad, el impacto, la causa raíz probable, las mitigaciones y el impacto transfronterizo cuando proceda.
Por tanto, el proceso de SLA debe conectarse con la respuesta a incidentes. Una vulnerabilidad crítica con evidencias de explotación activa debe activar el triaje de seguridad, la supervisión, la preservación de evidencias y una evaluación de notificación, no solo un ticket rutinario de parcheo.
Riesgo TIC DORA: los plazos de remediación como evidencia de resiliencia
Para las entidades financieras, DORA se aplica desde el 17 de enero de 2025 y establece requisitos uniformes en materia de gestión del riesgo TIC, notificación de incidentes graves relacionados con las TIC, pruebas de resiliencia operativa digital, intercambio de información y gestión del riesgo de terceros de TIC. Se trata como el acto jurídico sectorial específico de la UE para las entidades financieras cubiertas identificadas con arreglo a las normas nacionales NIS2.
El modelo operativo de DORA se aproxima a un SGSI integrado. Articles 5 y 6 exigen gobierno, políticas, procedimientos, herramientas, revisión anual o periódica, auditoría, remediación de hallazgos de auditoría críticos y una estrategia de resiliencia operativa digital. Article 8 exige la identificación e inventario de funciones de negocio soportadas por TIC, activos de información, activos TIC, dependencias, procesos de terceros y riesgos TIC heredados. Article 9 exige controles de protección y prevención, incluida la aplicación de parches y la gestión de cambios. Articles 11 y 12 exigen continuidad, respuesta, recuperación, copia de seguridad, restauración y objetivos de recuperación.
DORA Articles 17 a 19 exigen un proceso de gestión de incidentes relacionados con las TIC que detecte, gestione, registre, clasifique, escale, notifique, comunique, analice la causa raíz y restaure operaciones seguras. Articles 24 a 26 exigen pruebas de resiliencia operativa digital, incluidas pruebas adecuadas de herramientas y sistemas TIC, evaluaciones de vulnerabilidades, evaluaciones de seguridad de red, análisis de deficiencias, revisiones de código fuente cuando sea viable, pruebas de penetración y pruebas de penetración basadas en amenazas para determinadas entidades financieras. Articles 28 y 30 exigen gestión del riesgo de terceros de TIC, registros de contratos de servicios TIC, diligencia debida, derechos de auditoría e inspección, niveles de servicio, asistencia del proveedor durante incidentes, derechos de terminación y mecanismos de salida.
Para los SLA de remediación, DORA cambia las expectativas de evidencia de tres maneras.
Primero, los hallazgos de vulnerabilidades derivados de pruebas deben alimentar un proceso de remediación priorizado. Un informe de escaneo no es suficiente.
Segundo, la remediación de hallazgos críticos debe supervisarse mediante gobierno y auditoría. DORA espera la remediación formal de hallazgos de auditoría críticos en entidades que no sean microempresas.
Tercero, los terceros proveedores de servicios TIC deben estar sujetos a obligaciones medibles. Si su proveedor de nube, SaaS o MSP controla la ventana de aplicación de parches, su contrato y su registro deben mostrar cómo sus plazos de remediación respaldan sus obligaciones de resiliencia.
La Política de gestión de vulnerabilidades y parches aborda esto directamente:
Aplicación de parches por terceros y supervisión del riesgo SaaS 6.6.1 Todos los sistemas de terceros (SaaS, PaaS, gestionados por MSP) deben demostrar controles adecuados de gestión de vulnerabilidades y parches. 6.6.2 Los SLA de proveedores deben incluir plazos de remediación equivalentes a los umbrales definidos internamente según la criticidad.
Esa cláusula suele ser el puente que falta entre las evidencias ISO internas y la supervisión de proveedores exigida por DORA.
GDPR: cuando los retrasos en parches se convierten en fallos de responsabilidad proactiva sobre datos personales
GDPR no es una norma de gestión de vulnerabilidades, pero cambia las consecuencias de un fallo de parcheo.
GDPR Article 5 exige que los datos personales se traten de forma segura y que el responsable del tratamiento pueda demostrar el cumplimiento. Article 32 exige medidas técnicas y organizativas adecuadas para garantizar un nivel de seguridad adecuado al riesgo. Cuando sistemas sin parchear tratan datos personales, especialmente datos de identidad, datos financieros, datos biométricos, datos de salud, datos laborales o información KYC, los SLA de remediación pasan a formar parte de la responsabilidad proactiva sobre la seguridad del tratamiento.
Un parche retrasado puede ser defendible si se evaluó el riesgo, se aplicaron controles compensatorios y la persona adecuada aceptó el riesgo residual. Es mucho más difícil de defender si la vulnerabilidad estaba vencida, expuesta a internet y sin propietario.
Zenith Controls mapea la gestión de vulnerabilidades con GDPR Articles 32 y 5(1)(f), porque la aplicación oportuna de parches reduce los riesgos para la confidencialidad y la integridad de los datos personales. También mapea la gestión de cambios con GDPR Article 24 y Article 32, porque los cambios en sistemas que tratan datos personales deben evaluarse en función del riesgo, aprobarse, documentarse y revisarse.
La lección de cumplimiento es sencilla: si hay datos personales implicados, sus evidencias de parcheo deben incluir el contexto de datos. Los auditores y reguladores no preguntarán solo “¿se parcheó?”, sino “¿qué datos estuvieron expuestos al riesgo, durante cuánto tiempo y qué controles redujeron ese riesgo?”.
Un flujo de trabajo práctico de Clarysec para evidencias de SLA preparadas para auditoría
Un proceso maduro de remediación de vulnerabilidades no empieza cuando un auditor pide registros. Está diseñado para producir registros todos los meses.
Paso 1: Aprobar la política de SLA
Comience con la Política de gestión de vulnerabilidades y parches o la Política de gestión de vulnerabilidades y parches para pymes, según su modelo operativo. Adapte los umbrales de SLA a su apetito de riesgo, alcance regulatorio, criticidad del servicio, sensibilidad de los datos y restricciones técnicas. Asegure la aprobación por el CISO, el comité de riesgos o el órgano de dirección.
Para entornos empresariales, utilice CVSS, criticidad del activo, explotabilidad, exposición a internet, sensibilidad de los datos e impacto en las operaciones de la organización. Para pymes, mantenga el modelo sencillo pero explícito: parches críticos en un plazo de tres días; otros parches en un plazo de 30 días salvo que exista una excepción válida.
Paso 2: Mapear activos con propietarios y servicios críticos
Todo hallazgo de vulnerabilidad debe resolverse hasta:
- Nombre del activo e identificador único
- Servicio o aplicación de la organización
- Propietario del sistema
- Propietario técnico
- Clasificación de datos
- Exposición a internet
- Dependencia de proveedor, si procede
- Criticidad de la función soportada
Esto respalda la propiedad del riesgo en ISO/IEC 27001:2022, la gestión de activos NIS2, el inventario de activos y dependencias TIC DORA y los resultados IDENTIFY de NIST CSF.
Paso 3: Triar la vulnerabilidad
Cree un ticket para cada hallazgo o conjunto agrupado de hallazgos. Incluya puntuación CVSS, escáner de origen, activo afectado, estado de explotación, inteligencia de amenazas, criticidad para las operaciones de la organización y SLA requerido. Si se sospecha explotación, vincule el ticket con una evaluación de incidente.
Paso 4: Ejecutar mediante gestión de cambios
La aplicación de parches es un cambio. Utilice cambio estándar para actualizaciones rutinarias y cambio de emergencia para vulnerabilidades críticas explotadas. Incluya evidencias de pruebas, aprobación, marca temporal de implantación, plan de reversión y validación posterior al cambio.
Esto coincide con la relación de Zenith Controls entre 8.8 y 8.32, donde la aplicación de parches se gobierna mediante la gestión de cambios para equilibrar urgencia y estabilidad operativa.
Paso 5: Validar el cierre
No cierre tickets basándose solo en “parche instalado”. Exija validación mediante reescaneo, confirmación de versión, verificación de configuración o confirmación de controles compensatorios. Cuando el parche no pueda aplicarse, abra una excepción.
Paso 6: Registrar excepciones y riesgo residual
La Política de gestión de vulnerabilidades y parches define el contenido requerido de las excepciones:
Las solicitudes de excepción deben incluir: 7.2.1 Justificación de negocio del retraso o de la no remediación 7.2.2 Evaluación de riesgos (basada en CVSS, criticidad del activo e inteligencia de amenazas) 7.2.3 Controles compensatorios propuestos 7.2.4 Plazo de remediación o reevaluación
También define la aprobación y revisión:
Las excepciones deben ser aprobadas por el CISO o por el comité de riesgos delegado y registrarse en el Registro de excepciones del SGSI, con un intervalo de revisión que no supere los 90 días.
Ese registro de excepciones se convierte en evidencia esencial para el tratamiento de riesgos y la aceptación del riesgo residual conforme a la cláusula 6.1.3 de ISO/IEC 27001:2022, así como para la revisión por la dirección.
| Campo de excepción | Ejemplo de evidencia |
|---|---|
| ID de activo | PROD-DB-04, base de datos heredada de analítica de clientes |
| Vulnerabilidad | Vulnerabilidad crítica de ejecución remota de código con CVSS 9.8 |
| Justificación de negocio | El parche es incompatible con un runtime heredado y causaría una indisponibilidad en una aplicación programada para retirada |
| Evaluación de riesgos | No está expuesta a internet, alto impacto en las operaciones de la organización, sin exploit activo contra esta configuración; el riesgo sigue siendo alto pero reducido |
| Controles compensatorios | VLAN segura, reglas estrictas de cortafuegos, registro de eventos reforzado, comprobaciones de integridad, acceso mediante bastión con MFA |
| Plazo de remediación | Retirada antes del 31 de octubre de 2026; excepción revisada cada 90 días |
| Aprobación | Aprobación del CISO, entrada en el Registro de excepciones del SGSI, aceptación del propietario del riesgo |
Este registro demuestra que la organización no ignoró la vulnerabilidad. Evaluó el riesgo, aplicó controles compensatorios, aprobó el riesgo residual y fijó una fecha de revisión.
Paso 7: Crear el paquete mensual de evidencias
Su paquete mensual de evidencias de remediación de vulnerabilidades debe incluir:
| Elemento de evidencia | Finalidad | Valor de auditoría |
|---|---|---|
| Política aprobada de gestión de vulnerabilidades y parches | Define criterios y SLA | Muestra gobierno y aprobación de la dirección |
| Exportación de criticidad de activos | Vincula vulnerabilidades con impacto en las operaciones de la organización | Respalda la priorización basada en riesgos |
| Informe del escáner | Muestra cobertura de detección | Prueba que las vulnerabilidades se identifican |
| Exportación de tickets | Muestra asignación, fechas y estado | Prueba flujo de trabajo y responsabilidad proactiva |
| Registros de cambios | Muestran despliegue controlado | Prueban que los parches fueron aprobados e implantados |
| Escaneo de validación | Confirma la remediación | Prueba la eficacia |
| Registro de excepciones | Muestra el riesgo residual aceptado | Prueba que los retrasos están gobernados |
| Seguimiento de SLA de proveedores | Muestra obligaciones de terceros | Prueba la supervisión de la cadena de suministro |
| Cuadro de mando de KPI | Muestra tendencias de desempeño | Respalda la revisión por la dirección |
| Registro de acciones correctivas | Muestra mejoras ante fallos | Respalda la gestión de no conformidades |
Para pymes, las evidencias pueden ser más ligeras, pero deben seguir siendo coherentes. La Política de gestión de vulnerabilidades y parches para pymes exige registros de parches con trazabilidad:
Los registros deben incluir el nombre del dispositivo, la actualización aplicada, la fecha de parcheo y el motivo de cualquier retraso
Esa única cláusula es oro para auditoría. Convierte la aplicación de parches de una afirmación en un registro.
Aplicación de parches por proveedores: el contrato debe coincidir con su SLA
Si un MSP, proveedor SaaS, proveedor PaaS o proveedor de servicios en la nube controla el despliegue de parches, los SLA internos son inútiles salvo que las obligaciones del proveedor coincidan con ellos.
La Política de seguridad de terceros y proveedores para pymes incluye obligaciones de seguridad de la información como requisito de gobierno. Para la remediación de vulnerabilidades, esas obligaciones deben convertirse en lenguaje contractual medible:
- Ventanas de notificación de vulnerabilidades críticas
- Plazos de remediación para severidad crítica, alta, media y baja
- Proceso de cambio de emergencia
- Requisitos de aprobación del cliente para indisponibilidades
- Formato de evidencias para la finalización del parcheo
- Proceso de divulgación de vulnerabilidades
- Obligaciones de asistencia en incidentes
- Derecho de auditoría o de recepción de informes de aseguramiento
- Obligaciones de parcheo de subencargados o subcontratistas
- Soporte de salida y transición para servicios críticos
Zenith Blueprint, fase Controles en acción, paso 20, control 8.21 Seguridad de los servicios de red, establece el principio con claridad:
Cuando los servicios se prestan externamente, incluidos ISP, proveedores SD-WAN o proveedores de nube privada, los requisitos de seguridad deben incorporarse a los contratos y SLA. Esto incluye garantías de disponibilidad, tiempos de respuesta ante incidentes, obligaciones de parchear o mitigar vulnerabilidades y límites claros de tratamiento de datos. Nunca debe asumir que un proveedor cumple sus expectativas salvo que esté escrito, sea medible y sea auditable.
DORA hace que esto sea especialmente importante para las entidades financieras. Los acuerdos con terceros de TIC deben incluir niveles de servicio, asistencia del proveedor durante incidentes de TIC, acceso y recuperación de datos, cooperación con autoridades, derechos de terminación y disposiciones reforzadas para funciones críticas o importantes, incluida la supervisión, derechos de auditoría, planes de contingencia y medidas de seguridad.
NIST CSF 2.0 afirma lo mismo mediante resultados de riesgo de la cadena de suministro: los proveedores deben conocerse, priorizarse por criticidad, evaluarse antes de la contratación, gobernarse mediante requisitos contractuales, supervisarse durante toda la relación, incluirse en la planificación de incidentes y gestionarse al finalizar la relación.
Qué preguntarán realmente los auditores
La conversación de auditoría cambia según la experiencia del auditor.
Un auditor de ISO/IEC 27001:2022 comenzará por el SGSI. Comprobará si la gestión de vulnerabilidades está incluida en la Declaración de Aplicabilidad, si la evaluación de riesgos identifica los sistemas sin parchear como un riesgo, si los planes de tratamiento de riesgos tienen propietarios y plazos, si el control 8.8 del Anexo A está implantado, si se conservan evidencias y si la auditoría interna y la revisión por la dirección evalúan el desempeño.
Zenith Blueprint, fase Controles en acción, paso 19, hace explícita la expectativa de auditoría:
Este es un control de alta prioridad para los auditores, y normalmente profundizarán en él. Espere que le pregunten con qué frecuencia se parchean los sistemas, qué proceso sigue cuando se anuncia una vulnerabilidad de día cero y qué sistemas son más difíciles de parchear.
Continúa con expectativas prácticas de evidencia:
Es probable que los auditores soliciten resultados de escaneos de vulnerabilidades. Si utiliza herramientas como Nessus, OpenVAS o Qualys, exporte un informe que muestre vulnerabilidades recientes detectadas y cómo se trataron. Lo ideal es que incluya calificaciones de riesgo (CVSS) y plazos de remediación.
Un auditor o autoridad competente centrado en NIS2 buscará aprobación del consejo, proporcionalidad, ciberhigiene, gestión de vulnerabilidades, seguridad de proveedores, gestión de incidentes, evaluación de eficacia, acción correctiva sin demora indebida y registros de decisiones de notificación si la explotación causó un impacto significativo.
Un supervisor DORA comprobará si los hallazgos de vulnerabilidades están integrados en la gestión del riesgo TIC, las pruebas de resiliencia operativa digital, la clasificación de incidentes, el análisis de causa raíz, los registros de terceros, las obligaciones contractuales, los derechos de auditoría y la remediación de hallazgos críticos.
Un evaluador de NIST CSF probablemente organizará la revisión en torno a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER. Preguntará si se comprenden los requisitos legales y contractuales, si se documenta la tolerancia al riesgo, si se identifican y priorizan las vulnerabilidades, si se gestionan las excepciones, si la supervisión detecta la explotación y si se coordinan las acciones de respuesta y recuperación.
Un auditor COBIT 2019 o de estilo ISACA se centrará en objetivos de gobierno, capacidad del proceso, prácticas de gestión, métricas, propiedad, diseño de controles, operación de controles y suficiencia de las evidencias. Preguntará si la remediación de vulnerabilidades es repetible, medible, escalada, mejorada y alineada con los objetivos empresariales y el apetito de riesgo.
| Enfoque de auditoría | Pregunta probable | Evidencia sólida |
|---|---|---|
| ISO/IEC 27001:2022 | ¿La gestión de vulnerabilidades está basada en riesgos e incluida en el SGSI? | SoA, registro de riesgos, política, plan de tratamiento, registros de auditoría |
| NIS2 | ¿La ciberhigiene y la gestión de vulnerabilidades están aprobadas, supervisadas y corregidas sin demora indebida? | Actas de dirección, cuadro de mando de SLA, acciones correctivas, evaluación de notificación de incidentes |
| DORA | ¿Las vulnerabilidades TIC se gestionan como parte de la resiliencia y del riesgo de terceros? | Inventario de activos TIC, resultados de pruebas, plan de remediación, registro de proveedores, SLA contractuales |
| GDPR | ¿Podría un retraso de parche afectar a la seguridad de los datos personales? | Clasificación de datos, evaluación de riesgos, evaluación de brecha, controles compensatorios |
| NIST CSF 2.0 | ¿Están definidos los resultados actuales y objetivo, y se priorizan las deficiencias? | Perfil CSF, POA&M, métricas de vulnerabilidades, registros de excepciones |
| COBIT 2019 o ISACA | ¿El proceso está gobernado, medido y es eficaz? | RACI, tendencias de KPI y KRI, pruebas de controles, informes de gestión |
Escalado y métricas: cómo probar que el SLA se gestiona
Un SLA sin escalado es solo un objetivo. Un programa defendible de remediación de vulnerabilidades necesita escalado antes del incumplimiento, en el momento del incumplimiento y después de fallos repetidos.
Clarysec recomienda un modelo de escalado de cuatro niveles:
- Escalado operativo, se notifica al propietario del ticket y al responsable técnico antes del incumplimiento.
- Escalado de riesgos, el propietario del activo y el propietario del riesgo revisan el impacto cuando el incumplimiento es probable.
- Escalado de gobierno de la seguridad, el CISO o el comité de riesgos aprueba la excepción o la acción de emergencia.
- Escalado a la dirección, los incumplimientos de SLA repetidos o críticos se comunican en la revisión por la dirección con acciones correctivas.
La Política de gestión de vulnerabilidades y parches refuerza esta expectativa de auditoría:
Auditorías periódicas deben ser realizadas por auditoría interna o por un tercero independiente para verificar: 5.6.1 Cumplimiento de los SLA 5.6.2 Evidencia de priorización basada en riesgos 5.6.3 Eficacia de los parches desplegados 5.6.4 Controles sobre sistemas sin parchear
Las métricas deben apoyar decisiones, no decorar cuadros de mando. Las métricas más sólidas de 2026 incluyen:
- Porcentaje de cumplimiento de SLA críticos
- Porcentaje de cumplimiento de SLA altos
- Tiempo medio hasta el triaje
- Tiempo medio de remediación por clase de activo
- Número de vulnerabilidades críticas vencidas
- Número de excepciones aceptadas por antigüedad
- Excepciones que superan 90 días
- Recuento de exposición crítica en sistemas expuestos a internet
- Incumplimientos de SLA de proveedores
- Vulnerabilidades reabiertas tras la validación
- Cambios de emergencia causados por vulnerabilidades explotadas
- Fallos de parcheo por plataforma o unidad de negocio
Vincule estas métricas con la revisión por la dirección de la cláusula 9.3 de ISO/IEC 27001:2022, los informes de gobierno DORA y la supervisión de la dirección NIS2. Para NIST CSF 2.0, utilícelas para actualizar los perfiles actual y objetivo, el análisis de deficiencias y los planes de acción.
La lista de verificación de SLA de remediación de Clarysec
Use esta lista de verificación para evaluar su programa actual:
- ¿Existe una política aprobada de gestión de vulnerabilidades y parches?
- ¿Los SLA de remediación se definen por severidad y criticidad para las operaciones de la organización?
- ¿Se aceleran las vulnerabilidades expuestas a internet y explotadas?
- ¿Los activos están mapeados con propietarios, servicios, datos y proveedores?
- ¿Los hallazgos de escáner se convierten en tickets asignados?
- ¿Los parches se ejecutan mediante gestión de cambios?
- ¿Los cambios de emergencia se documentan y revisan?
- ¿Los resultados de remediación se validan mediante reescaneos o comprobaciones de versión?
- ¿Las excepciones se evalúan en función del riesgo, se aprueban y se revisan al menos cada 90 días?
- ¿Los controles compensatorios están documentados para sistemas no parcheables?
- ¿Los contratos de proveedores están alineados con los umbrales internos de remediación?
- ¿Los registros de parches son suficientemente completos para probar qué ocurrió y cuándo?
- ¿Los incumplimientos de SLA se escalan y se corrigen?
- ¿La dirección revisa las métricas?
- ¿Se activan evaluaciones de incidentes y de brechas cuando se sospecha explotación?
Si varias respuestas son “no”, el problema no es la herramienta. Es el diseño del control.
Próximos pasos: convertir los plazos de parcheo en resiliencia preparada para auditoría
En 2026, los SLA de remediación de vulnerabilidades deben hacer más que satisfacer un cuadro de mando de escáner. Deben probar que su organización puede identificar la exposición, priorizar el riesgo, actuar dentro de plazos aprobados, controlar excepciones, gobernar proveedores y evidenciar decisiones conforme a las expectativas de auditoría de ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 y COBIT 2019.
Clarysec puede ayudarle a pasar de tickets de parcheo fragmentados a un programa integrado de remediación de vulnerabilidades basado en evidencias mediante:
- Política de gestión de vulnerabilidades y parches
- Política de gestión de vulnerabilidades y parches para pymes
- Política de seguridad de terceros y proveedores para pymes
- Zenith Blueprint: hoja de ruta de 30 pasos para auditores
- Zenith Controls: la guía de cumplimiento transversal
Empiece por un servicio de alto riesgo. Mapee sus activos, proveedores, vulnerabilidades, tickets, cambios, excepciones y evidencias. Después ejecute las preguntas de auditoría sobre él. Si no puede probar el SLA desde la detección hasta el cierre, ese es su primer proyecto de remediación.
El objetivo no es el parcheo perfecto. El objetivo es una remediación gobernada, basada en riesgos, medible y auditable. Descargue las plantillas de políticas de Clarysec, realice una evaluación de deficiencias específica o reserve una demostración de Clarysec para convertir la remediación de vulnerabilidades de presión de auditoría en resiliencia operativa.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
