Lei Sarbanes-Oxley (SOX): o que é e o que exige da TI

A Lei Sarbanes Oxley (SOX) é uma lei federal dos Estados Unidos de 2002 que estabelece responsabilidades sobre relatórios financeiros e controles internos de emissores sujeitos ao reporte à SEC (Securities and Exchange Commission). Para a TI, o ponto central é apoiar controles e evidências relacionados à informação financeira, dentro do escopo aplicável à organização.

O que é a Lei Sarbanes-Oxley e qual é seu objetivo?

A lei SOX trata, entre outros pontos, da responsabilidade dos administradores pelas informações financeiras e pelos controles internos que as sustentam. Seus dispositivos de 2002 relacionam certificações dos relatórios, avaliação dos controles e responsabilidades de executivos. O foco deste guia é esse recorte: entender quem responde pela informação e como a TI pode apoiar sua confiabilidade.

O contexto histórico inclui as fraudes financeiras na Enron e na WorldCom. Em discurso de 28 de janeiro de 2003 publicado pela SEC, Cynthia Glassman descreveu a promulgação da lei em julho de 2002 como uma resposta a essas fraudes e às de outras corporações, em um esforço para restaurar a confiança dos investidores.

Por isso, compreender SOX compliance começa pela obrigação de reporte e pelo escopo dos controles, não pela escolha de uma ferramenta. Uma trilha de acessos pode apoiar a avaliação de um controle; não substitui a responsabilidade da gestão nem a análise do auditor. Este conteúdo é educativo e não determina o enquadramento jurídico de uma organização.

A SOX se aplica a empresas brasileiras?

Uma empresa brasileira pode estar sujeita às obrigações pertinentes quando se enquadra como emissor obrigado ao reporte à SEC. A nacionalidade, a listagem no Brasil ou a existência de qualquer ADR, isoladamente, não bastam para concluir a aplicabilidade. Os dispositivos citados vinculam os deveres aos relatórios previstos na legislação norte-americana.

Subsidiárias brasileiras também podem participar dos controles do grupo no escopo da consolidação. A seção 302 menciona informação material do emissor e de suas subsidiárias consolidadas; isso não equivale a declarar uma obrigação autônoma e universal para toda subsidiária. Jurídico, gestão e auditoria devem confirmar o enquadramento e quais processos locais entram na avaliação.

O que dizem as seções 302, 404 e 906?

As seções têm funções distintas. O quadro resume as responsabilidades legais; a coluna de TI apresenta implicações operacionais para discussão, não uma transcrição de requisitos tecnológicos da lei.

Na seção 404, separar gestão e auditor evita um erro importante: a isenção da atestação prevista em 404(b) não deve ser tratada como isenção automática da avaliação da gestão em 404(a). O enquadramento nas categorias mencionadas precisa de análise específica. Nenhuma dessas certificações é um selo atribuído a software.

O que a SOX exige da TI e dos controles de acesso?

Para a TI, a ligação com a Lei Sarbanes Oxley está nos controles que sustentam a informação financeira. O ponto de partida é identificar quais sistemas, processos e acessos são relevantes para esse reporte, em vez de presumir que todo o parque tecnológico terá o mesmo tratamento. A seção 404 delimita a avaliação aos controles internos sobre o reporte financeiro.

ITGC são controles gerais de TI que apoiam a confiabilidade dos sistemas e de seu funcionamento. Neste artigo, seu recorte é a informação financeira; o aprofundamento operacional está no conteúdo sobre apoio aos controles ITGC de acessos.

No padrão AS 2201, o PCAOB relaciona controles internos eficazes à segurança razoável sobre a confiabilidade do reporte financeiro, não a uma garantia absoluta. Na organização das evidências de acesso, isso orienta uma pergunta prática: o registro permite avaliar o controle definido ou apenas mostra que uma atividade aconteceu?

Quais evidências organizar para a auditoria?

O checklist abaixo é ilustrativo: propõe como organizar evidências de acessos para discutir com gestão e auditoria. Não é uma lista literal nem universal da SOX. O AS 2201 requer evidência apropriada e suficiente para a avaliação do auditor; a seleção e a suficiência dos registros dependem do escopo e dos testes.

• Escopo: registrar sistemas e acessos relacionados à informação financeira, período avaliado e responsáveis. Explicitar a relação de cada evidência com o controle que se pretende avaliar.
• Concessão: relacionar solicitação, justificativa, aprovador, data e resultado da execução. Uma aprovação documentada não deve ser confundida com a confirmação do acesso efetivamente concedido.
• Mudança e remoção: reunir evento de origem, acessos afetados, momento da execução e pendências. Manter as exceções identificáveis, em vez de apresentá-las como remoções concluídas.
• Revisão e recertificação: identificar população avaliada, responsável, decisão e justificativa. Quando a decisão for revogar, relacioná-la ao acompanhamento da remoção.
• Segregação de funções: registrar conflito identificado, avaliação, responsável pelo tratamento e controle compensatório quando cabível. O conceito de SoD ajuda a contextualizar a análise de combinações de acesso incompatíveis.
• Trilhas e logs: indicar origem, período e vínculo com os eventos avaliados. Discutir completude e confiabilidade; uma captura isolada não comprova, por si só, a eficácia do controle.

Frequência das revisões, retenção dos registros, amostra e prazos de tratamento devem ser definidos no contexto aplicável. Este checklist não estabelece periodicidade ou prazo universal.

Exemplo hipotético: mudança de função em um sistema financeiro

Imagine uma pessoa transferida para outra função. O conjunto de evidências pode relacionar o evento de mudança à aprovação dos novos acessos, à remoção dos antigos e ao resultado de cada execução. Se a combinação de permissões revelar um conflito, o registro deve permitir acompanhar sua avaliação e tratamento, sem presumir que uma justificativa o resolve.

A utilidade do exemplo está em conectar autorização e execução: o pedido foi aprovado, mas o acesso anterior saiu do sistema? Se houve uma pendência, quem ficou responsável? Trata-se de uma situação ilustrativa, não de um case, resultado de cliente ou procedimento imposto literalmente pela lei.

Onde a AccessOne ajuda?

A AccessOne é uma plataforma SaaS brasileira de Governança e Administração de Identidades (IGA). A plataforma apoia o ciclo de vida de acessos nos sistemas integrados, com trilhas que registram responsáveis, justificativas, datas e resultados de execução. Inventário e workflows permitem identificar acessos e relacionar solicitações às autorizações.

A AccessOne já atendeu cliente com requisitos de conformidade com a SOX.

A edição Enterprise inclui revisão e recertificação de acessos e tratamento de violações de SoD com controles compensatórios. A solução de revisão de acessos integra esse contexto, conforme edição, sistemas integrados e escopo contratado. Essas capacidades apoiam a organização das evidências; não garantem conformidade SOX nem substituem a avaliação dos responsáveis pelos controles e pela auditoria.

Perguntas frequentes

A SOX se aplica a empresas brasileiras?

Pode se aplicar conforme a sujeição ao reporte à SEC e o escopo dos controles da consolidação. Não basta ser brasileira com ADR ou subsidiária para presumir obrigação universal; o enquadramento específico requer avaliação jurídica e de auditoria.

O que dizem as seções 302, 404 e 906 da SOX?

A 302 trata de certificações e responsabilidades dos administradores; a 404(a), da avaliação da gestão sobre controles do reporte financeiro. A 404(b) prevê atestação do auditor quando aplicável, com as isenções legais, enquanto a 906 trata da declaração de CEO/CFO e das penalidades por certificação falsa nos termos do dispositivo.

O que são ITGC (controles gerais de TI)?

ITGC são controles gerais de TI que apoiam a confiabilidade dos sistemas. No contexto deste guia sobre SOX, importam os controles relacionados à informação financeira, sem estender automaticamente o escopo a todo o ambiente tecnológico.

Quais evidências de controle de acesso a auditoria SOX pede?

A seleção depende do escopo e dos testes, não de uma lista universal apresentada neste artigo. Solicitações, aprovações, resultados de concessão e remoção, decisões de revisão e tratamento de exceções são exemplos a discutir; sua suficiência precisa ser avaliada.

Qual a diferença entre SOX e LGPD/ISO 27001?

No recorte SOX deste artigo, o foco são os controles internos sobre o reporte financeiro. A LGPD é o marco brasileiro de proteção dos dados pessoais; segundo a ANPD, seu objetivo é assegurar aos titulares o direito de saber como seus dados pessoais são tratados. Já a ISO/IEC 27001 define requisitos para um sistema de gestão de segurança da informação (SGSI). Esses escopos não são equivalentes: atender a um deles não comprova atendimento automático aos demais.

Quais as penalidades por descumprir a SOX?

A seção 906 prevê multa, prisão ou ambas para certificações falsas nas condições descritas no dispositivo, distinguindo as modalidades de conduta. Isso não significa punição criminal automática por qualquer falha de acesso, e essa seção não representa um catálogo completo das sanções da SOX. A análise de uma situação concreta exige orientação jurídica.

Conclusão: alinhe o escopo antes de reunir evidências

Entender a Lei Sarbanes Oxley significa distinguir responsabilidades legais, controles do reporte financeiro e evidências operacionais. Para a TI, a contribuição prática é tornar verificável a relação entre acesso, autorização, execução e tratamento de pendências no escopo definido. A gestão continua responsável pelos controles, com avaliação profissional e participação do auditor conforme aplicável.

Leituras relacionadas para aprofundar os processos, sem confundi-los com a definição da lei:

• ITGC e governança de acessos.
• Revisão de acessos e evidências.
• Segregação de funções e conflitos de acesso.