SAP GRC: por que sua matriz de SoD vira papel morto em 6 meses
Tags: SAP, GRC, Governança, Segurança
Título: SAP GRC: por que sua matriz de SoD vira papel morto em 6 meses
A maior parte das empresas que implementa SAP GRC vive o mesmo ciclo. Compra a licença, contrata o projeto, gera relatórios bonitos no go-live e, em seis meses, descobre que a matriz de segregação de funções virou papel morto.
Os auditores apontam exceções, os gestores reclamam que o sistema trava a operação e o time de segurança vira o vilão da empresa. Já vi esse filme em mineração, varejo, indústria farmacêutica e bancos. A causa raiz quase nunca é a ferramenta.
GRC é um modelo de governança, não um projeto técnico
O problema começa antes do GRC. A empresa olha Access Control, Process Control e Risk Management como três produtos isolados, tratando cada um como um projeto técnico de configuração.
A organização esquece que GRC é, antes de tudo, um modelo de governança que precisa de dono executivo, processo desenhado e cadência de revisão. Sem isso, a ferramenta vira mais um sistema legado na paisagem SAP, alimentado por exceção e ignorado por padrão.
A dor que vejo nas empresas brasileiras é específica. A auditoria interna aponta riscos de SoD que ninguém entende como tratar. O time de SAP empilha 200, 400, às vezes mais de mil conflitos por usuário e fica paralisado.
Os mitigating controls são copiados de templates genéricos sem aderência ao processo real. Quando chega a auditoria externa, a resposta é sempre a mesma: vamos remediar nas próximas semanas. Só que essas semanas viram meses, e os meses viram anos. O resultado é um GRC implementado tecnicamente e fracassado operacionalmente.
A real função de cada módulo GRC
A primeira coisa que precisa mudar é a leitura do que é o GRC. Access Control não é uma ferramenta para gerar relatório de risco. É uma plataforma para tomar decisão sobre quem acessa o quê, em qual sistema, com qual finalidade.
Process Control não é um checklist automatizado. É a evidência viva de que o controle interno está funcionando. Risk Management não é um mapa de calor para apresentar no comitê. É um instrumento de priorização do que vale a pena tratar primeiro.
Quando trato GRC com um cliente, começo pelo desenho do processo de gestão de acesso fim a fim. Quem aprova, com qual critério, em qual prazo, com qual evidência. Antes de configurar um workflow no ARQ, preciso saber se o gestor de área tem clareza sobre o que está aprovando.
A maioria não tem. Aprova por inércia, baseado em template de um cargo antecessor. Quando a auditoria pergunta o porquê, ninguém sabe responder. Esse é o ponto onde a matriz de SoD começa a virar papel morto.
Remediação e o uso indevido de firefighters
Empresas falam em remediar 800 conflitos como se fosse uma planilha do Excel. Não é. Cada conflito tem origem, contexto e impacto operacional. Remediar de verdade exige redesenho de papel, mudança de processo e treinamento de usuário. Em alguns casos, exige contratação adicional.
Quando você pula essa parte e só aplica um mitigating control genérico, o conflito volta na próxima auditoria com o mesmo número. A diferença é que agora ele tem um histórico de exceção aprovada por anos seguidos. Isso não é controle, é teatro de governança.
Existe também o tema dos firefighters, ou EAM. Vejo empresas onde o usuário Firefighter é usado todo dia, por dezenas de pessoas, sem revisão de log. O propósito original do EAM é o uso emergencial, com justificativa, com evidência e com revisão posterior.
Quando o uso emergencial vira rotina, o controle deixa de existir. E quando a auditoria pergunta o motivo, a resposta tradicional é que o sistema não permite outra forma de operar. Quase sempre permite. O que falta é o redesenho de papéis e funções.
As complexidades do GRC no Brasil
No Brasil, a complexidade aumenta com a estrutura de holdings e múltiplas empresas. Cada empresa do grupo costuma ter seu próprio plano de contas, suas próprias regras fiscais e seus próprios compliances setoriais.
A matriz de SoD precisa ser desenhada com sensibilidade contextual. Replicar a matriz de uma empresa de bens de consumo em uma empresa de mineração simplesmente não funciona. O risco operacional é diferente, o impacto regulatório é diferente e o apetite a risco do board é diferente. Um GRC bem implementado respeita isso.
Outro tema sensível é a integração entre o GRC e o resto do ecossistema SAP. O Access Control precisa conversar com o SuccessFactors para a gestão de identidade. O Process Control precisa coletar evidências do S/4HANA, Ariba e EWM, sem que o time de cada módulo precise gerar relatórios manuais.
O Risk Management precisa receber dados de eventos reais do negócio, não apenas uma avaliação subjetiva trimestral. Quando essa integração é tratada como um acessório, o GRC vira uma ilha. E uma ilha não governa.
Três decisões para um GRC funcional
O caminho que tem funcionado nos meus projetos passa por três decisões que precisam ser tomadas no início. Primeiro, definir um sponsor executivo com mandato real, geralmente o CFO ou o diretor de auditoria interna, que responda por governança e tenha autoridade para mover o time funcional.
Segundo, tratar SoD como um esporte contínuo, com cadência mensal de revisão e uma meta clara de redução de conflitos por trimestre.
Terceiro, integrar a operação de gestão de acessos ao ciclo de vida do funcionário, do onboarding ao desligamento, sem deixar gaps que gerem riscos para a companhia.
Quando esses três pontos estão no lugar, o GRC sai do papel e vira um instrumento de decisão. A matriz de SoD passa a refletir a realidade operacional da empresa. Os mitigating controls ganham aderência aos processos. Os firefighters voltam a ser exceção, não rotina. A auditoria passa de adversário para parceiro de melhoria. E o investimento em GRC, que muita empresa enxerga como custo regulatório, começa a gerar valor mensurável.
GRC é cultura, não apenas tecnologia
GRC não é um projeto técnico. É um projeto de cultura, com um viabilizador tecnológico. Quem trata como o contrário paga caro, geralmente em multas, em retrabalho e na perda de confiança do board.
E paga em ciclo. Porque quando o GRC fracassa, a primeira reação é sempre a mesma: trocar a ferramenta. O ciclo então recomeça, com um novo logo no slide, mas com o mesmo problema de governança por baixo.