Antes de criarmos nossa primeira política, eu gostaria de discutir um pouco mais em detalhes o G — Governança.
A razão disso é que, sem esse primeiro passo, qualquer projeto de GRC vai morrer em sua concepção. Se a sua diretoria executiva (caso você seja um diretor, isso também vale) não comprar a ideia, infelizmente nenhuma ação de riscos ou de compliance será executada da forma correta. Tudo inicia no G.
Mas, por que isso importa?
Isso significa, na prática, que tudo começa com a governança e você precisa de um apoio muito robusto para continuar com o projeto. Nós chamamos isso de Sponsor (patrocinador). Ou seja, alguém com poder de alta decisão, como diretores, CEOs, CISOs, precisa patrocinar o processo de GRC como um todo, incluindo, mas não limitado, à parte financeira e recursos (como o tempo dos colaboradores).
Tanto se você é um sponsor ou um técnico, não importa: esse post vai trazer insights importantes para os dois lados. Ambos são fundamentais ao processo, praticamente não existe um sem o outro, e a atuação correta dos dois lados é a única forma de garantir que tudo vai funcionar. Não existem empecilhos aqui, apenas aliados a um mesmo objetivo.
Eu quero que você entenda isso de forma clara, pois a grande maioria dos processos de GRC surge no formato incorreto. Eles só aparecem de forma REATIVA, quando uma auditoria surge, um cliente solicita um compliance específico ou, no pior dos casos, um incidente cibernético (que pode causar os outros dois).
O problema do processo reativo é que ele funciona como um band-aid correndo atrás do próximo “machucado”. O GRC deixa de pensar como um processo completo e estruturado e passa a correr atrás da próxima correção e da próxima correção… Se você já teve contato com programação, isso é muito comum, você lança a próxima atualização atrás da próxima atualização, mas nunca pensa no código como um todo. No final, só existe um resultado: você vai quebrar.
Normalmente porque o seu processo está totalmente inviável de manter, as documentações começam a te afogar e fica impossível entender o que você tem, o que não tem e o que falta. Também complica muito a apresentação de dados. Pergunte-se o seguinte:
“Se eu precisar entregar um relatório completo de tudo o que eu tenho, como foi implementado, evidências disso, quais os controles geradores e qual a porcentagem de compliance com frameworks de mercado, eu conseguiria fazer isso em menos de 1 dia?”
Um projeto bem estruturado nunca sofre com falta de dados (normalmente é o oposto, na verdade), já que você pensou em todos os pontos e em como eles se conversam.
Os primeiros e principais sintomas de um processo falho são:
- A falta de autoridade: O GRC perde a autoridade de definir regras e processos para as outras áreas. Então, as suas definições de boas práticas não são implementadas, e eles simplesmente ignoram.
- Visão de negócio: Um GRC limitado (e aqui eu estou me referindo principalmente ao de cibersegurança) normalmente tem uma grande atuação da área de TI. É claro que o próximo passo é a evolução para uma área completa de segurança, mas isso não é o caso na maioria das vezes. O detalhe aqui é que se a TI (ou responsável pelo GRC) não tem uma visão do negócio como um todo, de todos os processos, áreas e dados, é impossível definir o que é crítico, o que tem que ser melhorado e o que precisa alterar para se adaptar ao compliance.
- A bagunça: Esse parece simples, mas muitas vezes nem notamos que estamos entrando em um buraco negro de políticas e processos sem sentido. Você com toda certeza vai perceber que ninguém sabe onde ficam os documentos, onde estão as evidências e o que precisamos para cumprir cada item.
Mas uma coisa eu quero deixar bem claro. Nada disso é fatal! Na verdade, notar esses problemas é uma coisa boa, já que você pode mudar isso. Mudando o processo de GRC é possível alterar qualquer erro.
O detalhe é que voltamos no início desse texto… a sua diretoria entende isso dessa forma também?
Se a resposta for “SIM”, é o melhor dos mundos, é claro, você já tem a percepção e a autorização para mudar e melhorar esse processo.
Mas se a resposta for “NÃO”, não adianta tentar mudar tudo, você vai ser barrado. Então, é hora de preparar uma boa apresentação executiva e explicar em detalhes a razão dessa mudança ser tão importante.
A parte que me deixa mais animado com isso tudo é que estamos vendo cada vez mais que as empresas como um todo estão percebendo a validade de tudo isso e estão “comprando a briga” para que os processos se tornem robustos e muito bem definidos. Isso é uma ótima notícia para a segurança cibernética.
O que é isso afinal?
O papel do sponsor é atuar próximo, mas não como “dono” do processo de GRC, isso ainda cabe à equipe mais técnica (não de TI necessariamente). Mas ele vai atuar em diversos níveis. Vamos entender os principais:
- Suporte Ativo e Visível: O sponsor deve comunicar para toda a empresa que “isto é uma prioridade”.
- Provisão de Recursos: Garantir o orçamento e, mais importante, o tempo das pessoas de diferentes áreas para participarem do processo.
- Tomada de Decisão: Ser o “árbitro” final. Quando a área de vendas disser que um controle de segurança atrapalha o fechamento de um negócio, é o patrocinador quem bate o martelo, com base na estratégia da empresa.
E veja que aquela visão de “negócio” que comentamos anteriormente é muito apoiada pelo sponsor, e sem ele a política vai morrer na primeira resistência de um departamento. E entenda que essa resistência é super comum, a segurança sempre foi uma inimiga do conforto, infelizmente.
Imagine que trancar a sua casa todos os dias é chato. É muito mais fácil só não trancar nada e entrar e sair quando precisar, mas ninguém faz isso, nós sabemos as implicações de segurança disso. Infelizmente, essa mentalidade às vezes é ignorada para a cibersegurança.
Ninguém gosta de rotacionar as senhas a cada 45 dias, isso é um fato, nem eu gosto. Mas o ponto chave aqui não é sobre o que fazer ou não, é explicar a razão disso. Seus pais provavelmente explicaram para você a razão de trancar as portas ao sair logo cedo, precisamos fazer a mesma coisa para cada item do GRC. Não é sobre tentar convencer que não é um inconveniente (porque é), é sobre explicar a razão desse inconveniente ser fundamental e necessário para todos.
Mas existe um item muito importante que apenas a governança pode definir, e que não falamos anteriormente, algo que chamamos de Apetite ao Risco, e a importância desse item é gigantesca antes mesmo de iniciar qualquer processo de GRC. O Apetite ao Risco é uma diretriz e gera, muitas vezes, um documento chamado RAS (Risk Appetite Statement).
Digamos que você queira corrigir o maior número de riscos possíveis dentro da organização, isso pode ser quase impossível. A chance de alguém sofrer um ataque de engenharia social pode ser baixa, mas nunca é zero. A única forma de deixar um risco em zero é eliminar ele completamente.
Quer eliminar o risco de engenharia social? Não tenha nenhum funcionário, nem mesmo você.
Isso não faz o menor sentido, claro que nós não vamos buscar nunca o zero, a ideia é ficar o mais próximo disso. Mas o que define que estamos “próximo o suficiente” para aceitar o risco? O Apetite ao Risco!
A criação dessa diretriz é justamente para isso: definir o “próximo o suficiente”. Dessa forma, sabemos que onde o risco está no presente momento é até onde nós vamos atuar.
Imagine o seguinte: se você tem uma empresa ou trabalha em uma startup focada na inovação tecnológica, provavelmente o seu apetite ao risco vai ser maior que o de uma instituição de saúde. A razão está no modelo de cada empresa, uma visa adotar novas tecnologias e melhorar o mais rápido possível, a outra foca em segurança dos dados e estabilidade (continuidade).
Veja que o apetite ao risco pode mudar drasticamente entre o mais conservador possível (sem mirar nos zeros, é claro, isso é impossível) e o mais aberto possível, onde os riscos quase não são tratados.
Para ser sincero, normalmente você vai desejar ficar no espectro central, de não muito e não pouco, mas mesmo assim alterar para qual lado você tendenciona de acordo com o seu mercado, produto, clientes e objetivos empresariais.
Como isso funciona na prática?
Como eu comentei anteriormente, o processo começa com o G (governança). Antes de iniciar qualquer coisa, é 100% necessário que a diretoria, C-Levels e toda a alta gestão estejam alinhados e com a ideia do que isso pode gerar. Mas a prática vai além de uma reunião de “ok, pode fazer”.
Para que o GRC funcione e você não se torne o “chato da segurança” que ninguém ouve, você precisa estabelecer as regras do jogo. E a regra de ouro aqui é definir quem é quem.
Muitos projetos falham porque a equipe de TI/Segurança acha que é dona de todos os riscos da empresa. Isso é um erro brutal.
Vamos separar os papéis:
- O Patrocinador (Sponsor): É quem dá a autoridade e o recurso (dinheiro e tempo). Normalmente é o CEO ou o Conselho.
- O Executor (Equipe de GRC): Tem o papel de identificar o buraco, medir a profundidade, sugerir a escada para sair de lá e monitorar se a escada está firme.
- O Dono do Risco (Risk Owner): O dono do risco não é a TI. O dono do risco de um vazamento de dados do RH… é o diretor de RH. O dono do risco de uma fraude no financeiro… é o CFO e assim por diante.
Por que essa distinção salva a sua vida (e o processo)?
Imagine que você identificou um risco crítico no sistema de vendas. Você sugere implementar Duplo Fator de Autenticação (MFA).
O diretor de Vendas diz:
Não! Isso vai deixar o processo lento e vamos perder vendas. Eu não aceito.
Sem Governança, você iniciaria uma briga até que um dos lados desista.
Com Governança, você documenta o risco, apresenta as consequências e, se o diretor de vendas (o dono do risco) decidir não implementar e aceitar o risco (baseado naquele apetite ao risco que definimos antes), ele assina a responsabilidade.
Isso o torna “parte” fundamental do problema.
Se houver um incidente amanhã, a decisão foi de negócio, amparada pela governança, e não uma “falha da TI”.
Isso tira da equipe de GRC e coloca a responsabilidade onde ela deve estar: na liderança do negócio.
O segredo aqui é dar a maior visibilidade e trazer expertise para auxiliar cada área com o processo, e não resolver o problema por eles.
