Como aproximar o time de TI e a auditoria em projetos de segurança

Introdução: por que TI e auditoria costumam se estranhar

Quem vive segurança da informação no dia a dia sabe que TI e auditoria nem sempre falam a mesma língua. De um lado, o time técnico, acostumado a pensar em logs, chaves, pipelines, instâncias e configurações. Do outro, auditores focados em controles, evidências, escopo, amostragens e conformidade.

O resultado dessa diferença de linguagem costuma ser previsível:

• TI sente que a auditoria pede coisas irreais ou burocráticas demais.
• Auditoria sente que TI responde de forma defensiva, com jargão e pouca objetividade.
• A empresa perde tempo traduzindo, retrabalhando, ajustando documentos e explicações.

Este artigo mostra como aproximar esses dois mundos, usando uma linguagem comum e evitando extremos, como controles de fachada só para “agradar auditor” ou, na outra ponta, uma postura de “isso é frescura, aqui está seguro e pronto”.

---

Entendendo o papel da auditoria e o que ela espera enxergar

O primeiro passo é TI entender o jogo que a auditoria está jogando. Em geral, o auditor não está ali para testar cada linha de configuração, mas para responder algumas perguntas principais:

• Existe um sistema de gestão minimamente organizado?
• Os controles declarados realmente existem, funcionam e são repetíveis?
• As evidências apresentadas sustentam o que está escrito nas políticas e procedimentos?
• Os riscos mais relevantes foram considerados e tratados de forma razoável?

Na prática, isso significa que a auditoria procura:

• Coerência entre o que está escrito nas políticas, o que é dito nas entrevistas e o que é visto em telas, relatórios e registros.
• Evidências rastreáveis, com data, responsável e relação clara com o controle avaliado.
• Regularidade, não ações pontuais feitas só para o dia da auditoria.

Quando TI entende esse papel, fica mais fácil moldar a comunicação. Em vez de mostrar “truques técnicos” isolados, o time passa a organizar as informações em torno de controles e evidências, que é a forma como a auditoria enxerga o mundo.

---

Traduzindo recursos técnicos em controles e evidências

Boa parte do conflito vem do fato de que TI costuma descrever recursos, enquanto a auditoria quer enxergar controles. Por exemplo:

• TI diz: “Temos CloudTrail, Security Hub, GuardDuty e um SIEM integrado.”
• Auditoria quer ouvir: “Temos controles de registro e monitoramento de eventos críticos, com alertas para atividades suspeitas, e aqui estão as evidências.”

Para aproximar os dois lados, uma técnica simples é sempre responder fazendo este mapeamento mental:

1. Recurso técnico
   O que usamos de fato? Exemplo: CloudTrail, WAF, backup diário, MFA, pipeline com testes automatizados.

2. Controle
   Que objetivo esse recurso atende? Exemplo: controle de registro de logs, controle de acesso, controle de backup, controle de revisão de código.

3. Evidência
   Como provamos que ele existe e funciona? Exemplo: prints, relatórios, export de logs, registros de pipeline, tickets, atas.

Na comunicação com a auditoria, organizar a explicação sempre nesses três níveis ajuda muito:

“Para este controle de backup, usamos serviço X com agendamento diário, mantemos retenção de N dias e realizamos teste de restauração trimestral. Aqui estão os relatórios e o registro do último teste.”

Ou, no contexto de acessos:

“Para o controle de gestão de acessos, usamos grupos e papéis em tal ferramenta, com revisão semestral registrada em tickets. Estes são exemplos de relatórios e registros de revisão.”

TI continua fazendo o que sabe fazer, porém agora com uma camada de tradução para a linguagem de controles.

---

Como documentar o que já existe, sem inventar controles

Um erro comum quando a auditoria se aproxima é tentar inventar controles e documentos do zero, apenas para “ficar bonito no papel”. O risco é criar uma distância enorme entre o que está descrito e o que realmente acontece.

O caminho mais saudável é o inverso:

1. Mapear o que já existe na prática
   Quais rotinas TI já executa? Que tipos de checagem, monitoramento, backup, análise de log, revisão de código, mudança de configuração já acontecem naturalmente?

2. Dar nome de controle para essas práticas
   Registrar de forma simples: “Rotina diária de verificação de alertas de segurança”, “Revisão de acessos trimestral”, “Teste semestral de restauração de backup”.

3. Criar registros mínimos
   Sem burocracia excessiva, mas com o suficiente para provar a execução: planilha simples, ticket em ferramenta, relatório rápido, ata de reunião objetiva.

4. Só depois pensar em novos controles
   Quando o essencial estiver documentado, aí sim faz sentido avaliar lacunas e criar controles adicionais, de forma realista.

Essa abordagem evita controles de fachada e reduz a resistência de TI, que deixa de ver a auditoria como fonte de “coisa inútil”. Em vez disso, a auditoria ajuda a organizar e dar visibilidade ao que já é feito, além de sugerir melhorias.

---

Exemplos de boas evidências técnicas para auditorias

Nem todo print é uma boa evidência, e nem toda evidência precisa ser um documento longo. O que o auditor procura é algo que seja:

• Rastreável no tempo (data, período).
• Associável a um responsável ou área.
• Claramente ligado a um controle ou requisito.

Alguns exemplos de boas evidências técnicas:

• Logs de backup e relatórios de restauração: mostrando que o backup é executado com sucesso e que já foi testado em ambiente controlado.
• Registros de revisão de acesso: lista de usuários, data da revisão, quem aprovou ou removeu acessos.
• Histórico de pipelines de CI/CD: execução de testes, análises de segurança, aprovações antes do deploy.
• Configurações exportadas de WAF, grupos de segurança, grupos de IAM, com data de captura.
• Tickets de mudança e incidentes: descrevendo o que foi feito, quem aprovou, qual foi o impacto e quais ações de melhoria foram definidas.
• Relatórios de ferramentas de vulnerabilidade: com evidência de análise e de correção dos itens relevantes.

Perceba que são coisas que TI já lida no dia a dia. A diferença está em guardar e organizar essas informações de forma acessível, para que possam ser apresentadas de forma coerente durante a auditoria.

---

Papel de uma plataforma na ponte entre TI e auditoria

Uma plataforma de gestão de segurança ou de ISO 27001 ajuda justamente a organizar essa ponte:

• TI continua registrando suas atividades em ferramentas técnicas, mas exporta ou integra resultados relevantes na plataforma.
• A plataforma vira o lugar onde controles, evidências, tarefas recorrentes e auditorias se conectam.
• A auditoria passa a navegar por essa visão organizada, em vez de exigir uma coleção de planilhas e prints avulsos.

Alguns ganhos práticos:

• Linguagem comum: o controle é o ponto central, e tanto TI quanto auditoria passam a falar dele, cada um a partir do seu contexto.
• Rastreabilidade automática: a plataforma registra quem anexou evidência, quando, para qual controle.
• Visão de maturidade: dashboards, status de implementação, pendências e ações corretivas aparecem de forma unificada.

Em vez de TI ter que “montar um dossiê manual” a cada auditoria, muita coisa já está pronta, atualizada ao longo do ano.

---

Boas práticas de comunicação antes, durante e depois da auditoria

Comunicação é metade do caminho para uma auditoria tranquila. Algumas práticas simples ajudam muito:

Antes da auditoria:

• Realizar uma reunião de alinhamento entre TI, segurança e quem coordena o SGSI.
• Revisar escopo, principais controles, evidências já disponíveis e lacunas críticas.
• Combinar quem responde o quê: nem toda pergunta técnica precisa ser respondida pela mesma pessoa.

Durante a auditoria:

• Responder de forma objetiva, sem entrar em detalhes desnecessários, mas sem esconder limitações.
• Usar sempre a trilha controle → recurso técnico → evidência.
• Evitar promessas vagas, como “isso está implementado, só não está documentado”, sem combinarem ações concretas.

Depois da auditoria:

• Registrar resultados, não conformidades, observações e oportunidades de melhoria.
• Traduzir recomendações em ações práticas para TI, com responsáveis e prazos.
• Atualizar a plataforma ou registros do SGSI com o que foi ajustado, para que na próxima auditoria isso já apareça consolidado.

Essa cadência, repetida ciclo após ciclo, transforma a auditoria de um momento de tensão em uma rotina de validação e melhoria contínua.

---

Checklist de preparação conjunta TI mais auditoria

Para fechar, um checklist que TI, segurança e a área responsável pela auditoria podem usar juntos:

1. Linguagem e alinhamento

• [ ] TI entende o escopo, critérios e objetivos da auditoria.
• [ ] Auditoria conhece os principais sistemas, arquiteturas e serviços em uso.
• [ ] Existe um vocabulário mínimo comum sobre controles, evidências e riscos.

2. Mapeamento de controles e recursos técnicos

• [ ] Controles principais estão mapeados e associados a recursos técnicos concretos.
• [ ] Para cada controle, há pelo menos um exemplo claro de evidência técnica.
• [ ] Controles de fachada foram identificados e estão sendo ajustados ou removidos.

3. Organização de evidências

• [ ] Evidências estão centralizadas ou referenciadas em um local único (plataforma, repositório, pasta organizada).
• [ ] Cada evidência tem data, responsável e relação clara com um controle.
• [ ] Exemplo recente de execução de controles recorrentes está disponível (backup, revisão de acesso, testes, etc.).

4. Preparação da equipe

• [ ] Pessoas que serão entrevistadas sabem o que podem ser questionadas e qual é o seu papel.
• [ ] Há orientações básicas sobre como responder: com objetividade, sem prometer o que não existe, sem esconder problemas.
• [ ] Eventuais lacunas já conhecidas foram assumidas, com plano de ação em andamento.

5. Pós auditoria

• [ ] Resultados foram consolidados e comunicados para TI, segurança e gestão.
• [ ] Não conformidades e recomendações viraram ações com prazo e responsável.
• [ ] Controles e evidências foram atualizados para refletir as correções.

Quando TI e auditoria passam a trabalhar assim, a relação deixa de ser de confronto e passa a ser de colaboração para elevar o nível de segurança. A empresa ganha um SGSI mais maduro, menos papel por papel e mais foco em controles que realmente funcionam na prática.