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 apenas guardan relación con lo que realmente ocurre en los dispositivos finales. Los acuerdos de nivel de servicio (SLA) son meras aspiraciones. En la lista de funciones figura alguien que se marchó hace dos años. Nadie sabe decir cuándo se revisó por última vez, ni qué cambios se introdujeron en caso de que se revisara.
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 los cambios de personal, cumple con los requisitos de auditoría y ofrece al equipo un argumento al que recurrir cuando los responsables de la empresa se oponen a una ventana de mantenimiento. Cuando está mal redactada, no es más que un mero formalismo 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 quede en meras aspiraciones. Las soluciones RMM de Kaseya gestionan la aplicación de parches en millones de terminales para proveedores de servicios gestionados (MSP) y equipos de TI internos, 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 silenciosamente.
¿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 aplicar dichas normas. (Si necesitas conocer la definición básica antes de continuar, nuestro artículo de referencia sobre la gestión de parches es el punto de partida ideal).
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 le indica a un ingeniero qué botón debe pulsar en la herramienta de gestión remota de activos (RMM). Lo que hace es comunicar a la organización que los parches críticos deben implementarse 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 se encargan de poner 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:
Lo primero 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 resisten 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 aspecto 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 cuantificables. La norma ISO 27001:2002, anexo A, punto 8.8, aborda explícitamente la gestión de vulnerabilidades, de la que la aplicación de parches es el núcleo operativo. La NIS2, en vigor 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 «aplicamos parches cuando podemos».
El tercero es la continuidad. La gente se va, las herramientas cambian, las prioridades varían. 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 introdujo requisitos más estrictos en materia de priorización basada en el riesgo, lo que significa que un enfoque basado únicamente en el CVSS podría ya no satisfacer a un evaluador riguroso.
La Norma de Seguridad de la HIPAA no especifica plazos, pero exige a las entidades sujetas a ella 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, punto 8.8 (Gestión de vulnerabilidades técnicas), exige que se recopile información sobre las vulnerabilidades técnicas de manera oportuna, se evalúe el riesgo al que está expuesta la organización y se adopten las medidas adecuadas. Los auditores esperan encontrar una política documentada, 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. Aunque las medidas de aplicación de los Estados miembros varían en 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 a los incidentes de seguridad y a las vulnerabilidades. Una política de gestión de parches es uno de los elementos de prueba habituales 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, sustituya y elimine en función del riesgo, lo que en la práctica implica 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 contenido es el mismo. Omitir cualquiera de ellas deja un vacío que un auditor detectará.
1. Objeto y ámbito de aplicación
Explica 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, sin embargo, 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 eternamente sobre si se suponía que debían hacerlo.
2. Funciones y responsabilidades
Cada apartado de la política debe corresponderse con un cargo concreto. Las políticas genéricas recurren a cargos genéricos; las eficaces, en cambio, definen funciones específicas y las responsabilidades de cada una de ellas. Una estructura viable:
- Responsable de la gestión de parches (normalmente el director de seguridad de la información o el director de TI). Es el responsable de la política. Aprueba las excepciones. Revisa los informes de cumplimiento. Es la última instancia a la que se puede recurrir.
- 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 ventanas 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. Colaboren con los horarios de reinicio. No desactiven los agentes de actualización. Informen de cualquier problema relacionado con las actualizaciones.
Los nombres cambian, las funciones permanecen. La política enumera las funciones y, en un apéndice, se indica a qué personas concretas corresponden, en caso de que así lo exija su 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 las amenazas 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 acuerdo de nivel de servicio (SLA) de implementación. Un modelo viable para 2026 tendría este 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. Actualización fuera de ciclo, pruebas reducidas, reinicio obligatorio.
- Crítica. CVSS 9,0 o superior, o cualquier vulnerabilidad en sistemas conectados a Internet, independientemente del CVSS. Implementar en un plazo de 7 a 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.
- Medio. CVSS 4.0 a 6.9. Implementar en un plazo de 60 a 90 días, normalmente como parte de los ciclos de mantenimiento habituales.
- Bajo. CVSS inferior a 4,0. Implementar en el mantenimiento habitual; no se requiere un 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 con 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 se explotan activamente.
En el caso concreto de los sistemas conectados a Internet, muchos programas consolidados aplican un acuerdo de nivel de servicio (SLA) más estricto que el de la tabla anterior. El informe DBIR 2025 de Verizon identificó 17 vulnerabilidades en 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 diferencia 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é se entiende por «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 el á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 paso 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. Pruebas de parches y normas de implementación
Defina cómo se prueban los parches antes de su implementación generalizada. La política no establece los detalles técnicos, sino que fija los requisitos. Una norma viable:
- Las actualizaciones de rutina siguen una estructura por fases definida (piloto, validación, producción) con periodos de espera entre cada fase.
- Los parches de emergencia siguen una estructura de anillos comprimidos (prueba de funcionamiento en un proyecto piloto representativo, seguida de un despliegue general) 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 tenga prioridad 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 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 etapas en la práctica, nuestra guía sobre el proceso de gestión de parches las desglosa una por una.
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 actualización. La política debe incluir un proceso de excepciones bien definido, no un acuerdo tácito de que «ya se nos ocurrirá algo».
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 encargada de la gestión de parches para excepciones de duración limitada, con revisión por parte del equipo de seguridad)
- Una duración máxima de la excepción (90 días es un valor predeterminado razonable; para renovarla, es necesario volver a examinarla)
- Un requisito de control compensatorio (segmentación de la red, supervisión adicional, parches virtuales) para cualquier excepción que supere el 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
Especifique 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 parches, índice de cumplimiento del SLA, número de excepciones, tiempo medio hasta la aplicación del parche. Revisados por el responsable del equipo de gestión de parches 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 los marcos normativos, deficiencias y medidas correctivas. Entregado a la dirección ejecutiva y a los auditores externos.
El requisito de presentación de informes suele ser el aspecto en el que los resultados de la auditoría son más fáciles de predecir. Si la política establece que deben realizarse revisiones trimestrales y no puedes presentar las actas de las cuatro últimas, ese será el resultado.
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 parches evita verse bloqueado por un comité de cambios que se reúne semanalmente cuando el reloj de la amenaza corre 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 recomienda 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 en una organización de cierta envergadura —que supere unas pocas docenas de terminales— genera inconsistencias y retrasos. La automatización, si se cuenta con los controles de seguridad adecuados, resulta 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 en manos del personal. A efectos normativos, este requisito es suficiente.
10. Revisión de políticas y control de versiones
Establezca una periodicidad para las revisiones y cúmplala. 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 graves, reestructuración organizativa)
- Requisitos de control de versiones (cada versión debe estar fechada, los cambios deben resumirse y deben conservarse las versiones anteriores)
- Órgano competente para aprobar los cambios en la política (por lo general, el mismo que aprobó la política original)
Una política sin historial de versiones es una política que nadie supervisa.
Modelo de política de gestión de parches
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
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 de 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 de la gravedad
4.2 Acuerdos de nivel de servicio (SLA) para la implementación según la 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 implementaciones fallidas
7. Gestión de excepciones
7.1 Procedimiento de solicitud de excepciones
7.2 Autoridad competente
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. Presentación de 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 Mapeo del marco
9. Integración de la gestión del cambio
9.1 Clasificaciones de los cambios: estándar, normales y de emergencia
9.2 Modificar la interacción con el comité asesor
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
Anexos
A. Mapeo 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 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 acuerdos de nivel de servicio (SLA) sin especificar la herramienta. Exige la realización de pruebas sin imponer la estructura de los ciclos. Fija la periodicidad de los informes sin diseñar los paneles de control.
En un programa bien gestionado, la política es el documento que garantiza que el proceso de gestión de parches sea repetible, independientemente de la rotación de personal y los cambios en las herramientas. También es el documento que permite que las buenas prácticas de gestión de parches se apliquen de verdad, en lugar de quedarse en meras aspiraciones. Un equipo puede decidir, como buena 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 bajo presión.
La política es también el ámbito en el que la automatización se impone como norma, en lugar de limitarse a tolerarse. En las organizaciones que no han incorporado formalmente la automatización en su política, cada nuevo administrador de sistemas vuelve a cuestionar 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 debidamente 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 concretas en cuanto a su alcance, en lugar de limitarse a expresar aspiraciones. 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 silenciosa. 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 acredite.
Si estás elaborando 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 estás actualizando 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 un plazo de 14 días, la herramienta no es capaz de indicar 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 trabajo manual con hojas de cálculo. La cobertura integrada de aplicaciones de terceros cubre las lagunas de alcance que la mayoría de las políticas establecen, pero que pocas herramientas logran subsanar. 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 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 solo un documento. Una política que la solución hace cumplir, supervisa y sobre la que genera informes es un control.
