Toda empresa passa pelo menos uma vez por aquela semana de auditoria. A corrida para achar evidências, os documentos em pastas erradas, as capturas de tela tiradas às pressas. Existe um jeito melhor — e começa muito antes do auditor marcar a data.
Você já viveu essa semana. Ou vai viver.
O auditor confirmou: chega em seis dias. O escopo cobre doze meses de operação e o relatório de evidências precisa estar pronto antes da reunião de abertura. Então o time começa a busca: onde está a ata da última revisão de acessos? Quem fez o treinamento de segurança em março e onde ficou o comprovante? O relatório de pentest do segundo semestre foi o arquivo do dia 14 ou do dia 22? A política de controle de acesso que está no Drive é a versão aprovada ou o rascunho que ficou salvo no lugar errado?
Os próximos cinco dias consomem um volume desproporcional de horas. Mensagens no Slack fora do horário, pelo menos um engenheiro tirando capturas de tela de logs às madrugada, e uma quantidade considerável de “acho que é esse arquivo” servindo de resposta onde o auditor esperava uma evidência verificada. Pesquisas do SANS Institute apontam que equipes de segurança gastam entre 30% e 40% do tempo total de um ciclo de auditoria apenas coletando e organizando evidências, não analisando nem reportando. Esse número não surpreende ninguém que já passou por uma preparação de auditoria conduzida à mão.
O que chama atenção é que isso se repete, na mesma empresa, com o mesmo time, auditoria após auditoria. Não porque o time é desorganizado. Porque o modelo é estruturalmente reativo.
Por que o problema se repete mesmo em empresas bem organizadas
A empresa tem controles de segurança funcionando. Faz revisões de acesso, conduz treinamentos, monitora vulnerabilidades, gerencia incidentes quando surgem. O problema não está na prática dos controles. Está no registro dessa prática.
Evidências de compliance não aparecem sozinhas. Alguém precisa exportar o log, salvar a ata, registrar a conclusão do treinamento, aprovar formalmente a nova versão da política. Quando esse trabalho de registro não está estruturado como parte do processo, ele depende de alguém lembrar de fazê-lo no momento certo. Em empresas em crescimento, com times pequenos e muitas demandas simultâneas, esse alguém está ocupado com outra coisa no momento em que o registro precisava ter sido feito.
O resultado é o que aparece na semana pré-auditoria: controles que existem e funcionam, mas sem evidência verificável do seu funcionamento ao longo do período coberto. Um dos achados mais frequentes em auditorias de SOC 2 Type II não é ausência de controles. É ausência de evidência de que os controles foram aplicados de forma consistente nos seis ou doze meses anteriores. Para o relatório final, isso é tão problemático quanto o controle simplesmente não existir.
Os três tipos de evidência que fazem o auditor pausar
Quando um auditor pede evidências e recebe material incompleto, ele classifica o problema de três formas, cada uma com implicações distintas para o relatório.
A evidência inexistente é o caso mais direto: o controle foi executado, mas não foi registrado de forma alguma. O treinamento de segurança aconteceu numa reunião de team meeting sem lista de presença formal. A revisão de acessos ocorreu numa conversa entre o head de engenharia e o CTO sem nenhuma documentação gerada. O monitoramento de vulnerabilidades é feito, mas os relatórios nunca foram salvos sistematicamente. Para o auditor, ausência de evidência é indistinguível de ausência do controle. Se não está documentado, operacionalmente não existe.
A evidência desatualizada é provavelmente o tipo mais comum. A política de segurança foi escrita há dois anos, quando a empresa tinha 15 pessoas, e nunca foi revisada formalmente desde então, mesmo com o time tendo triplicado e os sistemas terem mudado completamente. O DPA com o principal fornecedor de nuvem é de 2022 e ainda referencia estruturas de dados que a operação da empresa já não usa. O documento existe, mas não representa a realidade atual, e qualquer auditor com experiência identifica isso durante a revisão.
A evidência não verificável é a mais delicada. São as capturas de tela tiradas na véspera da entrega do relatório, os documentos exportados às pressas sem metadados que confirmem a data original de criação, os logs que cobrem apenas as últimas semanas mas foram apresentados como representativos do ano inteiro. Tecnicamente, o material está lá. Na prática, um auditor de SOC 2 ou ISO 27001 vai questionar a rastreabilidade, e isso vai gerar achados no relatório final.
O que coleta contínua de evidências muda na prática
A diferença entre um programa de compliance que funciona e um que gera crise pré-auditoria não está no tamanho do time de segurança nem no orçamento. Está em quando a evidência é coletada.
Numa empresa com coleta contínua, a revisão trimestral de acessos gera automaticamente um registro no momento em que acontece. O sistema de gestão de vulnerabilidades envia o relatório mensal diretamente para a plataforma de compliance logo após a geração. Cada treinamento de segurança concluído por um colaborador é registrado com timestamp no perfil daquele colaborador. A aprovação de uma nova versão de política fica registrada com a data exata e o nome do responsável. Quando o auditor chega, tudo isso já está organizado, rastreável e no formato que cada framework exige. A semana antes da auditoria passa a ser usada para revisar e preparar o relatório, não para reconstruir evidências de memória.
Isso muda o perfil de esforço do time de segurança ao longo do ano inteiro. Em vez de gastar entre 40 e 80 horas numa semana de crise concentrada, o trabalho acontece de forma distribuída, integrado à operação normal, sem o pico de estresse no pior momento possível.
Como o Imara Trust elimina a corrida por evidências
O Imara Trust foi construído com a premissa de que evidência coletada no momento certo vale fundamentalmente mais do que evidência reconstituída depois. As integrações com provedores de nuvem, sistemas de RH, ferramentas de gestão de acesso e plataformas de desenvolvimento alimentam a plataforma com evidências automaticamente, no momento em que os eventos acontecem.
O histórico de conformidade da empresa deixa de ser algo que precisa ser montado antes da auditoria. Ele existe de forma permanente, está rastreável e pode ser apresentado ao auditor no formato que cada framework exige, sem trabalho adicional de preparação.
Para empresas que estão testando o Imara Trust agora, o onboarding começa com um mapeamento das evidências que já estão sendo geradas pelos sistemas existentes e de como conectá-las à plataforma. Esse exercício costuma revelar o que estaria bem coberto numa auditoria e o que viraria problema, antes que o auditor seja o primeiro a identificar isso.