Resumo: O PCI DSS 4.0 expandiu significativamente os requisitos de pentesting em comparação com a versão 3.2.1. Os requisitos com data futura tornaram-se obrigatórios em 31 de março de 2025, o que significa que toda organização que processa, armazena ou transmite dados de cartão de pagamento deve agora cumprir as regras mais rigorosas. As principais mudanças incluem metodologia documentada obrigatória, requisitos explícitos de testes internos e externos, verificação expandida de segmentação, testes de camada de aplicação alinhados ao OWASP Top 10 e a nova opção de validação de abordagem personalizada que exige testes ainda mais rigorosos. Provedores de serviço enfrentam obrigações adicionais, incluindo testes de segmentação semestrais e verificação de isolamento multi-tenant. Este guia mapeia cada requisito, explica o que mudou e fornece um checklist prático de preparação para avaliações de 2026.
O PCI DSS 4.0 representa a revisão mais significativa do Padrão de Segurança de Dados da Indústria de Cartões de Pagamento desde sua criação. Lançado em março de 2022 com um período de transição que terminou em 31 de março de 2025, o padrão atualizado introduziu mudanças substanciais nos requisitos de pentesting que muitas organizações ainda estão trabalhando para entender e implementar. Com as avaliações de 2026 se aproximando, a janela de preparação está se estreitando.
Se você processa, armazena ou transmite dados de cartão de pagamento -- ou se fornece serviços a organizações que o fazem -- entender os requisitos de pentesting do PCI DSS 4.0 não é opcional. Diferentemente de alguns frameworks de conformidade onde o pentesting é implícito ou recomendado, o PCI DSS o exige explicitamente com requisitos específicos de escopo, metodologia e frequência que seu Assessor de Segurança Qualificado (QSA) avaliará em detalhes.
O Que Mudou do PCI DSS 3.2.1 para o 4.0
O PCI DSS 3.2.1 abordava pentesting principalmente no Requisito 11.3, com linguagem relativamente ampla que dava às organizações latitude significativa em como conduziam e documentavam seus testes. A versão 4.0 renumerou, expandiu e tornou esses requisitos consideravelmente mais rigorosos. Aqui estão as mudanças mais significativas.
Requisitos Renumerados
O PCI DSS 4.0 reorganizou a estrutura de requisitos. O pentesting foi movido do Requisito 11.3 para o Requisito 11.4, com sub-requisitos 11.4.1 a 11.4.7. Isso não é apenas cosmético -- a renumeração reflete conteúdo expandido e sub-requisitos adicionais que não existiam na versão 3.2.1.
Metodologia Documentada Obrigatória
O Requisito 11.4.1 agora exige explicitamente que uma metodologia de pentesting seja definida, documentada e implementada. A metodologia deve:
- Ser baseada em uma abordagem aceita pela indústria (PTES, OSSTMM, OWASP Testing Guide ou NIST SP 800-115)
- Cobrir todo o perímetro do ambiente de dados do portador de cartão (CDE) e sistemas críticos
- Incluir testes internos e externos
- Incluir testes de dentro e de fora da rede
- Incluir testes de camada de aplicação que abordem, no mínimo, as vulnerabilidades listadas no Requisito 6.2.4 (que se alinha estreitamente ao OWASP Top 10)
- Incluir testes de penetração de camada de rede que cubram todas as funções de rede e sistemas operacionais
Na versão 3.2.1, as organizações podiam se virar com uma metodologia que referenciasse padrões da indústria em termos gerais. Na versão 4.0, o QSA avaliará se sua metodologia documentada aborda especificamente cada um desses elementos e se seus testes reais seguiram a metodologia documentada. Uma referência vaga a "melhores práticas da indústria" não será aceita.
Escopo e Criticidade Expandidos
O Requisito 11.4.2 especifica que pentesting interno deve ser realizado em todos os sistemas dentro do escopo. A definição de "dentro do escopo" no PCI DSS 4.0 inclui qualquer sistema que armazena, processa ou transmite dados de portadores de cartão, qualquer sistema que esteja no mesmo segmento de rede que os sistemas CDE e qualquer sistema que possa afetar a segurança do CDE. Isso é mais amplo do que muitas organizações percebem, e subdimensionar o escopo do pentesting é uma das descobertas mais comuns que os QSAs reportam.
O Requisito 11.4.3 cobre pentesting externo, exigindo testes do perímetro acessível externamente do CDE e de quaisquer sistemas críticos acessíveis de fora da rede da organização.
Testes de Segmentação: Agora Mais Rigorosos
O Requisito 11.4.5 aborda a verificação de segmentação de rede -- testes que confirmam que os controles de segmentação de rede isolam efetivamente o CDE de sistemas fora do escopo. Na versão 3.2.1, os testes de segmentação eram obrigatórios, mas a metodologia era vagamente definida. Na versão 4.0:
- Os testes de segmentação devem confirmar que os métodos de segmentação estão operacionais e eficazes
- Os testes devem verificar que sistemas fora do escopo não podem se comunicar com sistemas no CDE
- Para provedores de serviço, os testes de segmentação devem ser realizados a cada seis meses (não apenas anualmente)
- Os testes devem ocorrer após quaisquer alterações nos controles ou métodos de segmentação
O requisito semestral para provedores de serviço é particularmente significativo. Organizações que realizavam verificação de segmentação anual na versão 3.2.1 agora precisam dobrar sua frequência de testes, o que tem implicações significativas de custo e operação.
Requisitos com Data Futura (Agora Obrigatórios)
Vários requisitos de pentesting foram designados como "data futura" quando o PCI DSS 4.0 foi lançado, significando que eram melhores práticas até 31 de março de 2025, após o que se tornaram obrigatórios. Estes agora são totalmente aplicáveis:
- 11.4.1: O requisito de metodologia documentada descrito acima.
- 11.4.6: Para provedores de serviço, o pentesting deve confirmar especificamente que a abordagem personalizada resulta nos controles de segurança esperados. Este é um território novo -- a abordagem personalizada é um conceito do PCI DSS 4.0 que permite que organizações atendam objetivos de segurança através de controles alternativos, mas esses controles alternativos devem ser validados por meio de testes.
- 11.4.7: Provedores de serviço multi-tenant devem permitir pentesting por seus clientes. Isso significa que se você fornece infraestrutura compartilhada para comerciantes, deve ter processos e políticas que permitam que seus inquilinos realizem (ou tenham realizado em seu nome) pentesting de seus ambientes dentro de sua infraestrutura.
A Distinção entre Varredura e Pentest: Crítica para a Conformidade
O PCI DSS 4.0 é excepcionalmente claro sobre a diferença entre varredura de vulnerabilidades e pentesting, e confundir os dois é uma das maneiras mais rápidas de falhar em uma avaliação.
Varreduras de vulnerabilidades (Requisitos 11.3.1 e 11.3.2) são avaliações automatizadas que identificam vulnerabilidades conhecidas, configurações incorretas e patches ausentes nos sistemas. O PCI DSS exige:
- Varreduras internas de vulnerabilidades pelo menos trimestralmente
- Varreduras externas de vulnerabilidades pelo menos trimestralmente por um Fornecedor de Varredura Aprovado (ASV)
- Varreduras após qualquer mudança significativa
Testes de penetração (Requisito 11.4) vão além da varredura para incluir exploração ativa. O padrão declara explicitamente que pentesting envolve "tentar explorar vulnerabilidades" para "determinar se acesso não autorizado ou outra atividade maliciosa é possível." Um pentesting que apenas identifica vulnerabilidades sem tentar exploração não satisfaz o Requisito 11.4.
Essa distinção importa porque alguns fornecedores comercializam varredura de vulnerabilidades como pentesting. Um relatório de varredura automatizada, independentemente de quão abrangente seja, não satisfaz o requisito de pentesting. Seu QSA examinará a metodologia do relatório e as evidências para determinar se houve tentativa real de exploração. Se as evidências mostrarem apenas saída de scanner sem tentativas de exploração, o requisito será marcado como não atendido.
A implicação para plataformas de testes automatizados com IA é importante: a plataforma deve demonstrar validação de exploração, não apenas detecção de vulnerabilidades, para satisfazer os requisitos de pentesting do PCI DSS. Os testes automatizados do ThreatExploit incluem tentativas ativas de exploração com captura de evidências, que é especificamente projetado para atender a esse requisito.
Detalhamento Requisito por Requisito
Aqui está um mapeamento detalhado de cada requisito de pentesting sob o PCI DSS 4.0, o que o QSA avalia e como satisfazê-lo.
Requisito 11.4.1: Metodologia e Escopo
O que diz: Uma metodologia de pentesting é definida, documentada e implementada, e inclui abordagens de pentesting aceitas pela indústria, cobertura de todo o perímetro do CDE e sistemas críticos, testes de dentro e de fora da rede, e testes para validar controles de segmentação e redução de escopo.
O que o QSA avalia:
- Existe um documento de metodologia escrito?
- Ele referencia um padrão reconhecido (PTES, OSSTMM, OWASP, NIST)?
- O escopo cobre todos os sistemas dentro do escopo?
- Há evidência de que os testes seguiram a metodologia documentada?
Como satisfazê-lo: Mantenha um documento de política de pentesting que especifique a metodologia, o processo de definição de escopo, a frequência de testes e os requisitos de relatórios. Garanta que seu provedor de testes (seja interno, externo ou automatizado) siga e documente a aderência a essa metodologia.
Requisito 11.4.2: Pentesting Interno
O que diz: Pentesting interno é realizado conforme a metodologia definida pelo menos uma vez a cada 12 meses e após qualquer mudança significativa na infraestrutura ou aplicação.
O que o QSA avalia:
- O teste interno foi realizado nos últimos 12 meses?
- O relatório do teste cobre todos os sistemas internos dentro do escopo?
- Os testes foram repetidos após mudanças significativas?
- As vulnerabilidades identificadas foram corrigidas e retestadas?
Como satisfazê-lo: Realize pentesting interno anualmente no mínimo. Documente o que constitui uma "mudança significativa" em sua metodologia. Mantenha evidências de que retestes ocorreram após grandes mudanças de infraestrutura, implantações de aplicações ou modificações de rede.
Requisito 11.4.3: Pentesting Externo
O que diz: Pentesting externo é realizado conforme a metodologia definida pelo menos uma vez a cada 12 meses e após qualquer mudança significativa na infraestrutura ou aplicação.
O que o QSA avalia:
- Mesmos critérios do 11.4.2, aplicados a testes externos
- Todo o perímetro externo foi testado?
- Todos os sistemas acessíveis externamente foram incluídos?
Como satisfazê-lo: Realize pentesting externo anualmente no mínimo. Garanta que o escopo inclua todos os sistemas voltados à internet no CDE: aplicações web, APIs, endpoints de VPN, gateways de e-mail e quaisquer outros serviços acessíveis externamente.
Requisito 11.4.4: Remediação e Reteste
O que diz: Vulnerabilidades exploráveis e fraquezas de segurança encontradas durante o pentesting são corrigidas, e os testes são repetidos para verificar as correções.
O que o QSA avalia:
- Existe um plano de remediação para cada descoberta?
- As descobertas críticas e altas foram remediadas?
- Há evidência de reteste após a remediação?
- A evidência de reteste está documentada no relatório?
Como satisfazê-lo: Estabeleça um fluxo de trabalho de remediação com SLAs definidos por severidade (ex.: crítico: 15 dias, alto: 30 dias, médio: 90 dias). Após a remediação, realize retestes e documente os resultados. Testes automatizados com IA tornam o reteste eficiente e imediato -- você pode validar uma correção em horas após a implantação, em vez de agendar um engajamento de acompanhamento.
Requisito 11.4.5: Verificação de Segmentação
O que diz: Se a segmentação é usada para isolar o CDE, pentesting é realizado para verificar se os controles de segmentação estão operacionais e eficazes -- pelo menos a cada 12 meses e a cada seis meses para provedores de serviço.
O que o QSA avalia:
- Existe segmentação entre o CDE e redes fora do escopo?
- Os controles de segmentação foram testados tentando penetrar de segmentos fora do escopo para segmentos dentro do escopo?
- Para provedores de serviço: dois testes de segmentação foram realizados nos últimos 12 meses?
- Os testes foram repetidos após mudanças nos métodos de segmentação?
Como satisfazê-lo: Agende testes de segmentação específicos na frequência exigida. Os testes devem incluir tentativas de cruzar limites de segmentos usando análise de roteamento, teste de regras de firewall, tentativas de VLAN hopping e exploração de quaisquer serviços que abrangem segmentos. Testes automatizados podem realizar verificação de segmentação de forma contínua, detectando desvios de configuração entre ciclos formais de avaliação.
Requisito 11.4.6: Validação de Abordagem Personalizada (Provedores de Serviço)
O que diz: Se usar a abordagem personalizada para qualquer requisito do PCI DSS, a abordagem personalizada da entidade é confirmada por meio de pentesting.
O que o QSA avalia:
- A organização adotou a abordagem personalizada para algum requisito?
- Se sim, o pentesting valida especificamente os controles alternativos?
- Há evidência documentada de que os controles alternativos alcançam o objetivo de segurança pretendido?
Como satisfazê-lo: Se você usa a abordagem personalizada, trabalhe com seu QSA para definir cenários específicos de pentesting que validem seus controles alternativos. Documente a abordagem de teste, os resultados esperados e os resultados reais. Isso requer coordenação estreita entre seu programa de testes e sua equipe de conformidade.
Requisito 11.4.7: Suporte a Testes de Provedores de Serviço Multi-Tenant
O que diz: Provedores de serviço multi-tenant suportam as solicitações de pentesting de seus clientes de acordo com métodos especificados.
O que o QSA avalia:
- O provedor de serviço tem uma política para suportar pentesting de clientes?
- Existem procedimentos definidos para que clientes solicitem e realizem testes?
- Prazos e métodos razoáveis são especificados?
Como satisfazê-lo: Desenvolva uma política de pentesting para clientes que defina: como clientes solicitam testes, quais métodos são permitidos (apenas externo, interno com coordenação, varredura automatizada), procedimentos de agendamento e quaisquer restrições necessárias para proteger outros inquilinos. Comunique essa política a todos os clientes.
Testes de Camada de Aplicação: O Alinhamento com o OWASP
O Requisito 6.2.4 do PCI DSS 4.0 define o conjunto mínimo de vulnerabilidades de aplicação que devem ser abordadas no desenvolvimento, e o Requisito 11.4 vincula o pentesting a essas mesmas categorias de vulnerabilidade. Embora o padrão não use a frase "OWASP Top 10" diretamente, as categorias de vulnerabilidade se alinham estreitamente:
- Ataques de injeção (SQL, LDAP, XPath, injeção de comando)
- Buffer overflows
- Armazenamento criptográfico inseguro
- Comunicações inseguras
- Tratamento inadequado de erros
- Cross-site scripting (XSS)
- Controle de acesso inadequado (incluindo IDOR, navegação forçada, escalação de privilégios)
- Cross-site request forgery (CSRF)
- Autenticação e gerenciamento de sessão quebrados
- Todas as outras vulnerabilidades identificadas no Requisito 6.2.4
Seu pentesting deve demonstrar que cada uma dessas categorias de vulnerabilidade foi testada. O QSA revisará o relatório de teste para confirmar a cobertura. Se seu relatório mostra testes de SQL injection mas nenhuma evidência de testes de autenticação, o requisito será parcialmente atendido na melhor das hipóteses.
Esta é uma área onde plataformas de testes automatizados proporcionam uma vantagem significativa. Testes com IA verificam sistematicamente cada categoria de vulnerabilidade na metodologia com consistência completa, garantindo que nenhuma categoria seja perdida devido à pressão de tempo ou descuido humano. Testadores manuais, sob as restrições de tempo de um engajamento com escopo fixo, podem priorizar certas categorias e dar atenção superficial a outras.
Como Testes Automatizados com IA Satisfazem o PCI DSS 4.0
Mapeando pentesting automatizado com IA para cada requisito do PCI DSS 4.0:
| Requisito | O Que Exige | Como a Automação Satisfaz |
|---|---|---|
| 11.4.1 | Metodologia documentada | Documentação de metodologia da plataforma baseada em OWASP/PTES |
| 11.4.2 | Testes internos anuais + após mudanças | Testes internos sob demanda, acionados por CI/CD ou agendamento |
| 11.4.3 | Testes externos anuais + após mudanças | Testes externos sob demanda com disponibilidade no mesmo dia |
| 11.4.4 | Remediação e reteste | Reteste imediato após correções com evidência antes/depois |
| 11.4.5 | Verificação de segmentação (semestral para SPs) | Testes de segmentação automatizados em agendamento configurável |
| 11.4.6 | Validação de abordagem personalizada | Cenários de teste configuráveis para controles personalizados |
| 11.4.7 | Suporte a testes multi-tenant | Capacidade de teste self-service por inquilino |
A principal vantagem é a frequência. O PCI DSS 4.0 define frequências mínimas de teste (anualmente para a maioria, semestralmente para segmentação de provedores de serviço), mas o padrão também exige testes após "mudanças significativas." Em ambientes de desenvolvimento modernos onde código é implantado semanalmente ou diariamente, definir e rastrear mudanças significativas é operacionalmente desafiador. Testes automatizados contínuos contornam esse problema inteiramente: se você testa continuamente, toda mudança é testada, e o gatilho de "mudança significativa" se torna irrelevante.
Checklist de Preparação para Avaliações de 2026
Use este checklist para avaliar sua prontidão para os requisitos de pentesting do PCI DSS 4.0 em sua próxima avaliação.
Documentação
- Metodologia de pentesting escrita referenciando PTES, OSSTMM, OWASP ou NIST SP 800-115
- Escopo definido que mapeia o limite atual do CDE e todos os sistemas dentro do escopo
- Definição de "mudança significativa" que aciona reteste
- SLAs de remediação por severidade de vulnerabilidade
- Cronograma de testes que atende aos requisitos mínimos de frequência
Cobertura de Testes
- Pentesting interno concluído nos últimos 12 meses
- Pentesting externo concluído nos últimos 12 meses
- Verificação de segmentação concluída (dentro de 12 meses para comerciantes, 6 meses para provedores de serviço)
- Testes de camada de aplicação cobrindo todas as categorias de vulnerabilidade do Requisito 6.2.4
- Testes de camada de rede cobrindo todos os sistemas operacionais e funções de rede no escopo
- Reteste realizado após todas as mudanças significativas de infraestrutura ou aplicação desde a última avaliação
Qualidade das Evidências
- Relatórios de teste incluem evidência de exploração, não apenas identificação de vulnerabilidades
- Pontuações CVSS atribuídas a todas as descobertas
- Evidência de remediação documentada para todas as descobertas críticas e altas
- Resultados de reteste confirmando eficácia da remediação
- Resumo executivo e seções de metodologia adequados para revisão do QSA
- Declaração clara de escopo em cada relatório correspondendo ao limite do CDE
Específico para Provedores de Serviço
- Testes de segmentação semestrais concluídos (dois testes nos últimos 12 meses)
- Controles de abordagem personalizada validados por meio de pentesting (se aplicável)
- Política de suporte a pentesting de clientes documentada e comunicada (se multi-tenant)
Melhorias de Processo para 2026
- Avaliar testes automatizados com IA para aumentar a frequência de testes além dos mínimos
- Implementar testes contínuos para atender requisitos de testes de "mudança significativa"
- Integrar pentesting ao pipeline de gerenciamento de mudanças e implantação
- Estabelecer fluxo de trabalho de reteste automatizado para validação mais rápida de remediação
- Revisar e atualizar o documento de metodologia de testes pelo menos anualmente
O Piso de Conformidade versus o Teto de Segurança
O PCI DSS 4.0 define um piso para pentesting -- requisitos mínimos que devem ser atendidos para alcançar conformidade. Atender esse piso é necessário. Mas como discutimos em detalhes em nosso artigo sobre pentesting de conformidade versus testes de segurança reais, os mínimos de conformidade são projetados para estabelecer uma linha base, não para fornecer segurança abrangente.
Organizações que tratam os requisitos de pentesting do PCI DSS como teto em vez de piso deixam riscos significativos sem tratamento. Os requisitos não cobrem testes de sistemas adjacentes a pagamentos que estão fora do escopo mas poderiam servir como pivôs de ataque. Eles não exigem testes de falhas de lógica de negócio específicas para fluxos de pagamento. Eles não exigem testes de engenharia social ou avaliações de segurança física.
As organizações de pagamento mais seguras usam os requisitos do PCI DSS como ponto de partida e estendem os testes para cobrir seu perfil de risco real. Testes automatizados com IA tornam isso economicamente viável porque o custo marginal de testar além do mínimo de conformidade é insignificante quando os testes são automatizados. Executar um pentest contra sistemas fora do escopo junto com o teste obrigatório no escopo custa pouco esforço adicional quando a plataforma lida com ambos simultaneamente.
O PCI DSS 4.0 elevou significativamente o piso de pentesting em comparação com a versão 3.2.1. Atender o novo piso exige melhor documentação, escopo mais amplo, testes mais frequentes e evidências mais rigorosas. Organizações que se preparam agora -- com metodologias documentadas, capacidades de testes automatizados e fluxos de trabalho de remediação -- navegarão suas avaliações de 2026 sem problemas. Aquelas que esperarem descobrirão que a lacuna entre suas práticas atuais e os novos requisitos é maior do que o esperado.
Perguntas Frequentes
Quais são os requisitos de pentesting do PCI DSS 4.0?
O PCI DSS 4.0 exige: metodologia de pentesting documentada (OSSTMM, OWASP ou NIST SP 800-115), testes internos e externos, verificação de segmentação de rede, testes de camada de aplicação cobrindo o OWASP Top 10 e testes de todos os sistemas no escopo. Os novos requisitos incluem validação de abordagem personalizada e obrigações de teste para provedores de serviço multi-tenant.
Com que frequência o PCI DSS exige pentesting?
O PCI DSS exige pentesting pelo menos anualmente e após qualquer alteração significativa na infraestrutura ou aplicação. Os controles de segmentação devem ser testados a cada seis meses para provedores de serviço. Os requisitos com data futura do 4.0 (agora obrigatórios desde 31 de março de 2025) adicionam exigências mais rigorosas de documentação de metodologia e escopo de testes.
Qual é a diferença entre uma varredura de vulnerabilidades e um teste de penetração segundo o PCI DSS?
O PCI DSS distingue explicitamente os dois. Varreduras de vulnerabilidades (Requisito 11.3.1-11.3.2) são avaliações automatizadas baseadas em ferramentas que identificam vulnerabilidades conhecidas. Testes de penetração (Requisito 11.4) envolvem tentativas ativas de exploração para determinar se as vulnerabilidades podem ser usadas para comprometer sistemas. Usar apenas um scanner de vulnerabilidades não atenderá ao requisito de pentesting e resultará em falha na auditoria.