Política de gestión de parches: por qué necesitas una y cómo elaborarla

La mayoría de las políticas de gestión de parches fracasan de la misma manera. Sobre el papel parecen correctas, se guardan en una carpeta de SharePoint, se muestran al auditor una vez al año y no guardan prácticamente ninguna relación con lo que ocurre realmente en los terminales. Los SLA son meras aspiraciones. En la lista de funciones figura alguien que se marchó hace dos años. Nadie sabe cuándo se revisó por última vez, ni qué cambios se introdujeron en caso de que se haya revisado.

Una política de gestión de parches está pensada para ser el documento que garantice la aplicación de los parches. Define qué se actualiza, con qué rapidez, quién lo hace, con qué excepciones y cómo se demuestra que se ha llevado a cabo. Cuando está bien redactada, resiste la rotación de personal, cumple con los requisitos de auditoría y ofrece al equipo un argumento al que recurrir cuando los responsables del negocio se oponen a una ventana de mantenimiento. Cuando está mal redactada, no es más que un mero pretexto para cumplir con la normativa.

Esta guía aborda los elementos que debe incluir una política de gestión de parches eficaz, los acuerdos de nivel de servicio (SLA) que se ajustan a los plazos actuales de las amenazas y cómo estructurar el documento para que sea aplicable en la práctica y no se quede en meras aspiraciones. Las soluciones RMM de Kaseya gestionan la aplicación de parches en millones de terminales para proveedores de servicios de gestión (MSP) y equipos internos de TI, lo que ofrece una visión bastante clara de qué estructuras de políticas se siguen en la práctica y cuáles se ignoran discretamente.

¿Qué es una política de gestión de parches?

Una política de gestión de parches es el documento normativo que define cómo una organización identifica, evalúa, implementa y verifica las actualizaciones de software. Establece las normas, los plazos y las responsabilidades relacionadas con la aplicación de parches, mientras que el proceso de gestión de parches es el flujo de trabajo operativo diario que se utiliza para llevar a cabo dichas normas. (Si necesitas conocer la definición básica antes de seguir adelante, nuestro artículo de referencia sobre la gestión de parches es el punto de partida adecuado).

Esta distinción es importante porque la mayoría de los equipos confunden ambos conceptos. Una política no es un manual de procedimientos. No indica a un ingeniero en qué botón debe hacer clic en la herramienta de gestión remota (RMM). Lo que sí indica a la organización es que los parches críticos deben aplicarse dentro de un plazo definido, que una función concreta es responsable de ello y que las excepciones requieren una autorización documentada. Los manuales de procedimientos ponen en práctica la política. La política hace que el trabajo operativo sea justificable.

¿Por qué necesitamos una política de gestión de parches?

Es necesaria una política de gestión de parches por tres razones, más o menos en este orden de importancia:

La primera es la aplicabilidad. Sin una política, cada implementación de parches se convierte en una negociación. Los responsables de las aplicaciones solicitan aplazamientos, las unidades de negocio se oponen a los reinicios y el equipo encargado del mantenimiento de los parches carece de autoridad formal para imponerse. Una política ratificada por la dirección otorga al equipo de parches un mandato documentado.

El segundo es la auditoría. Casi todos los marcos de cumplimiento normativos modernos exigen un enfoque documentado para la aplicación de parches, y los auditores buscan una política real, no un mero formalismo. La norma PCI DSS 4.0, por ejemplo, exige que los parches de seguridad se instalen en el plazo de un mes desde su lanzamiento en los sistemas críticos. La HIPAA exige medidas de seguridad técnicas «razonables y adecuadas», lo que los evaluadores interpretan como una aplicación de parches documentada con resultados medibles. El anexo A, apartado 8.8, de la norma ISO 27001:2002 aborda explícitamente la gestión de vulnerabilidades, de la que la aplicación de parches constituye el núcleo operativo. La normativa NIS2, vigente en toda la UE, exige pruebas de la gestión de vulnerabilidades para las organizaciones incluidas en su ámbito de aplicación. El criterio CC7.1 de los Servicios de Confianza de SOC 2 exige la supervisión y la corrección de nuevas vulnerabilidades. Ninguna de estas normas acepta como respuesta un «aplicamos los parches cuando podemos».

El tercero es la continuidad. La gente se va, las herramientas cambian, las prioridades varían. Contar con una política por escrito es lo que permite a un nuevo director de TI hacerse cargo de un programa de aplicación de parches sin tener que volver a crearlo desde cero.

El caso de incumplimiento, con más detalle

Vale la pena ser concreto sobre lo que exigen los principales marcos normativos, ya que los resúmenes imprecisos hacen que las políticas acaben sin cumplir los requisitos que se someten a auditoría.

La norma PCI DSS 4.0 exige que los parches de seguridad críticos se instalen en los sistemas incluidos en el ámbito de aplicación en el plazo de un mes desde su lanzamiento, y que se aplique un enfoque documentado basado en el riesgo para los parches no críticos. La versión 4.0 ha introducido requisitos más estrictos en cuanto a la priorización basada en el riesgo, lo que significa que un enfoque basado únicamente en el CVSS podría ya no ser suficiente para un evaluador exigente.

La Norma de Seguridad de la HIPAA no especifica plazos, pero exige a las entidades sujetas a su aplicación que «apliquen procedimientos para prevenir, detectar y notificar el software malicioso» y que «apliquen medidas de seguridad suficientes para reducir los riesgos y las vulnerabilidades a un nivel razonable y adecuado». En la práctica, las medidas coercitivas de la OCR del HHS han considerado que los retrasos de varios meses en la aplicación de parches para vulnerabilidades conocidas constituyen un incumplimiento de la Norma de Seguridad.

La norma ISO 27001:2022, anexo A, apartado 8.8 («Gestión de vulnerabilidades técnicas»), exige que se obtenga información sobre las vulnerabilidades técnicas de manera oportuna, se evalúe la exposición de la organización y se adopten las medidas adecuadas. Los auditores esperan encontrar una política por escrito, acuerdos de nivel de servicio (SLA) definidos y pruebas de su aplicación.

La Directiva NIS2 exige a las entidades esenciales e importantes de los sectores críticos de la UE que gestionen las vulnerabilidades y las notificaciones de seguridad. Aunque las medidas de aplicación de los Estados miembros varían en cuanto a los detalles, la expectativa general es que se documente la aplicación de parches con tiempos de respuesta cuantificables.

El criterio CC7.1 de los Servicios de Confianza de SOC 2 exige que la entidad detecte y responda ante incidentes de seguridad y vulnerabilidades. Una política de gestión de parches es uno de los elementos de prueba estándar que revisan los auditores.

El NIST CSF 2.0, en el marco de la función «Proteger» (PR.PS-02), exige que el software se mantenga, se sustituya y se elimine en función del riesgo, lo que en la práctica significa una gestión documentada de los parches.

Si estás redactando una política principalmente para superar una auditoría, hazlo basándote en el marco normativo más exigente al que estés sujeto. El resto se derivará de ahí.

Elementos de una política eficaz de gestión de parches

Una política de gestión de parches consta, aproximadamente, de diez secciones. Algunas plantillas las dividen o combinan de forma diferente, pero el fondo es el mismo. Omitir cualquiera de ellas crea una laguna que un auditor detectará.

1. Objeto y ámbito de aplicación

Indica cuál es el objetivo de la política y qué abarca. El objetivo se resume en una o dos frases: esta política garantiza la identificación, evaluación e implementación oportunas de las actualizaciones de software para mantener la seguridad, la estabilidad y el cumplimiento normativo. El alcance es más importante y suele pasarse por alto con mayor frecuencia. Debe especificar:

• Qué activos cubre la póliza (servidores, estaciones de trabajo, ordenadores portátiles, dispositivos móviles, máquinas virtuales, contenedores, dispositivos de red, IoT, firmware)
• ¿Qué tipos de software (sistemas operativos, aplicaciones, software de terceros, firmware)?
• ¿Qué entornos (producción, staging, desarrollo, BYOD, si procede)?
• ¿Qué entidades (empleados, contratistas, sistemas gestionados por terceros)?

Las lagunas en el alcance son el origen de los hallazgos de auditoría. Si la política no cubre explícitamente el firmware de red o las aplicaciones de terceros, el equipo puede discutir indefinidamente sobre si se suponía que debían estar incluidos.

2. Funciones y responsabilidades

Cada apartado de la política debe corresponderse con un cargo concreto. Las políticas genéricas utilizan cargos genéricos; las eficaces especifican funciones concretas y las responsabilidades de cada una de ellas. Una estructura viable:

• Responsable de la gestión de parches (normalmente el CISO o el director de TI). Es el responsable de la política. Aprueba las excepciones. Revisa los informes de cumplimiento. Es la instancia de escalación final.
• Jefe del equipo de gestión de parches (un responsable de operaciones de TI o de seguridad). Es el responsable del programa operativo. Establece el calendario de aplicación de parches. Se coordina con los responsables de las aplicaciones.
• Administradores de sistemas. Aplicar parches en los sistemas que se les hayan asignado. Mantener los entornos de pruebas. Gestionar la reversión de cambios cuando sea necesario.
• Responsables de aplicaciones. Identificar las aplicaciones críticas para el negocio. Aprobar las franjas horarias de mantenimiento. Comprobar el correcto funcionamiento tras la aplicación de parches.
• Equipo de seguridad. Supervisar la información sobre amenazas. Señalar las vulnerabilidades urgentes. Realizar un seguimiento de las listas KEV de la CISA y de los CVE relacionados con el ransomware. Verificar el cumplimiento normativo.
• Titulares de activos. Mantener un inventario preciso de los activos que tienen bajo su control.
• Usuarios finales. Colaborad con los horarios de reinicio. No desactivéis los agentes de aplicación de parches. Informad de cualquier problema relacionado con los parches.

Los nombres cambian, las funciones permanecen. La política enumera las funciones y, en un apéndice, se indica a qué personas concretas corresponden actualmente, en caso de que así lo exija tu estructura de gobierno.

3. Clasificación de parches y acuerdos de nivel de servicio (SLA)

Esta es la sección más importante, y en la que la mayoría de las políticas están peligrosamente desactualizadas. Los plazos de amenaza en los que se basaban las plantillas de hace cinco años ya no son válidos.

La clasificación divide los parches según su gravedad y su vulnerabilidad a los ataques, y luego vincula cada nivel a un SLA de implementación. Un modelo viable para 2026 tendría el siguiente aspecto:

• Emergencia/explotada activamente. Una vulnerabilidad incluida en el catálogo KEV de la CISA, con un exploit publicado, en un sistema afectado. Implementar en un plazo de 24 a 48 horas. Lanzamiento fuera de banda, pruebas aceleradas, reinicio obligatorio.
• Crítica. CVSS 9,0 o superior, o cualquier vulnerabilidad en sistemas conectados a Internet, independientemente de la puntuación CVSS. Implementar en un plazo de entre 7 y 14 días. Pruebas estándar, implementación programada.
• Alto. CVSS 7,0 a 8,9, en sistemas internos, sin explotación activa. Implementar en un plazo de 30 días.
• Media. CVSS 4.0 a 6,9. Implementar en un plazo de entre 60 y 90 días, normalmente como parte de los ciclos de mantenimiento habituales.
• Bajo. CVSS inferior a 4,0. Implementar durante el mantenimiento habitual; no se requiere ningún SLA específico.

La razón por la que estos plazos se han acortado es que el panorama de las amenazas ha cambiado. El análisis de VulnCheck sobre el primer semestre de 2025 reveló que el 32,1 % de las vulnerabilidades incluidas en la lista KEV fueron explotadas en las 24 horas siguientes a su divulgación, o incluso antes, lo que supone un aumento respecto al 23,6 % del año anterior. Una política que concede 30 días para aplicar parches a los sistemas conectados a Internet supone, según la información actual sobre amenazas, permitir semanas de exposición conocida a vulnerabilidades que están siendo explotadas activamente.

En el caso concreto de los sistemas conectados a Internet, muchos programas consolidados aplican un SLA más estricto que el de la tabla anterior. El informe DBIR 2025 de Verizon identificó 17 vulnerabilidades de dispositivos periféricos incluidas en la lista KEV y determinó que el tiempo medio para su corrección total fue de 209 días, frente a los cinco días que tardaron los atacantes en explotarlas de forma masiva. Una política que no tenga en cuenta esta brecha es como escribir en un mundo congelado.

Independientemente de los SLA que establezcas, exprésalos en días laborables, define cuándo comienza a contar el plazo (¿la publicación del proveedor, la inclusión en la lista KEV o tu detección?) y especifica qué significa «parcheado» (implementado y verificado, no solo enviado a la consola de gestión).

4. Requisitos relativos al inventario de activos

La política debe exigir un inventario continuo y automatizado de todos los activos incluidos en su ámbito de aplicación, con responsabilidad nominal sobre la exactitud del inventario. Especifique los datos mínimos que deben registrarse por cada activo (nombre de host, sistema operativo, versión, nivel de parches, propietario, última comprobación), la periodicidad con la que se concilia el inventario y el umbral por debajo del cual se considera que el programa incumple sus propios requisitos. La mayoría de las políticas omiten este aspecto y luego no pueden explicar por qué un host ha estado sin parches durante seis meses. La razón es siempre la misma: nadie sabía que existía.

5. Normas para las pruebas de parches y su implementación

Definir cómo se prueban los parches antes de su implantación generalizada. La política no establece los detalles técnicos, sino que fija los requisitos. Una norma viable:

• Las actualizaciones rutinarias siguen una estructura por fases definida (piloto, validación, producción) con períodos de espera entre cada fase.
• Los parches de emergencia siguen una estructura de «anillo comprimido» (prueba de funcionamiento en un proyecto piloto representativo, seguida de un despliegue generalizado) con una aceptación de riesgos documentada.
• Los parches que afectan a sistemas críticos para el negocio requieren la aprobación expresa del responsable de la aplicación antes de su implementación en producción.
• Los reinicios necesarios para la aplicación de parches se programan dentro de las franjas horarias de mantenimiento aprobadas, salvo en casos de emergencia en los que el SLA prevalezca sobre dicha franja horaria.
• Las implementaciones fallidas activan un reintento automático y, si el segundo intento falla, se envía una alerta al equipo de aplicación de parches.

El motivo por el que se redactan como normas en lugar de procedimientos es que el equipo operativo pueda modificar las herramientas y las tácticas sin tener que reescribir la política. Siempre que se cumpla la norma, la implementación puede evolucionar. Para obtener más detalles sobre cómo los equipos llevan a cabo estas fases en la práctica, nuestra guía sobre el proceso de gestión de parches desglosa cada una de ellas.

6. Gestión de excepciones y aceptación de riesgos

En cualquier entorno hay sistemas a los que no se les pueden aplicar parches según lo previsto. Aplicaciones heredadas que dejan de funcionar con las bibliotecas más recientes. Dispositivos de proveedores sujetos a un contrato de mantenimiento que controla las actualizaciones. Sistemas aislados físicamente con sus propias ventanas de cambio. La política debe contar con un proceso de excepciones bien definido, no con un acuerdo tácito de que «ya lo resolveremos».

Una cláusula de excepción válida incluye:

• Un formulario de solicitud de excepción debidamente documentado (activo, vulnerabilidad, motivo, controles compensatorios, responsable, fecha de caducidad)
• Un responsable de la aprobación designado (normalmente, la Autoridad de Gestión de Parches para excepciones con plazo limitado, con revisión por parte del equipo de seguridad)
• Una duración máxima de la excepción (90 días es un valor por defecto razonable; para renovarla, es necesario volver a evaluarla)
• Un requisito de control compensatorio (segmentación de la red, supervisión adicional, parches virtuales) para cualquier excepción que se prolongue más allá del SLA original
• Un registro central de excepciones que se revisa trimestralmente y sobre el que se informa anualmente

La razón por la que esta sección es importante es que, sin ella, el proceso de excepción se reduce a que «el equipo se rinde y pasa a otra cosa». Ese es el camino que lleva a que los sistemas acumulen vulnerabilidades conocidas durante años sin que quede constancia alguna de por qué.

7. Presentación de informes y verificación del cumplimiento

Especifica qué se comunica, a quién y con qué frecuencia. Una estructura de información que se pueda justificar:

• Cuadros de mando operativos. Cumplimiento de las actualizaciones en tiempo real por grupo de activos, a disposición del equipo de actualizaciones de forma continua.
• Informes mensuales. Porcentaje de cumplimiento de las actualizaciones, índice de cumplimiento del SLA, número de excepciones y tiempo medio hasta la aplicación de la actualización. Revisados por el responsable del equipo de gestión de actualizaciones y la autoridad competente.
• Revisiones trimestrales. Análisis de tendencias, cobertura de amenazas emergentes, revisión del registro de excepciones, eficacia de las políticas. Presentadas al equipo directivo de seguridad.
• Informe anual. Situación de cumplimiento a lo largo de todo el año, resumen de la correspondencia con el marco normativo, deficiencias y medidas correctoras. Entregado a la dirección ejecutiva y a los auditores externos.

El requisito de presentación de informes suele ser el ámbito en el que resulta más fácil predecir las observaciones de la auditoría. Si la política establece que deben realizarse revisiones trimestrales y no puedes presentar las actas de las cuatro últimas, esa será la observación.

8. Integración de la gestión del cambio

La aplicación de parches y la gestión de cambios se solapan. La política debe especificar cómo encaja la aplicación de parches en el proceso más amplio de gestión de cambios: qué se considera un cambio estándar (tipos de parches preaprobados implementados en ventanas de tiempo definidas), qué se considera un cambio normal (implementaciones puntuales o fuera de ciclo) y qué se considera un cambio de emergencia (respuesta ante una explotación activa). Esto no es una carga burocrática. Es la forma en que el equipo de aplicación de parches evita verse bloqueado por un comité de cambios que se reúne semanalmente, cuando el reloj de la amenaza avanza por horas.

9. Requisitos de automatización

Las políticas actuales deberían exigir explícitamente la automatización siempre que sea viable. La formulación es importante: no «se fomenta la automatización», sino «el programa de aplicación de parches utilizará herramientas automatizadas para la detección, el análisis, la implementación y la generación de informes, reservando la intervención manual para las excepciones documentadas».

Los motivos para ello son de carácter operativo y de seguridad. La aplicación manual de parches a la escala de cualquier organización que supere unas pocas docenas de terminales genera inconsistencias y retrasos. La automatización, con los controles de seguridad adecuados, es más rápida, más coherente y más justificable. En nuestro blog sobre la gestión automatizada de parches se puede encontrar un análisis más detallado sobre qué procesos automatizar y cuáles dejar manuales. A efectos normativos, este requisito es suficiente.

10. Revisión de políticas y control de versiones

Establece una periodicidad para las revisiones y cúmplela. La revisión anual es el mínimo; la revisión trimestral es adecuada cuando las condiciones de amenaza o los requisitos de cumplimiento cambian de forma significativa. La política debe especificar:

• Periodicidad de la revisión (normalmente anual)
• Condiciones que dan lugar a una revisión fuera de ciclo (cambios importantes en el marco, incidentes de seguridad significativos, reestructuración organizativa)
• Requisitos de control de versiones (cada versión debe llevar fecha, se deben resumir los cambios y se deben conservar las versiones anteriores)
• Organismo con competencia para aprobar modificaciones de la política (normalmente el mismo que aprobó la política original)

Una política sin historial de versiones es una política que nadie supervisa.

Plantilla de política de gestión de parches (ejemplo)

Aquí tienes un esquema que se corresponde con las diez secciones anteriores. No es un documento definitivo, sino una estructura sobre la que ir añadiendo detalles.

PLANTILLA DE POLÍTICA DE GESTIÓN DE PARCHES

1. Objetivo

2. Ámbito de aplicación

   2.1 Activos incluidos en el ámbito de aplicación

   2.2 Tipos de software incluidos en el ámbito de aplicación

   2.3 Entornos incluidos en el ámbito de aplicación

   2.4 Activos excluidos del ámbito de aplicación y exclusiones

3. Funciones y responsabilidades

   3.1 Autoridad encargada de la gestión de parches

   3.2 Responsable del equipo de gestión de parches

   3.3 Administradores del sistema

   3.4 Propietarios de aplicaciones

   3.5 Equipo de seguridad

   3.6 Titulares de activos

   3.7 Usuarios finales

4. Clasificación de parches y acuerdos de nivel de servicio (SLA)

   4.1 Clasificación por gravedad

   4.2 Acuerdos de nivel de servicio (SLA) de implementación según el nivel de gravedad

   4.3 Acuerdos de nivel de servicio (SLA) para sistemas conectados a Internet

   4.4 Criterios de respuesta ante emergencias

5. Inventario de activos

   5.1 Requisitos relativos a los datos de inventario

   5.2 Frecuencia de las conciliaciones

   5.3 Límites de cobertura

6. Pruebas de parches e implementación

   6.1 Requisitos de ensayo

   6.2 Estructura del anillo de despliegue

   6.3 Ventanas de mantenimiento

   6.4 Gestión del reinicio

   6.5 Gestión de las implementaciones fallidas

7. Gestión de excepciones

   7.1 Procedimiento de solicitud de excepciones

   7.2 Autoridad competente para la aprobación

   7.3 Duración y renovación de la excepción

   7.4 Controles de compensación

   7.5 Registro y revisión de excepciones

8. Informes y cumplimiento normativo

   8.1 Informes operativos

   8.2 Informes mensuales de cumplimiento

   8.3 Revisiones trimestrales

   8.4 Informe anual de cumplimiento

   8.5 Correlación de marcos

9. Integración de la gestión del cambio

   9.1 Clasificaciones de los cambios: estándar, normales y de emergencia

   9.2 Interacción con el comité asesor de cambios

10. Automatización

   10.1 Alcance de la automatización requerida

   10.2 Criterios de intervención manual

11. Gobernanza basada en políticas

   11.1 Frecuencia de las revisiones

   11.2 Condiciones que dan lugar a una revisión fuera de ciclo

   11.3 Control de versiones

   11.4 Autoridad competente para la aprobación

Anexos

A. Mapa del marco de cumplimiento (PCI DSS, HIPAA, ISO 27001, NIS2, SOC 2)

B. Funciones asignadas a personas concretas (actual)

C. Registro de excepciones

D. Glosario de términos

E. Historial de revisiones

Los anexos son el lugar donde la política se mantiene actualizada sin que sea necesario modificar constantemente el documento principal. Los nombres, los marcos normativos y las excepciones cambian. Los compromisos estructurales no deberían hacerlo.

Cómo se integra una política en el programa general de aplicación de parches

Una política es el nivel normativo que se sitúa por encima del trabajo operativo. Establece los SLA sin especificar la herramienta. Exige la realización de pruebas sin dictar la estructura de los ciclos. Fija la periodicidad de los informes sin diseñar los paneles de control.

En un programa eficaz, la política es el documento que hace que el proceso de gestión de parches sea repetible a pesar de la rotación de personal y los cambios en las herramientas. También es el documento que garantiza que las mejores prácticas de gestión de parches se apliquen de verdad, en lugar de quedarse en meras aspiraciones. Un equipo puede decidir, como mejor práctica, que dará prioridad a los parches relacionados con Internet, pero si la política no lo exige, esa práctica desaparecerá silenciosamente la próxima vez que el equipo se vea sometido a presión.

La política es también el ámbito en el que la automatización se impone como norma, en lugar de tolerarse. En las organizaciones que no han incorporado formalmente la automatización en su política, cada nuevo administrador de sistemas tiene que volver a debatir si la automatización es «segura» o «apropiada», y la deriva resultante va minando el programa con el paso de los años. Una política que establezca que la automatización es la norma por defecto, con excepciones documentadas, pone fin a ese debate.

Buenas prácticas en materia de políticas de gestión de parches

Una política de gestión de parches es uno de los documentos de gobernanza más influyentes con los que cuenta una organización de TI o de seguridad. Si se elabora correctamente, otorga autoridad al equipo encargado de la aplicación de parches, proporciona pruebas al auditor, aporta claridad a la empresa y garantiza la continuidad del programa. Si se elabora de forma deficiente, no pasa de ser un documento en SharePoint cuya existencia todos reconocen, pero que en realidad nadie sigue.

Las políticas que se mantienen en vigor comparten algunas características. Son específicas en cuanto a su alcance, en lugar de ser meramente aspiracionales. Sus acuerdos de nivel de servicio (SLA) reflejan los plazos actuales de las amenazas, no las plantillas de hace cinco años. Se refieren a funciones, no a personas concretas. Convierten las excepciones en un proceso documentado, no en una solución alternativa encubierta. Imponen la automatización en lugar de tolerar la proliferación de tareas manuales. Y se revisan con una periodicidad real, con un control de versiones que lo acredita.

Si vas a elaborar una política desde cero, basate en la estructura de diez secciones anterior y redacta cada sección teniendo en cuenta el marco normativo más exigente al que estés sujeto. Si vas a actualizar una política ya existente, empieza por los SLA. Son la parte que con mayor probabilidad se haya quedado desactualizada sin que te hayas dado cuenta, y son la parte que influye más directamente en si la política sigue reflejando cómo debe funcionar el programa. A partir de ahí, el resto del documento se puede actualizar sección por sección.

Cómo puede ayudarte Kaseya

Una política solo es aplicable si tus herramientas pueden realmente ejecutar y demostrar lo que exige dicha política. Ahí es donde fallan la mayoría de los programas de parches: el documento indica que los parches críticos deben implementarse en 14 días, pero la herramienta no puede indicarte cuáles incumplieron el SLA el mes pasado, y esa deficiencia se pone de manifiesto en la auditoría.

Las soluciones RMM de Kaseya están diseñadas para gestionar la aplicación de parches de acuerdo con los requisitos operativos que se derivan de una política de parches rigurosa. La detección continua de activos alimenta el módulo de inventario. El análisis y la implementación basados en políticas convierten la clasificación y los SLA en un flujo de trabajo automatizado, en lugar de un proceso manual basado en hojas de cálculo. La cobertura integrada de aplicaciones de terceros cubre la brecha de alcance que la mayoría de las políticas establecen, pero que pocas herramientas logran cubrir. La gestión de excepciones, los anillos de implementación y la reversión son funciones de primer nivel, en lugar de scripts personalizados.

Para los equipos internos de TI, esto se traduce en una política que se puede redactar, imponer y demostrar su cumplimiento sin necesidad de recopilar pruebas manualmente. Para los proveedores de servicios gestionados (MSP) que gestionan políticas de múltiples clientes, Datto RMM amplía el modelo a políticas de parches específicas para cada cliente, informes de SLA por cliente y el tipo de pruebas de certificación que satisfacen al auditor del cliente sin necesidad de elaborar un informe personalizado para cada proyecto.

La cuestión es de carácter operativo. Una política que la solución no puede hacer cumplir es un mero documento. Una política que la solución hace cumplir, supervisa y sobre la que genera informes es un control.