Pentest para PCI DSS: O Que Exigir Antes da Auditoria

Resumo

• O Requisito 11.4 do PCI DSS v4.0.1 estabelece requisitos específicos de pentest para as organizações às quais esses controles se aplicam.
• Um pentest para PCI DSS precisa considerar metodologia, escopo, testes internos e externos, remediação e reteste. Quando a segmentação é usada para isolar o CDE, os controles também precisam ser validados.
• Pentest e scan de vulnerabilidades não cumprem a mesma função. O PCI DSS trata os dois procedimentos como requisitos distintos.
• O relatório precisa permitir que a organização e, quando aplicável, o QSA ou outro avaliador entendam o que foi testado, como, quais falhas foram encontradas e se as correções foram verificadas.
• O melhor momento para contratar o Pentest é com antecedência suficiente para definir o escopo, executar os testes, corrigir achados e concluir o reteste antes da etapa de validação de conformidade.

Uma empresa pode contratar um pentest tecnicamente bom e, mesmo assim, chegar à auditoria com lacunas de escopo, documentação ou evidências. Isso acontece porque, no contexto do PCI DSS, a qualidade técnica do teste é apenas uma parte do problema.

O PCI DSS v4.0.1 define requisitos específicos para a metodologia, a frequência, a cobertura e a verificação das correções. Por isso, o fornecedor precisa entender como explorar vulnerabilidades e como estruturar um projeto que converse com o processo de conformidade.

Esse cuidado é ainda mais relevante em um cenário no qual a exploração de vulnerabilidades ganhou peso como vetor de acesso inicial. O Verizon 2026 Data Breach Investigations Report aponta que a exploração de vulnerabilidades respondeu por 31% dos vetores iniciais conhecidos no conjunto de dados analisados, tornando-se o vetor mais comum naquele recorte. 

Para entender os 12 requisitos do PCI DSS, acesse nosso guia sobre os 12 requisitos do PCI DSS. 

Neste artigo, você irá descobrir o que avaliar antes de contratar o Pentest e como preparar a parte técnica e as evidências para a auditoria. 

O PCI DSS exige pentest?

Sim, para as organizações e cenários aos quais o Requisito 11.4 se aplica. No PCI DSS v4.0.1, o Requisito 11.4 trata de pentests internos e externos, correção de vulnerabilidades exploráveis e, quando aplicável, validação dos controles de segmentação.

• 11.4.1: exige que a empresa defina, documente e implemente uma metodologia de pentest.
• 11.4.2: trata do pentest interno.
• 11.4.3: trata do pentest externo.
• 11.4.4: exige correção das vulnerabilidades exploráveis e repetição do teste para verificar as correções.
• 11.4.5: trata da verificação dos controles de isolamento quando a segmentação é aplicada ao CDE.
• 11.4.6: acrescenta requisitos de frequência para prestadores de serviços quando a segmentação é usada.

A versão 4.0.1 é atualmente a versão ativa do padrão. O PCI Security Standards Council esclarece que a revisão 4.0.1 não criou nem removeu requisitos, mas corrigiu e esclareceu pontos da versão 4.0.

Se a sua dúvida é sobre as mudanças entre essas duas versões, consulte o post da Vantico sobre PCI DSS 4.0.

O que precisa entrar no escopo do Pentest para PCI DSS?

Um dos erros mais caros é partir direto para a execução sem confirmar se o escopo está correto. Em PCI DSS, o Pentest precisa refletir o Cardholder Data Environment (CDE), suas conexões e os componentes que podem afetar sua segurança.

O escopo pode incluir aplicações web, APIs, sistemas internos, ativos externos, redes, controles de acesso e outros componentes relevantes ao ambiente de dados do titular do cartão. A definição exata depende da arquitetura e da aplicabilidade dos requisitos. Testar o escopo errado invalida a conformidade, independentemente da profundidade do Pentest.

Antes do kick-off, a empresa deve ter uma visão atualizada de:

• Quais sistemas fazem parte do CDE.
• Quais ativos e serviços estão expostos externamente.
• Quais redes e sistemas têm conectividade com o CDE.
• Quais aplicações e APIs processam, armazenam e transmitem dados relevantes.
• Quais controles de segmentação são usados para manter outros ambientes fora do escopo.
• Quais mudanças significativas ocorreram desde o último teste.

Pentest interno e externo: por que os dois importam?

Os requisitos 11.4.2 e 11.4.3 tratam separadamente de pentest interno e externo. Ambos devem seguir a metodologia definida pela organização e, quando aplicáveis, ser realizados pelo menos uma vez a cada 12 meses e após mudanças significativas de infraestrutura ou aplicação. 

O padrão também exige a qualificação do responsável e a independência organizacional do tester. Não é necessário que o pentester seja QSA ou ASV. Essas condições estão descritas nos procedimentos oficiais do PCI SSC.

Segmentation Testing: quando a segmentação também precisa ser testada

A segmentação pode ser usada para isolar o CDE e reduzir o número de sistemas sujeitos ao escopo do PCI DSS. Mas, quando a conformidade depende dessa separação, é necessário demonstrar que os controles realmente impedem o acesso entre os ambientes.

O Requisito 11.4.5 estabelece que, quando a segmentação é usada para isolar o CDE, os controles devem ser testados pelo menos uma vez a cada 12 meses e após mudanças nos controles ou métodos de segmentação. Para prestadores de serviços, o Requisito 11.4.6 aumenta essa frequência para pelo menos uma vez a cada seis meses, além de testes após mudanças. O PCI SSC também deixa claro que não é necessário que o responsável seja QSA ou ASV, mas ele deve ser qualificado e organizacionalmente independente.

A Vantico possui um conteúdo específico sobre segmentação de rede para PCI DSS, que aprofunda CDE, testes de segmentação e validação dos controles.

O scan de vulnerabilidades substitui o Pentest para PCI DSS?

Não. O scan de vulnerabilidade e o pentest são processos distintos e cumprem funções diferentes.

O NIST SP 800-115 separa o scan de vulnerabilidades de técnicas de validação, como o pentest. O documento destaca que nenhuma técnica sozinha entrega uma visão completa da segurança, sendo necessário combinar abordagens.

No PCI DSS, essa diferença também aparece na própria estrutura do padrão: scan e pentest são tratados em requisitos distintos. Um scan automatizado pode localizar vulnerabilidades conhecidas e exposições em escala, mas não substitui a validação exigida quando o Requisito 11.4 se aplica.

Para entender melhor essa diferença, acesse Scan de Vulnerabilidades: Vale a Pena em 2026?

O que acontece quando o pentest encontra vulnerabilidades?

Encontrar uma falha não encerra o requisito. O 11.4.4 determina que vulnerabilidades exploráveis e fraquezas de segurança identificadas durante o pentest devem ser corrigidas conforme o risco e que o teste seja repetido para verificar as correções.

O fluxo recomendado é:

1. O pentest identifica e documenta o achado.
2. A organização avalia prioridade e impacto.
3. A equipe responsável implementa a correção.
4. A correção é validada internamente.
5. O fornecedor realiza o reteste.
6. O resultado atualizado é documentado.

O reteste não deveria ser a primeira vez em que a correção é testada. Se a organização implementa uma mudança e a envia diretamente ao fornecedor, o reteste pode acabar funcionando como QA da remediação, prolongando o fechamento do projeto quando a vulnerabilidade ainda é explorável.

O que um relatório de pentest precisa demonstrar para o processo de PCI DSS?

Não existe valor em um relatório que apenas lista vulnerabilidades sem permitir que outra pessoa entenda o escopo e a execução. Em uma avaliação de conformidade, a documentação precisa tornar o trabalho verificável.

Por isso, é importante que o relatório e as evidências permitam identificar:

• Escopo e ativos efetivamente testados.
• Metodologia utilizada.
• Datas e janelas de execução.
• Perspectivas internas e externas contempladas.
• Testes de segmentação, quando aplicáveis.
• Vulnerabilidades e fraquezas identificadas.
• Evidências técnicas suficientes para contextualizar os achados.
• Classificação de risco e recomendações de correção.
• Resultado da remediação e do reteste.

O objetivo é produzir uma documentação que permita à organização e ao avaliador entenderem o que foi testado, quais resultados foram obtidos e se as correções necessárias foram verificadas.

Quem pode realizar o pentest para PCI DSS?

O PCI DSS não exige que o Pentest seja executado por um QSA ou ASV. Os Requisitos 11.4.2, 11.4.3 e 11.4.5 permitem a execução por recurso interno qualificado ou terceiro externo qualificado, desde que exista independência organizacional do tester. Isso está descrito nos procedimentos de teste do PCI Security Standards Council.

Isso também significa que escolher o fornecedor apenas pelo preço ou por uma promessa de curto prazo não é uma boa forma de avaliar capacidade. Para um pentest relacionado ao PCI DSS, verifique a experiência em ambientes de pagamento, composição da equipe, metodologia, profundidade de teste, documentação e capacidade de executar reteste.

Como avaliar uma proposta de pentest para PCI DSS

Antes de comparar duas propostas apenas pelo valor final, confirme se elas estão oferecendo efetivamente o mesmo trabalho. Um pentest de cinco dias e outro de dez, por exemplo, não são comparáveis sem saber quantas horas de execução, quantos profissionais e qual profundidade estão previstos.

Uma proposta deveria deixar claro:

• Quais ativos, aplicações, APIs e redes estão no escopo.
• Se os testes internos e externos aplicáveis estão contemplados.
• Se o Segmentation Testing está incluído quando necessário.
• Quantas horas ou qual esforço técnico está previsto.
• Quem realizará os testes e quais são as qualificações relevantes.
• Qual metodologia será utilizada.
• Como os achados e as evidências serão documentados.
• Se há apoio para dúvidas durante a remediação.
• Se o reteste está incluído e em quais condições.
• Quais entregáveis serão fornecidos ao final.

7 erros que podem comprometer um pentest para PCI DSS

• Contratar um pentest genérico sem mapear o Requisito 11.4

O nome do serviço não garante alinhamento ao objetivo. O fornecedor precisa saber como o teste se relaciona com os requisitos aplicáveis.

• Definir o escopo apenas a partir de uma lista antiga de IPs

O CDE, aplicações, integrações e caminhos de acesso podem mudar. Um escopo desatualizado cria uma falsa sensação de cobertura.

• Testar somente o perímetro externo

Quando o requisito interno é aplicável, o ambiente precisa ser avaliado a partir da perspectiva interna também.

• Assumir que a segmentação funciona porque existe no diagrama

Se a organização usa segmentação para isolar o CDE, os controles precisam ser tecnicamente validados.

• Contratar o teste próximo demais da auditoria

Vulnerabilidades podem exigir correção, validação e reteste. Sem margem no cronograma, qualquer achado relevante vira risco de atraso.

• Enviar correções diretamente para o reteste sem validação interna

Isso aumenta o retrabalho e pode manter o risco aberto por mais tempo.

• Escolher o fornecedor sem avaliar profundidade e evidências

Relatórios genéricos, pouco contexto e ausência de evidências de exploração dificultam tanto a remediação quanto a revisão do trabalho.

Quanto tempo antes da auditoria contratar o pentest?

Não existe um prazo que sirva para todas as empresas. O cronograma depende do tamanho do CDE, do número de ativos, das abordagens necessárias e, principalmente, do tempo de remediação. O planejamento deve reservar espaço para pelo menos cinco etapas:

• Definição e validação do escopo.
• Execução dos testes.
• Emissão e revisão do relatório.
• Remediação dos achados.
• Reteste e consolidação das evidências.

O importante é não tratar a data da auditoria como a data final do pentest. Ela deveria ser posterior ao ciclo de correção e reteste esperado.

Checklist: o que confirmar antes de assinar a proposta

• O CDE está definido e atualizado?
• Os ativos externos relevantes estão mapeados?
• As redes e sistemas internos relacionados ao CDE estão contemplados?
• Aplicações e APIs relevantes fazem parte do escopo?
• O projeto cobre pentest interno e externo quando aplicável?
• A segmentação foi considerada e será testada quando necessário?
• A metodologia está documentada?
• O fornecedor informa quem executará o trabalho e qual o esforço previsto?
• O relatório terá evidências técnicas e contexto suficiente?
• Há tempo no cronograma para correção?
• O reteste está previsto?
• Os entregáveis finais atendem ao processo de validação adotado pela organização?

Como o pentest PCI DSS se encaixa no restante do programa de segurança?

O PCI DSS não existe isolado de outros procedimentos de segurança. O pentest é uma forma de validação adversarial dentro de um programa maior que também pode incluir gestão de vulnerabilidades, controles de configuração, monitoramento, revisão de arquitetura e processos de remediação.

No setor financeiro, também é comum que o PCI DSS conviva com outras obrigações ou frameworks. A Vantico aborda essa relação no conteúdo sobre PCI DSS, LGPD e ISO 27001 no setor financeiro.

Como a Vantico executa Pentest para PCI DSS

A Vantico estrutura projetos de pentest para PCI DSS a partir do CDE e dos requisitos aplicáveis ao ambiente. O objetivo é que o projeto produza dois resultados ao mesmo tempo: uma avaliação ofensiva com profundidade técnica e evidências organizadas para apoiar o processo de conformidade.

Além disso, o reteste ilimitado por 90 dias garante uma ampla janela para validar as correções necessárias.

Conheça a solução de Pentest para PCI DSS da Vantico.

FAQ: Perguntas Frequentes

O PCI DSS exige pentest?

Sim, quando os requisitos de pentest do Requisito 11.4 são aplicáveis à organização. O padrão diferencia testes internos, externos, correção/reteste e validação de segmentação.

Com que frequência o pentest PCI DSS deve ser realizado?

Os Requisitos 11.4.2 e 11.4.3 determinam o pentest interno e externo pelo menos uma vez a cada 12 meses e após mudanças significativas, quando aplicáveis.

O PCI DSS exige pentest interno e externo?

O Requisito 11.4 trata das duas perspectivas separadamente. A aplicabilidade deve ser confirmada conforme o ambiente e o método de validação de conformidade da organização.

O scan de vulnerabilidades substitui o pentest para o PCI DSS?

Não. Scan e pentest são controles distintos e atendem a objetivos diferentes dentro do padrão.

Quando o Segmentation Testing é necessário?

Quando a segmentação é usada para isolar o CDE de outras redes, os controles precisam ser testados para comprovar que o isolamento é efetivo.

Segmentation Testing precisa ser feito a cada seis meses?

Para prestadores de serviços, o Requisito 11.4.6 exige pelo menos uma vez a cada seis meses. Para o Requisito 11.4.5 geral, a frequência é pelo menos uma vez a cada 12 meses, além de testes após mudanças nos controles de segmentação.

O pentester precisa ser QSA ou ASV?

Não. O PCI DSS permite recurso interno qualificado ou terceiro externo qualificado, com independência organizacional. QSA e ASV exercem funções diferentes no ecossistema PCI.

O pentest deve ser feito antes da auditoria?

Sim, com antecedência suficiente para permitir execução, remediação, validação interna e reteste antes da etapa em que as evidências precisam ser apresentadas.