Recebi semana passada uma ligação de um CIO de uma empresa industrial em Joinville. Faturamento de R$ 380 milhões, capital aberto há 2 anos, primeira auditoria SOX integral chegando em 90 dias.

A frase dele foi: "Anderson, o CFO me disse que SOX é coisa do financeiro. Acabei de descobrir que 80% dos controles caem aqui na TI. Estou perdido."

Olha, ele não está sozinho.

A maioria das empresas brasileiras de capital aberto descobre tarde demais que a Sarbanes-Oxley Act não é uma norma contábil. É uma norma de controles internos sobre relatórios financeiros — e como praticamente todo relatório financeiro hoje passa por um sistema de TI, a TI virou a espinha dorsal de qualquer programa SOX sério.

Deixa eu ser direto: se você é gestor de TI numa empresa que vai passar por auditoria SOX e nunca ouviu falar em ITGC, você tem um problema. Não daqui a um ano. Tem agora.

Por que TI responde por 80% dos controles SOX

A SOX foi escrita em 2002, depois dos escândalos da Enron e WorldCom. Na época, o foco era contábil. Mas em 20 anos uma coisa mudou completamente: hoje, o lançamento contábil não é mais feito manualmente pelo contador. É feito pelo sistema. Automaticamente. A partir de uma transação que aconteceu três sistemas antes.

Então quando o auditor da Big Four chega na sua empresa querendo testar a integridade de uma demonstração financeira, ele não vai olhar para a planilha do CFO. Ele vai olhar para o ERP. Para o sistema de faturamento. Para o sistema de folha. E vai querer saber se aqueles sistemas são confiáveis.

Confiável, no vocabulário do auditor, significa duas coisas:

Isso é o que os controles gerais de TI — ITGC, IT General Controls — se propõem a garantir.

E aqui vem o número que poucos CIOs sabem: numa auditoria SOX típica, cerca de 80% dos controles testados pelo auditor externo são ITGC ou dependem de ITGC funcionando. O CFO assina o relatório, mas é a TI que sustenta a assinatura.

Já vi CFOs perderem o bônus anual porque um servidor sem patch de segurança levou a ressalva em SOX. Não foi o financeiro que errou. Foi a TI que não tinha disciplina de controles.

Tem outra coisa que esse CIO de Joinville descobriu nas duas semanas seguintes: o nivel de detalhe que o auditor exige nao tem nada a ver com o nivel de detalhe que o pessoal de TI esta acostumado a documentar. Voce pode ter rodado um upgrade de versao do ERP em julho, com mil horas de trabalho do time, e mesmo assim nao ter a evidencia que o auditor quer ver — porque ninguem registrou quem aprovou cada uma das 47 mudancas tecnicas embarcadas no upgrade.

Olha, eu vejo isso o tempo todo. O time de TI faz o trabalho. Faz bem feito. Mas nao tem o habito de produzir evidencia que sobreviva ao escrutinio externo. SOX nao tolera essa lacuna. O auditor parte da premissa de que o que nao foi documentado, nao aconteceu.

E tem uma assimetria curiosa aqui: o custo de produzir a evidencia no momento da execucao e baixo (3-5 minutos por mudanca). O custo de reconstituir depois, quando a auditoria chega, e altissimo (horas, as vezes dias, com risco de virar ressalva por falha de rastreabilidade). E ainda assim, a maioria das empresas escolhe pagar o custo alto. Por inercia, na maioria das vezes.

Os 4 domínios ITGC que o auditor vai examinar

Existem variações entre frameworks (COSO, COBIT, ISACA), mas na prática todo auditor externo trabalha com quatro grandes domínios. Vou te mostrar cada um do jeito que eles aparecem na prática.

1. Gestão de acessos

Quem tem acesso a quê. Como esse acesso foi concedido. Quem aprovou. Se o acesso ainda é necessário. Se houve revisão periódica. Se quem saiu da empresa ainda tem login ativo (sim, isso acontece o tempo todo).

Num cliente de saúde que atendi em 2024, encontrei 47 usuários ativos no ERP que já não trabalhavam na empresa há mais de 6 meses. Três deles eram ex-funcionários demitidos por justa causa. O auditor descobriu isso em 20 minutos.

2. Gestão de mudanças

Quando alguém modifica um programa, um relatório, uma regra de negócio no sistema — como isso é controlado? Tem aprovação prévia? Foi testado em ambiente separado? Quem aprovou a subida para produção? Existe rollback documentado?

O auditor vai pegar uma amostra de mudanças do ano (digamos, 25 alterações) e pedir as evidências de cada uma. Se você não tem, é ressalva.

3. Operações de TI

Backups que funcionam de verdade (e foram testados). Jobs batch que rodaram quando deveriam. Logs que existem e são monitorados. Incidentes que foram tratados e documentados. Capacidade de recuperação de desastre testada nos últimos 12 meses.

4. Segurança lógica e física

Política de senha. MFA onde precisa. Segregação de ambientes. Acesso físico ao data center (se ainda existe). Monitoramento de tentativas de invasão.

Sobre proporcionalidade dos quatro dominios

Uma coisa que poucos consultores explicam: nao e que voce precise implementar profundamente os quatro dominios desde o dia um. O peso de cada dominio depende do perfil de risco da sua empresa. Indústria pesada com chao de fabrica conectado tende a ter risco maior em operacoes de TI e seguranca fisica. Empresa de servicos financeiros tende a concentrar risco em gestao de acessos e mudancas. Empresa de varejo com forte ecommerce tende a sofrer em interfaces, dados mestres e seguranca logica.

O auditor sabe disso. Ele vai aprofundar nos dominios que mais importam pro seu negocio e fazer verificacoes mais superficiais nos demais. Saber pra onde concentrar esforco te economiza dinheiro e tempo.

Na minha experiencia, gestao de acessos consome 40% do esforco inicial de qualquer programa SOX serio. Mudancas consomem outros 25%. Operacoes, 20%. Seguranca, 15%. Esses numeros variam, mas a ordem costuma ser essa.

Antes de receber o auditor, valide seus controles com o checklist ITGC gratuito.

Fazer o Checklist ITGC gratuito →

Quais sistemas entram no escopo SOX

Esse é o ponto onde mais vejo confusão. Nem todo sistema da empresa entra na auditoria SOX. Só os sistemas que tocam — direta ou indiretamente — em demonstrações financeiras materiais.

Na prática, o escopo costuma incluir:

E aqui vem o erro clássico: muita gente esquece dos sistemas satélites. Aquela planilha do controle de estoque que importa dados pro ERP. Aquele middleware que faz a ponte entre o e-commerce e o financeiro. Aquele relatório custom que o controller usa pra fechar o mês.

Tudo isso entra. Tudo isso precisa de controle.

O conceito de materialidade e como ele define o escopo

A palavra que voce mais vai ouvir do auditor e materialidade. Em termos praticos, materialidade e um valor de corte abaixo do qual o auditor nao se importa. Em uma empresa de R$ 500 milhoes de faturamento, a materialidade tipica fica entre R$ 2 e R$ 5 milhoes — qualquer linha do balanco abaixo disso nao gera atencao especial. Acima disso, controle reforcado.

Pra TI isso significa: sistemas que tocam contas materiais sao SOX-relevantes. Sistemas que tocam contas imateriais nao precisam do mesmo rigor (embora boas praticas se apliquem a todos). Saber onde esta a linha te ajuda a priorizar.

Tive um caso de uma empresa de medio porte em que descobrimos que o sistema de gestao de viagem corporativa, que ninguem considerava SOX, na verdade gerava lancamentos contabeis automaticos para uma rubrica que representava 6% do faturamento. Materialidade clara. Sistema entrou no escopo de ultima hora — e exigiu uns 30 dias de trabalho extra pra documentar controles.

Materialidade nao e bom-senso. E numero. Pede pro CFO o calculo formal antes de definir escopo de TI. Se nao tiver, voce esta chutando no escuro.

O que acontece quando a TI não está preparada

Vou te contar três cenários que vi nos últimos 18 meses.

Primeiro: indústria de capital aberto, faturamento R$ 1,2 bi, primeira auditoria SOX integral. O auditor encontrou 14 ressalvas materiais. 11 delas eram ITGC. O CFO foi à Comissão e teve que explicar publicamente. As ações caíram 8% no dia seguinte.

Segundo: empresa de mineração, processo de IPO em andamento. A auditoria pré-IPO travou no quesito controles internos. Atraso de 6 meses no calendário. Custo financeiro estimado em R$ 14 milhões.

Terceiro — esse é o pior. Empresa de varejo, segunda auditoria consecutiva. Ressalvas repetidas. O conselho exigiu a substituição do CIO e da diretoria financeira. Bônus zerados, processo administrativo interno.

Não é dramatização. É o que acontece quando a TI trata SOX como problema do CFO.

O efeito cascata interno apos uma ressalva

Tem um efeito que poucos comentam: ressalva SOX nao morre na divulgacao publica. Ela contamina internamente. Os primeiros a sentir sao o CIO e o CFO. Depois, a auditoria interna passa a ser cobrada mais agressivamente pelo conselho. Depois, o budget de TI vira refem do tema (toda solicitacao precisa virar SOX-relevante pra passar). Depois, o moral do time cai — porque ninguem gosta de virar exemplo negativo no relatorio anual.

Ja vi empresa que levou 2 ciclos completos (4 anos) pra recompor reputacao interna de TI depois de uma ressalva grave. Custo invisivel, mas real.

Por isso o investimento preventivo compensa. Uma boa preparacao custa fracao do que custa carregar uma ressalva.

Como começar antes que a Big Four chegue

Se você ainda não está em ciclo de auditoria SOX e quer se antecipar — ótimo, esse é o momento. Aqui está o que eu recomendo, em ordem:

Mês 1: Faça o inventário dos sistemas no escopo. Não confie no que dizem. Vá nos relatórios financeiros e rastreie a origem de cada número até o sistema-fonte.

Mês 2: Para cada sistema no escopo, mapeie quem tem acesso, com qual perfil, há quanto tempo. Identifique os usuários genéricos, os contas de serviço, os superusuários.

Mês 3: Documente os processos de mudança. Não precisa ter ITIL completo. Precisa ter aprovação por escrito, ambiente de teste, registro do que foi pra produção e quando.

Mês 4: Implemente revisão periódica de acessos. Trimestral é o mínimo. O gestor da área aprova ou remove cada acesso. Por escrito. Com data.

Mês 5-6: Teste seus próprios controles. Faça uma simulação interna. Pegue uma amostra. Se você não conseguir produzir as evidências em 48h, o auditor não vai conseguir.

Esse é o caminho. Não é mágica, não é consultoria de R$ 200 mil. É disciplina e organização.

O que eu vejo nas empresas que passam bem na auditoria SOX não é gente mais inteligente ou orçamento maior. É gente que começou cedo, com método, e tratou a coisa com a seriedade que ela exige.

Quem chega despreparado paga caro. Literalmente.

Veja também

Como Implementar

Como implementar controles SOX em sistemas legados sem parar a operação

Sistemas legados com 15 anos de histórico e sem documentação são o pesadelo de toda auditoria SOX. Veja como criar controles rastreáveis sem reescrever nada.

 Riscos

Os 7 erros que reprovam empresas na auditoria SOX — e como evitá-los

80% das ressalvas em auditorias SOX vêm de 7 erros repetidos. Todos evitáveis. Veja quais são e o que fazer antes que o auditor encontre primeiro.

Perguntas frequentes

O que é SOX na prática para TI?

SOX (Sarbanes-Oxley) é uma lei americana que exige controles internos sobre relatórios financeiros. Para TI, isso significa documentar e auditar quem acessa os sistemas financeiros, como mudanças são aprovadas e se os dados são íntegros. Cerca de 80% dos controles SOX testados por auditores externos são controles de TI (ITGC).

O que são ITGC e por que eles importam?

ITGC são IT General Controls — controles gerais de TI que garantem que os sistemas financeiros funcionam de forma confiável. Cobrem gestão de acessos, gestão de mudanças, operações de TI e segurança. Sem ITGC funcionando, o auditor não pode confiar nos relatórios financeiros gerados pelos sistemas.

Quanto tempo leva para preparar a TI para uma auditoria SOX?

Com organização, 6 meses é suficiente para montar controles básicos robustos. Mês 1: inventariar sistemas no escopo. Meses 2-3: mapear e documentar acessos e mudanças. Meses 4-5: implementar revisões periódicas. Mês 6: simulação interna. Empresas que começam com menos de 90 dias de antecedência tendem a ter ressalvas.

SOX no contexto brasileiro: o que muda na prática

Uma confusão recorrente: SOX é lei americana, mas atinge dezenas de empresas brasileiras. Toda subsidiária de multinacional listada na NYSE ou NASDAQ está sujeita. Toda empresa brasileira com ADR (American Depositary Receipt) também. Vale, Petrobras, Embraer, Itaú, Bradesco, Ambev, Gerdau, Suzano, Banco do Brasil — todas operam sob SOX. E o efeito cascata atinge a cadeia de fornecedores críticos quando eles tocam dados ou processos financeiros materiais.

Aqui no Brasil temos uma camada extra de complexidade: a SOX exige controle interno sobre relatórios financeiros, mas o nosso ambiente regulatório também impõe LGPD (proteção de dados), instruções da CVM, normas do BACEN para instituições financeiras, regulações setoriais (ANS, ANEEL, ANP). Boa parte dos controles se sobrepõe — e o gestor que constrói o programa SOX olhando só pra norma americana acaba duplicando esforço.

O que eu recomendo nos meus clientes brasileiros: tratar SOX como espinha dorsal de um programa integrado de controles internos, não como projeto isolado. Os mesmos controles de gestão de acessos que satisfazem SOX também ajudam a comprovar conformidade com LGPD. A mesma trilha de auditoria que o auditor SOX quer ver é a que a CVM eventualmente pede em fiscalizações. Trabalho integrado economiza 30-40% do esforço total.

Outro ponto que muda no contexto brasileiro: o calendário. A maioria das companhias com fechamento em dezembro recebe auditoria externa SOX entre janeiro e março. Significa que o trabalho de remediação precisa estar pronto até novembro. Quem começa em setembro tem dois meses pra apagar incêndio. Quem começa em maio chega tranquilo. A diferença entre ressalva e parecer limpo é tipicamente esses 4 meses de antecedência.

O papel do board e do comitê de auditoria

Esse é um ponto que CIO costuma subestimar. SOX não é só processo técnico — é estrutura de governança. O comitê de auditoria do conselho tem responsabilidade direta sobre a efetividade dos controles internos. Em empresas brasileiras com ADR, esse comitê precisa ser composto por conselheiros independentes, com pelo menos um deles com expertise financeira reconhecida.

Pra TI, isso significa que o CIO eventualmente vai apresentar ao comitê de auditoria. Vai precisar explicar o estado dos controles ITGC em linguagem que um conselheiro não-técnico entende. Vai ouvir perguntas sobre risco residual, plano de remediação, dependência de fornecedores externos.

Quem se prepara pra essa conversa antes dela acontecer ganha duas coisas: credibilidade institucional e influência sobre o orçamento de TI nos anos seguintes. O comitê de auditoria, quando confia no CIO, libera investimento em controles. Quando não confia, exige consultoria externa cara — que sai do orçamento da TI, mas é decisão do board.

Vi clientes muito bons nesse jogo. Constroem um relatório trimestral pro comitê de auditoria com 4-6 indicadores estáveis: número de acessos privilegiados, tempo médio de revisão de mudanças, eventos críticos tratados, percentual de controles testados internamente, status de remediação de gaps anteriores. Conselheiro lê em 5 minutos, formula 2-3 perguntas, vai embora confiante. CIO vira parceiro do board, não problema do board.

Modelo de maturidade: onde sua empresa está

Toda vez que um cliente novo me pergunta "em que nível estamos?", eu uso um modelo simples de 4 níveis. Não é COBIT formal — é uma régua prática que funciona pra fechar conversa em 15 minutos.

Nível 1 — Reativo. A empresa só pensa em SOX quando o auditor chega. Documentação produzida em força-tarefa às vésperas. Ressalvas recorrentes. Custo total alto (consultoria emergencial sempre). Característico de empresas no primeiro ou segundo ciclo, ou empresas que perderam liderança técnica recente.

Nível 2 — Documentado. Existe política, existe procedimento, existe controle implementado. Mas a execução é desigual. Algumas áreas funcionam, outras não. Documentação envelhece entre auditorias. Ressalvas ainda aparecem, mas em volume menor. A maioria das empresas brasileiras de capital aberto está aqui.

Nível 3 — Monitorado. A empresa tem disciplina de monitoramento contínuo. Indicadores trimestrais sobre a saúde dos controles. Auditoria interna ativa. Gaps identificados internamente antes da auditoria externa. Ressalvas se tornam exceção. Esse é o nível em que SOX para de ser problema e vira ativo de governança.

Nível 4 — Otimizado. Controles automatizados, monitoramento contínuo em tempo real, integração entre SOX, LGPD, ISO 27001 e demais frameworks. Auditoria externa é evento de rotina. Empresas nesse nível tipicamente investiram 5+ anos no programa. São minoria absoluta no Brasil.

Pra subir um nível, contam três coisas: liderança comprometida, ritual de manutenção e investimento sustentado. Não há atalho. Quem promete subir 2 níveis em 6 meses está vendendo fumaça.

O que esperar do primeiro ciclo SOX

Se a sua empresa vai entrar em SOX pela primeira vez — atenção. O primeiro ciclo é o mais difícil e o mais caro. Não pela complexidade técnica, mas pela curva de aprendizado organizacional. Você está construindo capacidades que não existiam: documentação rigorosa, evidência sistemática, ritmo de auditoria interna, comunicação com auditor externo.

Numbers típicos do primeiro ciclo numa empresa de médio porte (R$ 500 mi-1 bi de faturamento):

Quem entra esperando que o primeiro ciclo saia limpo se frustra. Quem entra preparado pra aprender com as ressalvas iniciais constrói um programa sólido pro segundo ciclo em diante.

Tive um cliente do setor industrial que levou 4 ressalvas no primeiro ciclo. Doloroso. Mas a empresa tratou cada uma como aprendizado, ajustou processo, ajustou documentação. Segundo ciclo: zero ressalvas. Terceiro ciclo: zero ressalvas. Hoje, sete anos depois, o programa SOX deles vira referência interna pra outras unidades do grupo.

A diferença não foi a empresa que reagiu bem à pressão. Foi a liderança que tratou auditoria como ferramenta de melhoria, não como inimigo.