Como avaliar um relatório de Red Team: 12 perguntas do decisor

O relatório do Red Team chegou. São 80-150 páginas, design caprichado, palavras importantes. Como você sabe se vale o que custou? Esta é a pergunta que separa CISOs que extraem valor do exercício dos que arquivam o documento como "fizemos Red Team em 2026" e seguem a vida.

As 12 perguntas abaixo são o que uso para auditar qualquer relatório de Red Team — meu ou de fornecedores que indico. Se algumas dessas respostas estão ausentes ou fracas, você tem direito de pedir complemento sem custo adicional.

Nível 1: estrutura e camadas

Pergunta 1: O relatório tem 3 camadas distintas?

Relatório bem feito tem três audiências e três documentos (ou três seções claramente separadas):

• Executive Summary (2-5 páginas): para CEO/board. Linguagem de risco e negócio. Sem jargão técnico. Métricas-chave.
• Management Report (15-30 páginas): para CISO, head de TI, head de risco. Narrativa da operação, métricas detalhadas, mapa ATT&CK, recomendações estratégicas.
• Technical Findings (50-100+ páginas): para time técnico. Cada finding com prova, replay step-by-step, recomendação técnica acionável.

Se você recebeu um único documento "tudo em um", já é red flag. Quem entrega Red Team profissional respeita as audiências.

Pergunta 2: O Executive Summary funciona sozinho?

Pegue só essas 2-5 páginas e leia como se fosse um C-level sem contexto. Você consegue responder:

• O que foi testado? (escopo em uma frase)
• Quem foi simulado? (adversário-modelo)
• O Red Team foi bem sucedido? Em quanto tempo?
• Em que momento o time defensivo detectou (se detectou)?
• Quais são os 3-5 riscos críticos identificados?
• O que precisa ser feito nos próximos 90 dias?

Se o executive summary não responde isso claramente, ele falhou. Peça correção.

Nível 2: rigor técnico

Pergunta 3: Cada ação está mapeada no MITRE ATT&CK?

Para cada técnica usada pelo operador, deve haver:

• ATT&CK ID (ex: T1078.001)
• Nome da técnica
• Sub-técnica se aplicável
• Descrição contextual: "Como o adversário X usa esta técnica"

Sem isso, você não consegue traduzir o relatório para a linguagem do seu programa de detecção. Veja por que isso virou padrão em Adversary Emulation e MITRE ATT&CK.

Pergunta 4: Há Heat Map ATT&CK consolidado?

Idealmente uma imagem clara mostrando as 14 táticas em colunas, células de técnica colorizadas por status de detecção (verde/amarelo/vermelho). É a "capa visual" do relatório. Se não tem, peça.

Pergunta 5: Cada finding técnico tem prova replicável?

Olhe 3-5 findings aleatórios. Para cada um:

• Há screenshot/log mostrando a evidência?
• Os passos descrevem o que foi feito de forma que outro operador poderia replicar?
• Há indicação de horário/timestamp dentro do ambiente?
• O finding está classificado em severidade com justificativa?

Se findings são vagos ("conseguimos acesso à rede interna após explorar vulnerabilidade não especificada"), peça detalhamento. Você pagou por isso.

Pergunta 6: As métricas de detecção/resposta estão lá?

O relatório precisa ter, em algum lugar visível:

• MTTD por tática: Mean Time To Detect, separado por fase da kill chain
• MTTR por incidente: Mean Time To Respond, quando aplicável
• Cobertura ATT&CK: percentual de técnicas testadas que foram detectadas
• Objetivos atingidos vs autorizados
• TTPs evadidas (não detectadas)

Para entender essas métricas em profundidade, leia MTTD e MTTR para o board.

Nível 3: utilidade para remediação

Pergunta 7: Cada finding tem recomendação técnica específica?

"Implementar controle adequado" é recomendação inútil. "Codificar regra Sigma X no SIEM monitorando evento Y" é recomendação acionável. Boa recomendação inclui:

• Comando, código ou config exata onde possível
• Onde aplicar (sistema, console)
• Esforço estimado (horas-pessoa)
• Pré-requisitos
• Validação: como confirmar que ficou efetivo

Pergunta 8: Há recomendações estratégicas além das táticas?

Findings técnicos são óbvios. Bom relatório também identifica padrões: "8 dos 12 findings críticos têm raiz em má configuração de Active Directory. Recomendamos projeto de hardening AD de 6 meses com escopo X."

Padrões viram projetos de programa, não tickets individuais. É onde mora 80% do valor de longo prazo.

Pergunta 9: Há plano de remediação prioritizado?

Bom relatório vem com tabela:

• 30 dias: ações críticas + quick wins
• 60-90 dias: hardening estrutural
• 180 dias: melhorias de processo e treinamento
• 12 meses: investimentos de tooling/arquitetura

Sem isso, você fica com a tarefa de criar essa estrutura — que é trabalho de 40-80h do CISO. Por que pagar Red Team que não entrega isso?

Nível 4: aprendizado e contexto

Pergunta 10: A narrativa da operação está coerente?

Algumas páginas no início do Management Report devem contar a história da operação:

• Como obtivemos Initial Access
• Como mantivemos persistência
• Como escalamos privilégios
• Como nos movemos lateralmente
• Como atingimos o objetivo
• Em que momento fomos detectados (se fomos)

Lida em voz alta, deveria fazer sentido como uma história. Se parece random walk técnico, falhou a narrativa — e o board vai sentir isso.

Pergunta 11: Há comparação com adversários reais conhecidos?

"Esta TTP é a mesma usada pelo grupo X no caso Y de 2024" é a frase que conecta o exercício à realidade. Sem isso, você fica com sensação abstrata. Com isso, vira concreto.

Pergunta 12: Há proposta de próximo ciclo?

Relatório bom termina sugerindo:

• Quando fazer próximo exercício (12-18 meses?)
• Qual deveria ser o foco mudado (adversário novo? cenário novo?)
• O que fazer no meio do caminho (Purple Team em 6 meses?)
• Métricas a acompanhar trimestralmente

Sem isso, o relatório é um ponto isolado. Com isso, vira programa.

Os sinais de relatório ruim

Além das 12 perguntas, alguns red flags imediatos:

• Excesso de jargão sem explicação no Executive Summary. CEO não precisa saber o que é "Kerberoasting". Precisa saber que credenciais administrativas foram extraídas usando técnica conhecida do MITRE ATT&CK.
• Severidade inflada: todos os findings são "Críticos". Isso é cobertura comercial, não rigor.
• Templates óbvios: o relatório parece preenchimento de template com seu nome no lugar de "<client>". Em alguns lugares, talvez tenha esquecido um placeholder.
• Recomendações vagas: "implementar Zero Trust" é meme, não recomendação.
• Falta de versão técnica: só tem Executive Summary e algumas screenshots. Você comprou consultoria, não auditoria fluffy.
• Sem rastreamento ATT&CK: já abordado, mas merece ênfase. Em 2026, é o mínimo.

O processo de aceite

Estabeleça SLA contratual de aceite:

1. Fornecedor entrega versão draft do relatório (15-20 dias após fim da operação)
2. Você tem 10 dias úteis para revisar
3. Você envia lista consolidada de pedidos de correção/complemento
4. Fornecedor responde em 5 dias úteis
5. Aceite formal após segunda iteração
6. Apresentação executiva ao board (se contratada) em até 30 dias

Sem esse processo, você assina aceite no calor da entrega e depois descobre o que falta — tarde demais para negociar.

Pagamento amarrado a aceite

Modelo recomendado de pagamento:

• 30% no início (planejamento)
• 30% no meio (operação)
• 30% na entrega do draft
• 10% após aceite formal do relatório final e executive readout

Os últimos 10% existem para garantir qualidade da entrega final. Sem essa amarração, há incentivo para o fornecedor entregar relatório fraco e seguir para o próximo cliente.

Conclusão

Relatório de Red Team vale o que pagamos quando ele se torna ferramenta de mudança real. As 12 perguntas deste artigo te ajudam a validar isso antes do aceite final. Use-as como checklist em qualquer relatório que receber — meu, do seu fornecedor preferido, ou de qualquer outro.

Se você ainda está na fase de avaliar propostas (antes do engagement), revise nosso guia completo do decisor com 12 perguntas para o fornecedor antes da contratação.