Posso afirmar de que a maioria das conversas sobre risco cibernético começa no lugar errado porque começa “pela máquina”, ou seja pelo inventário de sistemas, pelo diagrama de rede, pelo stack de ferramentas, pela lista de controles, mas quando o que de fato dói no mundo real é “o que a empresa perde” quando a informação deixa de estar disponível, íntegra e confiável, ou confidencial. Esse desalinhamento é sutil, porque quase sempre vem acompanhado de muito trabalho bem-intencionado com times que fazem varreduras, classificam vulnerabilidades, implantam EDR, SIEM, MFA, backups, hardening, e conseguem evidências de conformidade. Só que quando o ponto de partida é tecnológico o risco vira “técnico” antes de virar “significativo” para o negócio. E nesse caminho a empresa frequentemente fica ocupada e aderente a frameworks, sem necessariamente estar no controle do que mais importa.
Quando eu pergunto a um comitê executivo sobre “qual é o ativo mais crítico da empresa?”, as respostas geralmente vêm rápidas e confiantes, em que sempre aparece o ERP, ambiente de produção, plataforma de clientes, rede corporativa. Que são incçusive respostas sensatas, mas incompletas porque descrevem onde as coisas rodam, não o que está em jogo. Em um incidente grave, ninguém perde o sono porque “um servidor caiu” ou porque “uma ferramenta falhou”.
Saiba de que o que realmente tira o sono são consequências concretas, como pedidos que deixam de ser processados, ou números operacionais que deixam de ser confiáveis, ou serviços que precisam ser interrompidos porque a informação foi corrompida, ou dados pessoais expostos que disparam obrigações legais, regulatórias e contratuais, ou demonstrações financeiras questionadas, ou fraude habilitada por integridade comprometida, ou perda de confiança que exige ações de comunicação e remediação sob escrutínio público.
Assim diria de que em termos de gestão de risco, o evento técnico é o mecanismo, mas o dano é informacional e operacional, em que os incidentes cibernéticos machucam porque dados ficam indisponíveis, não confiáveis, ou expostos, e mesmo assim os “dados” quase nunca é o ponto de partida do desenho de risco cibernético.
O modelo dominante ainda é “bottom-up técnico”, em que se inventaria a tecnologia, se levantam as ameaças e vulnerabilidades, se implementam os controles porque um requisito de framework, auditoria ou regulação pede, e só depois se tenta traduzir tudo isso em impacto para a empresa.
Vejam de que o problema não é negligência, mas é herança de como segurança foi construída por décadas. O problema é a ordem. Quando o risco se torna técnico antes de se tornar significativo, três sintomas aparecem ao mesmo tempo, em que a matriz de riscos enche de cenários de ataque, mas permanece vaga sobre consequências, ou ainda de que os controles são aplicados de forma relativamente homogênea em que se “protege tudo quase igual”, isto em vez de proporcionalmente ao que faria mais estrago se falhasse, e a discussão de severidade durante incidentes vira debate subjetivo e demorado, porque falta um referencial estável de “o que mais importa” para orientar priorização, recuperação e reporte. O resultado é uma empresa que consegue produzir evidência de esforço e conformidade, mas que ainda não consegue responder com consistência à pergunta essencial do conselho sobre “se isso acontecer, o que realmente nos machuca e por quê?”.
É aqui que o framework do NIS2 de forma silenciosa, empurra a conversa para o lugar certo, em que ele não é na essência um pedido por “mais ferramentas”, mas é um deslocamento de accountability. Em que a lógica é clara de que a gestão precisa demonstrar entendimento sobre serviços críticos, dependências e impacto, e isso não pode ser terceirizado para TI, nem reduzido a output de ferramenta. Além disso o NIS2 impõe janelas de tempo que forçam decisões sob pressão, como um “early warning” em até 24 horas do momento em que a empresa toma ciência de um incidente significativo e notificação mais detalhada em até 72 horas, com relatório final em até um mês. Esse relógio regulatório expõe um desconforto, de que se a empresa não consegue articular com clareza quais domínios de dados sustentam seu funcionamento com continuidade operacional, obrigações legais, estabilidade financeira, confiança, ela também não consegue de modo consistente articular quais riscos merecem prioridade. E quando o referencial falta, a responsabilidade “embaça”, e ai como sabem bem tudo vira “prioritário”, e as decisões viram disputa de narrativas técnicas, e o conselho perde capacidade de governar.
Um experimento mental costuma fazer o conselho “enxergar” isso imediatamente, é de imaginar um incidente grande, e você recebe uma condição dura, de que em quatro horas você só consegue restaurar uma coisa por completo. Não um sistema, não um aplicativo, mas um conjunto de informações. Todo o resto levará muito mais tempo. O que você escolhe? Pedidos de clientes? Dados de planejamento operacional? Registros médicos? Informações de reporte financeiro?
Diria de que quase toda liderança responde rapidamente. E então vem a segunda realização, mais incômoda, de que a gestão de risco cibernético dentro da empresa raramente começa dessa resposta. Esse momento não é “falha” do time, mas é sinal de que o modelo colocou o holofote na camada errada com um sistemas antes de dados, com componentes antes de consequência, com controles antes de referência de impacto.
A partir daí o que muda quando se começa a conversa por dados?
Em geral alguém reage de que “isso é governança de dados e vai nos deixar lentos”. A objeção é legítima, porque muitos programas de dados viraram iniciativas grandes, amplas, com catalogação extensa e burocracia sem efeito proporcional na tomada de decisão. Só que aqui existe uma confusão entre dois objetivos diferentes. Em que a governança de dados no sentido amplo, busca elevar qualidade, consistência, ownership e ciclo de vida de dados em toda a empresa. Já gestão de risco aplicada a cibernético, pergunta algo mais estreito e pragmático sobre quais informações, se ficarem indisponíveis, não confiáveis ou expostas, causam dano material para a empresa? Essa pergunta não exige catalogar tudo, mas exige identificar poucos domínios de dados que realmente movem continuidade, obrigações regulatórias e legais, estabilidade financeira e confiança. Na prática esse conjunto costuma ser menor do que as pessoas imaginam. O gargalo não é volume, mas é clareza.
Quando a empresa inverte deliberadamente o modelo e começa por “dados críticos” e seus usos, quatro mudanças acontecem, e elas são bem práticas, não filosóficas.
A primeira é que a conversa fica concreta de que em vez de “sistema crítico”, se fala de pedidos, faturamento, conciliação, cadastro e autenticação, dados de risco e fraude, dados de liquidez e tesouraria, logs que sustentam investigação e reporte, dados pessoais sob LGPD, dados de reporte contábil e regulatório. A tecnologia vira contexto sobre quais aplicações, integrações, fornecedores e infra suportam esses domínios. Isso reduz ruído e melhora foco, porque o assunto passa a ser consequência e não componente.
A segunda mudança é que a priorização fica defensável. Com consenso sobre quais domínios informacionais são mais sensíveis por impacto, fica muito mais simples justificar por que certos serviços têm nível de proteção e monitoramento superior, por que certos cenários são classificados como severos, e por que determinados riscos residuais são conscientemente aceitos com apetite a risco explícito, em vez de aceitos por inércia. A decisão deixa de parecer arbitrária porque passa a ter âncora no impacto do negócio.
A terceira mudança é que accountability clareia. Dados têm significado de negócio e portanto têm dono no nível gerencial adequado. Quando esse ownership é explícito, discussões sobre aceitação de risco, priorização de remediação e trade-offs, como por exemplo uma indisponibilidade x contenção, interrupção x propagação, custo x tempo de recuperação, sobem para o nível correto, em vez de ficarem “absorvidas” por TI e segurança como se fossem apenas escolhas técnicas. Isso é governança de colocar decisão onde existe mandato e responsabilidade pelo impacto.
A quarta mudança, que parece contraintuitiva, é que a complexidade frequentemente diminui. Quando tudo é “ativo crítico”, nada é crítico de verdade, e a empresa tenta proteger tudo igualmente, desperdiçando energia e ainda assim deixando lacunas onde realmente importava. Ao focar no que dói, o esforço concentra onde falha seria mais destrutiva, e controles, testes, exercícios e capacidade de resposta passam a ser proporcionais. A empresa deixa de ser pesada; passa a ser deliberada.
Esse deslocamento de ponto de partida também torna os frameworls do NIS2 e ISO 27001 mais administráveis no que interessa ao conselho: controle e responsabilidade, não perfeição. A ISO 27001 define requisitos para um Sistema de Gestão de Segurança da Informação (SGSI/ISMS) baseado em risco, ou seja um mecanismo gerencial contínuo para selecionar e manter controles de forma consistente e justificável. O que costuma travar programas de ISO não é falta de controle técnico, mas falta de racional claro de priorização: por que isso é “alto risco” aqui e “médio risco” ali? A resposta “data-first” resolve essa justificativa de maneira natural: você explica criticidade por consequência e por dependência informacional, e então conecta os controles como instrumentos, não como ponto de partida. Quando auditor ou regulador perguntam por que um risco foi priorizado, por que um serviço foi classificado como crítico, ou por que determinado risco residual foi aceito, uma explicação ancorada em impacto informacional é invariavelmente mais coerente do que uma justificativa puramente técnica.
Onde isso fica imediatamente tangível é durante incidentes, que é exatamente quando a governança é testada de verdade. Sob NIS2 a empresa precisa avaliar impacto e decidir reporte com prazos curtos de 24h/72h, e com informação incompleta. Se a gestão já definiu previamente quais domínios de dados são críticos e o que significa, em termos de negócio, sua indisponibilidade, corrupção ou exposição, a classificação de severidade vira mais rápida e consistente. A decisão de notificar deixa de ser improviso e passa a ser aplicação de critérios previamente governados. A comunicação com autoridades, clientes e partes afetadas fica mais clara porque o framing do impacto já existia antes do relógio começar a correr. E aqui há um ponto de maturidade que eu considero relevante de que a resposta a incidente não deveria “provar” que há processo, mas existe porque incidentes vão acontecer. A pergunta relevante para a alta liderança não é “se”, é “quando”. Começar por dados é reconhecer que resiliência é testada sob pressão, e que a preparação real se demonstra muito antes do primeiro deadline regulatório.
Em termos práticos a virada “data-first” pode ser entendida como a criação de um referencial simples e governável para todo o ciclo, com a identificação sobre o que é crítico, a avaliação sobre o que acontece se falhar, o tratamento sobre o que fazer para reduzir probabilidade e impacto, o monitoramento sobre o que observar como sinais de deterioração, e a resposta sobre o que priorizar restaurar e o que comunicar.
Vejam de que não elimina inventário de ativos, gestão de vulnerabilidades ou controles e nada disso, mas apenas reposiciona esses elementos como meios. E isso muda o tom da conversa no conselho que sai o “estamos compliance?” e entra o “nós realmente entendemos o que mais nos machuca, e estamos protegendo isso de forma proporcional?”. Esse deslocamento é na prática a linha que separa uma empresa “ocupada com controles” de uma empresa “no controle”.
Se eu tivesse que resumir tudo isto em uma frase seria esta, de que mudar o ponto de partida da conversa de risco cibernético não exige burocracia, mas exige clareza sobre o que realmente importa. Quando essa clareza existe, sistemas, controles e processos “se encaixam” com muito mais naturalidade, e a governança deixa de ser um exercício de inventário para se tornar disciplina de decisão.
