Pentest para PCI DSS 4.0 e BACEN: o que o auditor realmente espera do seu relatório

O problema: pentest que não serve para a auditoria

Toda semana falamos com times de segurança que contrataram um pentest, receberam um PDF de 40 páginas e, na hora da auditoria, ouviram do QSA ou do auditor interno que aquilo "não atende". Não porque o teste foi ruim — porque o relatório não prova o que a norma exige.

No PCI DSS 4.0 e na regulação do Banco Central o pentest deixou de ser uma formalidade anual. Ele precisa ter escopo definido por metodologia, evidência de exploração, correção e reteste documentados. Sem isso, a empresa paga duas vezes.

O que o PCI DSS 4.0 pede (requisito 11.4)

O requisito 11.4 é explícito sobre alguns pontos que muita gente ignora:

• Metodologia documentada e aceita pela indústria (o padrão de mercado é citar NIST SP 800-115, PTES ou OWASP WSTG). O relatório precisa dizer qual foi usada, não apenas listar findings.
• Cobertura de toda a superfície do CDE — perímetro e componentes críticos, camada de aplicação e de rede. Um scan externo com Nessus não é pentest.
• Testes de segmentação: se você isola o ambiente de cartão com VLANs e firewalls, o pentest precisa provar que a segmentação funciona. É um dos pontos mais reprovados.
• Periodicidade: ao menos anual e após qualquer mudança significativa em infraestrutura ou aplicação.
• Correção e reteste: vulnerabilidades exploráveis encontradas devem ser corrigidas e o reteste documentado. Um relatório sem seção de reteste deixa o requisito em aberto.

A versão 4.0 também exige que quem executa o teste tenha independência organizacional e qualificação demonstrável — outro motivo para o relatório identificar a equipe e suas certificações.

O que o Banco Central espera

A Resolução CMN 4.893/2021 (e a 4.658 antes dela) obriga instituições financeiras e de pagamento a manter política de segurança cibernética com procedimentos de testes periódicos, gestão de incidentes e controle sobre serviços de terceiros. O BACEN não prescreve uma metodologia, mas na supervisão pergunta três coisas: com que frequência você testa, como trata o que encontra e como comprova.

Na prática, fintechs reguladas passam a supervisão quando têm: calendário de pentest por criticidade, relatórios com PoC e classificação de risco, plano de tratamento com prazos, e evidência de reteste. O mesmo pacote serve para o Open Finance e para due diligence de bancos parceiros.

Anatomia de um relatório que passa

1. Sumário executivo de uma página: escopo, período, metodologia, risco geral, número de achados por severidade, status pós-reteste.
2. Escopo e regras de engajamento: URLs, IPs, credenciais usadas (black/grey/white-box), exclusões e janelas.
3. Metodologia nomeada com as fases executadas.
4. Achados com: descrição, CVSS e risco de negócio, evidência reproduzível (request/response, screenshots, passos), recomendação de correção com referência (OWASP, CWE).
5. Testes de segmentação (quando aplicável) com resultado explícito.
6. Reteste com data, achados corrigidos, pendentes e aceitos.
7. Atestado assinado, identificando a equipe e as certificações.

Erros que reprovam

• Relatório de scanner com logo de consultoria.
• Findings sem evidência ("possível SQL injection").
• Escopo que não bate com o diagrama de rede entregue ao auditor.
• Reteste feito, mas não documentado.
• Pentest de 2023 apresentado em 2026 depois de duas migrações de cloud.

Como a Pentest Machine testa isso

Nossos relatórios seguem a estrutura acima por padrão, com metodologia nomeada (OWASP WSTG, PTES, NIST 800-115), PoC para cada achado, testes de segmentação quando o escopo é PCI e reteste incluso no preço. Se a sua auditoria está no calendário, o momento de alinhar o escopo é antes do teste — não depois do relatório.