CVD para NIS2 e DORA: mapa de evidências ISO 27001

Às 08:17 de uma terça-feira, a caixa de correio de segurança recebe uma mensagem de um investigador independente. O assunto é calmo, quase educado: “Potencial tomada de controlo de conta no vosso portal de clientes”. O corpo da mensagem é menos confortável. O investigador afirma que uma vulnerabilidade encadeada na aplicação SaaS permite que um tenant aceda aos registos de faturas de outro tenant. Está anexada uma prova de conceito, cifrada com a chave PGP pública publicada pela organização.

Para Maria, a nova CISO da FinanTechSaaS, o momento não podia ser pior. A empresa acabou de assinar um contrato relevante com um banco de primeira linha da UE. A equipa de diligência prévia do cliente já solicitou uma “Política de Divulgação Coordenada de Vulnerabilidades” e evidência da sua implementação, referindo explicitamente NIS2 e DORA. A empresa tem um endereço de correio eletrónico security@, mas este é monitorizado por um único programador. Não existe um registo formal de admissão, não há SLA de validação definido, não existe via de escalonamento para a gestão e não há pista de auditoria.

Três relógios começam a contar em simultâneo.

O primeiro é operacional. A vulnerabilidade é real? É explorável em produção? Alguém está a explorá-la ativamente?

O segundo é regulamentar. Se dados de clientes estiverem expostos, inicia-se a avaliação de violação de dados ao abrigo do RGPD da UE. Se a prestação do serviço for afetada para uma entidade essencial ou importante ao abrigo da NIS2, podem ser acionados limiares de notificação de incidentes. Se a empresa for uma entidade financeira ou um prestador de TIC que apoia serviços financeiros, as regras do DORA sobre gestão de incidentes, classificação, escalonamento e comunicação a clientes podem tornar-se relevantes.

O terceiro é de evidência. Seis meses depois, um auditor ISO/IEC 27001:2022, um supervisor do setor financeiro, uma equipa de garantia de clientes ou um comité interno de auditoria pode perguntar: “Mostrem-nos como esta vulnerabilidade foi tratada.”

É nessa pergunta que muitas organizações descobrem que a divulgação coordenada de vulnerabilidades não é apenas uma caixa de correio de segurança. É um sistema de governação. Precisa de responsabilidade definida pela política, canal público de reporte, fluxo de triagem, SLA de remediação, escalonamento de fornecedores, lógica de decisão sobre incidentes, revisão de privacidade, reporte à gestão e evidência defensável.

A Clarysec trata a CVD como um padrão de controlo integrado, não como uma caixa de entrada isolada. Em Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, o tratamento de vulnerabilidades surge na fase Controls in Action, Step 19: Technological Controls I, onde a orientação é clara: as organizações não devem arquivar passivamente constatações de vulnerabilidades; devem triá-las, atribuí-las e acompanhá-las até ao encerramento. O mesmo padrão aplica-se às divulgações externas. Se alguém lhe indica como o seu serviço pode falhar, a verdadeira pergunta passa a ser: consegue provar que recebeu, avaliou, priorizou, remediou, comunicou e aprendeu com isso?

Porque é que a CVD é agora uma matéria de nível do conselho de administração ao abrigo da NIS2 e do DORA

Durante anos, as organizações com maturidade em segurança convidaram investigadores de segurança a reportar vulnerabilidades porque era uma boa prática. Ao abrigo da NIS2 e do DORA, essa prática passou a fazer parte da resiliência digital regulada.

A NIS2 aplica-se a muitas entidades médias e grandes em setores de elevada criticidade e noutros setores críticos, incluindo prestadores de infraestrutura digital, prestadores de serviços de computação em nuvem, prestadores de serviços de centros de dados, prestadores de serviços geridos, prestadores de serviços de segurança geridos e determinados prestadores digitais, como mercados em linha, motores de pesquisa e plataformas de redes sociais. Pode também aplicar-se independentemente da dimensão a categorias como prestadores de serviços de confiança, prestadores de serviços DNS, registos TLD e prestadores de redes ou serviços públicos de comunicações eletrónicas.

O Article 21 da NIS2 exige que as entidades essenciais e importantes implementem medidas técnicas, operacionais e organizacionais adequadas e proporcionais de gestão de riscos de cibersegurança, usando uma abordagem que cubra todos os riscos. Uma das áreas mínimas é a segurança na aquisição, no desenvolvimento e na manutenção de sistemas de redes e informação, incluindo o tratamento e a divulgação de vulnerabilidades. A mesma linha de base também cobre tratamento de incidentes, segurança da cadeia de fornecimento, continuidade do negócio, controlo de acesso, gestão de ativos, formação, criptografia e procedimentos para avaliar a eficácia dos controlos.

O Article 20 da NIS2 também torna explícita a responsabilização da gestão. Os órgãos de gestão devem aprovar as medidas de gestão de riscos de cibersegurança, supervisionar a implementação e receber formação. Para um programa de CVD, isto significa que o conselho de administração ou a alta direção deve compreender o canal de reporte, a equipa de resposta a vulnerabilidades, os prazos de validação, as expectativas de remediação, as dependências de fornecedores e os gatilhos de notificação de incidentes.

O DORA cria um regime setorial específico para entidades financeiras a partir de 17 de janeiro de 2025. Abrange a gestão do risco das TIC, a notificação de incidentes relacionados com as TIC, os testes de resiliência operacional digital, a partilha de informação, o risco de terceiros de TIC, os requisitos contratuais, a supervisão de prestadores terceiros críticos de TIC e a cooperação com autoridades de supervisão. Para entidades financeiras abrangidas pelo DORA, o DORA prevalece geralmente sobre a NIS2 em matéria de gestão do risco das TIC e notificação de incidentes, por ser o ato jurídico da União específico do setor. Mas o requisito prático permanece o mesmo: as entidades financeiras e os prestadores de TIC que as servem devem operar um processo estruturado, documentado e testável para identificar, analisar, classificar, escalar, remediar e aprender com fraquezas de TIC.

Um reporte de vulnerabilidade pode começar como uma constatação técnica, tornar-se um evento de segurança, escalar para incidente, acionar uma avaliação de violação de dados pessoais ao abrigo do RGPD da UE, exigir ação de fornecedor e, mais tarde, aparecer na Declaração de Aplicabilidade ISO/IEC 27001:2022. Por isso, a CVD deve ser concebida como um modelo operacional único que abrange segurança, conformidade, engenharia, jurídico, privacidade, compras e gestão.

A base ISO 27001: da divulgação à evidência do SGSI

A ISO/IEC 27001:2022 fornece aos CISO e aos responsáveis de conformidade o sistema de gestão que torna a CVD auditável.

As cláusulas 4.1 a 4.4 exigem que a organização compreenda as questões internas e externas, os requisitos das partes interessadas, os limites do SGSI e as dependências com outras organizações. É aqui que NIS2, DORA, RGPD da UE, contratos de clientes, obrigações de fornecedores e compromissos de divulgação de vulnerabilidades entram no SGSI.

As cláusulas 5.1 a 5.3 estabelecem a responsabilização da liderança. A alta direção deve alinhar a segurança da informação com a orientação estratégica, disponibilizar recursos, atribuir responsabilidades e assegurar que o SGSI alcança os resultados pretendidos. Para a CVD, isto significa nomear uma Equipa de Resposta a Vulnerabilidades, definir a autoridade para aceitar risco residual e escalar vulnerabilidades de elevado impacto à gestão.

As cláusulas 6.1.1 a 6.1.3 fornecem o motor de risco. A organização deve definir critérios de risco, avaliar riscos de segurança da informação, designar proprietários do risco, selecionar opções de tratamento de riscos, comparar controlos com o Anexo A, produzir uma Declaração de Aplicabilidade e obter aprovação para o risco residual. As cláusulas 8.1 a 8.3 exigem depois controlo operacional, alterações planeadas, controlo de processos fornecidos externamente, avaliações de risco em intervalos planeados ou após alterações significativas e evidência dos resultados do tratamento.

Em Zenith Blueprint, fase Risk Management, Step 13, a Declaração de Aplicabilidade é descrita como mais do que uma folha de cálculo de conformidade:

“A SoA é, na prática, um documento de ligação: liga a sua avaliação/tratamento de riscos aos controlos reais que possui.”
Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

Para a divulgação coordenada de vulnerabilidades, a SoA deve ligar obrigações regulamentares, risco de negócio, controlos do Anexo A, cláusulas de política e evidência operacional.

O objetivo não é criar silos paralelos de conformidade. A política de CVD deve ser um processo controlado do SGSI que suporta, ao mesmo tempo, a certificação ISO/IEC 27001:2022, o cumprimento da NIS2, a preparação para DORA, a garantia de clientes e as operações de segurança.

A linha de base da política: o que a sua política de CVD deve dizer

O primeiro controlo visível é o canal público de divulgação. Investigadores, clientes, fornecedores e parceiros devem saber onde reportar vulnerabilidades e como proteger evidência sensível.

A Política de Divulgação Coordenada de Vulnerabilidades da Clarysec Política de Divulgação Coordenada de Vulnerabilidades fornece a linha de base empresarial:

“Canais públicos de divulgação: A organização deve manter um canal claro para reporte de vulnerabilidades, como um endereço de correio eletrónico dedicado para contacto de segurança (por exemplo, security@company.com) ou um formulário Web. Esta informação deve ser publicada na página de segurança do sítio Web da empresa, juntamente com a chave pública PGP da organização, para permitir submissões cifradas.”
Fonte: Política de Divulgação Coordenada de Vulnerabilidades, Requisitos de implementação, cláusula 6.1

Esta cláusula resolve uma falha comum em auditoria. Muitas organizações afirmam que aceitam reportes, mas a rota de reporte está escondida, não é cifrada ou pertence à equipa errada. Um canal maduro é público, seguro, monitorizado e atribuído a uma função responsável.

O controlo seguinte é a disciplina de resposta. Um reporte crítico seguido de silêncio cria risco de divulgação, risco reputacional e risco de exploração. A Política de Divulgação Coordenada de Vulnerabilidades define uma expectativa concreta de confirmação e validação:

“Triagem e confirmação: Após a receção de um reporte, a VRT deve registá-lo e enviar uma confirmação ao autor do reporte no prazo de 2 dias úteis, atribuindo uma referência de rastreio. A VRT deve realizar uma avaliação preliminar de severidade, por exemplo usando pontuação CVSS, e validar a questão, incluindo com apoio das equipas de TI e desenvolvimento quando necessário, dentro de um prazo-alvo de 5 dias úteis. Vulnerabilidades críticas, como as que permitem execução remota de código ou uma violação de dados relevante, devem ser aceleradas.”
Fonte: Política de Divulgação Coordenada de Vulnerabilidades, Requisitos de implementação, cláusula 6.4

Esta redação cria pontos imediatos de evidência: hora de receção, hora de confirmação, referência de rastreio, severidade preliminar, resultado da validação e decisão de tratamento acelerado.

Para PME, a Clarysec usa a mesma lógica com implementação proporcional. A Política de Requisitos de Segurança das Aplicações - PME Política de Requisitos de Segurança das Aplicações - PME exige que as organizações:

“especifiquem obrigações de divulgação de vulnerabilidades, tempos de resposta e aplicação de patches.”
Fonte: Política de Requisitos de Segurança das Aplicações - PME, Requisitos de governação, cláusula 5.3.2

Não precisa de uma grande equipa de segurança de produto para ser responsável. Precisa de obrigações explícitas, prazos realistas, responsáveis nomeados e evidência de que o processo funciona.

O fluxo de admissão de CVD: do e-mail do investigador ao registo de decisão

Um bom fluxo de admissão é suficientemente simples para funcionar sob pressão e suficientemente completo para satisfazer um auditor. Deve começar por um canal dedicado, como security@[company], um formulário Web ou um ficheiro security.txt publicado. A rota de submissão deve permitir evidência cifrada, produto ou endpoint afetado, passos de reprodução, dados de contacto do autor do reporte, calendário de divulgação preferido e qualquer indicação de exposição de dados ou exploração ativa.

Depois da receção, a Equipa de Resposta a Vulnerabilidades deve criar um registo numa ferramenta GRC, plataforma de tickets, sistema de gestão de vulnerabilidades ou registo controlado. A ferramenta importa menos do que a consistência e a qualidade da evidência.

O fluxo deve então avançar por sete passos operacionais.

1. Admissão: o reporte é recebido através do canal público e registado automática ou manualmente.
2. Confirmação: a VRT responde no prazo de 2 dias úteis e atribui uma referência de rastreio.
3. Validação: a equipa técnica reproduz a questão, confirma os sistemas afetados e executa a pontuação preliminar de severidade.
4. Avaliação do evento: a VRT determina se a vulnerabilidade é apenas uma fraqueza, um evento de segurança da informação ou um incidente.
5. Escalonamento: questões altas ou críticas são enviadas para responsáveis pelos sistemas, CISO, privacidade, jurídico, fornecedores e gestão conforme necessário.
6. Remediação: a equipa responsável aplica uma correção, mitigação, controlo compensatório ou restrição temporária.
7. Encerramento: a VRT verifica a correção, comunica com o autor do reporte, atualiza o ficheiro de evidência e regista as lições aprendidas.

A Clarysec mapeia este passo operacional para o controlo A.5.25 da ISO/IEC 27002:2022, avaliação e decisão sobre eventos de segurança da informação, e para o controlo A.8.8, gestão de vulnerabilidades técnicas, através de Zenith Controls: The Cross-Compliance Guide Zenith Controls. Para A.5.25, Zenith Controls explica que a avaliação de eventos é a função de triagem entre alertas brutos de monitorização e o tratamento formal de incidentes, usando logs, limiares e critérios de decisão para determinar o escalonamento. Para A.8.8, Zenith Controls liga a gestão de vulnerabilidades técnicas à proteção contra malware, gestão da configuração, gestão de alterações, segurança de endpoints, informações sobre ameaças, monitorização, desenvolvimento seguro, avaliação de eventos e resposta a incidentes.

Uma passagem de Zenith Controls é especialmente útil quando se suspeita de exploração ativa:

“As informações sobre ameaças indicam quais vulnerabilidades estão a ser exploradas ativamente, orientando a priorização da aplicação de patches.”
Fonte: Zenith Controls: The Cross-Compliance Guide, controlo 8.8 da ISO/IEC 27002:2022, ligação ao controlo 5.7 Informações sobre ameaças Zenith Controls

Este é um ponto importante de governação. A severidade não é apenas CVSS. Uma vulnerabilidade com pontuação média explorada ativamente contra o seu setor pode ter prioridade superior a uma questão crítica teórica num sistema de teste não exposto.

Quando uma vulnerabilidade se torna um incidente

Nem todo o reporte de vulnerabilidade é um incidente. Um cabeçalho de segurança em falta num ambiente de staging não é o mesmo que um bypass de autorização explorado que expõe faturas de clientes. Mas todo o reporte credível de vulnerabilidade deve passar por uma porta de decisão sobre incidentes.

O Article 23 da NIS2 exige que as entidades essenciais e importantes notifiquem o seu CSIRT ou autoridade competente, sem demora injustificada, sobre incidentes com impacto significativo na prestação do serviço. Um incidente significativo é aquele que causou ou é suscetível de causar perturbação operacional grave ou perda financeira, ou que afetou ou é suscetível de afetar terceiros causando danos materiais ou imateriais consideráveis. A sequência de reporte inclui um alerta precoce no prazo de 24 horas após a tomada de conhecimento, uma notificação de incidente no prazo de 72 horas, relatórios intermédios quando solicitados e um relatório final no prazo de um mês após a notificação de 72 horas.

Os Articles 17 to 20 do DORA exigem que as entidades financeiras detetem, giram, registem, classifiquem, escalem, notifiquem e comuniquem incidentes relacionados com as TIC e ameaças cibernéticas significativas. Incidentes graves relacionados com as TIC devem ser escalados à alta direção e ao órgão de gestão. A comunicação a clientes pode ser exigida quando os seus interesses financeiros são afetados.

Para PME, a cultura de reporte deve ser igualmente clara. A Política de Resposta a Incidentes - PME da Clarysec Política de Resposta a Incidentes - PME estabelece:

“O pessoal deve reportar qualquer atividade suspeita ou incidente confirmado para incident@[company] ou verbalmente ao Diretor-Geral ou ao prestador de TI.”
Fonte: Política de Resposta a Incidentes - PME, Requisitos de implementação da política, cláusula 6.2.1

Em Zenith Blueprint, fase Controls in Action, Step 16: People Controls II, o princípio é ainda mais simples:

“Em caso de dúvida, reporte.”
Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 16: People Controls II (A.6.5 a A.6.8)

Esta frase deve aplicar-se a programadores, equipas de suporte, gestores de fornecedores, responsáveis de privacidade, executivos e prestadores externalizados. Uma vulnerabilidade que possa afetar confidencialidade, integridade, disponibilidade, confiança do cliente, reporte regulamentar ou operações financeiras deve ser registada e avaliada, não tratada informalmente em chat.

Remediação, aplicação de patches e controlos compensatórios

Depois de validada, a vulnerabilidade deve ser tratada. O tratamento deve ser baseado no risco, suportado por evidência e limitado no tempo.

A Política de Divulgação Coordenada de Vulnerabilidades define a expectativa empresarial:

“Plano de remediação: Deve ser desenvolvido um plano de remediação ou mitigação para todas as vulnerabilidades confirmadas. A implementação da correção deve ser priorizada com base na severidade. Por exemplo, vulnerabilidades críticas devem ser corrigidas ou mitigadas no prazo de 14 dias, quando viável, ou antes quando for detetada exploração ativa, enquanto questões de menor severidade devem ser tratadas dentro de um prazo razoável. Quando uma correção completa for adiada, devem ser implementados controlos compensatórios ou medidas temporárias de mitigação, como desativar funcionalidade vulnerável ou aumentar a monitorização.”
Fonte: Política de Divulgação Coordenada de Vulnerabilidades, Requisitos de implementação, cláusula 6.6

Para a disciplina de aplicação de patches em PME, a Política de Gestão de Vulnerabilidades e Patches - PME Política de Gestão de Vulnerabilidades e Patches - PME estabelece:

“Patches críticos devem ser aplicados no prazo de 3 dias após a disponibilização, especialmente para sistemas expostos à Internet”
Fonte: Política de Gestão de Vulnerabilidades e Patches - PME, Requisitos de implementação da política, cláusula 6.1.1

Estes prazos não são contraditórios. Um patch de fornecedor para um sistema exposto à Internet pode exigir implementação muito rápida. Uma vulnerabilidade de produto que exige alterações de código, testes de regressão, coordenação com clientes e lançamento faseado pode exigir um plano de remediação com mitigações intercalares. O essencial é que a decisão seja documentada, pertença a um proprietário do risco e seja aprovada quando permanecer risco residual.

Um fluxo prático de caso é o seguinte:

1. Um investigador reporta um bypass de autorização na API de faturação de clientes.
2. A VRT regista CVD-2026-014 com carimbo temporal e confirma a receção no prazo de 2 dias úteis.
3. A segurança de produto valida a falha em 24 horas e atribui severidade Alta devido a acesso a dados entre tenants.
4. A privacidade realiza uma avaliação de violação ao abrigo do RGPD da UE porque os registos de faturas podem conter dados pessoais.
5. O gestor de incidentes abre uma avaliação de evento ao abrigo do controlo A.5.25 da ISO/IEC 27002:2022.
6. O responsável pelo sistema desativa o endpoint vulnerável através de uma feature flag temporária.
7. A engenharia cria um hotfix ao abrigo do controlo A.8.32 da ISO/IEC 27002:2022, Gestão de alterações.
8. São acrescentadas regras de monitorização para indicadores de exploração, ligadas a A.8.15, Registo em logs, e A.8.16, Atividades de monitorização.
9. O CISO informa a alta direção porque a questão é de alto risco.
10. A VRT coordena com o investigador o reteste e o calendário de divulgação.
11. O proprietário do risco aprova o encerramento apenas após testes de verificação e revisão do impacto em clientes.
12. A SoA, o Registo de Riscos, o ticket, os logs, a notificação à gestão e as lições aprendidas são atualizados.

Esta é a diferença entre “aplicámos o patch” e “conseguimos provar que governámos o processo”.

Dependências de fornecedores e nuvem: o ponto de falha oculto

Muitas falhas de CVD são, na realidade, falhas de fornecedores disfarçadas. A vulnerabilidade pode afetar um componente SaaS, serviço na nuvem, prestador de segurança gerido, gateway de pagamentos, intermediário de autenticação, biblioteca open source, equipa de desenvolvimento externalizado ou subcontratante.

O Article 21 da NIS2 exige segurança da cadeia de fornecimento, incluindo relações com fornecedores diretos e prestadores de serviços. As medidas relativas à cadeia de fornecimento devem considerar vulnerabilidades de fornecedores, qualidade dos produtos, práticas de cibersegurança e procedimentos de desenvolvimento seguro.

Os Articles 28 to 30 do DORA são mais aprofundados para entidades financeiras. Exigem que o risco de terceiros de TIC seja gerido como parte do quadro de risco das TIC, com registos de contratos de serviços de TIC, distinções entre funções críticas ou importantes, diligência prévia pré-contratual, requisitos contratuais de segurança, assistência em incidentes, cooperação com autoridades, direitos de auditoria, direitos de cessação e estratégias de saída. As entidades financeiras continuam totalmente responsáveis pela conformidade com o DORA mesmo quando usam prestadores terceiros de TIC.

A Política de Segurança de Terceiros e Fornecedores - PME da Clarysec Política de segurança de terceiros e fornecedores - PME inclui uma regra simples de escalonamento:

“Deve notificar imediatamente o Diretor-Geral sobre qualquer violação de segurança, alteração ou incidente”
Fonte: Política de segurança de terceiros e fornecedores - PME, Papéis e responsabilidades, cláusula 4.4.3

Para contratos empresariais com fornecedores, Zenith Blueprint, fase Controls in Action, Step 23, recomenda incluir obrigações de confidencialidade, responsabilidades de controlo de acesso, medidas técnicas e organizativas, prazos de notificação de incidentes, direito de auditoria, controlos de subcontratantes e disposições de fim de contrato. Afirma:

“O que importa é que existam e que sejam compreendidas e aceites por ambas as partes.”
Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 23: Organizational controls (5.19 a 5.37)

A preparação de fornecedores para CVD deve responder a estas perguntas:

• O fornecedor publica um canal de reporte de vulnerabilidades?
• Os prazos de notificação de vulnerabilidades estão definidos no contrato?
• As vulnerabilidades críticas de fornecedores são reportadas sem demora injustificada?
• As fraquezas com impacto em clientes estão ligadas a obrigações de assistência em incidentes?
• O fornecedor consegue fornecer evidência de remediação ou avisos de segurança?
• As obrigações relativas a vulnerabilidades são transmitidas aos subcontratantes?
• Existe uma estratégia de saída se a remediação for inadequada?

É aqui que NIS2, DORA e ISO/IEC 27001:2022 convergem. A gestão de vulnerabilidades de fornecedores não é uma caixa de verificação de compras. É parte da resiliência operacional.

Mapeamento de evidência para ISO 27001, NIS2, DORA, RGPD da UE e COBIT

Os programas de CVD mais robustos começam pela evidência. Assumem que qualquer reporte significativo pode ser posteriormente revisto por auditoria interna, auditores de certificação, reguladores, clientes, seguradoras ou um comité de risco do conselho de administração.

A Política de Auditoria e Monitorização da Conformidade - PME da Clarysec Política de Auditoria e Monitorização da Conformidade - PME capta um detalhe que muitas equipas ignoram:

“Os metadados (por exemplo, quem os recolheu, quando e a partir de que sistema) devem ser documentados.”
Fonte: Política de Auditoria e Monitorização da Conformidade - PME, Requisitos de implementação da política, cláusula 6.2.3

Uma captura de ecrã de um servidor corrigido é fraca se ninguém souber quem a capturou, quando, a partir de que sistema e como se mapeia à vulnerabilidade. Um ticket com carimbos temporais, saída do scanner, pull request, aprovação da alteração, logs de implementação, consulta de monitorização, confirmação de reteste e metadados é muito mais forte.

Uma matriz de rastreabilidade mais detalhada ajuda durante a diligência prévia de clientes e a auditoria interna.

Diferentes auditores testarão o mesmo processo através de lentes diferentes.

Um auditor ISO/IEC 27001:2022 começará pelo SGSI. Perguntará se as obrigações de divulgação de vulnerabilidades estão incluídas nos requisitos das partes interessadas, se os riscos são avaliados de forma consistente, se os controlos aparecem na SoA, se existe evidência operacional e se a gestão revê tendências e itens em atraso.

Um revisor DORA ou de serviços financeiros focar-se-á na resiliência operacional. Examinará a integração do risco das TIC, a classificação de incidentes, o escalonamento à alta direção, a comunicação a clientes, as dependências de terceiros, os testes e as lições aprendidas. Se a vulnerabilidade afetar uma função crítica ou importante, esperará uma ligação estreita entre o ticket técnico, o impacto no negócio, as implicações de continuidade e as obrigações de fornecedores.

Um revisor do RGPD da UE focar-se-á nos dados pessoais. Houve dados pessoais envolvidos? Existiu acesso não autorizado, perda, alteração ou divulgação? Os papéis de responsável pelo tratamento e subcontratante estavam claros? O limiar de violação foi avaliado? Salvaguardas como cifragem, controlo de acesso, registo em logs e minimização eram relevantes?

Um auditor COBIT 2019 ou ISACA focar-se-á em governação, responsabilização, desempenho e garantia. Procurará responsabilidades definidas, métricas, escalonamento, objetivos de controlo, supervisão da gestão e acompanhamento de exceções. Uma vulnerabilidade crítica em atraso não é apenas um problema técnico. É uma questão de governação, salvo se for formalmente escalada e aceite como risco.

Um avaliador orientado por NIST pensará em termos de Identify, Protect, Detect, Respond e Recover. Pretenderá responsabilidade por ativos, identificação de vulnerabilidades, priorização, alteração protetiva, deteção de exploração, coordenação de resposta e validação de recuperação.

A vantagem de um modelo CVD integrado é que a mesma espinha dorsal de evidência pode suportar todas estas revisões.

O ciclo mensal de controlo: métricas que a gestão pode usar

A CVD não termina quando o ticket fecha. A Política de Divulgação Coordenada de Vulnerabilidades exige revisão contínua do registo:

“A VRT deve manter um log de divulgação de vulnerabilidades que acompanhe cada reporte desde a receção até ao encerramento. O log deve ser revisto mensalmente para assegurar a progressão atempada dos itens em aberto. Os itens em atraso devem ser escalados.”
Fonte: Política de Divulgação Coordenada de Vulnerabilidades, Monitorização e Auditoria, cláusula 9.1

Esta revisão mensal transforma a divulgação de vulnerabilidades em governação preparada para o conselho de administração. A gestão não precisa de todos os detalhes técnicos. Precisa de tendência, exposição, responsabilização e risco em atraso.

Numa implementação madura da Clarysec, esta revisão mensal do registo alimenta o Registo de Riscos, a Declaração de Aplicabilidade, o backlog de desenvolvimento seguro, as revisões de fornecedores, as lições aprendidas de incidentes, o plano de auditoria interna e o pacote de reporte à gestão.

Construa o processo antes de chegar o reporte grave

O pior momento para desenhar a divulgação coordenada de vulnerabilidades é depois de um investigador publicar a sua fraqueza ou de um cliente bancário crítico congelar a integração. NIS2, DORA, RGPD da UE, ISO/IEC 27001:2022, expectativas de resiliência ao estilo NIST e governação COBIT 2019 apontam todas na mesma direção: a divulgação de vulnerabilidades deve ser planeada, ter responsável, ser testada, evidenciada e melhorada.

Comece com estas cinco ações:

1. Adote ou adapte a Política de Divulgação Coordenada de Vulnerabilidades.
2. Construa o fluxo de admissão e triagem usando Zenith Blueprint, especialmente Step 13 para rastreabilidade da SoA, Step 16 para cultura de reporte, Step 19 para gestão de vulnerabilidades técnicas e Step 23 para acordos com fornecedores.
3. Mapeie o fluxo através de Zenith Controls, com foco nos controlos ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 e A.8.32.
4. Acrescente cláusulas prontas para PME da Política de Resposta a Incidentes - PME, Política de Gestão de Vulnerabilidades e Patches - PME, Política de segurança de terceiros e fornecedores - PME, Política de Requisitos de Segurança das Aplicações - PME e Política de Auditoria e Monitorização da Conformidade - PME quando a proporcionalidade for relevante.
5. Execute um exercício de simulação que represente um reporte de investigador que afeta dados pessoais e um componente alojado por fornecedor; depois teste confirmação, triagem, classificação de incidente, aplicação de patches, comunicação a clientes, captura de evidência e escalonamento à gestão.

A Clarysec pode ajudá-lo a transformar isto numa política de CVD operacional, num registo de admissão, num mapa de evidência ISO/IEC 27001:2022, numa árvore de decisão NIS2 e DORA, num modelo de escalonamento de fornecedores e num pacote de controlos preparado para auditoria. O objetivo é simples: quando chegar o próximo reporte de vulnerabilidade, a sua equipa não deve improvisar. Deve executar com confiança, evidência e controlo.