SLAs de remediação de vulnerabilidades para NIS2 e DORA

Às 08:17 de uma terça-feira de manhã, no início de 2026, Anna, Diretora de Segurança da Informação (CISO) de uma fintech em rápido crescimento, recebe a primeira mensagem antes de acabar o café.

O SOC sinalizou conversas sobre exploração ativa de uma vulnerabilidade num gateway de API exposto aos clientes. A engenharia informa que o patch está disponível, mas que a sua aplicação é arriscada, porque o gateway está à frente dos fluxos de pagamento. O gestor de conformidade reencaminha um pedido formal de uma autoridade nacional competente a solicitar evidência de “tratamento e divulgação de vulnerabilidades” e prova de que o processo foi eficaz nos últimos 12 meses. A equipa de Compras acrescenta um terceiro problema: o gateway é gerido por um prestador de serviços geridos (MSP) e o contrato limita-se a indicar que o prestador aplicará “atualizações de segurança em tempo útil”.

Às 09:00, isto já não é apenas uma questão de aplicação de patches. É uma questão de evidência ISO/IEC 27001:2022, de ciber-higiene NIS2, de gestão do risco de TIC DORA, de governação de fornecedores e, potencialmente, de notificação de incidentes se a exploração afetar a continuidade do serviço ou dados pessoais.

Esta é a lacuna prática de conformidade que muitas organizações enfrentarão em 2026. Têm scanners, painéis de gestão, tickets e ferramentas de aplicação de patches, mas não conseguem responder com clareza às perguntas de auditoria:

• Quem aprovou o SLA de remediação?
• De que forma o SLA é baseado no risco?
• O que acontece quando um patch crítico ultrapassa o prazo?
• Como são priorizados os ativos expostos à Internet?
• Como são os fornecedores obrigados aos mesmos prazos?
• Onde está o registo de aceitação do risco de um sistema sem patch?
• Que evidência prova que o controlo funcionou, e não apenas que existia?

A resposta não é mais uma folha de cálculo com datas-limite. Os SLAs de remediação de vulnerabilidades devem ser geridos como um sistema vivo de controlos que liga propriedade de ativos, pontuação de vulnerabilidades, informações sobre ameaças, gestão de alterações, SLAs de fornecedores, tratamento de exceções, monitorização, resposta a incidentes e revisão pela gestão.

É aqui que a Política de Gestão de Vulnerabilidades e Patches empresarial da Clarysec (VPMP), a Política de Gestão de Vulnerabilidades e Patches para PME (VPMP-SME), a Política de Segurança de Terceiros e Fornecedores para PME (TPSSP-SME), o Zenith Blueprint (ZB) e os Zenith Controls (ZC) se tornam úteis. Em conjunto, transformam “aplicar patches mais depressa” num processo de governação defensável, capaz de resistir ao escrutínio de auditoria ISO, NIS2, DORA, RGPD da UE, NIST e de estilo ISACA.

Porque os SLAs de remediação de vulnerabilidades se tornaram evidência ao nível do órgão de administração

A remediação de vulnerabilidades costumava ser tratada como uma métrica de ciber-higiene de TI. Em 2026, está mais próxima de um compromisso regulado de resiliência operacional.

A NIS2 transforma a cibersegurança numa matéria de responsabilização da gestão. As entidades essenciais e importantes devem ter órgãos de gestão que aprovem medidas de gestão de riscos de cibersegurança, supervisionem a implementação e recebam formação para compreenderem os riscos e o impacto das práticas de segurança nos serviços. O NIS2 Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionais, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de abastecimento, aquisição e manutenção seguras, tratamento e divulgação de vulnerabilidades, ciber-higiene, formação, controlo de acesso, gestão de ativos e autenticação.

Para as entidades financeiras, o DORA é o regime especializado de resiliência operacional. Exige mecanismos de governação e controlo para o risco de TIC, com o órgão de gestão a definir, aprovar, supervisionar e manter a responsabilidade pela gestão do risco de TIC. Exige também a identificação de ativos e dependências de TIC, controlos de proteção e prevenção como aplicação de patches e gestão de alterações, gestão de incidentes relacionados com as TIC, testes de resiliência operacional digital e gestão do risco de terceiros de TIC.

O impacto prático é significativo. O incumprimento de um prazo de aplicação de patch pode indicar uma falha de:

• Governação, se a gestão não tiver aprovado SLAs baseados no risco
• Gestão de ativos, se o proprietário do sistema afetado for desconhecido
• Gestão de alterações, se a aplicação de patches de emergência não for controlada
• Gestão de fornecedores, se os prazos do prestador forem vagos
• Resposta a incidentes, se os sinais de exploração não forem triados
• Gestão de evidência, se tickets e logs não conseguirem provar o encerramento
• Tratamento de riscos, se as exceções não forem aprovadas e revistas

A ISO/IEC 27001:2022 fornece a espinha dorsal do sistema de gestão. As cláusulas 4.1 a 4.3 exigem que as organizações compreendam questões internas e externas, requisitos das partes interessadas, obrigações legais e contratuais e interfaces com outras organizações. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos, uma Declaração de Aplicabilidade e aprovação do risco residual pelo proprietário do risco. As cláusulas 9.1, 9.2, 9.3, 10.1 e 10.2 exigem monitorização, auditoria interna, revisão pela gestão, melhoria contínua, ação corretiva e evidência retida.

Em termos simples, se pretende que os SLAs de remediação de vulnerabilidades estejam preparados para auditoria, estes devem fazer parte do SGSI, e não ser apenas uma métrica DevOps.

O modelo de SLA que os auditores esperam ver

Um SLA de remediação de vulnerabilidades deve responder a três perguntas:

1. Com que rapidez devemos atuar?
2. Quem é responsável?
3. Que evidência prova o resultado?

A Política de Gestão de Vulnerabilidades e Patches define um ponto de partida prático para prazos de remediação baseados no risco:

A organização deve classificar todas as vulnerabilidades detetadas utilizando uma metodologia normalizada (por exemplo, CVSS v3.x) e aplicar prazos de remediação alinhados com a criticidade do negócio: 5.2.1 Crítica (CVSS 9.0-10.0): análise imediata; prazo máximo de aplicação de patch de 72 horas. 5.2.2 Alta (7.0-8.9): resposta no prazo de 48 horas; prazo de aplicação de patch de 7 dias de calendário. 5.2.3 Média (4.0-6.9): resposta no prazo de 5 dias; prazo de aplicação de patch de 30 dias de calendário. 5.2.4 Baixa (<4.0): resposta no prazo de 10 dias; prazo de aplicação de patch de 60 dias de calendário.

Esta cláusula é forte porque separa o tempo de resposta do prazo de aplicação de patch. Uma vulnerabilidade alta não deve ficar seis dias sem ser analisada e depois receber patch no sétimo dia. O relógio da resposta confirma a triagem, a propriedade, a avaliação de impacto e o planeamento da remediação. O prazo de aplicação de patch confirma o encerramento técnico ou uma exceção aprovada.

Para organizações mais pequenas, a Política de Gestão de Vulnerabilidades e Patches para PME utiliza linguagem mais simples, mas ainda auditável:

Os patches críticos devem ser aplicados no prazo de 3 dias após a disponibilização, especialmente em sistemas expostos à Internet

E para o conjunto mais amplo de patches:

Todos os outros patches devem ser aplicados no prazo de 30 dias, salvo se existir uma exceção válida documentada

O ponto não é que todas as organizações tenham de utilizar prazos idênticos. A ISO/IEC 27001:2022, a NIS2 e o DORA suportam a proporcionalidade. O ponto é que os SLAs de remediação devem ser definidos, aprovados, baseados no risco, monitorizados e evidenciados.

É aqui que muitas empresas falham. Definem o SLA, mas não definem a evidência. Na perspetiva de um auditor, uma política sem registos operacionais é uma promessa, não um controlo.

A propriedade dos ativos é a dependência oculta

Um scanner consegue indicar que existe uma CVE num servidor. Não consegue indicar se esse servidor suporta um processo crítico de pagamentos, armazena categorias especiais de dados pessoais, se liga a um prestador de liquidação ou está agendado para descomissionamento.

Esse contexto vem da gestão de ativos, classificação de dados, inventário de fornecedores e avaliação de riscos.

O controlo 8.8 do Anexo A da ISO/IEC 27001:2022, Gestão de vulnerabilidades técnicas, é central, mas não funciona isoladamente. Depende fortemente da gestão da configuração, gestão de alterações, monitorização de fornecedores, governação cloud, registo de logs, monitorização e tratamento de riscos.

O NIST CSF 2.0 expressa o mesmo problema em linguagem orientada a resultados. A Função GOVERN espera que os requisitos legais, regulamentares e contratuais de cibersegurança sejam compreendidos e geridos, que o apetite ao risco e a tolerância ao risco sejam documentados, que funções e recursos sejam atribuídos e que as políticas de cibersegurança sejam estabelecidas, aplicadas, revistas e atualizadas. Os resultados de IDENTIFY incluem inventários de hardware, software, serviços, sistemas, dados e ciclo de vida, bem como identificação de vulnerabilidades, análise de riscos, gestão de exceções e processos de divulgação de vulnerabilidades.

No cenário de terça-feira de manhã de Anna, a primeira pergunta técnica é “onde está o componente vulnerável?”. A primeira pergunta de governação é “que serviço e que risco afeta?”.

O Zenith Blueprint, fase de Gestão de Riscos, Step 13: Risk Treatment Planning and Statement of Applicability, aborda isto ao ligar riscos a controlos, proprietários e prazos:

Além disso, atribua um Proprietário e um Prazo a cada ação (talvez numa coluna separada ou nos comentários). Por exemplo: “Proprietário: Responsável de TI, Prazo: até ao 3.º trimestre de 2025.” Isto transforma-o num plano real.

É exatamente disso que a remediação de vulnerabilidades precisa. Uma constatação sem proprietário torna-se ruído no backlog. Uma constatação com proprietário, prazo, decisão de tratamento de riscos e trilho de evidência torna-se um controlo auditável.

Como os Zenith Controls mapeiam as relações entre controlos

Os Zenith Controls tratam o controlo 8.8 da ISO/IEC 27002:2022, Gestão de vulnerabilidades técnicas, como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade. Ligam-no aos conceitos de cibersegurança Identify e Protect, à capacidade operacional de gestão de ameaças e vulnerabilidades e aos domínios de segurança de governação, ecossistema, proteção e defesa.

Isto importa porque os SLAs de remediação não são apenas um mecanismo de proteção. São também um mecanismo de governação e um mecanismo de ecossistema. A exposição é moldada por fornecedores, plataformas cloud, serviços geridos, componentes open source e dependências expostas à Internet.

Os Zenith Controls mapeiam o 8.8 para vários controlos de suporte:

Os Zenith Controls também ligam a gestão de vulnerabilidades à ISO/IEC 27005:2024, especialmente à identificação de vulnerabilidades e aos cenários de risco que envolvem sistemas sem patch. Isto reforça o argumento de que os prazos de aplicação de patches devem ser baseados no risco, e não arbitrários. Também liga a monitorização de fornecedores à ISO/IEC 27036-4:2016 para níveis de segurança de acordos de serviços cloud e à ISO/IEC 20000-1:2018 para planeamento da prestação do serviço e gestão de alterações.

Esta estrutura transversal entre normas é relevante em auditoria. Se uma organização afirma que “as vulnerabilidades críticas recebem patch no prazo de 72 horas”, o auditor testará se essa afirmação é suportada por avaliação de riscos, classificação de ativos, obrigações de fornecedores, registos de alteração e evidência de monitorização.

Ciber-higiene NIS2: do tratamento de vulnerabilidades à ação corretiva

O NIS2 Article 21 exige uma abordagem multirriscos aos sistemas de rede e informação. Para os SLAs de remediação de vulnerabilidades, vários elementos do Article 21 são diretamente relevantes:

• Análise de riscos e políticas de segurança dos sistemas de informação
• Tratamento de incidentes
• Continuidade de negócio e gestão de crises
• Segurança da cadeia de abastecimento
• Aquisição, desenvolvimento e manutenção seguros, incluindo tratamento e divulgação de vulnerabilidades
• Procedimentos para avaliar a eficácia da cibersegurança
• Ciber-higiene básica e formação
• Controlo de acesso e gestão de ativos
• Autenticação multifator ou autenticação contínua, quando adequado

O NIS2 Article 20 torna os órgãos de gestão responsáveis pela aprovação e supervisão das medidas de gestão de riscos de cibersegurança. Isto significa que as métricas de remediação de vulnerabilidades não podem existir apenas num painel de engenharia. Devem constar em relatórios de gestão, pacotes de comité de risco ou registos de revisão pela gestão do SGSI.

O Article 21 também espera que as entidades que identifiquem incumprimento das medidas exigidas adotem ações corretivas sem demora injustificada. Esta expressão é importante. Se o painel mostrar vulnerabilidades críticas em atraso, a evidência de conformidade não deve terminar em “temos conhecimento”. Deve demonstrar escalonamento, revisão de risco, visibilidade pela gestão, ação corretiva e reavaliação.

O NIS2 Article 23 acrescenta outra dimensão. Se a exploração de uma vulnerabilidade sem patch causar, ou for capaz de causar, perturbação operacional grave, perda financeira ou danos a outras pessoas, pode tornar-se um incidente significativo. O ciclo de reporte inclui alerta precoce no prazo de 24 horas após tomar conhecimento do incidente significativo, notificação do incidente no prazo de 72 horas, relatórios intermédios mediante pedido e um relatório final no prazo de um mês após a notificação do incidente. Esse relatório final deve incluir severidade, impacto, causa raiz provável, mitigações e impacto transfronteiriço, quando aplicável.

Assim, o processo de SLA deve ligar-se à resposta a incidentes. Uma vulnerabilidade crítica com evidência de exploração ativa deve desencadear triagem de segurança, monitorização, preservação de evidência e avaliação de reporte, não apenas um ticket de patch de rotina.

Risco de TIC DORA: prazos de remediação como evidência de resiliência

Para as entidades financeiras, o DORA aplica-se desde 17 de janeiro de 2025 e cria requisitos uniformes em matéria de gestão do risco de TIC, notificação de incidentes graves relacionados com as TIC, testes de resiliência operacional digital, partilha de informações e gestão do risco de terceiros de TIC. É tratado como o ato jurídico setorial específico da UE para as entidades financeiras abrangidas identificadas ao abrigo das regras nacionais da NIS2.

O modelo operativo do DORA está próximo de um SGSI integrado. Os Articles 5 e 6 exigem governação, políticas, procedimentos, ferramentas, revisão anual ou periódica, auditoria, remediação de constatações de auditoria críticas e uma estratégia de resiliência operacional digital. O Article 8 exige identificação e inventariação de funções de negócio suportadas pelas TIC, ativos de informação, ativos de TIC, dependências, processos de terceiros e riscos de TIC legadas. O Article 9 exige controlos de proteção e prevenção, incluindo aplicação de patches e gestão de alterações. Os Articles 11 e 12 exigem continuidade, resposta, recuperação, cópia de segurança, restauro e objetivos de recuperação.

Os DORA Articles 17 a 19 exigem um processo de gestão de incidentes relacionados com as TIC que detete, gira, registe, classifique, escalone, reporte, comunique, analise a causa raiz e restaure operações seguras. Os Articles 24 a 26 exigem testes de resiliência operacional digital, incluindo testes adequados a ferramentas e sistemas de TIC, avaliações de vulnerabilidades, avaliações de segurança de redes, análises de lacunas, revisões de código-fonte quando exequível, testes de intrusão e testes de intrusão baseados em ameaças para certas entidades financeiras. Os Articles 28 e 30 exigem gestão do risco de terceiros de TIC, registos de contratos de serviços de TIC, diligência prévia, direitos de auditoria e inspeção, níveis de serviço, assistência do prestador durante incidentes, direitos de cessação e mecanismos de saída.

Para os SLAs de remediação, o DORA altera as expectativas de evidência de três formas.

Primeiro, as constatações de vulnerabilidades resultantes de testes devem alimentar um processo de remediação priorizado. Um relatório de análise não é suficiente.

Segundo, a remediação de constatações críticas deve ser acompanhada através de governação e auditoria. O DORA espera remediação formal de constatações de auditoria críticas para entidades que não sejam microempresas.

Terceiro, os terceiros prestadores de serviços de TIC devem estar sujeitos a obrigações mensuráveis. Se o prestador cloud, SaaS ou MSP controla a janela de aplicação de patches, o contrato e o registo devem mostrar como os seus prazos de remediação suportam as suas obrigações de resiliência.

A Política de Gestão de Vulnerabilidades e Patches aborda isto diretamente:

Aplicação de patches por terceiros e supervisão do risco SaaS 6.6.1 Todos os sistemas de terceiros (SaaS, PaaS, geridos por MSP) devem demonstrar controlos adequados de gestão de vulnerabilidades e patches. 6.6.2 Os SLAs de fornecedores devem incluir prazos de remediação equivalentes aos limiares definidos internamente com base na criticidade.

Esta cláusula é muitas vezes a ponte em falta entre a evidência ISO interna e a supervisão de fornecedores DORA.

RGPD da UE: quando atrasos na aplicação de patches se tornam falhas de responsabilização por dados pessoais

O RGPD da UE não é uma norma de gestão de vulnerabilidades, mas altera as consequências de uma falha de aplicação de patches.

O GDPR Article 5 exige que os dados pessoais sejam tratados de forma segura e que o responsável pelo tratamento consiga demonstrar conformidade. O Article 32 exige medidas técnicas e organizativas adequadas para assegurar um nível de segurança adequado ao risco. Quando sistemas sem patch tratam dados pessoais, especialmente dados de identidade, dados financeiros, dados biométricos, dados de saúde, dados laborais ou informação KYC, os SLAs de remediação tornam-se parte da responsabilização pela segurança do tratamento.

Um patch atrasado pode ser defensável se o risco tiver sido avaliado, se controlos compensatórios tiverem sido aplicados e se o risco residual tiver sido aceite pela pessoa certa. É muito mais difícil defendê-lo se a vulnerabilidade estava em atraso, exposta à Internet e sem proprietário.

Os Zenith Controls mapeiam a gestão de vulnerabilidades para os GDPR Articles 32 e 5(1)(f), porque a aplicação tempestiva de patches reduz riscos para a confidencialidade e integridade dos dados pessoais. Também mapeiam a gestão de alterações para o GDPR Article 24 e Article 32, porque alterações a sistemas que tratam dados pessoais devem ser sujeitas a avaliação de risco, aprovadas, documentadas e revistas.

A lição de conformidade é simples: se estiverem envolvidos dados pessoais, a evidência de patch deve incluir o contexto dos dados. Auditores e reguladores não perguntarão apenas “foi aplicado o patch?”, mas também “que dados estiveram expostos ao risco, durante quanto tempo e que controlos reduziram esse risco?”.

Um fluxo de trabalho Clarysec prático para evidência de SLA preparada para auditoria

Um processo maduro de remediação de vulnerabilidades não começa quando um auditor pede registos. É desenhado para produzir registos todos os meses.

Step 1: Aprovar a política de SLA

Comece pela Política de Gestão de Vulnerabilidades e Patches ou pela Política de Gestão de Vulnerabilidades e Patches para PME, consoante o seu modelo operativo. Adapte os limiares de SLA ao apetite ao risco, âmbito regulamentar, criticidade do serviço, sensibilidade dos dados e restrições técnicas. Assegure a aprovação pelo CISO, pelo Comité de Risco ou pelo órgão de gestão.

Em ambientes empresariais, utilize CVSS, criticidade do ativo, explorabilidade, exposição à Internet, sensibilidade dos dados e impacto no negócio. Para PME, mantenha o modelo simples mas explícito: patches críticos no prazo de três dias, outros patches no prazo de 30 dias, salvo se existir uma exceção válida.

Step 2: Mapear ativos para proprietários e serviços críticos

Cada constatação de vulnerabilidade deve ser associada a:

• Nome do ativo e identificador único
• Serviço de negócio ou aplicação
• Proprietário do sistema
• Proprietário técnico
• Classificação de dados
• Exposição à Internet
• Dependência de fornecedor, se aplicável
• Criticidade da função suportada

Isto suporta a propriedade do risco na ISO/IEC 27001:2022, a gestão de ativos NIS2, o inventário de ativos e dependências de TIC DORA e os resultados IDENTIFY do NIST CSF.

Step 3: Triar a vulnerabilidade

Crie um ticket para cada constatação ou conjunto agrupado de constatações. Inclua pontuação CVSS, scanner de origem, ativo afetado, estado de exploração, informações sobre ameaças, criticidade de negócio e SLA exigido. Se houver suspeita de exploração, associe o ticket a uma avaliação de incidente.

Step 4: Executar através da gestão de alterações

A aplicação de patches é uma alteração. Utilize alteração padrão para atualizações de rotina e alteração de emergência para vulnerabilidades críticas exploradas. Inclua evidência de testes, aprovação, carimbo temporal de implementação, plano de reversão e validação pós-alteração.

Isto corresponde à relação dos Zenith Controls entre 8.8 e 8.32, em que a aplicação de patches é governada através da gestão de alterações para equilibrar urgência e estabilidade operacional.

Step 5: Validar o encerramento

Não encerre tickets apenas com base em “patch instalado”. Exija validação através de nova análise, confirmação de versão, verificação de configuração ou confirmação de controlo compensatório. Quando o patch não puder ser aplicado, abra uma exceção.

Step 6: Registar exceções e risco residual

A Política de Gestão de Vulnerabilidades e Patches define o conteúdo obrigatório das exceções:

Os pedidos de exceção devem incluir: 7.2.1 Justificação de negócio para o atraso ou não remediação 7.2.2 Avaliação de riscos (baseada em CVSS, criticidade do ativo, informações sobre ameaças) 7.2.3 Controlos compensatórios propostos 7.2.4 Prazo para remediação ou reavaliação

Também define a aprovação e a revisão:

As exceções devem ser aprovadas pelo CISO ou pelo Comité de Risco delegado e registadas no Registo de Exceções do SGSI, com intervalo de revisão não superior a 90 dias.

Esse registo de exceções torna-se evidência essencial para a cláusula 6.1.3 da ISO/IEC 27001:2022 relativa ao tratamento de riscos e à aceitação do risco residual, bem como para a revisão pela gestão.

Este registo demonstra que a organização não ignorou a vulnerabilidade. Avaliou o risco, aplicou controlos compensatórios, aprovou o risco residual e definiu uma data de revisão.

Step 7: Construir o pacote mensal de evidência

O pacote mensal de evidência de remediação de vulnerabilidades deve incluir:

Para PME, a evidência pode ser mais leve, mas deve continuar a ser consistente. A Política de Gestão de Vulnerabilidades e Patches para PME exige logs de patches com rastreabilidade:

Os logs devem incluir o nome do dispositivo, a atualização aplicada, a data de aplicação do patch e a razão de qualquer atraso

Esta única cláusula tem elevado valor de auditoria. Transforma a aplicação de patches de uma afirmação num registo.

Aplicação de patches por fornecedores: o contrato deve corresponder ao seu SLA

Se um MSP, prestador SaaS, prestador PaaS ou prestador de serviços cloud controla a implementação de patches, os SLAs internos são inúteis salvo se as obrigações dos fornecedores forem equivalentes.

A Política de Segurança de Terceiros e Fornecedores para PME inclui obrigações de segurança da informação como requisito de governação. Para a remediação de vulnerabilidades, essas obrigações devem transformar-se em linguagem contratual mensurável:

• Janelas de notificação de vulnerabilidades críticas
• Prazos de remediação para vulnerabilidades críticas, altas, médias e baixas
• Processo de alteração de emergência
• Requisitos de aprovação do cliente para indisponibilidade
• Formato da evidência de conclusão de patch
• Processo de divulgação de vulnerabilidades
• Obrigações de assistência em incidentes
• Direito de auditoria ou de receção de relatórios de garantia
• Obrigações de aplicação de patches por subcontratantes subsequentes ou subcontratados
• Suporte de saída e transição para serviços críticos

O Zenith Blueprint, fase Controls in Action, Step 20, Control 8.21 Security of network services, estabelece o princípio com clareza:

Quando os serviços são prestados externamente, incluindo ISP, fornecedores de SD-WAN ou prestadores de cloud privada, os requisitos de segurança devem ser incorporados nos contratos e SLAs. Isto inclui garantias de disponibilidade, tempos de resposta a incidentes, obrigações de aplicação de patches ou mitigação de vulnerabilidades e limites claros de tratamento de dados. Nunca se deve presumir que um prestador cumpre as expectativas, salvo se estiver escrito, for mensurável e auditável.

O DORA torna isto especialmente importante para entidades financeiras. Os acordos com terceiros prestadores de serviços de TIC devem incluir níveis de serviço, assistência do prestador durante incidentes de TIC, acesso e recuperação de dados, cooperação com autoridades, direitos de cessação e disposições mais robustas para funções críticas ou importantes, incluindo monitorização, direitos de auditoria, planos de contingência e medidas de segurança.

O NIST CSF 2.0 diz o mesmo através dos resultados de risco da cadeia de abastecimento: os fornecedores devem ser conhecidos, priorizados por criticidade, avaliados antes da contratação, governados por requisitos contratuais, monitorizados ao longo da relação, incluídos no planeamento de incidentes e geridos no momento da cessação.

O que os auditores irão efetivamente perguntar

A conversa de auditoria muda consoante o enquadramento do auditor.

Um auditor ISO/IEC 27001:2022 começará pelo SGSI. Verificará se a gestão de vulnerabilidades está incluída na Declaração de Aplicabilidade, se a avaliação de riscos identifica sistemas sem patch como risco, se os planos de tratamento de riscos têm proprietários e prazos, se o controlo 8.8 do Anexo A está implementado, se a evidência é retida e se a auditoria interna e a revisão pela gestão avaliam o desempenho.

O Zenith Blueprint, fase Controls in Action, Step 19, explicita a expectativa de auditoria:

Este é um controlo de alta prioridade para auditores, e normalmente irão analisá-lo em profundidade. Conte com perguntas sobre a frequência com que os sistemas recebem patches, que processo segue quando é anunciada uma zero-day e que sistemas são mais difíceis de corrigir.

Continua com expectativas práticas de evidência:

Os auditores irão provavelmente solicitar resultados de análises de vulnerabilidades. Se utilizar ferramentas como Nessus, OpenVAS ou Qualys, exporte um relatório que mostre vulnerabilidades recentes detetadas e como foram tratadas. Idealmente, isto deve incluir classificações de risco (CVSS) e prazos de remediação.

Um auditor ou autoridade competente focado na NIS2 procurará aprovação pelo órgão de administração, proporcionalidade, ciber-higiene, tratamento de vulnerabilidades, segurança de fornecedores, tratamento de incidentes, avaliação de eficácia, ações corretivas sem demora injustificada e registos de decisão de reporte caso a exploração tenha causado impacto significativo.

Um supervisor DORA testará se as constatações de vulnerabilidades estão integradas na gestão do risco de TIC, nos testes de resiliência operacional digital, na classificação de incidentes, na análise de causa raiz, nos registos de terceiros, nas obrigações contratuais, nos direitos de auditoria e na remediação de constatações críticas.

Um avaliador NIST CSF organizará provavelmente a revisão em torno de GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. Perguntará se os requisitos legais e contratuais são compreendidos, se a tolerância ao risco está documentada, se as vulnerabilidades são identificadas e priorizadas, se as exceções são geridas, se a monitorização deteta exploração e se as ações de resposta e recuperação são coordenadas.

Um auditor COBIT 2019 ou de estilo ISACA focar-se-á em objetivos de governação, capacidade dos processos, práticas de gestão, métricas, propriedade, desenho de controlos, operação dos controlos e suficiência da evidência. Perguntará se a remediação de vulnerabilidades é repetível, medida, escalonada, melhorada e alinhada com os objetivos empresariais e o apetite ao risco.

Escalonamento e métricas: como provar que o SLA é gerido

Um SLA sem escalonamento é apenas uma meta. Um programa defensável de remediação de vulnerabilidades precisa de escalonamento antes do incumprimento, no momento do incumprimento e após falhas repetidas.

A Clarysec recomenda um modelo de escalonamento em quatro níveis:

1. Escalonamento operacional, o proprietário do ticket e o responsável técnico são notificados antes do incumprimento.
2. Escalonamento de risco, o proprietário do ativo e o proprietário do risco reveem o impacto quando o incumprimento é provável.
3. Escalonamento de governação da segurança, o CISO ou o Comité de Risco aprova a exceção ou a ação de emergência.
4. Escalonamento para a gestão, incumprimentos repetidos ou críticos de SLA são reportados à revisão pela gestão com ações corretivas.

A Política de Gestão de Vulnerabilidades e Patches reforça esta expectativa de auditoria:

Auditorias periódicas devem ser conduzidas pela Auditoria Interna ou por um terceiro independente para verificar: 5.6.1 Cumprimento dos SLAs 5.6.2 Evidência de priorização baseada no risco 5.6.3 Eficácia dos patches implementados 5.6.4 Controlos sobre sistemas sem patch

As métricas devem suportar decisões, não decorar painéis. As métricas mais fortes em 2026 incluem:

• Percentagem de cumprimento de SLAs críticos
• Percentagem de cumprimento de SLAs altos
• Tempo médio até à triagem
• Tempo médio até à remediação por classe de ativo
• Número de vulnerabilidades críticas em atraso
• Número de exceções aceites por antiguidade
• Exceções que excedem 90 dias
• Contagem de exposições críticas expostas à Internet
• Incumprimentos de SLAs de fornecedores
• Vulnerabilidades reabertas após validação
• Alterações de emergência causadas por vulnerabilidades exploradas
• Falhas de patches por plataforma ou unidade de negócio

Associe estas métricas à revisão pela gestão da cláusula 9.3 da ISO/IEC 27001:2022, ao reporte de governação DORA e à supervisão da gestão NIS2. Para o NIST CSF 2.0, utilize-as para atualizar perfis atuais e alvo, análise de lacunas e planos de ação.

Lista de verificação Clarysec para SLAs de remediação

Utilize esta lista de verificação para avaliar o seu programa atual:

• Existe uma política aprovada de gestão de vulnerabilidades e patches?
• Os SLAs de remediação estão definidos por severidade e criticidade de negócio?
• As vulnerabilidades expostas à Internet e exploradas são aceleradas?
• Os ativos estão mapeados para proprietários, serviços, dados e fornecedores?
• As constatações dos scanners são convertidas em tickets atribuídos?
• Os patches são executados através da gestão de alterações?
• As alterações de emergência são documentadas e revistas?
• Os resultados de remediação são validados por novas análises ou verificações de versão?
• As exceções são sujeitas a avaliação de risco, aprovadas e revistas pelo menos a cada 90 dias?
• Os controlos compensatórios são documentados para sistemas sem possibilidade de patch?
• Os contratos com fornecedores estão alinhados com os limiares internos de remediação?
• Os logs de patches são suficientemente completos para provar o que aconteceu e quando?
• Os incumprimentos de SLA são escalonados e corrigidos?
• As métricas são revistas pela gestão?
• São desencadeadas avaliações de incidentes e de violação quando há suspeita de exploração?

Se várias respostas forem “não”, o problema não é a ferramenta. É o desenho dos controlos.

Próximos passos: transformar prazos de patches em resiliência preparada para auditoria

Em 2026, os SLAs de remediação de vulnerabilidades devem fazer mais do que satisfazer um painel de scanner. Devem provar que a organização consegue identificar exposição, priorizar riscos, atuar dentro de prazos aprovados, controlar exceções, governar fornecedores e evidenciar decisões face às expectativas de auditoria da ISO/IEC 27001:2022, NIS2, DORA, RGPD da UE, NIST CSF 2.0 e COBIT 2019.

A Clarysec pode ajudar a passar de tickets de patches fragmentados para um programa integrado de remediação de vulnerabilidades orientado por evidência, utilizando:

• Política de Gestão de Vulnerabilidades e Patches
• Política de Gestão de Vulnerabilidades e Patches para PME
• Política de Segurança de Terceiros e Fornecedores para PME
• Zenith Blueprint: roteiro de 30 passos de um auditor
• Zenith Controls: guia de conformidade transversal

Comece por um serviço de alto risco. Mapeie os respetivos ativos, fornecedores, vulnerabilidades, tickets, alterações, exceções e evidência. Depois aplique-lhe as perguntas de auditoria. Se não conseguir provar o SLA desde a deteção até ao encerramento, esse é o seu primeiro projeto de remediação.

O objetivo não é a aplicação perfeita de patches. O objetivo é remediação governada, baseada no risco, mensurável e auditável. Descarregue os modelos de políticas da Clarysec, execute uma avaliação de lacunas direcionada ou marque uma demonstração da Clarysec para transformar a remediação de vulnerabilidades de pressão de auditoria em resiliência operacional.