Depois de 12 anos auditando empresas reguladas e mais de 60 ciclos SOX entre clientes diretos e revisões de pares, eu te garanto: 80% das ressalvas que aparecem nas auditorias vêm sempre dos mesmos sete erros.
Todos evitáveis. Todos repetidos. Todos custosos quando o auditor encontra antes de você.
Esse artigo é a lista que eu queria ter tido quando comecei. Se você ainda precisa de panorama, comece por o que SOX significa na prática para TI. Vou direto ao ponto.
Erro 1: Acesso privilegiado sem revisão periódica
Esse é campeão absoluto. Empresa tem 12 usuários com perfil de superusuário no ERP. Quando o auditor pergunta há quanto tempo cada um tem esse perfil, e quem revisou pela última vez se ainda precisa — silêncio.
O controle que falta aqui é simples: revisão trimestral de acessos privilegiados. O gestor da área responsável aprova ou remove cada acesso. Por escrito. Com data. Com assinatura (digital serve).
Num cliente do setor financeiro encontrei o seguinte: a controladoria tinha 7 usuários com acesso DBA ao banco do ERP. Três deles eram estagiários que haviam sido promovidos pra outra área dois anos antes. Ninguém revogou. Ressalva imediata.
O que eu recomendo:
- Inventário trimestral de todos os perfis privilegiados
- Aprovação documentada por gestor responsável a cada revisão
- Remoção automática se o gestor não responder em 15 dias
- Relatório mensal pro comitê de auditoria interna
Como construir a revisao trimestral que funciona
O processo que mais vejo dar errado e a revisao trimestral feita por email. TI manda planilha pro gestor, gestor responde "ok, manter tudo", arquiva. Auditor pega aquela troca e identifica que e cumprimento de fachada — ninguem leu a planilha de verdade.
O que funciona: reuniao real de 30-60 minutos por trimestre com cada gestor. Tela compartilhada com a lista de usuarios da area dele. Pra cada usuario, decisao explicita: mantem, ajusta perfil, remove. Ata da reuniao. Plano de acao das remocoes em 5 dias uteis.
Custa tempo? Custa. Mas eu nao vi outro formato que sobrevive a auditoria rigorosa.
Erro 2: Mudanças em produção sem aprovação documentada
Esse é o segundo lugar. A TI faz mudança porque "era urgente". A mudança subiu sem aprovação. Funcionou. Ninguém comentou. Seis meses depois o auditor pega aquele JIRA e pergunta: onde está a aprovação do change manager?
Não tem. Ressalva.
Olha, eu entendo a urgência. Sistema crítico travado, cliente reclamando, faturamento parado. A pressão é real. Mas o auditor não está nem aí pra urgência — ele só quer ver evidência.
O que funciona na prática:
Toda mudança em produção precisa de pelo menos três coisas: aprovação prévia (mesmo que seja email de 1 linha do gestor), registro de execução (quem fez, quando, o que mudou) e aprovação pós-implementação (alguém testou e confirmou). Quando houver mudança emergencial, o processo é o mesmo — só que a aprovação prévia pode ser por telefone, documentada formalmente em até 24h depois.
O processo emergencial que o auditor aceita
Mudanças emergenciais são realidade. Auditor sabe. O que ele exige é protocolo formalizado pra elas. O fluxo aceito tipicamente:
- Acionamento documentado (chamado, email, whatsapp arquivado)
- Aprovação verbal do gestor (registrada em qualquer canal rastreável)
- Execução registrada com hora de início e fim
- Notificação pós-execução ao gestor e ao change manager
- Ticket retroativo aberto em até 24h com toda a documentação
- Revisão em comitê de mudanças (CAB) na próxima reunião regular
Quando você tem esse protocolo formalizado e documentado, mudança emergencial vira exceção tratada — não furo de controle.
Erro 3: Logs que existem mas ninguém lê
Esse erro tem ironia. A empresa investe R$ 200 mil num SIEM. Coleta 47 fontes diferentes de log. Tem dashboards bonitos. Mas quando o auditor pergunta "o que vocês fizeram com o alerta de 14 de junho às 3h17?" — ninguém viu o alerta.
Log que ninguém revisa é prova de que o controle não funciona. Pior: é prova ativa de negligência.
O auditor vai pegar 5, 10 alertas críticos do ano e pedir o registro de tratamento de cada um. Se você não tem, vira ressalva.
O que eu implemento nos clientes:
- Lista de eventos críticos definida e aprovada (não mais que 20 tipos, ou ninguém revisa)
- Responsável nomeado para revisão diária dos alertas
- Registro de tratamento de cada alerta crítico
- Revisão semanal pelo gestor de segurança
O paradoxo do excesso de logs
Vejo cliente investir em SIEM cobrindo 200 fontes de log, gerando milhoes de eventos diarios, e ninguem revisar nada. Pra auditor SOX, isso e pior que nao ter log nenhum — porque demonstra investimento sem disciplina de execucao. Sinal de governanca imatura.
O que funciona e o oposto: 15-25 eventos criticos selecionados, com regra clara, alerta dimensionado pra ser tratavel, e revisao diaria documentada. Menos volume, mais qualidade.
Antes da próxima auditoria, mapeie seus gaps com o checklist ITGC.
Fazer o Checklist ITGC gratuito →Erro 4: Segregação de funções no papel, não no sistema
A política diz que quem cria fornecedor não pode aprovar pagamento. Bonita política. Está num PDF de 47 páginas que ninguém lê.
O auditor não lê a política. O auditor entra no sistema, identifica três usuários com ambos os perfis ativos simultaneamente e marca ressalva.
Política sem implementação técnica é teatro. Eu vejo isso o tempo todo.
A correção exige duas coisas: matriz de SoD documentada (quais combinações de perfil são proibidas) e controle automatizado que impede a criação dessas combinações no sistema. Se o sistema não suporta automação, controle compensatório com revisão mensal e evidência de exceções.
SoD em sistemas que nao suportam tecnicamente
Em sistemas legados que não suportam segregação tecnicamente, o caminho aceito é o controle compensatório formal. Algo como: o controller revisa 100% das transações que envolvem a combinação proibida, em janela mensal, com evidência arquivada.
Esse controle só funciona se for ritualizado. Reunião marcada no calendário, responsável nominado, planilha de revisão padronizada, arquivo organizado. Sem ritual, vira teatro e o auditor pega.
Erro 5: Usuários genéricos compartilhados
O usuário ROOT. O ADMIN. O DBA. O SAP_ALL. Aquele login que três pessoas usam porque é mais prático.
Toda vez que vejo isso em cliente eu sei que vai virar ressalva. O auditor olha o log de uma operação crítica, vê que foi feita pelo usuário SAP_ALL e pergunta: quem fez essa operação?
A resposta honesta é: pode ter sido qualquer um dos três que conhecem a senha. E aí o controle inteiro perde validade. Se não dá pra atribuir a operação a um indivíduo, não há accountability. Não há accountability, não há SOX.
O caminho pra eliminar usuario generico
Eliminar usuário genérico não é trivial. Em sistemas legados que dependem dele (jobs batch que rodam como ADMIN, integrações que usam usuário compartilhado), exige refatoração. Mas dá pra fazer em fases:
- Fase 1: inventário de onde o usuário genérico é usado
- Fase 2: criação de usuários técnicos nominados pra jobs e integrações
- Fase 3: revogação progressiva do genérico
- Fase 4: monitoramento de tentativas de uso do genérico (deveria estar zerado)
Empresa que faz esse trabalho gradual em 6-12 meses elimina o problema. Empresa que tenta de uma vez quebra coisa em produção.
Erro 6: Backup que ninguém testou
Backup é o controle que todo mundo tem. Backup que foi testado nos últimos 12 meses é o que poucos têm.
O auditor vai perguntar a data do último teste de restore completo. Vai pedir evidência (relatório, screenshot, log do teste). Se o último teste foi há 3 anos ou se nunca foi feito, ressalva.
O teste de restore não precisa ser do ambiente inteiro toda vez. Pode ser amostral. Mas precisa existir, ser documentado e ser repetido pelo menos anualmente.
Como testar restore sem parar produção
Teste de restore não precisa ser do ambiente inteiro. Tipicamente roda em ambiente isolado de homologação:
- Restaura um banco crítico em servidor isolado
- Verifica integridade (consultas básicas funcionam, contagens batem)
- Mede tempo de restore para fins de uptime.com.br/" style="color:#1a365d;text-decoration:underline;font-weight:500;">SLA
- Documenta evidência (screenshot, log, relatório)
Custo do teste: meia jornada de DBA, mais infraestrutura temporária. Frequência mínima: anual. Frequência ideal para sistemas críticos: trimestral. É barato comparado ao custo de descobrir backup quebrado durante incidente real.
Erro 7: Documentação que existe mas está desatualizada
Esse é traiçoeiro. A empresa tem política, tem procedimento, tem fluxograma. Tudo aprovado em 2019. Em 2025 nada disso reflete a realidade.
O auditor pega a política, vai ao processo real e identifica três pontos onde a prática difere do documento. Ressalva.
Documentação desatualizada é pior que documentação inexistente. Porque cria a falsa impressão de controle.
Documentação viva: o que separa empresa pronta de empresa enrolada
O segredo de documentação SOX não é ela ser detalhada. É ela ser viva. Ou seja: revisada periodicamente, com data e responsável da última revisão visíveis, alinhada com o que acontece na prática.
Eu uso um padrão simples com clientes: todo documento de controle tem cabeçalho com versão, data, autor, aprovador, data da próxima revisão. Quando a próxima revisão vence, alerta automático dispara. Quem não revisa em 30 dias entra em escalation.
Esse ritual custa pouco tempo. Mas garante que a documentação reflete o processo real. E em SOX, isso vale ouro.
Empresa que faz isso tem documentação confiável ano após ano. Empresa que não faz, repete o ciclo: descobre na auditoria que tudo está velho, faz força-tarefa antes do auditor chegar, esquece de novo no próximo ano. Eterno reaprender.
Controle vivo é o que diferencia maturidade real de maturidade declarada. Auditor experiente lê a diferença em 10 minutos.
O padrão que eu vejo se repetir
Esses sete erros têm uma raiz comum: controle sem manutenção. As empresas implementam, lançam, esquecem. E o controle vai degradando mês a mês até que na hora da auditoria nada mais funciona como deveria.
O que diferencia as empresas que passam limpo das que se complicam não é o tamanho do orçamento de TI. É o ritual de manutenção.
Revisão trimestral de acessos. Teste mensal de backup. Auditoria interna semestral. Atualização anual de documentação. É chato. É repetitivo. Mas é isso que separa empresa SOX-compliant de empresa em apuros.
O auditor não busca perfeição. Ele busca evidência de que você tem um sistema vivo de controle interno. Esse é o jogo — e o passo a passo de implementação mostra como construir esse sistema sem reescrever os legados.
Veja também
Guia CompletoO que é SOX na prática: o que a TI precisa saber antes da auditoria
SOX não é só problema do CFO. TI responde por 80% dos controles. Saiba o que é ITGC, quais sistemas entram no escopo e o que o auditor vai procurar.
Como ImplementarComo 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.
Perguntas frequentes
Quais são os erros mais comuns que causam ressalvas em auditoria SOX?
Os 7 mais frequentes: 1) Usuários ativos de ex-funcionários. 2) Mudanças em produção sem aprovação documentada. 3) Revisão de acessos apenas no papel, sem evidência. 4) Backups sem teste de restauração. 5) Superusuários com acesso desnecessário. 6) Segregação de funções violada (quem aprova também executa). 7) Documentação produzida após o fato, não no momento da execução.
O que acontece quando uma empresa leva ressalva SOX?
Ressalvas materiais exigem divulgação pública e podem impactar o preço das ações. Internamente, o CFO e CIO precisam apresentar ao conselho um plano de remediação. O budget de TI fica refém do tema por 1-2 anos. Em casos graves, lideranças são substituídas. O custo total de uma ressalva grave supera em muito o custo de prevenção.
Como saber se minha empresa está pronta para auditoria SOX?
Faça esse teste: pegue uma amostra de 10 mudanças feitas nos sistemas financeiros nos últimos 3 meses e tente produzir, em 48 horas, evidência de que cada uma foi aprovada antes de ir para produção. Se não conseguir, não está pronto. O auditor fará exatamente isso — com amostra maior e sem aviso.
O custo real de cada erro: ressalva por ressalva
Pra dimensionar o impacto desses sete erros, vou colocar números. São médias observadas em projetos reais nos últimos 5 anos, empresas brasileiras de capital aberto entre R$ 300 mi e R$ 3 bi de faturamento.
Erro de acesso privilegiado: custa em média R$ 80-150 mil pra remediar em situação de pressão (consultoria emergencial, horas extras, reorganização de processos). Em situação preventiva, sai por R$ 15-25 mil. Diferença: 5 a 6 vezes.
Mudança sem aprovação: R$ 60-120 mil de remediação emergencial. Sob ritmo normal, R$ 10-20 mil. Mas o custo invisível é maior — porque exige refazer a ferramenta de ITSM, retreinar o time, fazer backfill de aprovações antigas. Esforço total em horas internas frequentemente passa de 400 horas.
Logs sem revisão: R$ 100-200 mil pra estruturar processo de revisão e gerar 6 meses de evidência retroativa. Preventivamente, R$ 30-50 mil pra implementar processo limpo. Diferença econômica é menor que nos outros erros, mas o tempo de remediação é maior — tipicamente 4-6 meses pra construir histórico defensável.
SoD violada: esse é o mais caro. Remediar em pressão pode chegar a R$ 250-500 mil, especialmente se exigir customização técnica em sistema legado. Preventivamente, R$ 50-100 mil. Tempo de remediação: 6-9 meses no mínimo.
Usuário genérico: R$ 80-180 mil emergencial, R$ 20-40 mil preventivo. Custo principal é refatoração de jobs e integrações que dependem do usuário compartilhado.
Backup sem teste: esse é barato em termos absolutos — R$ 15-40 mil pra estruturar processo recorrente — mas é o mais constrangedor quando acontece incidente real e o backup não funciona.
Documentação desatualizada: R$ 40-100 mil de força-tarefa pra atualizar. Preventivamente, basta o ritual de revisão anual — custo marginal.
Soma rápida: empresa que tem todos os sete erros e remedia sob pressão gasta entre R$ 625 mil e R$ 1,3 milhão. Empresa que previne gasta entre R$ 170 mil e R$ 305 mil. Diferença de 3 a 4 vezes — sem contar o custo reputacional da ressalva pública.
O efeito ressalva: o que acontece nos 12 meses seguintes
Quem nunca passou por ressalva subestima o impacto. Vou descrever o que acontece tipicamente nos 12 meses após uma ressalva material em SOX, baseado em casos que acompanhei.
Mês 1: divulgação pública do relatório. Conselho convocado. Plano de remediação exigido em 30 dias. Comunicação interna sobre o tema. Acionistas começam a perguntar.
Mês 2-3: CFO e CIO apresentam plano detalhado ao comitê de auditoria. Consultoria externa contratada (compulsoriamente em muitos casos). Orçamento da TI ajustado pra acomodar os trabalhos. Equipe redirecionada pra remediação — projetos estratégicos atrasam.
Mês 4-6: execução intensa do plano. Reuniões semanais com comitê de auditoria. Auditor externo retorna trimestralmente pra avaliar progresso. Tensão alta na equipe. Algumas saídas voluntárias começam.
Mês 7-9: primeira evidência de progresso. Indicadores começam a estabilizar. Ainda há resistência interna ("isso vai passar"). CFO precisa renovar credibilidade com investidores em call trimestral.
Mês 10-12: preparação para o próximo ciclo de auditoria. Pressão pra demonstrar que a ressalva foi remediada. Se a segunda auditoria sair limpa, a empresa começa a sair da crise. Se vier ressalva repetida, o problema escala — substituição de lideranças é comum nesse ponto.
O custo total disso, contabilizado honestamente, raramente fica abaixo de R$ 2 milhões pra uma empresa média. Soma de consultoria, horas internas redirecionadas, projetos atrasados, prêmio de risco que o mercado adiciona às ações, custo de talento perdido. E ainda há o custo reputacional intangível.
Por isso eu insisto: investimento preventivo em SOX é o ROI mais previsível que existe em governança corporativa. Não é debate estratégico — é matemática.
Protocolo de crise: o que fazer se você descobriu o problema sozinho
Pode acontecer: você assumiu como CIO de uma empresa, fez a primeira varredura interna e identificou que tem um erro grave que vai virar ressalva quando o auditor chegar daqui 4 meses. O que fazer?
Primeiro, não esconda. Auditoria SOX tem instrumento chamado autorrelato — empresa que reconhece o problema voluntariamente antes do auditor encontrar recebe tratamento mais leve no relatório. O reverso (auditor descobre algo que a empresa sabia e não comunicou) é tratado como fraude de governança.
Segundo, escale formalmente. Comunique CFO em 48h. Comunique comitê de auditoria em 7 dias. Documente a comunicação. Esse registro protege você profissionalmente — e demonstra cultura de governança madura.
Terceiro, plano de remediação realista. Não promete 30 dias o que precisa de 90. O auditor é experiente, ele sabe diferenciar plano sério de promessa otimista. Cronograma realista, com marcos verificáveis, ganha credibilidade.
Quarto, execute com transparência. Reporte progresso semanalmente. Quando atrasar (vai atrasar), comunique antes do prazo, com causa raiz e novo prazo. Surpresa é o que destrói confiança.
Quinto, e mais importante: aproveite a crise pra instalar disciplina permanente. Empresas que tratam ressalva como catalisador de maturidade saem mais fortes. Empresas que tratam como evento isolado pra esquecer rapidamente repetem o problema 3-4 anos depois.
Como construir um programa interno de testes
O melhor antídoto contra ressalva é teste interno regular. Pense como se você fosse o auditor — antes do auditor chegar.
O programa que eu recomendo tem cobertura rotativa. Ao longo de 12 meses, todos os controles materiais são testados pelo menos uma vez por equipe interna independente do dia a dia operacional. A frequência por controle varia: gestão de acessos uma vez por trimestre, mudanças uma vez por trimestre, backups uma vez por semestre, documentação uma vez por ano.
Cada teste segue o mesmo método que o auditor externo usa:
- Definição da amostra (10-25 itens dependendo do controle)
- Solicitação formal de evidência
- Avaliação binária — passou ou não passou
- Documentação do resultado
- Plano de ação pros itens que falharam
- Retest do plano de ação em 60-90 dias
Empresa que mantém esse ritmo chega na auditoria externa com 12 meses de evidência de monitoramento. Auditor externo entra, vê o programa funcionando, e tende a reduzir o tamanho da amostra que ele próprio testa. Resultado: auditoria mais leve, mais rápida, mais barata.
Custo do programa interno: tipicamente 0,3-0,8% da receita operacional, pra empresa de médio porte. Investimento que se paga com a redução de risco de ressalva (e o tempo poupado em auditorias futuras).
Quem tem coragem de auditar a si mesmo antes que outros auditem? Empresa madura. E essa maturidade é exatamente o que o auditor está medindo.
