Política de gerenciamento de patches: por que você precisa de uma e como elaborá-la

A maioria das políticas de gerenciamento de patches falha da mesma maneira. Elas parecem ótimas no papel, ficam guardadas em uma pasta do SharePoint, são apresentadas ao auditor uma vez por ano e não têm praticamente nenhuma relação com o que realmente está acontecendo nos terminais. Os SLAs são meras aspirações. A lista de funções inclui alguém que saiu da empresa há dois anos. Ninguém sabe dizer quando foi a última revisão — nem o que mudou, caso tenha havido alguma.

Uma política de gerenciamento de patches tem como objetivo ser o documento que torna a aplicação de patches obrigatória. Ela define o que deve receber patches, com que rapidez, por quem, quais são as exceções e como comprovar que a aplicação ocorreu. Quando bem elaborada, ela resiste à rotatividade de pessoal, atende aos requisitos de auditoria e oferece à equipe um argumento a ser invocado quando os responsáveis pela empresa questionam uma janela de manutenção. Quando mal elaborada, serve apenas como um artifício de conformidade.

Este guia aborda o que uma política eficaz de gerenciamento de patches deve conter, os SLAs que se mantêm válidos diante dos prazos atuais de ameaças e como estruturar o documento para que seja aplicável, em vez de meramente declarativo. As soluções RMM da Kaseya gerenciam a aplicação de patches em milhões de terminais para MSPs e equipes internas de TI, o que oferece uma visão bastante clara de quais estruturas de política são seguidas na prática e quais são discretamente ignoradas.

O que é uma política de gerenciamento de patches?

Uma política de gerenciamento de patches é o documento normativo que define como uma organização identifica, avalia, implanta e verifica atualizações de software. Ela estabelece os padrões, prazos e responsabilidades relacionados à aplicação de patches, enquanto o processo de gerenciamento de patches é o fluxo de trabalho operacional diário utilizado para colocar esses padrões em prática. (Se você precisar da definição básica antes de prosseguir, nosso artigo de referência sobre gerenciamento de patches é o ponto de partida ideal.)

Essa distinção é importante porque a maioria das equipes confunde os dois conceitos. Uma política não é um manual de procedimentos. Ela não diz a um engenheiro em qual botão clicar na ferramenta de RMM. Ela informa à organização que patches críticos devem ser aplicados dentro de um intervalo de tempo definido, que uma função específica é responsável por isso e que exceções exigem aprovação documentada. Os manuais de procedimentos colocam a política em prática. A política torna o trabalho operacional justificável.

Por que precisamos de uma política de gerenciamento de patches?

É necessária uma política de gerenciamento de patches por três motivos, mais ou menos nesta ordem de importância:

O primeiro é a aplicabilidade. Sem uma política, toda implantação de patch se torna uma negociação. Os responsáveis pelas aplicações defendem adiamentos, as unidades de negócios resistem às reinicializações e a equipe que mantém os patches não tem autoridade formal para se sobrepor a essas decisões. Uma política aprovada pela liderança confere à equipe de patches um mandato documentado.

O segundo aspecto é a auditoria. Quase todas as estruturas modernas de conformidade exigem uma abordagem documentada para a aplicação de patches, e os auditores buscam uma política concreta, não apenas um lugar-marcador. O PCI DSS 4.0, por exemplo, exige que os patches de segurança sejam instalados no prazo de um mês após o lançamento para sistemas críticos. A HIPAA exige salvaguardas técnicas “razoáveis e apropriadas”, o que os avaliadores interpretam como a aplicação documentada de patches com resultados mensuráveis. O Anexo A, seção 8.8, da ISO 27001:2002 aborda explicitamente o gerenciamento de vulnerabilidades, do qual a aplicação de patches é o cerne operacional. A NIS2, em vigor em toda a UE, exige comprovação do tratamento de vulnerabilidades para organizações abrangidas pela norma. O Critério CC7.1 dos Serviços de Confiança do SOC 2 exige o monitoramento e a correção de novas vulnerabilidades. Nenhuma dessas normas aceita “aplicamos patches quando podemos” como resposta.

O terceiro aspecto é a continuidade. Pessoas vão embora, ferramentas mudam, prioridades se alteram. Uma política por escrito é o que permite que um novo diretor de TI assuma um programa de aplicação de patches sem precisar recriá-lo do zero.

O caso de conformidade em mais detalhes

Vale a pena ser específico quanto aos requisitos das principais estruturas, pois é justamente por causa de resumos vagos que as políticas acabam deixando de atender aos requisitos que são objeto de auditoria.

A norma PCI DSS 4.0 exige que as correções de segurança críticas sejam aplicadas nos sistemas abrangidos pela norma no prazo de um mês após o lançamento, com uma abordagem documentada e baseada no risco para as correções não críticas. A versão 4.0 introduziu requisitos mais rigorosos em relação à priorização baseada no risco, o que significa que uma abordagem baseada exclusivamente no CVSS pode não mais satisfazer um avaliador rigoroso.

A Regra de Segurança da HIPAA não especifica prazos, mas exige que as entidades abrangidas “implementem procedimentos para prevenir, detectar e notificar softwares maliciosos” e que “implementem medidas de segurança suficientes para reduzir os riscos e vulnerabilidades a um nível razoável e adequado”. Na prática, as ações de fiscalização do OCR do HHS têm considerado atrasos de vários meses na aplicação de patches para vulnerabilidades conhecidas como uma violação da Regra de Segurança.

A Norma ISO 27001:2022, Anexo A, 8.8 (Gestão de vulnerabilidades técnicas), exige que as informações sobre vulnerabilidades técnicas sejam obtidas em tempo hábil, que a exposição da organização seja avaliada e que sejam tomadas as medidas adequadas. Os auditores esperam encontrar uma política por escrito, SLAs definidos e evidências de execução.

A Diretiva NIS2 exige que entidades essenciais e importantes em setores críticos da UE gerenciem vulnerabilidades e divulgações. As implementações dos Estados-membros variam em detalhes, mas a aplicação documentada de correções com tempos de resposta mensuráveis é a expectativa comum.

O Critério CC7.1 dos Serviços de Confiança do SOC 2 exige que a entidade detecte e responda a eventos de segurança e vulnerabilidades. Uma política de gerenciamento de patches é um dos elementos de evidência padrão analisados pelos auditores.

O NIST CSF 2.0, na função “Proteger” (PR.PS-02), exige que o software seja mantido, substituído e removido de acordo com o risco, o que, na prática, significa um gerenciamento documentado de patches.

Se você estiver elaborando uma política principalmente para ser aprovado em uma auditoria, elabore-a com base no marco regulatório mais rigoroso ao qual você está sujeito. Os demais se encaixarão naturalmente a partir daí.

Componentes de uma política eficaz de gerenciamento de patches

Uma política de gerenciamento de patches tem cerca de dez seções. Alguns modelos as dividem ou combinam de maneiras diferentes, mas o conteúdo é o mesmo. Ignorar qualquer uma delas cria uma lacuna que um auditor irá detectar.

1. Objetivo e escopo

Explique qual é a finalidade da política e o que ela abrange. A finalidade deve ser descrita em uma ou duas frases: esta política garante a identificação, avaliação e implantação oportunas de atualizações de software para manter a segurança, a estabilidade e a conformidade. O escopo é mais importante e costuma ser ignorado com mais frequência. Ele precisa especificar:

• Quais ativos a apólice cobre (servidores, estações de trabalho, laptops, dispositivos móveis, máquinas virtuais, contêineres, dispositivos de rede, IoT, firmware)
• Quais tipos de software (sistemas operacionais, aplicativos, software de terceiros, firmware)
• Quais ambientes (produção, teste, desenvolvimento, BYOD, se aplicável)
• Quais entidades (funcionários, prestadores de serviços, sistemas gerenciados por terceiros)

As lacunas no escopo são a origem das constatações de auditoria. Se a política não abranger explicitamente o firmware de rede ou aplicativos de terceiros, a equipe pode ficar discutindo indefinidamente se isso deveria ou não estar incluído.

2. Funções e responsabilidades

Cada seção da política deve corresponder a uma função específica. Políticas genéricas utilizam funções genéricas; as políticas eficazes definem funções específicas e as responsabilidades de cada uma. Uma estrutura viável:

• Autoridade responsável pelo gerenciamento de patches (normalmente o CISO ou o diretor de TI). É responsável pela política. Aprova exceções. Analisa os relatórios de conformidade. É o ponto final de escalonamento.
• Líder da Equipe de Gerenciamento de Patches (um gerente de operações de TI ou de segurança). É responsável pelo programa operacional. Define o cronograma de aplicação de patches. Coordena com os responsáveis pelas aplicações.
• Administradores de sistema. Aplicar patches nos sistemas que lhes foram atribuídos. Manter ambientes de teste. Realizar a reversão das alterações quando necessário.
• Responsáveis pelas aplicações. Identificar as aplicações essenciais para os negócios. Aprovar janelas de manutenção. Validar a funcionalidade após a aplicação de patches.
• Equipe de segurança. Monitorar informações sobre ameaças. Sinalizar vulnerabilidades urgentes. Acompanhar as listas KEV da CISA e os CVEs relacionados a ransomware. Verificar a conformidade.
• Proprietários de ativos. Manter um inventário preciso dos ativos sob seu controle.
• Usuários finais. Colaborem com os horários de reinicialização. Não desativem os agentes de atualização. Relatem problemas relacionados às atualizações.

Os nomes mudam, as funções permanecem. A política enumera as funções e inclui um apêndice que identifica as pessoas atualmente designadas para essas funções, caso sua estrutura de governança assim o exija.

3. Classificação de patches e SLAs

Esta é a seção mais importante e aquela em que a maioria das políticas está perigosamente desatualizada. Os prazos relativos às ameaças que serviram de base para modelos criados há cinco anos já não se aplicam mais.

A classificação divide as vulnerabilidades por gravidade e possibilidade de exploração e, em seguida, vincula cada nível a um SLA de implantação. Um modelo defensável para 2026 se apresenta da seguinte forma:

• Emergência/explorada ativamente. Uma vulnerabilidade listada no catálogo KEV da CISA, com um exploit publicado, em um sistema dentro do escopo. Implemente dentro de 24 a 48 horas. Lançamento fora da banda, testes condensados, reinicialização obrigatória.
• Crítica. CVSS 9,0 ou superior, ou qualquer vulnerabilidade em sistemas expostos à Internet, independentemente do CVSS. Implemente dentro de 7 a 14 dias. Testes padrão, implantação programada.
• Alta. CVSS 7,0 a 8,9, em sistemas internos, sem exploração ativa. Implemente em até 30 dias.
• Médio. CVSS 4.0 a 6,9. Implementar em um prazo de 60 a 90 dias, normalmente como parte dos ciclos de rotina.
• Baixo. CVSS inferior a 4,0. Implemente durante a manutenção de rotina; não é necessário um SLA específico.

A razão pela qual esses prazos se tornaram mais apertados é que o cenário das ameaças mudou. A análise da VulnCheck sobre o primeiro semestre de 2025 revelou que 32,1% das vulnerabilidades listadas no KEV foram exploradas em até 24 horas após a divulgação, ou até mesmo antes, um aumento em relação aos 23,6% do ano anterior. Uma política que concede 30 dias para a aplicação de patches em sistemas conectados à internet está, de acordo com as informações atuais sobre ameaças, permitindo semanas de exposição conhecida a vulnerabilidades ativamente exploradas.

Especificamente para sistemas expostos à internet, muitos programas já consolidados operam com um SLA mais rigoroso do que o apresentado na tabela acima. O DBIR 2025 da Verizon identificou 17 vulnerabilidades em dispositivos de borda na lista KEV e constatou que o tempo médio para a correção total foi de 209 dias, contra a exploração em massa por parte de invasores em cinco casos. Uma política que não reconheça essa lacuna é como escrever em um mundo estagnado.

Seja qual for o SLA que você definir, indique-o em dias úteis, defina quando o prazo começa a correr (lançamento do fornecedor, listagem no KEV ou sua detecção?) e especifique o que significa “corrigido” (implantado e verificado, não apenas enviado para o console de gerenciamento).

4. Requisitos para o inventário de ativos

A política deve exigir um inventário contínuo e automatizado de todos os ativos abrangidos, com responsabilidade nominal pela precisão do inventário. Especifique os dados mínimos a serem coletados por ativo (nome do host, sistema operacional, versão, nível de patch, proprietário, última verificação), a frequência com que o inventário é reconciliado e o limite abaixo do qual o programa é considerado em desacordo com suas próprias normas. A maioria das políticas ignora esse ponto e, então, não consegue explicar por que um host ficou sem patches por seis meses. O motivo é sempre o mesmo: ninguém sabia que ele existia.

5. Padrões para testes de patches e implantação

Defina como as correções são testadas antes da implantação em larga escala. A política não determina os detalhes técnicos; ela estabelece os requisitos. Um padrão viável:

• As atualizações de rotina passam por uma estrutura em anéis definida (piloto, validação, produção), com períodos de espera entre os anéis.
• As correções de emergência seguem uma estrutura em anel comprimido (teste de verificação em um projeto-piloto representativo, seguido de implantação em larga escala), com aceitação de riscos documentada.
• As correções que afetam sistemas essenciais aos negócios exigem a aprovação explícita do responsável pelo aplicativo antes da implantação em produção.
• As reinicializações exigidas pelas correções são programadas para janelas de manutenção aprovadas, exceto em casos de emergência em que o SLA se sobreponha à janela.
• Implantações com falha acionam uma nova tentativa automática e, em seguida, um alerta para a equipe de atualizações, caso a segunda tentativa falhe.

O objetivo de definir isso como padrões, em vez de procedimentos, é permitir que a equipe operacional altere as ferramentas e táticas sem precisar reescrever a política. Desde que o padrão seja cumprido, a implementação pode evoluir. Para mais detalhes sobre como as equipes realmente conduzem essas etapas, nosso guia sobre o processo de gerenciamento de patches explica cada uma delas detalhadamente.

6. Tratamento de exceções e aceitação de riscos

Todo ambiente possui sistemas que não podem receber patches dentro do cronograma previsto. Aplicativos legados que apresentam falhas ao serem executados com bibliotecas mais recentes. Equipamentos de fornecedores sob contrato de manutenção que controla as atualizações. Sistemas isolados (air-gapped) com suas próprias janelas de alteração. A política precisa de um processo de exceção definido, e não de um entendimento tácito de que “vamos dar um jeito nisso”.

Uma cláusula de exceção válida inclui:

• Um formulário de solicitação de exceção documentado (ativo, vulnerabilidade, motivo, controles compensatórios, responsável, data de validade)
• Um aprovador designado (normalmente a Autoridade de Gerenciamento de Patches para exceções com prazo determinado, com revisão da equipe de segurança)
• Um prazo máximo para a exceção (90 dias é um valor padrão razoável, sendo que a renovação exige uma nova análise)
• Uma exigência de controle compensatório (segmentação de rede, monitoramento adicional, aplicação de patches virtuais) para qualquer exceção que ultrapasse o SLA original
• Um registro central de exceções que é analisado trimestralmente e sobre o qual se presta contas anualmente

A importância desta seção reside no fato de que, sem ela, o processo de tratamento de exceções se resume a “a equipe desiste e segue em frente”. Esse é o caminho que leva os sistemas a permanecerem com vulnerabilidades conhecidas por anos, sem nenhum registro do motivo.

7. Relatórios e verificação da conformidade

Especifique o que deve ser relatado, a quem e com que frequência. Uma estrutura de relatórios que se justifique:

• Painéis operacionais. Conformidade com patches em tempo real por grupo de ativos, disponível continuamente para a equipe de atualização de patches.
• Relatórios mensais. Porcentagem de conformidade com patches, taxa de cumprimento do SLA, número de exceções, tempo médio para aplicação de patches. Revisados pelo líder da equipe de gerenciamento de patches e pela autoridade responsável.
• Relatórios trimestrais. Análise de tendências, cobertura de ameaças emergentes, análise do registro de exceções, eficácia das políticas. Apresentados à liderança de segurança.
• Relatório anual. Situação de conformidade ao longo do ano, resumo do mapeamento da estrutura, lacunas e medidas corretivas. Apresentado à alta direção e aos auditores externos.

A exigência de prestação de contas é, muitas vezes, o aspecto em que as constatações da auditoria são mais fáceis de prever. Se a política estabelecer que devem ser realizadas revisões trimestrais e você não puder apresentar as atas das últimas quatro, essa será a constatação.

8. Integração da gestão de mudanças

A aplicação de patches e o gerenciamento de mudanças se sobrepõem. A política deve especificar como a aplicação de patches se encaixa no processo mais amplo de gerenciamento de mudanças: o que é considerado uma mudança padrão (tipos de patches pré-aprovados implantados em janelas definidas), o que é considerado uma mudança normal (implantações pontuais ou fora do ciclo) e o que é considerado uma mudança de emergência (resposta a explorações ativas). Isso não é burocracia desnecessária. É assim que a equipe de aplicação de patches evita ser bloqueada por um comitê de mudanças que se reúne semanalmente, enquanto o tempo para conter uma ameaça se conta em horas.

9. Requisitos de automação

As políticas modernas devem exigir explicitamente a automação sempre que viável. A formulação é importante: não “a automação é incentivada”, mas “o programa de aplicação de patches utilizará ferramentas automatizadas para detecção, varredura, implantação e geração de relatórios, reservando a intervenção manual para exceções documentadas”.

A justificativa para isso é de natureza operacional e de segurança. A aplicação manual de patches na escala de qualquer organização que ultrapasse algumas dezenas de terminais gera inconsistências e atrasos. A automação, quando acompanhada de medidas de proteção adequadas, é mais rápida, mais consistente e mais justificável. Uma análise mais aprofundada sobre o que deve ser automatizado e o que deve permanecer manual pode ser encontrada em nosso blog sobre gerenciamento automatizado de patches. Para fins de política, esse requisito é suficiente.

10. Revisão de políticas e controle de versões

Defina uma frequência de revisão e cumpra-a. A revisão anual é o mínimo exigido; a revisão trimestral é adequada quando as condições de ameaça ou os requisitos de conformidade sofrem alterações significativas. A política deve especificar:

• Frequência das revisões (normalmente anual)
• Condições que desencadeiam uma revisão fora do ciclo (grandes mudanças na estrutura, incidentes de segurança significativos, reestruturação organizacional)
• Requisitos de controle de versão (cada versão datada, alterações resumidas, versões anteriores mantidas)
• Órgão responsável pela aprovação de alterações na política (normalmente o mesmo órgão que aprovou a versão original)

Uma política sem histórico de versões é uma política que ninguém está aplicando.

Modelo de política de gerenciamento de patches

Aqui está um esboço que corresponde às dez seções acima. Não é um documento finalizado; trata-se de uma estrutura na qual se podem inserir os detalhes.

MODELO DE POLÍTICA DE GESTÃO DE ATUALIZAÇÕES

1. Objetivo

2. Escopo

   2.1 Ativos abrangidos

   2.2 Tipos de software abrangidos

   2.3 Ambientes abrangidos

   2.4 Ativos fora do escopo e exclusões

3. Funções e responsabilidades

   3.1 Autoridade de gerenciamento de patches

   3.2 Líder da Equipe de Gerenciamento de Patches

   3.3 Administradores de sistema

   3.4 Proprietários de aplicativos

   3.5 Equipe de Segurança

   3.6 Proprietários de ativos

   3.7 Usuários finais

4. Classificação de patches e SLAs

   4.1 Classificação de gravidade

   4.2 SLAs de implantação por nível de gravidade

   4.3 SLAs de sistemas conectados à Internet

   4.4 Critérios de resposta a emergências

5. Inventário de ativos

   5.1 Requisitos relativos aos dados de estoque

   5.2 Frequência de reconciliação

   5.3 Limites de cobertura

6. Teste e implantação de patches

   6.1 Requisitos de ensaio

   6.2 Estrutura do anel de implantação

   6.3 Janelas de manutenção

   6.4 Gerenciamento de reinicialização

   6.5 Tratamento de falhas na implantação

7. Tratamento de exceções

   7.1 Processo de solicitação de exceção

   7.2 Autoridade de aprovação

   7.3 Duração e renovação da exceção

   7.4 Controles de compensação

   7.5 Registro e análise de exceções

8. Relatórios e Conformidade

   8.1 Relatórios operacionais

   8.2 Relatórios mensais de conformidade

   8.3 Revisões trimestrais

   8.4 Relatório anual de conformidade

   8.5 Mapeamento do quadro de referência

9. Integração da Gestão de Mudanças

   9.1 Classificações de alterações: padrão, normal e de emergência

   9.2 Interação com o comitê consultivo de mudanças

10. Automação

   10.1 Escopo de automação exigido

   10.2 Critérios para intervenção manual

11. Governança de Políticas

   11.1 Frequência das revisões

   11.2 Condições que desencadeiam uma revisão fora do ciclo

   11.3 Controle de versão

   11.4 Autoridade de aprovação

Anexos

A. Mapeamento da estrutura de conformidade (PCI DSS, HIPAA, ISO 27001, NIS2, SOC 2)

B. Funções atribuídas a pessoas específicas (atual)

C. Registro de exceções

D. Glossário de termos

E. Histórico de revisões

É nos apêndices que a política se mantém atualizada, sem que o documento principal precise ser constantemente revisado. Nomes, estruturas e exceções mudam. Os compromissos estruturais, porém, não devem mudar.

Como uma política se relaciona com o programa de atualizações mais amplo

Uma política é a camada de governança que se situa acima do trabalho operacional. Ela estabelece os SLAs sem determinar a ferramenta a ser utilizada. Exige a realização de testes sem ditar a estrutura do ciclo. Define a frequência dos relatórios sem projetar os painéis de controle.

Em um programa bem estruturado, a política é o documento que torna o processo de gerenciamento de patches repetível, independentemente da rotatividade de pessoal e das mudanças nas ferramentas. É também o documento que torna as melhores práticas de gerenciamento de patches aplicáveis, em vez de meras aspirações. Uma equipe pode decidir, como melhor prática, que priorizará mais rapidamente os patches relacionados à internet, mas, se a política não exigir isso, a prática desaparecerá discretamente na próxima vez que a equipe estiver sob pressão.

É também na política que a automação passa a ser exigida, em vez de apenas tolerada. Em organizações que não incorporaram formalmente a automação à política, cada novo administrador de sistemas acaba tendo que rediscutir se a automação é “segura” ou “apropriada”, e o desvio resultante corrói o programa ao longo dos anos. Uma política que estabeleça que a automação é o padrão, com exceções documentadas, põe fim a essa discussão.

Melhores práticas para políticas de gerenciamento de patches

Uma política de gerenciamento de patches é um dos documentos de governança de maior impacto que uma organização de TI ou de segurança possui. Quando bem elaborada, ela confere autoridade à equipe de aplicação de patches, fornece evidências ao auditor, traz clareza para a empresa e garante a continuidade do programa. Quando mal elaborada, é um documento no SharePoint cuja existência todos reconhecem, mas que ninguém realmente segue.

As políticas que se mantêm em vigor compartilham algumas características. Elas são específicas quanto ao escopo, em vez de serem meramente ambiciosas. Seus SLAs refletem os prazos atuais das ameaças, e não os modelos de cinco anos atrás. Elas definem funções, e não indivíduos. Elas transformam as exceções em um processo documentado, e não em uma solução alternativa silenciosa. Elas exigem automação, em vez de tolerar a proliferação de tarefas manuais. E são revisadas com uma frequência real, com controle de versão que comprove isso.

Se você estiver elaborando uma política do zero, baseie-se na estrutura de dez seções acima e redija cada seção de acordo com o quadro de conformidade mais rigoroso ao qual você está sujeito. Se estiver atualizando uma política já existente, comece pelos SLAs. Essa é a parte que tem maior probabilidade de estar discretamente desatualizada e que afeta mais diretamente se a política ainda reflete como o programa deve funcionar. A partir daí, o restante do documento pode ser atualizado seção por seção.

Como a Kaseya pode ajudar

Uma política só é aplicável se suas ferramentas forem capazes de realmente executar e comprovar o que a política exige. É aí que a maioria dos programas de correção falha: o documento diz que as correções críticas devem ser implantadas em 14 dias, a ferramenta não consegue indicar quais não cumpriram o SLA no mês passado, e essa lacuna aparece na auditoria.

As soluções RMM da Kaseya foram desenvolvidas para gerenciar a aplicação de patches de acordo com os requisitos operacionais decorrentes de uma política de patches rigorosa. A descoberta contínua de ativos alimenta o módulo de inventário. A verificação e a implantação orientadas por políticas transformam a classificação e os SLAs em um fluxo de trabalho automatizado, em vez de um trabalho manual em planilhas. A cobertura integrada de aplicativos de terceiros preenche a lacuna de escopo que a maioria das políticas define, mas que poucas ferramentas conseguem cumprir. O tratamento de exceções, os anéis de implantação e a reversão são recursos de primeira linha, em vez de scripts personalizados.

Para equipes internas de TI, isso significa uma política que pode ser elaborada, imposta e comprovada sem a necessidade de coleta manual de evidências. Para MSPs que administram várias políticas de clientes, o Datto RMM amplia o modelo para políticas de atualizações por cliente, relatórios de SLA por cliente e o tipo de evidência de atestado que satisfaz o auditor do cliente, sem a necessidade de criar um relatório personalizado para cada projeto.

A questão é de natureza operacional. Uma política que a solução não consegue fazer cumprir é apenas um documento. Uma política que a solução faz cumprir, monitora e sobre a qual gera relatórios é um controle.