Pentest para PCI DSS: o que o Requisito 11.4 diz

O PCI DSS v4.0.1 coloca o pentest no Requisito 11.4, e o texto dele diz mais do que os resumos costumam dizer. Define um piso de no mínimo uma vez a cada 12 meses, acrescenta a mudança relevante como gatilho separado, pede que o teste seja repetido depois das correções, coloca os prestadores de serviço em um ciclo de seis meses para segmentação e deixa claro — sete vezes — que quem executa o teste não precisa ser um QSA. Esta página cita o texto do requisito e traz o link. Fonte: PCI SSC, acessado em 29 de julho de 2026 — veja a referência no fim.
Feita para as entidades que o PCI DSS trata de forma diferente
PSPs, adquirentes e processadoras. Se a organização é um prestador de serviço no PCI DSS, o ciclo de teste de segmentação é de seis meses, e não de doze. O 11.4.6 é o que mais passa batido em times que leem material escrito para lojistas.
Lojistas com CDE segmentado. Se a segmentação é o que mantém o ambiente de dados de cartão enxuto, os controles de segmentação entram no escopo de teste pelo 11.4.5. É justamente a eficácia deles que sustenta a redução de escopo.
Times se preparando para o QSA. A evidência que um QSA procura é uma metodologia definida, os resultados do teste, a remediação e o reteste. O 11.4.1 lista nove itens que essa metodologia contempla.

O que o PCI DSS pede e onde o pentest entra
Você precisa executar pentests regularmente. O Requisito 11.4 fica dentro do Requisito 11, Test Security of Systems and Networks Regularly. O título da seção diz: «External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected» — pentests externos e internos são executados regularmente, e vulnerabilidades exploráveis e fragilidades de segurança são corrigidas. Ele se divide em sete subrequisitos, do 11.4.1 ao 11.4.7.
Antes da frequência, o padrão pede uma abordagem documentada. O 11.4.1 diz que «A penetration testing methodology is defined, documented, and implemented by the entity» e lista o que ela contempla: entre outros pontos, «Coverage for the entire CDE perimeter and critical systems», «Testing from both inside and outside the network», «Testing to validate any segmentation and scope-reduction controls», «Review and consideration of threats and vulnerabilities experienced in the last 12 months» e «Retention of penetration testing results and remediation activities results for at least 12 months».
Os testes internos e externos são tratados separadamente, com redação quase idêntica. Os dois dizem que o teste é executado «Per the entity's defined methodology», «At least once every 12 months» — no mínimo uma vez a cada 12 meses — e «After any significant infrastructure or application upgrade or change» — depois de qualquer atualização ou mudança relevante de infraestrutura ou de aplicação.
Vale ler duas coisas com atenção. A frequência é «no mínimo uma vez a cada 12 meses»: um piso, nas palavras do próprio padrão, o que não é a mesma coisa que um evento anual. E a mudança é um gatilho separado que convive com esse piso, não uma nota de rodapé. Um ambiente que sobe código toda semana atende a segunda condição muito mais vezes do que a primeira.
É aqui que o PCI DSS é lido errado com mais frequência. O 11.4.2 e o 11.4.3 dizem que o teste é executado «By a qualified internal resource or qualified external third-party» — por um recurso interno qualificado ou por um terceiro externo qualificado — e que «Organizational independence of the tester exists (not required to be a QSA or ASV)».
Esse parêntese está no padrão e aparece sete vezes ao longo do Requisito 11.4. O PCI DSS não pede que o pentest seja executado por um QSA nem por um ASV. Ele pede alguém qualificado, com independência organizacional em relação aos sistemas testados. QSAs avaliam conformidade; ASVs são citados no requisito de varredura de vulnerabilidades, não no de pentest. Sobre qualificação, o guia do padrão menciona «Specific penetration testing certifications» e «Prior experience conducting penetration testing» como pontos a considerar, não como um patamar definido.
O 11.4.4 diz que as vulnerabilidades exploráveis e as fragilidades encontradas no teste são corrigidas «In accordance with the entity's assessment of the risk posed by the security issue», e acrescenta uma linha que muda o formato do requisito inteiro: «Penetration testing is repeated to verify the corrections» — o pentest é repetido para verificar as correções.
O entregável não é o teste. É a correção verificada. Um programa que gera um relatório e para aí cobriu uma parte do 11.4, e não a parte que o fecha.
Onde a segmentação isola o CDE, os controles de segmentação também são testados. Para todas as entidades, o 11.4.5 diz «At least once every 12 months and after any changes to segmentation controls/methods». Para prestadores de serviço, o 11.4.6 diz «At least once every six months and after any changes to segmentation controls/methods» — no mínimo uma vez a cada seis meses e depois de qualquer mudança nos controles ou métodos de segmentação. Os dois pedem a confirmação de que os controles estão «operational and effective, and isolate the CDE from all out-of-scope systems».
Prestadores de serviço multicliente apoiam o pentest externo dos seus clientes conforme o 11.4.3 e o 11.4.4. É o único subrequisito do 11.4 que teve data futura: a nota de aplicabilidade dizia «This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment». Essa data já passou. Do 11.4.1 ao 11.4.6 não havia essa nota, e eles valeram de imediato.
A Strike é uma plataforma de Validação Híbrida Contínua: Threat Emulations conduzidas por IA com validação humana especializada antes da entrega ao cliente. Diante do formato do Requisito 11.4, três pontos se encaixam.
Os testes podem ser disparados por mudanças conforme o escopo configurado, que é a condição de mudança do 11.4.2 e do 11.4.3, e não um calendário. Os achados são reproduzidos e confirmados antes de chegar até você, com 97% de precisão / 3% de falsos positivos (dado reportado pela Strike — como medimos os resultados), porque um achado que o QSA não consegue acompanhar não é evidência. E o reteste — a linha do 11.4.4 — faz parte do modelo de operação em vez de ser um trabalho à parte, embora a disponibilidade de reteste dependa do escopo contratado.
Dois limites, ditos com clareza. A cobertura depende do escopo autorizado e do acesso: um teste de segmentação pelo 11.4.5 ou pelo 11.4.6 é definido de forma deliberada e é um exercício diferente do perímetro. E a Strike não determina a sua conformidade: a Strike apoia programas de auditoria e conformidade e não emite atestações de PCI DSS. A suficiência diante do 11.4 é determinada pelo seu avaliador.
A configuração leva menos de 5 minutos em escopos suportados, e os primeiros achados curados chegam em 1 a 2 horas (os dois dados reportados pela Strike — como medimos os resultados). Escopo e autorização são definidos antes disso e correm num relógio diferente desses dois números. Até hoje, US$4.5B+ em risco mitigado (dado reportado pela Strike — como medimos os resultados).
PCI DSS e pentest, respondido
O PCI DSS pede um pentest anual?
SIM! O texto diz «At least once every 12 months» — no mínimo uma vez a cada 12 meses — no 11.4.2 e no 11.4.3. Os dois também citam «After any significant infrastructure or application upgrade or change» como condição separada, então os doze meses são um piso, e não um cronograma.
O pentest precisa ser executado por um QSA?
Não. O 11.4.2, o 11.4.3, o 11.4.5 e o 11.4.6 dizem que o teste é executado «By a qualified internal resource or qualified external third party» e que «Organizational independence of the tester exists (not required to be a QSA or ASV)».
O time interno pode executar?
O padrão admite «a qualified internal resource», sujeito a independência organizacional: quem testa é separado da gestão dos sistemas-alvo. Ele não define um patamar de certificação; o guia trata certificações e experiência anterior como pontos a considerar.
Uma varredura de vulnerabilidades basta?
Não. O PCI DSS trata varredura e pentest em requisitos diferentes. O 11.4.1 pede que a metodologia contemple «Application-layer penetration testing» e «Network-layer penetration tests», que uma varredura não executa.
De quanto em quanto tempo os prestadores de serviço testam segmentação?
O 11.4.6, que vale apenas para prestadores de serviço, diz «At least once every six months and after any changes to segmentation controls/methods». Para as demais entidades, o 11.4.5 define doze meses.
Qual versão do PCI DSS está vigente?
PCI DSS v4.0.1, publicada em junho de 2024. Em junho de 2026 o PCI SSC abriu um pedido de comentários sobre a v4.0.1 como ponto de partida da próxima iteração, e a v4.0.1 continua sendo a versão publicada. Não foi encontrada data de aposentadoria da v4.0.1 nem data de publicação de uma sucessora nos materiais públicos revisados em 29 de julho de 2026.
Fontes, acessado em 29 de julho de 2026. O texto do requisito é citado do PCI DSS v4.0.1 (junho de 2024), Requisito 11.4, conforme reproduzido no template de Report on Compliance do PCI DSS v4.0.1 (PCI SSC). Versão vigente confirmada em Request for Comments: PCI DSS v4.0.1 (PCI SSC, 3 de junho de 2026). O padrão é obtido na biblioteca de documentos do PCI SSC e é liberado sob um termo de licença com aceite prévio. As citações são reproduzidas no idioma original, inglês, porque é o texto autoritativo do padrão. A Strike não emite atestações de PCI DSS e não é um QSA; esta página resume texto de requisitos de acesso público e não constitui orientação jurídica nem de conformidade. A suficiência diante do Requisito 11.4 é determinada pelo seu avaliador.
Escolhida pelas equipes de segurança que lideram o setor.
Experiência humana. Poder da IA. Segurança superior.
Quer você esteja crescendo rapidamente, fechando contratos corporativos ou apenas cansado de relatórios barulhentos, ajudaremos você a construir uma pilha de segurança que se mova mais rápido do que suas ameaças.






