A régua comum do board: medir risco cibernético junto com crédito e operacional

Todo conselho de administração que toma decisões de alocação de capital já usa uma régua. Pode não chamar assim, mas o raciocínio está lá: probabilidade de ocorrência multiplicada por magnitude do impacto. É assim que se decide expandir para um novo mercado. É assim que se avalia uma aquisição. É assim que o jurídico apresenta um risco de litígio.

Para quase toda categoria de risco empresarial, o board tem um framework implícito. Com a cibersegurança, esse framework raramente é aplicado.

O problema não é que os executivos não entendam risco. É que ninguém traduziu o risco cibernético para a linguagem que eles já dominam.

O board já decide com prob × impacto

Quando o diretor financeiro apresenta uma projeção de cenário, ele trabalha com intervalos. Melhor caso, caso-base, pior caso. Cada um com uma probabilidade implícita e uma estimativa de impacto no resultado. O conselho lê esse documento e toma decisões a partir dele.

Quando o CISO apresenta o relatório de segurança, o documento tem outra estrutura. Lista de vulnerabilidades com classificação técnica. Crítica, alta, média, baixa. Recomendações de mitigação. Status de projetos de segurança. O conselho lê esse documento e não sabe o que decidir, porque não há decisão mapeada.

Essa não é uma crítica aos profissionais de segurança. É uma observação sobre o design da comunicação. O relatório foi construído para quem lida com detalhe técnico, não para quem decide sobre alocação de capital.

O que falta para que cyber entre na régua

Para que a cibersegurança seja avaliada com a mesma régua que outros riscos, o conselho precisa de três elementos.

Primeiro, probabilidade estimada de ocorrência num horizonte definido. Não "risco alto" ou "exposição crítica". Isso não é comparável a outros riscos. A pergunta é: qual a probabilidade de um incidente que cause interrupção operacional significativa nos próximos 12 meses? As estimativas devem se basear em histórico setorial, perfil de exposição e maturidade dos controles existentes.

Segundo, magnitude do impacto por cenário. O que significa "interrupção operacional significativa" em reais, dias de operação, contratos em risco, clientes afetados? O impacto precisa chegar ao board em unidades que o board usa. Não em variáveis técnicas.

Terceiro, custo de mitigação versus custo de ocorrência. Investir R$ 500 mil em controles que reduzem em 60% a probabilidade de um incidente estimado em R$ 8 milhões é uma decisão clara. Apresentada dessa forma, não compete com outros projetos. É uma análise de ROI de proteção.

Métrica de impacto: o que medir por vertical

A tradução do impacto cibernético para linguagem de negócio varia por setor. Não porque os riscos sejam fundamentalmente diferentes, mas porque as unidades de negócio que o board monitora são distintas.

Em indústria, a métrica central costuma ser custo de parada de linha por hora e dias de entrega comprometidos. Em serviços financeiros, é exposição regulatória, custo de notificação de clientes e impacto em rating. Em saúde, é custo de interrupção do atendimento e risco reputacional com convênios e reguladores. Em varejo, é indisponibilidade de plataforma em períodos de pico e custo de fraude.

Cada vertical tem sua régua específica. O trabalho de tradução consiste em mapear qual métrica de negócio é mais sensível ao risco cibernético. Depois, apresentar o risco nessa métrica.

A virada de reativo para preventivo

Uma característica das organizações que ainda operam no modo reativo é que a conversa sobre segurança com o board acontece depois do incidente. O conselho conhece o problema quando ele já virou crise.

Esse modelo tem um custo que vai além do incidente em si. Decisões tomadas em contexto de crise são mais caras, menos criteriosas e carregam pressa que compromete a qualidade da resposta. O board paga duas vezes: pelo impacto do incidente e pela solução apressada.

A alternativa não é apresentar relatórios técnicos mensais. É construir um modelo de risco que permita ao conselho perguntar, proativamente. Como está nossa exposição comparada ao trimestre anterior? Onde está o maior risco residual? O que estamos priorizando e por quê?

Quando o conselho consegue fazer essas perguntas com base em dados, ele passou de reativo para preventivo. E quando o board está fazendo as perguntas certas, o CISO deixou de ser um gerente de infraestrutura. Passou a ser um conselheiro de risco.

Essa é a diferença que uma régua comum faz.

LeanBic Cibersegurança

www.leanbic.com.br