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

Tem um cliente meu, indústria química do interior de São Paulo, que roda um ERP customizado escrito em Progress 4GL desde 2004. Vinte e um anos de código. Quatro gerações de programadores. Zero documentação técnica viva.

O CFO me chamou em outubro porque a controladora americana exigiu SOX completo até março do ano seguinte. Cinco meses pra implementar controles num sistema que ninguém mais entende inteiro.

A primeira reação dele foi a clássica: "Acho que vamos ter que substituir o ERP."

Eu disse não. Antes de pensar em substituição, é preciso entender o que SOX realmente exige da TI. Substituir ERP pra passar em SOX é como mudar de carro porque o farol queimou. Tem solução muito mais barata.

O problema real com sistemas legados e SOX

Sistema legado em si não é o problema. Eu já vi auditoria SOX passar limpa em mainframe IBM dos anos 90. O problema é outro — é que sistemas antigos foram construídos numa época em que a palavra auditabilidade não fazia parte do vocabulário de TI.

Os sintomas típicos:

• Não tem log de quem fez o quê, ou tem mas é truncado a cada 30 dias
• O acesso é por usuário compartilhado (todo mundo loga como ADMIN)
• Mudanças no sistema sobem direto em produção, sem ambiente de teste
• Documentação técnica é o cérebro do João, que está saindo em junho
• Relatórios são gerados por scripts que rodam à meia-noite e ninguém sabe quem agendou

Quando você junta isso tudo, dá pra entender por que a primeira reação é querer trocar tudo. Mas trocar tudo, no meio de um ciclo de auditoria, é receita pra desastre. Você só vai aumentar o risco, não diminuir.

O que eu faço é o contrário: deixo o sistema legado rodando exatamente como está, e construo uma camada de controle em volta dele.

Por que substituir nao e solucao

Cada vez que ouco um CIO falar em substituir o ERP pra resolver SOX, eu pergunto: "voce tem 3 anos e R$ 8 milhoes sobrando?". Porque e isso que substituicao real de ERP custa numa empresa de medio porte. E enquanto o projeto roda, o auditor vai continuar visitando todo ano.

Implantar SAP do zero hoje custa entre R$ 4 e R$ 15 milhoes pra uma empresa de medio porte. Implantar Oracle Cloud, faixa parecida. Implantar Totvs Protheus, entre R$ 2 e R$ 6 milhoes. Tudo isso considerando consultoria de implantacao, hardware/cloud, licencas, gestao de mudanca, treinamento, parada operacional. Sao numeros que travam projeto rapidamente.

E o pior: o sistema novo, recem-implantado, comeca com seus proprios problemas de governanca. Voce troca um conjunto de dores conhecidas por outro conjunto de dores desconhecidas. Em SOX, esse tipo de troca raramente vale a pena.

Mapeamento de riscos: por onde começar

Antes de qualquer controle novo, você precisa entender o que está em risco. E aqui a maioria das consultorias erra: elas chegam com um checklist genérico de 200 controles e tentam aplicar tudo. Resultado: 6 meses de projeto, R$ 80 mil de fatura e uma planilha bonita que ninguém usa.

O método que funciona é inverso. Você começa pelas contas significativas das demonstrações financeiras.

Pega o balanço. Olha quais contas representam acima de 5% do total. Pra cada uma dessas contas, rastreia: de onde vem esse número?

Sai do balanço, entra no razão. Sai do razão, entra no sistema-fonte. Dentro do sistema-fonte, identifica os pontos onde dados são criados, modificados ou agregados.

São esses pontos — e só esses — que precisam de controle SOX. Tudo o resto é gold-plating.

Num cliente, identifiquei que de 312 pontos de controle teóricos, só 47 eram materiais para a auditoria. O resto era ruído consultivo.

Como o controller pode ajudar (mais do que voce imagina)

Quem realmente conhece o caminho do numero ate o relatorio nao e a TI. E o controller. Quando eu chego pra rodar mapeamento de riscos, eu sento com a controladoria primeiro. Pergunto: "esse numero da DRE, como voce confere que esta certo?". A resposta deles me leva direto aos pontos de controle.

Em alguns casos, descubro controles informais que ja funcionam ha anos — o controller faz uma reconciliacao manual todo mes 5, gera um relatorio e arquiva. Esse trabalho, formalizado e documentado, vira controle compensatorio aceito pelo auditor. Nao precisei criar nada — so dar visibilidade ao que ja existia.

O que mais economiza esforco em projetos SOX e essa arqueologia interna. Antes de implementar controle novo, pergunte se ja nao tem alguem fazendo o trabalho informalmente.

Criando trilha de auditoria sem modificar o sistema

Aqui é onde a coisa fica interessante. Como você cria log de auditoria num sistema que não tem capacidade nativa de logar?

Tem várias estratégias. Vou te mostrar as três que mais uso:

Trigger de banco de dados

Se o sistema legado roda em Oracle, SQL Server, PostgreSQL — você pode criar triggers nas tabelas críticas que registram cada INSERT, UPDATE e DELETE numa tabela de auditoria separada. O sistema legado não muda. Mas agora você tem trilha.

Cuidado: tem que medir o impacto em performance. Em tabelas com 50 mil operações por dia, trigger mal feita pode dobrar o tempo de processamento.

Captura de log via SIEM

Se o sistema gera algum log, mesmo que pobre, você joga ele num SIEM (Splunk, Wazuh, Graylog). O SIEM normaliza, correlaciona e armazena com retenção adequada. Eventos críticos disparam alerta.

Captura de tela ou screenscraping

Pra sistemas onde nem o banco está acessível (já vi um Magnus antigo assim), a saída é capturar via screenscraping ou RPA. Não é elegante, mas funciona.

Quando trilha completa e impossivel

Em alguns legados, trilha real e tecnicamente inviavel. Nao tem trigger, nao tem log, nao tem nada. O que fazer?

A resposta e: aceitar a limitacao e construir controles detectivos em vez de controles preventivos. Em vez de tentar registrar tudo, voce monitora resultados e pega anomalias.

Exemplo concreto: num cliente com sistema cobol dos anos 90, criamos uma rotina diaria que extrai indicadores chave (totais, contagens, distribuicoes) e compara com baselines. Variacao acima de threshold dispara alerta. Auditor pergunta evidencia, voce mostra o registro do alerta e o tratamento. Funcional, defensivel.

Nao e elegante. Mas e o que se faz pra evitar reescrever um sistema de 30 anos de historia.

Segregação de funções em sistemas que não foram projetados para isso

Esse é o calcanhar de aquiles dos sistemas legados. A maioria foi construída com perfil único: ou você tem acesso total ou não tem acesso nenhum. Não tem granularidade.

Quando o auditor pergunta "o usuário que cria o fornecedor consegue também aprovar o pagamento?", a resposta honesta na maioria dos legados é: sim, qualquer um do financeiro consegue.

Isso é uma falha de SoD (segregation of duties) clássica e geralmente material para SOX.

O que dá pra fazer sem reescrever o sistema:

• Criar uma camada de aprovação externa (workflow paralelo) para transações acima de X reais
• Implementar revisão pós-fato com amostragem mensal
• Estabelecer controle compensatório: o controller revisa 100% das transações acima de Y antes do fechamento

Controle compensatório é palavra mágica em SOX. Significa: o sistema não previne o erro, mas tem alguém que detecta antes que vire problema. Auditor aceita, desde que a evidência exista.

Testando controles antes que o auditor teste por você

Esse é o passo que mais empresas pulam. E é o mais importante.

Implementar controle é uma coisa. Provar que ele funciona consistentemente é outra. E o auditor não vai testar uma vez — ele vai testar uma amostra ao longo do ano todo.

O que eu faço com meus clientes nos 90 dias antes da auditoria:

Semana 1-2: Defino quais controles vão ser testados (geralmente entre 30 e 80, dependendo do escopo).

Semana 3-6: Para cada controle, pego uma amostra dos últimos 12 meses e testo eu mesmo. Pego o controle de aprovação de mudança, sorteio 10 mudanças do período e pergunto: onde está a evidência de aprovação dessa mudança?

Semana 7-8: Os controles que falharam no teste interno são corrigidos. Os que passaram são documentados com a evidência de teste anexada.

Semana 9-12: Simulação completa. Eu ajo como auditor externo, faço o cliente produzir evidências em prazo apertado. Se a TI não consegue gerar a evidência em 48h, treina até conseguir.

Quando o auditor de verdade chega, está tudo pronto. Sem correria. Sem sufoco. Sem ressalva — e os sete erros que reprovam empresas ficam neutralizados.

O cliente da indústria química que mencionei lá em cima passou na auditoria. Sem nenhuma modificação no ERP legado. Os controles foram construídos ao redor. Custo total: R$ 38 mil em 4 meses, contra uma proposta de R$ 280 mil em 18 meses que tinham recebido de uma Big Four.

O segredo não é tecnologia. É método.

Documentacao dos testes internos

Tem um truque que poucos consultores ensinam: quando voce testa seus proprios controles antes da auditoria, gera evidencia que tambem serve pra ela. Se voce testou o controle de aprovacao de mudanca, anotou data, amostra, resultado e arquivou — esse documento entra como evidencia de monitoramento contínuo. O auditor adora ver isso.

Empresa que faz autoavaliacao formal trimestral demonstra maturidade. Empresa que so prepara em janeiro pra auditoria de marco passa a impressao de reativa. E reativa, em SOX, e sinal de risco.

O que eu recomendo: institucionalizar uma auditoria interna leve trimestral, com cobertura rotativa dos controles. Em 4 trimestres voce cobre tudo. Custo: 20-40 horas de auditoria interna por trimestre. Beneficio: chega na auditoria externa com 9 meses de evidencia de monitoramento.

O kit de documentação mínimo que o auditor exige

Tem uma pergunta que aparece sempre: "Anderson, qual é o mínimo de documentação que o auditor aceita?". Boa pergunta — porque excesso de documentação é desperdício, e falta de documentação é ressalva. O ponto ótimo existe.

Pra sistemas legados, o kit mínimo defensável é esse:

• Matriz de risco e controle — planilha que liga cada conta financeira material aos sistemas que a tocam e aos controles que mitigam o risco. Uma página por sistema crítico. Atualizada anualmente.
• Inventário de sistemas no escopo — lista única, formato simples, com nome do sistema, função, criticidade, responsável técnico, responsável de negócio.
• Matriz de acessos — quem tem qual perfil em qual sistema. Pode ser extração mensal automática.
• Registro de mudanças — log de todas as mudanças com aprovação, execução e verificação. Ferramenta de ITSM ou planilha — desde que rastreável.
• Logs de auditoria — eventos críticos capturados e retidos. Frequência de revisão documentada.
• Evidência de testes internos — relatórios da auditoria interna, com amostras testadas e resultado.
• Plano de continuidade — política de backup, RTO/RPO definidos, evidência do último teste.

São sete artefatos. Não é pouco, mas é gerenciável. Empresa que mantém esses sete vivos passa em qualquer auditoria SOX que eu já vi. Empresa que enche documentação adicional só consome esforço sem ganhar nada — porque o auditor não vai ler 200 páginas de política se ele já viu o controle funcionando.

Quick wins: os controles que se implementa em 30 dias

Tem ações que dão resultado rápido e geram credibilidade institucional. Quando o calendário aperta, são as primeiras a executar. Aqui vai a lista que eu uso com clientes que têm 90 dias até a auditoria:

Semana 1: limpeza de acessos óbvios

Extração de todos os usuários ativos nos sistemas no escopo. Cruzamento com base de RH (funcionários atuais). Identificação imediata de ex-funcionários com acesso ainda ativo. Desativação documentada. Esse trabalho leva 3-5 dias úteis e tipicamente remove 10-30% dos usuários ativos. Vira evidência forte pro auditor de que existe controle funcionando.

Semana 2: revisão de superusuários

Lista de todos os perfis administrativos (DBA, ROOT, ADMIN, SAP_ALL e equivalentes). Validação com gestor da área se cada acesso ainda é necessário. Remoção dos que não justificam. Documentação da aprovação dos que ficam.

Semana 3: formalização de mudanças recentes

Pegar as últimas 30 mudanças feitas em sistemas no escopo. Pra cada uma, registrar retroativamente: quem solicitou, quem aprovou, quem executou, quem verificou. Não é o ideal — o ideal é capturar no momento — mas formaliza o backlog e cria padrão pra frente.

Semana 4: implementação do processo formal

Ferramenta de ITSM (Jira Service, ServiceNow, ou planilha estruturada) ativa. Fluxo de aprovação claro. Treinamento rápido do time. A partir desse momento, toda mudança nova passa pelo fluxo. Em 60 dias você acumula histórico defensável.

Esses quatro quick wins resolvem entre 40% e 60% dos achados típicos de primeiro ciclo. Não é completo, mas é defensável — e dá tempo de tratar os pontos mais profundos nas semanas seguintes.

Gestão de mudanças: o ritual que separa empresa madura

Vou aprofundar nesse tema porque é onde mais vejo empresa boa em tecnologia falhar em SOX. Não é por falta de capacidade técnica — é por falta de ritual.

O ritual mínimo de gestão de mudanças que sobrevive a auditoria SOX tem cinco elementos:

Solicitação documentada. Toda mudança nasce de um chamado, RFC, ticket — qualquer formato rastreável. Conteúdo mínimo: o que se quer mudar, por quê, qual o impacto esperado, qual o risco identificado, qual o plano de rollback.

Aprovação prévia. Antes da execução, alguém com autoridade aprova. Esse alguém varia conforme o impacto: mudança técnica menor — líder técnico aprova. Mudança em sistema financeiro core — controller e change manager aprovam. Mudança que afeta regra de negócio material — comitê de mudanças (CAB) aprova com ata.

Teste em ambiente separado. Mudança vai pra ambiente de homologação antes de produção. Evidência de teste anexada ao ticket. Pra mudanças emergenciais, esse passo pode ser dispensado — mas a exceção fica documentada.

Janela de mudança definida. Mudança em produção acontece em janela acordada, fora do horário crítico, com responsável técnico designado. Início e fim registrados.

Verificação pós-implementação. Alguém — preferencialmente não quem executou — confirma que a mudança funcionou e não causou problema colateral. Esse passo é onde mais empresa esquece. E é o que o auditor mais quer ver.

Implementar esse ritual completo leva 60-90 dias de mudança cultural na TI. Mas uma vez instalado, ele se sustenta. E vira o controle mais robusto que a TI da empresa vai ter — não só pra SOX, mas pra qualquer auditoria.

Como conversar com o CFO sobre SOX (sem perder a paciência)

Pode parecer fora de escopo, mas não é. Boa parte do sucesso de um programa SOX em TI depende do relacionamento entre CIO e CFO. E essa conversa, na maioria das empresas brasileiras, é truncada.

O CFO típico tem três medos em SOX: ressalva pública (afeta imagem dele com o board), custo descontrolado (sai do CapEx que ele defende) e cronograma furado (afeta a divulgação trimestral). Quando o CIO entende esses três medos, conversa fica produtiva.

O que funciona: relatório mensal de status em uma página, com três blocos visuais — status atual dos controles (semáforo), pontos críticos do mês (lista curta), o que vai acontecer no mês seguinte (lista curta). Cinco minutos de leitura. Zero jargão técnico.

O que não funciona: reunião de duas horas com 47 slides técnicos, listando todos os achados em detalhe, sem priorização clara. O CFO sai sem saber o que ele precisa fazer. E perde confiança no CIO.

Tem um padrão que eu observo: empresas onde CIO e CFO se reúnem 30 minutos por mês especificamente sobre SOX tendem a passar em auditoria. Empresas onde essa reunião não existe, ou existe só em crise, tendem a se complicar. O ritual é o que faz diferença, mais que talento individual.

O CIO que assume protagonismo nessa relação ganha capital político. O CIO que delega isso pro gerente de governança perde influência sobre as decisões que mais importam pro próprio orçamento.