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

O problema: um pentest que não sobrevive à auditoria

Todas as semanas falamos com equipas de segurança que contrataram um pentest, receberam um PDF de 40 páginas e, na auditoria, ouviram do QSA ou do auditor interno que aquilo "não cumpre". Não porque o teste tenha sido mau — porque o relatório não prova o que a norma exige.

Com o PCI DSS 4.0 (e com a ISO 27001, o DORA e as expectativas dos reguladores financeiros europeus) o pentest deixou de ser uma formalidade anual. Precisa de âmbito definido por metodologia, evidência de exploração, e 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 em pontos que muitas equipas ignoram:

• Metodologia documentada e aceite pela indústria (NIST SP 800-115, PTES ou OWASP WSTG são as referências habituais). O relatório tem de dizer qual foi usada, não apenas listar achados.
• Cobertura de toda a superfície do CDE — perímetro e componentes críticos, camada aplicacional e de rede. Um scan externo com Nessus não é pentest.
• Testes de segmentação: se isola o ambiente de cartões com VLANs e firewalls, o pentest tem de provar que a segmentação funciona. É um dos pontos mais chumbados.
• Periodicidade: pelo menos anual e após qualquer alteração significativa na infraestrutura ou nas aplicações.
• Correção e reteste: as vulnerabilidades exploráveis têm de ser corrigidas e o reteste documentado. Um relatório sem secçã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 — mais uma razão para o relatório identificar a equipa e as certificações.

O que os auditores de ISO 27001 e DORA procuram

Nenhum prescreve uma metodologia, mas ambos fazem as mesmas três perguntas: com que frequência testa, como trata o que encontra e como o comprova. O DORA vai mais longe e exige testes de penetração baseados em ameaças (TLPT) para entidades financeiras críticas. As empresas passam 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.

Anatomia de um relatório que passa

1. Sumário executivo de uma página: âmbito, datas, metodologia, risco global, achados por severidade, estado após reteste.
2. Âmbito e regras de engagement: 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, capturas, passos), recomendação de correção com referências (OWASP, CWE).
5. Testes de segmentação (quando aplicável) com resultado explícito.
6. Reteste com data, achados corrigidos, pendentes e aceites.
7. Atestado assinado, identificando a equipa e as certificações.

Erros que chumbam

• Output de scanner com logótipo de consultora.
• Achados sem evidência ("possível SQL injection").
• Âmbito que não bate certo com o diagrama de rede entregue ao auditor.
• Reteste feito, mas não documentado.
• Pentest de 2023 apresentado em 2026 após duas migrações para a cloud.

Como a Pentest Machine testa isto

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