Pentest PCI DSS 11.4: interno, externo e segmentação

Por que o 11.4 reprova auditorias que "tinham pentest"

Quase toda empresa que processa cartão sabe que precisa de pentest. O que pega de surpresa é a auditoria: o QSA abre o requisito 11.4 do PCI DSS 4.0.1 e não pergunta "vocês fizeram pentest?". Ele percorre uma lista de sub-requisitos, cada um com evidência própria: metodologia, teste interno, teste externo, correção e reteste, segmentação. É comum um relatório cobrir quatro deles e deixar dois em aberto, e aí a empresa paga duas vezes.

Este guia complementa o artigo sobre o que o auditor espera do relatório. Aqui o foco é o requisito em si: o que cada sub-requisito diz, que evidência o QSA costuma pedir, como escopar o teste e onde as empresas tropeçam.

O 11.4 de relance

Item	O que exige	Evidência que o QSA costuma pedir
11.4.1	Metodologia de pentest definida, documentada e implementada	Documento da metodologia, referência a NIST SP 800-115, PTES ou OWASP WSTG, registro de como foi aplicada
11.4.2	Pentest interno ao menos a cada 12 meses e após mudança significativa, por testador qualificado e independente	Relatório com data, escopo, credenciais usadas e qualificação do time
11.4.3	Pentest externo com a mesma frequência e os mesmos gatilhos	Relatório separado do interno, cobrindo o perímetro e os sistemas expostos
11.4.4	Vulnerabilidades exploráveis corrigidas conforme o risco, e teste repetido para confirmar	Estado por achado após o reteste, com data e evidência
11.4.5	Controles de segmentação testados ao menos a cada 12 meses e após mudança nesses controles	Seção explícita com todos os segmentos testados e o resultado
11.4.6	Só para provedores de serviço: segmentação testada a cada 6 meses e após mudanças	Dois ciclos por ano com evidência de cada um
11.4.7	Só para provedores de serviço multi-tenant: apoiar clientes no teste externo (11.4.3 e 11.4.4)	Evidência (inclusive redigida) de que o teste foi feito na infraestrutura do cliente, ou acesso do cliente para testar

Confirme o texto na versão vigente publicada pelo PCI SSC. A numeração acima segue o PCI DSS 4.0.1, e o 11.4.7 passou de boa prática a requisito obrigatório depois de 31 de março de 2025.

11.4.1: a metodologia precisa estar escrita

O padrão pede uma abordagem aceita pela indústria. Na prática, o relatório cita NIST SP 800-115, PTES ou OWASP WSTG e explica como a metodologia foi aplicada. Ela deve cobrir:

o perímetro inteiro do CDE e os sistemas críticos;
testes de dentro e de fora da rede;
validação dos controles de segmentação e de redução de escopo;
testes na camada de aplicação (no mínimo as vulnerabilidades do requisito 6.2.4) e na camada de rede;
a análise de ameaças e vulnerabilidades dos últimos 12 meses;
uma abordagem documentada para tratar o risco do que for encontrado;
retenção dos resultados e da remediação por pelo menos 12 meses.

Guarde a metodologia como documento da empresa, não só como página do relatório do fornecedor. O QSA pode pedir o procedimento mesmo que o PDF já cite a norma.

Escopo: o CDE e tudo que conversa com ele

A maior causa de reprovação não é técnica, é de escopo. O CDE inclui sistemas que armazenam, processam ou transmitem dados de cartão e também os que se conectam a eles ou podem afetar sua segurança. Isso inclui, tipicamente:

aplicações de pagamento, APIs e painéis administrativos;
bancos de dados e filas com PAN;
servidores de salto, VPNs e contas de administração que chegam ao CDE;
ambientes em nuvem (VPCs, security groups, contas) ligados ao CDE;
integrações com adquirentes, gateways e antifraude.

O escopo do pentest precisa bater com o diagrama de rede e o fluxo de dados que você entrega ao QSA. Se o diagrama mostra cinco sub-redes e o relatório testou duas, o requisito fica em aberto.

Exemplo de escopo: um e-commerce com checkout próprio

Imagine uma loja que recebe o cartão no próprio checkout. O ambiente tem uma rede corporativa, uma VPC de produção com a aplicação e uma VPC isolada com o banco que guarda PAN criptografado, acessada só por um servidor de salto. A empresa afirma que a rede corporativa e a VPC de aplicação estão "fora" do CDE por segmentação.

Um escopo defensável para o pentest ficaria assim:

Externo (11.4.3): o site, as APIs, o painel administrativo, a VPN, o DNS e qualquer serviço descoberto no inventário de IPs públicos.
Interno (11.4.2): partindo da rede corporativa com um usuário comum, e de dentro da VPC de aplicação, tentando chegar ao banco e ao servidor de salto.
Segmentação (11.4.5): de cada segmento declarado "fora do CDE" (corporativa, aplicação, ambientes de homologação e de terceiros) para o CDE, em todas as portas e caminhos.
Aplicação: testes autenticados no checkout e no painel, com perfis diferentes.

Note que a premissa "está fora do CDE por segmentação" só vale se o teste de segmentação a provar. Se um servidor da VPC de aplicação alcança o banco, o próprio servidor entra no escopo do PCI.

11.4.2 e 11.4.3: interno e externo são testes diferentes

O teste externo parte da internet contra o que está exposto: sites, APIs, VPN, e-mail, DNS, serviços esquecidos. O teste interno parte de dentro: da rede corporativa, de um segmento não confiável ou do CDE, simulando um atacante que já passou pelo perímetro, um funcionário mal-intencionado ou um dispositivo comprometido.

Um scan de vulnerabilidades externo (ASV) não substitui nenhum dos dois. O ASV atende o requisito 11.3.2; o pentest é conduzido por pessoa, prova exploração e encadeia falhas. Os dois coexistem.

Mudança significativa é o gatilho que muita empresa esquece. Nova aplicação de pagamento, migração de nuvem, troca de adquirente ou mudança de topologia ou de firewall dentro do escopo exigem novo teste, mesmo que o anual tenha sido feito em março. Defina internamente o que conta como mudança significativa e registre a decisão com data.

11.4.4: reteste não é opcional

Vulnerabilidades exploráveis precisam ser corrigidas conforme o risco atribuído a elas, e o teste repetido para confirmar. O relatório final mostra, por achado, o estado: corrigido e validado, pendente com prazo, ou risco aceito com justificativa formal. Um PDF sem seção de reteste deixa o 11.4.4 sem evidência.

Planeje o calendário com folga: pentest em outubro, correção em novembro e reteste em dezembro cabem no ano. Pentest em dezembro, não.

11.4.5 e 11.4.6: segmentação, o ponto mais reprovado

Segmentar a rede reduz o escopo do PCI, mas só se alguém prova que a segmentação funciona. O teste tenta, de redes fora do CDE, alcançar o CDE em todas as portas e caminhos que os controles deveriam bloquear: VLANs, firewalls, ACLs, regras de security group e políticas de rede em Kubernetes.

Teste cada segmento fora do CDE em direção ao CDE, não uma amostra.
Cubra todos os controles de segmentação, inclusive os de nuvem e de contêineres.
Repita após qualquer mudança nesses controles.
Provedores de serviço repetem a cada 6 meses (11.4.6), não só uma vez por ano.
O resultado precisa ser explícito: "nenhum caminho encontrado", com evidência, ou os caminhos encontrados.

Onde as empresas tropeçam

Segmentação declarada, nunca testada. O diagrama mostra o isolamento, mas ninguém tentou atravessá-lo. É o achado de auditoria mais comum neste requisito.
Só teste não autenticado. O pentest bate no login e para. O risco real está atrás dele, com perfis comuns e administrativos.
Reteste sem data ou sem evidência. O achado "sumiu" do relatório novo, mas não há prova de que foi corrigido.
Escopo menor que o diagrama. O fornecedor testa os IPs que o cliente informou, e o ambiente de homologação com dados reais fica de fora.
Falta de independência. Quem opera o ambiente também faz o teste.
Mudança significativa ignorada. A migração para a nuvem aconteceu depois do pentest anual e não gerou novo teste.
Ferramenta no lugar de pessoa. Um relatório que é a saída de um scanner não prova exploração nem metodologia.

Quem pode testar: qualificação e independência

O padrão exige que o testador seja qualificado e organizacionalmente independente de quem gerencia o ambiente testado. Não é preciso ser QSA nem ASV. O time interno de infraestrutura que opera o CDE não deve ser quem testa. Um time interno de segurança separado pode atender, se houver independência organizacional real, e um fornecedor externo costuma simplificar a conversa com o QSA.

Peça ao fornecedor o currículo e as certificações dos testadores e inclua a identificação no relatório. Veja também as 10 perguntas para fazer antes de contratar um pentest.

Como escolher o fornecedor para o 11.4

Peça um relatório de exemplo anonimizado e confira se ele tem metodologia, evidência reproduzível, seção de segmentação e reteste.
Pergunte se o reteste está incluído e quantas rodadas.
Confirme que o mesmo time cobre rede e aplicação, ou que há coordenação entre eles.
Verifique se o fornecedor aceita testar por segmento e entregar o resultado da segmentação separadamente.
Combine o formato de entrega com o QSA antes de contratar, para evitar retrabalho.

Checklist antes de contratar

[ ] Diagrama de rede e fluxo de dados do cartão atualizados
[ ] Lista de todos os segmentos "fora do CDE" que dependem de segmentação
[ ] Inventário de IPs, domínios e APIs expostos
[ ] Contas de teste para cada perfil (usuário comum, administrador, parceiro)
[ ] Definição interna de "mudança significativa" e histórico do último ano
[ ] Janelas de teste combinadas com operações e com o NOC
[ ] Contatos de emergência durante a execução
[ ] Data prevista do reteste e responsável pelas correções

Em que ordem fazer ao longo do ano

Trimestre 1: escopo e diagrama de rede atualizados; contratação.
Trimestre 2: pentest externo, interno e de segmentação.
Trimestre 3: correções e reteste; arquivo de evidências.
Contínuo: gatilho de mudança significativa e, para provedores de serviço, segmentação a cada 6 meses.

Para saber o que esperar de preço e prazo, veja quanto custa um pentest. Se a sua empresa também tem requisitos de ISO 27001 ou SOC 2, um mesmo teste bem escopado pode servir aos dois: veja pentest para ISO 27001, SOC 2 e LGPD.

Perguntas frequentes

Scan de vulnerabilidades substitui o pentest do 11.4?

Não. O scan automatizado atende outros requisitos, como o 11.3. O 11.4 exige teste conduzido por pessoa qualificada, com metodologia e prova de exploração.

Com que frequência é preciso fazer o pentest PCI?

No mínimo a cada 12 meses, interno e externo, e também após qualquer mudança significativa na infraestrutura ou nas aplicações do escopo.

Quando o teste de segmentação é obrigatório?

Se você usa segmentação para reduzir o escopo do PCI, ela precisa ser testada ao menos a cada 12 meses e após mudanças nos controles. Provedores de serviço testam a cada 6 meses.

O time interno pode fazer o pentest?

Pode, desde que seja qualificado e organizacionalmente independente de quem opera o ambiente testado. Muitas empresas contratam um fornecedor externo para simplificar a avaliação do QSA.

O reteste precisa estar no relatório?

Sim. O requisito pede que as vulnerabilidades exploráveis sejam corrigidas e o teste repetido, e o relatório deve mostrar o estado de cada achado após o reteste.

O pentest precisa ser feito por um QSA ou ASV?

Não. O padrão exige testador qualificado e independente, mas não que ele seja QSA ou ASV. O QSA é quem avalia a evidência na auditoria.

Preciso testar ambientes de homologação?

Se eles têm conexão com o CDE ou usam dados reais de cartão, sim, entram no escopo. Ambientes isolados e sem dados reais podem ficar de fora, desde que a segmentação seja demonstrada.

Sou provedor multi-tenant. O que muda?

Além do 11.4.6, o 11.4.7 pede que você apoie os clientes no teste externo, com evidência de que o teste foi feito na infraestrutura deles ou com acesso para que testem por conta própria.

Próximo passo

Se sua auditoria PCI está no calendário, o melhor momento para alinhar escopo e diagrama é antes do teste. Peça um orçamento e receba uma proposta com escopo, segmentação e reteste incluídos.