Se a sua empresa aceita cartão — e-commerce, fintech, SaaS com assinatura recorrente, rede de varejo, call center que anota número de cartão por telefone — o PCI DSS deixou de ser opcional há muito tempo. O que mudou é o nível de prova que a bandeira e o adquirente exigem de você agora.
Em 31 de março de 2025, 51 requisitos que eram "boas práticas futuras" na versão 4.0 viraram obrigatórios. A versão em vigor é a PCI DSS v4.0.1, e ela mudou o que conta como pentest válido. Relatório genérico de scanner automatizado não passa mais.
O que é o PCI DSS e quem precisa cumprir
PCI DSS (Payment Card Industry Data Security Standard) é o padrão de segurança mantido pelas bandeiras — Visa, Mastercard, Amex, Discover, JCB — para quem armazena, processa ou transmite dados de cartão. Não é lei brasileira, é exigência contratual do seu adquirente. Quem não cumpre paga multa, perde a taxa preferencial ou perde o direito de processar.
O escopo gira em torno do CDE (Cardholder Data Environment): todo sistema que toca dado de cartão, mais qualquer sistema que possa impactar a segurança desse ambiente. Esse "mais" é onde a maioria das empresas erra o escopo — o servidor de log que recebe dados do CDE, o jump host do time de infraestrutura e o Active Directory que autentica quem acessa o CDE entram no escopo, mesmo sem nunca terem visto um número de cartão.
O que a v4.0.1 exige de pentest, na prática
O bloco de requisitos 11.4 é o que trata de teste de intrusão. Traduzindo o que o QSA vai pedir para ver:
- Metodologia documentada (11.4.1): a empresa precisa ter uma metodologia escrita de pentest, aprovada, que defina escopo, abordagem, critérios de severidade e retenção de evidências. Não basta contratar — precisa existir um documento seu descrevendo como o teste é feito.
- Pentest externo anual (11.4.3): no perímetro externo do CDE, no mínimo uma vez por ano e após qualquer mudança significativa de infraestrutura ou aplicação.
- Pentest interno anual (11.4.2): partindo de dentro da rede, com credenciais. É o teste que quase ninguém faz e que sempre revela mais — movimentação lateral, escalada de privilégio, credencial em share de rede.
- Correção e reteste (11.4.4): achou vulnerabilidade explorável, corrige e testa de novo. O QSA quer ver as duas evidências: o achado e a confirmação de que fechou.
- Validação de segmentação (11.4.5 e 11.4.6): se você usa segmentação de rede para reduzir escopo, precisa provar que ela funciona. A cada 12 meses para comerciantes, a cada 6 meses para provedores de serviço. Se a segmentação cai no teste, todo o resto da rede entra no escopo da auditoria.
Repare no padrão: a v4.0.1 não pede só o teste, pede a cadeia de evidência — metodologia, execução, achado, correção, reteste. É o mesmo raciocínio de rastreabilidade que aparece em outras certificações; se sua empresa já passou por esse processo, vale ler nosso guia de SOC 2 no Brasil e comparar as exigências de evidência lado a lado.
Os dois requisitos que pegaram todo mundo de surpresa: 6.4.3 e 11.6.1
Esses dois são novos na prática e são a maior fonte de não conformidade desde março de 2025. Eles existem por causa de um ataque específico: e-skimming (também chamado de Magecart) — o atacante injeta um script de terceiro na sua página de pagamento e passa a copiar o número do cartão enquanto o cliente digita. Nada quebra, nada fica lento, e o vazamento pode durar meses sem ninguém notar.
As duas exigências:
- 6.4.3 — inventário de todos os scripts que rodam na página de pagamento, com autorização explícita e justificativa de negócio para cada um. Aquele pixel de remarketing que o time de marketing colocou sem avisar? Precisa estar na lista ou sair.
- 11.6.1 — mecanismo que detecta alteração não autorizada nos scripts e nos cabeçalhos HTTP da página de pagamento, com verificação a cada sete dias no mínimo, e alerta para o time de segurança.
Na prática, isso costuma ser resolvido com CSP (Content Security Policy) restritiva, SRI (Subresource Integrity — hash que invalida o script se ele mudar) e monitoramento client-side. E vale um lembrete: se o seu checkout é uma SPA que consome APIs, o risco não está só no navegador. Vale revisar também pentest em APIs e por que seus endpoints estão em risco, porque o CDE moderno é feito de endpoints, não de servidores.
Os 4 erros de escopo que mais reprovam empresas brasileiras
- Achar que usar gateway terceirizado tira você do escopo. Se a página que carrega o iframe do gateway é sua, os requisitos 6.4.3 e 11.6.1 continuam sendo seus. Terceirizar o processamento reduz o escopo, não zera.
- Pentest só externo. O 11.4.2 é interno e autenticado. Empresa que entrega só o relatório de perímetro reprova nesse item todo ano.
- Confundir scan de vulnerabilidade com pentest. Os scans trimestrais ASV (requisito 11.3.2) são obrigatórios e separados do pentest do 11.4. São dois entregáveis diferentes, com objetivos diferentes.
- Não testar a segmentação depois de mexer na rede. Uma regra de firewall nova entre a VLAN de corporativo e a de pagamento já é "mudança significativa" — e dispara reteste.
Como se preparar sem gastar duas vezes
A ordem que costuma funcionar melhor:
- Desenhe o fluxo do dado de cartão antes de contratar qualquer teste. Onde entra, por onde passa, onde para, quem acessa. Sem esse diagrama, o escopo do pentest sai errado e você paga por um teste que o QSA não aceita.
- Reduza o escopo com segmentação, mas só depois de conseguir provar que ela segura. Segmentação mal feita é escopo maior disfarçado de escopo menor.
- Escolha a modalidade certa do teste. Para validar controles do CDE, teste autenticado (greybox ou whitebox) entrega muito mais achado por hora do que blackbox puro — a diferença está detalhada em BlackBox, WhiteBox e GreyBox.
- Alinhe o calendário. Pentest interno, externo, validação de segmentação e reteste em uma janela só custa menos e gera um pacote de evidência coerente para o auditor.
Se sua empresa já mantém ISO 27001, boa parte da documentação de política e gestão de risco aproveita. O que não aproveita é a parte técnica: o PCI DSS é bem mais específico sobre o que testar e com que frequência.
A LDL Security executa pentest interno e externo de CDE, validação de segmentação e reteste com o pacote de evidências no formato que o QSA pede.