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 quase não têm 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 — ou o que mudou, caso tenha havido alguma.
Uma política de gerenciamento de patches deve ser o documento que torna a aplicação de patches obrigatória. Ela define o que deve ser corrigido, com que rapidez, por quem, quais são as exceções e como comprovar que a correção foi realizada. Quando bem elaborada, ela resiste à rotatividade de pessoal, atende aos requisitos de auditoria e dá à 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 para cumprir as normas.
Este guia aborda o que uma política eficaz de gerenciamento de patches deve conter, os SLAs que se mostram adequados diante dos prazos atuais de ameaças e como estruturar o documento para que seja aplicável na prática, em vez de ficar no papel. 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, implementa e verifica as 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 as correções críticas devem ser aplicadas 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, aproximadamente nesta ordem de importância:
O primeiro é a aplicabilidade. Sem uma política, cada 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 responsável pela manutenção dos 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. A norma 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 adequadas”, o que os avaliadores interpretam como uma aplicação documentada de patches com resultados mensuráveis. A ISO 27001:2002, Anexo A 8.8, 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 evidências de tratamento de vulnerabilidades para organizações abrangidas. O Critério CC7.1 dos Serviços de Confiança SOC 2 exige o monitoramento e a correção de novas vulnerabilidades. Nenhuma dessas normas aceita “aplicamos patches quando podemos” como resposta.
O terceiro é 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 cumprir os requisitos que são alvo de auditoria.
A norma PCI DSS 4.0 exige que as correções de segurança críticas sejam aplicadas nos sistemas abrangidos 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 ser mais suficiente para 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 comunicar software malicioso” 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 correções 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 as 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 SOC 2 exige que a entidade detecte e responda a incidentes 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 uma gestão documentada de patches.
Se você estiver elaborando uma política principalmente para passar em uma auditoria, redija-a com base no quadro normativo mais rigoroso ao qual você está sujeito. Os demais requisitos decorrerão naturalmente disso.
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 dividem ou combinam essas seções de maneira diferente, mas o conteúdo é o mesmo. Ignorar qualquer uma delas cria uma lacuna que um auditor irá detectar.
1. Objetivo e âmbito
Explique qual é o objetivo da política e o que ela abrange. O objetivo deve ser descrito 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 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)
- Que tipos de software (sistemas operacionais, aplicativos, software de terceiros, firmware)
- Quais ambientes (produção, staging, 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 pela gestão de patches (normalmente o CISO ou o diretor de TI). É responsável pela política. Aprova exceções. Analisa os relatórios de conformidade. 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 reversões quando necessário.
- Responsáveis pelas aplicações. Identificar aplicações essenciais para os negócios. Aprovar janelas de manutenção. Verificar o funcionamento 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 sua responsabilidade.
- Usuários finais. Colaborem com os horários de reinicialização. Não desativem os agentes de atualização. Comuniquem 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 nomeadas, 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 de 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 abrangido pela política. Implemente dentro de 24 a 48 horas. Lançamento fora da janela de atualização, testes acelerados, 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, implementaçã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. Implementação em um prazo de 60 a 90 dias, normalmente como parte dos ciclos de rotina.
- Baixo. CVSS inferior a 4,0. Implantação na manutenção de rotina, sem necessidade de SLA específico.
A razão pela qual esses prazos se tornaram mais apertados é que o panorama 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 mesmo antes, um aumento em relação aos 23,6% do ano anterior. Uma política que concede 30 dias para aplicar 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 no caso de sistemas conectados à 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 congelado.
Independentemente dos SLAs que você definir, indique-os em dias úteis, defina quando o prazo começa a contar (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 a consola 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 isso e, então, não consegue explicar por que um host ficou sem patch por seis meses. O motivo é sempre o mesmo: ninguém sabia que ele existia.
5. Testes de patch e normas de implantação
Defina como as correções são testadas antes da implantação em larga escala. A política não prescreve 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 compactado (teste preliminar 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 para os negócios exigem a aprovação expressa do responsável pela aplicação antes da implantação em produção.
- As reinicializações exigidas pelas correções são agendadas para janelas de manutenção aprovadas, exceto em casos de emergência em que o SLA se sobreponha à janela.
- As implantações com falha acionam uma nova tentativa automática e, caso a segunda tentativa falhe, um alerta é enviado à equipe de atualizações.
O objetivo de definir isso como normas, em vez de procedimentos, é permitir que a equipe operacional altere as ferramentas e as táticas sem precisar reescrever a política. Desde que a norma seja cumprida, a implementação pode evoluir. Para mais detalhes sobre como as equipes realmente executam 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 prazo previsto. Aplicativos legados que apresentam falhas quando executados com bibliotecas mais recentes. Equipamentos de fornecedores sob contrato de manutenção que controla as atualizações. Sistemas isolados com suas próprias janelas de atualizaçã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 prazo previsto no SLA original
- Um registro central de exceções que é analisado trimestralmente e objeto de relatório anual
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 a sistemas que permanecem com vulnerabilidades conhecidas por anos, sem qualquer 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 fundamentada:
- 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. Apresentado à liderança de segurança.
- Relatório anual. Situação de conformidade ao longo do ano, resumo do mapeamento de referências, lacunas e medidas corretivas. Entregue à 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 a gestão de mudanças se sobrepõem. A política deve especificar como a aplicação de patches se encaixa no processo mais amplo de gestão de mudanças: o que se considera uma mudança padrão (tipos de patches pré-aprovados implantados em janelas definidas), o que se considera uma mudança normal (implantações pontuais ou fora do ciclo) e o que se considera 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, quando o tempo para lidar com a ameaça se mede 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 correção utilizará ferramentas automatizadas para detecção, verificação, 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 com mais do que algumas dezenas de terminais gera inconsistências e atrasos. A automação, quando acompanhada de medidas de segurança adequadas, é mais rápida, mais consistente e mais justificável. Uma análise mais aprofundada sobre o que automatizar e o que manter 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
Estabeleça uma periodicidade para as revisões 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 nas políticas (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á controlando.
Modelo de política de gerenciamento de patches
Aqui está um esboço que corresponde às dez seções acima. Não se trata de um documento finalizado, mas sim de uma estrutura na qual se podem inserir os detalhes.
MODELO DE POLÍTICA DE GESTÃO DE ATUALIZAÇÕES
1. Objetivo
2. Âmbito
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 Acordos de Nível de Serviço (SLA) para 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. Testes 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 responsável pela aprovação
7.3 Duração e renovação da exceção
7.4 Controles de compensação
7.5 Registro e revisão 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
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 Âmbito de automação exigido
10.2 Critérios para intervenção manual
11. Governança por políticas
11.1 Frequência das revisões
11.2 Condições de acionamento para revisão fora do ciclo
11.3 Controle de versão
11.4 Autoridade responsável pela aprovação
Anexos
A. Mapeamento do quadro 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 anexos 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 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 sobrepõe ao 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 periodicidade 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 exequíveis, em vez de meras aspirações. Uma equipe pode decidir, como melhor prática, que dará prioridade aos patches relacionados à Internet mais rapidamente, 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 “adequada”, e o desvio resultante acaba minando o programa ao longo dos anos. Uma política que estabeleça a automação como 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 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 de resposta às ameaças atuais, 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. E exigem automação, em vez de tolerar a proliferação de tarefas manuais. Além disso, são revisadas com periodicidade regular, 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 mais provavelmente está desatualizada sem que se perceba, e é a que afeta mais diretamente se a política ainda reflete a forma 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 ela exige. É aí que a maioria dos programas de correção falha: o documento estabelece que as correções críticas devem ser implementadas em 14 dias, mas a ferramenta não consegue indicar quais não cumpriram o SLA no mês passado, e essa lacuna fica evidente 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 detecção contínua de ativos alimenta o 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 políticas de vários clientes, o Datto RMM amplia o modelo para incluir políticas de atualização por cliente, relatórios de SLA por cliente e o tipo de evidência de comprovação que satisfaz o auditor do cliente, sem a necessidade de criar um relatório personalizado para cada contrato.
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.
