GRC em OT: Governança, Risco e Conformidade

Em ambientes industriais, cibersegurança não é apenas uma questão de implementar controles técnicos.

É também uma questão de decidir quais riscos a organização pode aceitar, quais precisam ser tratados primeiro, quem responde por essas decisões e como demonstrar que os controles realmente funcionam.

É nesse contexto que Governança, Risco e Conformidade, o GRC, ganha importância para ambientes de Tecnologia Operacional.

Em 2026, essa discussão se tornou ainda mais relevante. A segurança OT avançou para a alta liderança, enquanto organizações continuam enfrentando desafios relacionados a visibilidade, segmentação, acesso remoto, resposta a incidentes e arquitetura de segurança. O relatório State of Operational Technology and Cybersecurity 2026, baseado em mais de 700 profissionais de OT, aponta justamente esse movimento de amadurecimento e maior participação de CISOs e CSOs na responsabilidade sobre OT.

Por isso, GRC não deveria ser visto como uma camada burocrática ao redor da segurança.

Em OT, GRC precisa transformar risco técnico em decisão operacional e empresarial.

Governança Define Quem Decide sobre o Risco

Uma das principais mudanças que eu faria no artigo original é ampliar o significado de governança.

Governança não significa apenas criar políticas e garantir que sejam cumpridas.

Significa estabelecer responsabilidades, autoridade para tomada de decisão, critérios de priorização, tolerância a risco e mecanismos de acompanhamento.

Essa visão ganhou força com o NIST Cybersecurity Framework 2.0.

Ao atualizar o CSF, o NIST criou uma sexta função específica: Govern. O objetivo foi dar maior visibilidade à governança e aproximar cibersegurança da gestão de riscos empresariais e das obrigações legais e regulatórias.

Para OT, isso é particularmente importante.

Quando uma vulnerabilidade é descoberta em um equipamento crítico, por exemplo, a decisão não pode considerar apenas sua severidade técnica.

É necessário entender:

Qual função operacional depende daquele ativo?

Existe exploração conhecida?

O ativo está exposto?

Existe uma janela segura para atualização?

Há controles compensatórios?

Qual seria a consequência de uma indisponibilidade?

Quem possui autoridade para aceitar temporariamente esse risco?

É aí que governança deixa de ser documentação e passa a orientar decisões reais.

Risco em OT Precisa Considerar Consequência Operacional

O artigo original tratava gerenciamento de risco principalmente como identificação de vulnerabilidades e prevenção de ataques.

Em 2026, essa abordagem é limitada.

Uma vulnerabilidade técnica não representa automaticamente um risco crítico.

O risco depende também da exposição do ativo, das ameaças relevantes, dos controles existentes, das dependências e, principalmente, das consequências que um comprometimento pode gerar para a operação.

Isso é particularmente importante porque ambientes OT lidam com consequências que podem ultrapassar perda ou exposição de dados.

Um incidente pode afetar produção, disponibilidade, qualidade, segurança física, equipamentos, meio ambiente e continuidade de serviços essenciais.

Por isso, a pergunta não deveria ser simplesmente:

“Qual é a vulnerabilidade mais grave?”

Mas:

“Qual cenário representa maior risco para nossa operação?”

Essa mudança de perspectiva também aparece nas análises mais recentes sobre OT. A Dragos defende que informações sobre ameaças e vulnerabilidades precisam resultar em uma resposta prática: o que deve ser priorizado agora para reduzir risco operacional?

Nem Todo Risco Precisa Ser Tratado da Mesma Forma

Essa é outra mudança importante em relação ao texto original.

GRC precisa ajudar a organização a priorizar.

O relatório OT Cybersecurity Year in Review 2026 da Dragos mostrou que apenas uma pequena parcela das vulnerabilidades relevantes para ICS analisadas exigia ação imediata. A análise também encontrou problemas nas informações disponíveis para orientar decisões: 25% das vulnerabilidades de ICS-CERT e NVD avaliadas apresentavam pontuações CVSS incorretas e 26% dos advisories não forneciam patch ou mitigação do fabricante.

Isso demonstra por que GRC não pode se transformar em uma corrida para “resolver tudo”.

A organização precisa conseguir combinar informações técnicas com contexto operacional para definir prioridades.

Uma decisão pode resultar em diferentes tratamentos:

mitigar, corrigir, transferir, evitar ou aceitar temporariamente o risco.

Quando um patch não pode ser aplicado imediatamente, por exemplo, segmentação, restrição de acesso, monitoramento adicional ou outros controles compensatórios podem reduzir a exposição até uma janela de manutenção apropriada.

O importante é que a decisão seja consciente, documentada, atribuída a um responsável e revisada quando o contexto mudar.

O Registro de Riscos Precisa Ser Vivo

Aqui eu incluiria um elemento que praticamente não aparece no artigo original.

Um programa de GRC em OT precisa transformar avaliações em algo gerenciável.

O registro de riscos não deveria funcionar como uma planilha criada para uma auditoria e esquecida depois.

Ele precisa conectar, quando aplicável:

cenário de risco → ativo ou função crítica → ameaça → vulnerabilidade ou exposição → controles existentes → consequência operacional → responsável → tratamento → risco residual → prazo → status.

Isso permite que liderança, Segurança, IT, Engenharia e Operações discutam o mesmo risco a partir de uma referência comum.

E o registro precisa mudar quando o ambiente muda.

Uma nova vulnerabilidade explorada ativamente, uma alteração de arquitetura, um novo acesso remoto, uma aquisição, uma mudança de fornecedor ou a descoberta de uma nova dependência pode alterar significativamente um risco anteriormente considerado aceitável.

GRC precisa acompanhar a operação, não apenas a auditoria.

Conformidade Não É Sinônimo de Segurança

Essa talvez seja uma das correções mais importantes no texto original.

Ele afirma que seguir a IEC 62443 “garante conformidade” e eleva o nível de segurança.

Eu evitaria essa relação automática.

A série ISA/IEC 62443 continua sendo uma referência fundamental para a cibersegurança de sistemas de automação e controle industrial, estabelecendo requisitos e responsabilidades ao longo do ciclo de vida.

Sua relevância continua crescendo. Em agosto de 2026, ISA e Operational Technology Cybersecurity Coalition anunciaram uma colaboração para estimular justamente a adoção e implementação prática de fundamentos de segurança OT, incluindo a ISA/IEC 62443.

Mas estar em conformidade com determinado requisito não significa automaticamente que o risco da organização esteja adequadamente controlado.

Uma organização pode possuir políticas documentadas e ainda ter caminhos inadequados entre IT e OT.

Pode realizar avaliações periódicas e ainda não possuir visibilidade suficiente sobre seus ativos.

Pode cumprir determinados controles e continuar sem saber como reagir diante de uma anomalia operacional.

Os dados de 2026 ajudam a mostrar essa diferença: em avaliações realizadas pela Dragos, 81% apresentaram problemas de segmentação IT/OT, enquanto apenas 46% possuíam monitoramento adequado da rede OT.

Portanto, conformidade deve servir como referência e evidência, não como substituto para análise de risco.

Evidência Importa Tanto Quanto a Política

Outra evolução que eu acrescentaria ao artigo é a diferença entre definir um controle e comprovar que ele funciona.

Uma política pode dizer que acessos remotos precisam ser controlados.

Mas:

Quantos acessos existem?

Quem pode utilizá-los?

Há contas compartilhadas?

Os privilégios continuam adequados?

As sessões são registradas?

Contas de antigos fornecedores foram desativadas?

Existe um caminho desse acesso até ativos críticos?

Governança precisa transformar políticas em controles verificáveis.

Isso também vale para segmentação, backups, gestão de vulnerabilidades, resposta a incidentes, contas privilegiadas e outras capacidades.

Um controle documentado não é necessariamente um controle efetivo.

Indicadores Precisam Mostrar Risco, Não Apenas Atividade

GRC também costuma produzir muitos indicadores.

Quantidade de vulnerabilidades.

Número de treinamentos.

Percentual de patches.

Quantidade de incidentes.

Número de auditorias realizadas.

Esses dados podem ser úteis, mas isoladamente dizem pouco sobre o risco operacional.

Uma organização pode reduzir o número total de vulnerabilidades e ainda manter uma vulnerabilidade explorável em um ativo crítico.

Pode atingir 100% de treinamento e continuar sem saber quem toma determinadas decisões durante um incidente.

Pode aumentar o número de controles e ainda manter caminhos de ataque importantes.

Por isso, indicadores de GRC deveriam ajudar a responder perguntas como:

Quais funções críticas permanecem mais expostas?

Quais riscos estão acima da tolerância definida?

Quantos riscos críticos continuam sem tratamento?

Quais controles essenciais não estão funcionando como esperado?

Quais dependências podem ampliar o impacto de um incidente?

O objetivo não é demonstrar que a equipe de segurança está ocupada.

É demonstrar se o risco está sendo reduzido.

Threat Intelligence Precisa Entrar no Processo de Risco

O artigo original estava correto ao mencionar Threat Intelligence, mas eu mudaria seu papel.

Threat Intelligence não deve existir apenas para “antecipar ataques”.

Ela precisa ajudar a organização a atualizar suas decisões.

Em 2026, adversários acompanhados pela Dragos avançaram do reconhecimento para atividades de mapeamento de control loops e compreensão dos processos físicos. Três novos grupos de ameaças OT foram identificados no relatório anual.

Se uma organização descobre que determinado adversário está explorando uma tecnologia presente em sua própria arquitetura, isso pode alterar imediatamente a prioridade de um risco.

Da mesma forma, informações sobre vulnerabilidades exploradas, técnicas utilizadas por adversários e setores atacados podem modificar avaliações anteriores.

Assim, Threat Intelligence passa a alimentar continuamente o GRC:

ameaça → exposição → ativo → função crítica → consequência → risco → decisão.

Terceiros Também Fazem Parte da Governança

Eu acrescentaria ainda risco de terceiros e cadeia de suprimentos.

Fabricantes, integradores, prestadores de manutenção, fornecedores de software e equipes externas podem possuir acessos ou responsabilidades importantes dentro do ambiente industrial.

Portanto, GRC em OT precisa definir também como esses relacionamentos são governados.

Isso envolve critérios de aquisição, requisitos contratuais, controle de acesso remoto, responsabilidades sobre vulnerabilidades, comunicação de incidentes, suporte durante o ciclo de vida e procedimentos de encerramento do relacionamento.

O risco não termina na fronteira jurídica da empresa.

Se um terceiro possui um caminho até a operação, ele também faz parte do modelo de risco da operação.

Treinamento Precisa Evoluir para Preparação

Eu reduziria bastante a seção genérica sobre conscientização.

Em OT, não basta afirmar que “todos precisam conhecer boas práticas”.

Pessoas diferentes tomam decisões diferentes.

Um operador precisa reconhecer quando um comportamento anormal do processo pode ter origem cibernética.

Uma equipe de engenharia precisa entender como mudanças podem alterar exposição e risco.

Segurança precisa compreender consequências operacionais antes de recomendar determinadas ações.

Lideranças precisam saber quando aceitar risco e quando exigir tratamento.

E equipes de resposta precisam conseguir trabalhar com Operações durante um incidente.

Os dados de 2026 mostram por que isso importa. Em 30% dos casos de resposta a incidentes analisados pela Dragos, a investigação começou com problemas operacionais sem explicação clara. Além disso, 82% das organizações avaliadas não tinham critérios claros para determinar quando uma anomalia operacional deveria iniciar uma investigação cibernética.

Isso vai muito além de conscientização.

É preparação operacional.

GRC Precisa Conectar Segurança à Operação

Um programa maduro de GRC em OT não deveria existir isoladamente dentro da área de cibersegurança.

Ele precisa conectar diferentes perspectivas.

Segurança entende ameaças e controles.

IT conhece parte importante da infraestrutura tecnológica.

Engenharia conhece arquitetura e processo.

Operações entende consequências e prioridades de produção.

Jurídico e Compliance acompanham obrigações.

Compras e Suprimentos influenciam riscos introduzidos por fornecedores.

E a liderança define prioridades e tolerância ao risco.

O crescimento da participação executiva na segurança OT reforça essa mudança. O estudo da Fortinet de 2026 mostra que a responsabilidade sobre OT está cada vez mais migrando para estruturas lideradas por CISO e CSO.

A governança precisa garantir que essas áreas não tomem decisões isoladas sobre o mesmo risco.

De GRC Burocrático para Governança de Risco Operacional

A maior evolução para 2026 é justamente essa.

GRC não deveria ser medido pela quantidade de políticas, auditorias, controles ou relatórios produzidos.

Seu valor aparece quando a organização consegue responder:

Quais são nossos principais riscos OT?

Quais funções críticas eles podem afetar?

Quais riscos estão acima da nossa tolerância?

Quem é responsável por cada decisão?

Quais controles realmente reduzem esses riscos?

Quais riscos estamos aceitando e por quê?

Para a Cyrex Security, GRC em ambientes industriais precisa transformar informações técnicas em decisões que façam sentido para o negócio e para a operação.

Porque a pergunta mais importante não é:

“Estamos em conformidade?”

É:

“Sabemos quais riscos podem comprometer nossa operação e estamos tomando as decisões certas sobre eles?”