Quando o CVE não explica o risco: cibersegurança e gestão de riscos na mesma mesa

A gestão de segurança cibernética e a gestão de riscos corporativos nasceram de disciplinas diferentes, mas hoje precisam responder à mesma pergunta: quanto de exposição a organização está disposta a aceitar para alcançar seus objetivos sem comprometer continuidade, confiança, conformidade e valor?

Durante anos, a segurança cibernética foi frequentemente apresentada à alta administração por meio de indicadores técnicos: quantidade de vulnerabilidades, alertas, tentativas de ataque, incidentes bloqueados, cobertura de antivírus ou tempo para aplicação de patches. Esses números continuam importantes para a operação, mas isoladamente raramente respondem ao que diretoria e conselho precisam decidir.

A gestão de riscos trabalha em outra camada. Seu foco está nos objetivos do negócio, na incerteza que pode impedir esses objetivos, na probabilidade e no impacto de eventos adversos, no apetite a risco, nas alternativas de tratamento e na responsabilidade pela decisão. Quando as duas disciplinas não conversam, a empresa pode ter uma segurança tecnicamente ativa e, ainda assim, dificuldade para demonstrar se está protegendo aquilo que realmente importa.

O NIST vem formalizando essa aproximação. O Cybersecurity Framework 2.0 incorporou a função Govern, enquanto a série NIST IR 8286 e guias publicados entre 2024 e 2026 tratam da integração do risco cibernético ao Enterprise Risk Management (ERM). A utilidade dessa integração aparece quando uma mesma evidência técnica precisa sustentar decisões diferentes na operação, na gestão de riscos e no conselho.

Segurança cibernética e gestão de riscos enxergam o mesmo problema por ângulos diferentes

A gestão de segurança cibernética tende a começar pelos ativos digitais, dados, identidades, sistemas, aplicações, redes, nuvem, terceiros e ameaças. A partir dessa visão, são definidos controles preventivos, detectivos e responsivos: autenticação forte, gestão de privilégios, hardening, proteção de endpoints, segmentação, monitoramento, resposta a incidentes, backup, recuperação e inúmeras outras medidas.

A gestão de riscos começa pelos objetivos e processos de negócio. Ela pergunta o que pode impedir a empresa de operar, crescer, cumprir contratos, manter clientes, atender obrigações regulatórias ou proteger sua reputação. Em seguida, estrutura cenários, impactos, probabilidades, responsáveis, controles existentes, risco residual e alternativas de tratamento.

As duas áreas observam o mesmo fenômeno, mas podem chegar a prioridades diferentes se o contexto não estiver disponível. Uma CVE 9,8 em um servidor isolado de laboratório pode ter baixa urgência empresarial; uma falha 7,5 em um serviço exposto que participa do faturamento pode exigir resposta imediata. Da mesma forma, uma conta administrativa sem MFA pode parecer um problema de IAM até se descobrir que ela permite alterar regras de pagamento ou assumir outras identidades. A severidade técnica continua importante, mas não descreve sozinha a consequência.

A prioridade muda quando o contexto do ativo entra na análise

As duas disciplinas dependem de inventário, contexto, priorização, responsáveis, métricas e evidências. Ambas precisam conhecer ativos críticos, processos essenciais, dependências, terceiros, requisitos de conformidade, ameaças e controles. A diferença está menos no objeto e mais na linguagem e no nível de decisão.

Há também um princípio comum: recursos são limitados. Nenhuma organização consegue corrigir todas as vulnerabilidades ao mesmo tempo, eliminar todos os riscos ou implantar todos os controles possíveis. Segurança e risco precisam, portanto, priorizar. Quando essa priorização é feita de forma integrada, deixa de depender apenas da severidade técnica e passa a considerar criticidade do ativo, exposição, ameaça, impacto operacional, dependências, requisitos legais e capacidade de recuperação.

Esse ponto é especialmente relevante para programas de vulnerabilidades. Uma falha CVSS 9,8 em um ativo isolado, sem exploração observada e sem acesso a dados críticos, pode representar uma prioridade diferente de uma falha CVSS 7,5 em um serviço exposto à Internet, associado a um processo de receita e com exploração ativa. O risco empresarial ajuda a contextualizar a técnica sem substituí-la.

O risco cibernético precisa entrar no registro de riscos da empresa

Um dos sinais mais claros de maturidade é quando os riscos cibernéticos relevantes deixam de existir apenas em planilhas do time de segurança e passam a integrar o registro corporativo de riscos. Isso não significa levar milhares de vulnerabilidades ao conselho. Significa consolidar cenários que possam comprometer objetivos de negócio.

Um registro executivo pode conter, por exemplo, um cenário de indisponibilidade prolongada de um sistema crítico causada por ransomware. O risco deve indicar processos afetados, impacto financeiro estimado, tempo máximo tolerável de interrupção, dependências, controles existentes, risco residual, responsável, plano de tratamento e prazo. As vulnerabilidades e controles técnicos permanecem como evidências que sustentam essa avaliação.

O NIST IR 8286 propõe justamente uma estrutura de comunicação em que registros de risco cibernético alimentam níveis superiores de risco até chegar ao portfólio empresarial. Essa lógica reduz um problema comum: o conselho recebe relatórios de cibersegurança sem conseguir relacioná-los aos demais riscos estratégicos da organização.

Apetite e tolerância a risco mudam a conversa sobre investimento

Um programa de segurança sem referência ao apetite a risco corre o risco de cair em dois extremos. Pode tentar eliminar riscos a qualquer custo, gerando investimentos difíceis de justificar, ou aceitar exposições de forma implícita simplesmente porque não existe uma decisão formal.

Quando a organização define apetite e tolerâncias, a segurança passa a trabalhar com limites claros. Se o negócio considera inaceitável uma indisponibilidade superior a quatro horas em uma plataforma crítica, esse parâmetro influencia arquitetura, redundância, backup, testes de recuperação, monitoramento e resposta. Se o conselho define baixa tolerância para exposição de dados pessoais, investimentos em classificação, DLP, identidade, criptografia e monitoramento deixam de ser apresentados como iniciativas isoladas e passam a ser mecanismos de tratamento de um risco explicitamente reconhecido.

Do CVE ao conselho: a tradução que faz diferença

Uma das maiores dificuldades dos CISOs é levar questões técnicas para executivos sem perder precisão. A solução não é remover a técnica, mas conectá-la a uma cadeia de causa e efeito.

A linguagem de risco também melhora a qualidade da decisão quando o investimento é disputado com outras áreas. Em vez de perguntar “quanto custa a ferramenta?”, a diretoria consegue avaliar “qual exposição será reduzida, quanto risco residual permanecerá e como isso se compara ao apetite definido?”.

Um exemplo prático: ransomware em um processo de faturamento

Imagine uma empresa que possui um ERP responsável pelo faturamento e pela emissão de documentos fiscais. A equipe de segurança identifica servidores com sistemas desatualizados, contas administrativas compartilhadas e backup sem testes recentes de restauração.

Em uma abordagem puramente técnica, cada problema pode gerar uma atividade separada: patching, PAM e revisão de backup. Em uma abordagem integrada, a organização constrói um cenário único: comprometimento do ERP por ransomware, com indisponibilidade estimada de dois dias.

A área financeira estima a perda de faturamento diário. Operações avalia impactos em pedidos e entregas. Jurídico e compliance verificam obrigações contratuais e regulatórias. Segurança estima probabilidade, vetores de ataque e efetividade dos controles. Continuidade determina RTO e RPO. A diretoria passa a enxergar um risco de negócio completo e pode comparar alternativas: segmentar o ambiente, eliminar contas compartilhadas, adotar PAM, acelerar correções, melhorar detecção, criar redundância e testar recuperação.

O resultado mais importante é que o orçamento deixa de ser uma discussão abstrata sobre tecnologia. A organização passa a decidir sobre redução de exposição.

Controles precisam de evidência, não apenas de existência

Outra convergência importante ocorre na avaliação de controles. Em gestão de riscos, não basta registrar que um controle existe; é necessário considerar se funciona e se reduz o risco conforme esperado. Esse princípio é igualmente crítico na segurança.

Uma política de MFA não reduz risco se contas privilegiadas estiverem fora do escopo. Um processo de backup não garante resiliência se a restauração nunca foi testada. Uma ferramenta de EDR não representa cobertura se agentes estiverem inativos. Um plano de resposta a incidentes não é evidência de capacidade se equipes nunca realizaram exercícios.

Por isso, indicadores de controle devem combinar cobertura, efetividade e resultado. Essa visão aproxima segurança, auditoria, compliance e gestão de riscos, além de melhorar a prestação de contas para liderança e reguladores.

Quais métricas devem chegar à diretoria e ao conselho

O conselho não precisa acompanhar cada alerta, vulnerabilidade ou incidente menor. Precisa compreender tendências de exposição e saber se os riscos permanecem dentro dos limites aprovados. Indicadores executivos úteis tendem a responder quatro questões: quais riscos relevantes existem, como estão evoluindo, quais controles estão reduzindo a exposição e onde o risco residual ultrapassa o nível aceitável.

Exemplos incluem percentual de processos críticos acima da tolerância a risco, exposição financeira estimada por cenários prioritários, ativos críticos sem controles mínimos, dependências de terceiros relevantes, tempo de recuperação comprovado em testes, risco residual após tratamento e evolução de KRIs associados aos principais riscos.

Indicadores técnicos continuam necessários, mas devem existir como camadas de detalhe. O board pode receber a visão consolidada; a diretoria e os comitês podem aprofundar; a segurança mantém telemetria operacional. Essa arquitetura evita tanto simplificação excessiva quanto sobrecarga de informação.

Gestão de risco também protege a segurança de decisões ruins

A integração não serve apenas para convencer executivos a investir mais. Ela também pode mostrar quando determinado investimento de segurança não é a prioridade mais adequada. Isso é importante porque maturidade não significa maximizar orçamento; significa direcionar recursos para onde reduzem mais risco.

Se duas iniciativas competem pelo mesmo orçamento, uma análise integrada pode demonstrar que reforçar recuperação de um sistema essencial reduz uma exposição maior do que adquirir uma nova ferramenta para um ambiente de baixa criticidade. Em outro cenário, pode revelar que o principal risco não é tecnológico, mas um processo de terceiro, uma concentração de fornecedor ou uma ausência de responsabilidade definida.

Esse equilíbrio aumenta a credibilidade da segurança perante a liderança, porque o CISO deixa de ser percebido apenas como defensor de controles e passa a atuar como gestor de exposição empresarial.

Como estruturar uma visão integrada

O ponto de partida é mapear os processos e objetivos críticos e relacioná-los aos ativos digitais que os suportam. Em seguida, riscos técnicos relevantes devem ser convertidos em cenários de negócio com causa, evento e consequência. Os controles existentes precisam ser avaliados por efetividade, e o risco residual deve ser comparado ao apetite e às tolerâncias aprovadas.

Depois disso, segurança e gestão de riscos precisam compartilhar um ciclo de monitoramento. Mudanças no ambiente técnico — novas vulnerabilidades, exploração ativa, alterações em fornecedores, incidentes ou mudanças de arquitetura — podem elevar risco rapidamente. Da mesma forma, mudanças de negócio, como aquisições, expansão internacional, novos produtos ou adoção de IA, alteram criticidade e exposição.

A integração só funciona quando há governança clara: quem é o dono do risco, quem opera o controle, quem aceita o risco residual, quem monitora indicadores e quando a situação deve ser escalada.

Frameworks que ajudam a construir essa ponte

O NIST CSF 2.0 oferece uma estrutura orientada a resultados com as funções Govern, Identify, Protect, Detect, Respond e Recover. A série NIST IR 8286 aprofunda a relação entre riscos cibernéticos e ERM. A ISO 31000 fornece princípios e diretrizes de gestão de riscos corporativos, enquanto ISO/IEC 27001 e ISO/IEC 27005 estruturam a gestão de riscos de segurança da informação dentro de um SGSI.

Esses referenciais não precisam competir. Uma organização pode usar ISO 31000 para a arquitetura de risco empresarial, ISO/IEC 27001 para o sistema de gestão de segurança e NIST CSF para organizar resultados e maturidade. O mais importante é que a taxonomia, os registros, os responsáveis e os critérios de priorização sejam interoperáveis.

Conclusão: o mesmo risco precisa fazer sentido para quem opera e para quem decide

A aproximação entre Segurança e Gestão de Riscos não exige uma nova ferramenta. Exige que o mesmo cenário consiga ser descrito tecnicamente, relacionado a um processo de negócio e associado a um responsável pela decisão. Sem essa ligação, a operação corrige o que parece grave e a liderança administra um risco que pode não refletir a exposição real.

Quando essa ponte existe, o conselho não precisa decidir sobre CVEs. Decide sobre exposição. A diretoria não precisa aprovar uma tecnologia porque “segurança pediu”. Pode avaliar qual risco será reduzido, qual risco residual permanecerá e se essa exposição está de acordo com o que a organização está disposta a aceitar.

Quando essa ligação funciona, uma vulnerabilidade, uma identidade comprometida ou uma falha de terceiro deixam de ser números isolados. Passam a ter dono, prazo, tolerância, impacto esperado e evidência de tratamento — informações que permitem decidir sem esconder a complexidade técnica.

Referências

NIST — Cybersecurity Framework 2.0: Resource & Overview Guide
NIST — Cybersecurity Framework 2.0: Enterprise Risk Management Quick-Start Guide
NIST — Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide
NIST — CSF Updates Archive / NIST IR 8286 Series
ISO — ISO 31000 Risk Management
ISO — ISO/IEC 27001 Information Security Management Systems
ISO — ISO/IEC 27005 Information Security Risk Management
NACD — Cyber-Risk Oversight