O PCI DSS v4.0.1 é uma revisão limitada da versão 4.0, publicada em junho de 2024: corrige erros de redação e esclarece a intenção do texto, sem criar, remover ou alterar nenhum requisito. Desde 31 de março de 2025, os requisitos que eram "boas práticas" até essa data passaram a ser obrigatórios em qualquer avaliação de conformidade.
Para quem processa, armazena ou transmite dados de cartão, isso significa que não há mais período de transição a favor de ninguém. A v4.0.1 é hoje a única versão ativa do padrão, todos os requisitos futuros já venceram, e o teste de invasão do Requisito 11.4 precisa estar documentado, executado e retestado dentro do ciclo de doze meses. Este artigo explica o que efetivamente mudou, o que passou a ser obrigatório e como o Requisito 11.4 se traduz em um escopo de pentest concreto.
O que a v4.0.1 mudou em relação à v4.0?
A v4.0.1 não é uma nova versão do padrão no sentido de acrescentar controles. O PCI Security Standards Council a classifica como uma revisão limitada: o objetivo foi corrigir erros tipográficos e de formatação, esclarecer redações ambíguas e alinhar a linguagem entre o corpo do requisito e as notas de aplicabilidade. A intenção de segurança de cada requisito permanece idêntica à da v4.0.
Na prática, os ajustes se concentraram em três frentes:
- Correções editoriais. Erros de referência cruzada, numeração e formatação que geravam dúvida na leitura foram sanados.
- Esclarecimento de intenção. Pontos em que a redação original permitia interpretações divergentes — sobretudo em notas de aplicabilidade e nos requisitos ligados a autenticação multifator e a scripts de páginas de pagamento — foram reescritos para deixar a expectativa explícita.
- Alinhamento de linguagem. A terminologia foi harmonizada entre o texto do requisito, os procedimentos de teste e o guia de orientação, reduzindo o espaço para leituras conflitantes durante a avaliação.
O ponto que exige atenção operacional é o versionamento. A v4.0.1 substituiu a v4.0 como a versão de referência do padrão. Avaliações e documentos como o Attestation of Compliance passaram a citar a v4.0.1. Quem estruturou seu programa sobre a v4.0 não precisa reconstruir controles, mas precisa atualizar referências, modelos e a documentação interna para a versão vigente.
Comparação entre v4.0 e v4.0.1
| Critério | PCI DSS v4.0 | PCI DSS v4.0.1 |
|---|---|---|
| Natureza | Revisão maior do padrão | Revisão limitada (correções e esclarecimentos) |
| Publicação | Março de 2022 | Junho de 2024 |
| Novos requisitos | Sim, em relação à v3.2.1 | Nenhum novo requisito |
| Alteração de intenção | Redefine e amplia controles | Mantém a intenção da v4.0 |
| Situação atual | Substituída pela v4.0.1 | Versão vigente e única ativa |
| Ação exigida | Implementar novos controles | Atualizar referências e documentação para a versão |
Por que os requisitos "futuros" já são obrigatórios?
Quando a v4.0 foi publicada, o padrão dividiu seus requisitos em dois grupos. Um conjunto passou a valer imediatamente com a adoção da nova versão. O outro conjunto — os chamados requisitos com data futura — foi marcado como "boa prática" durante um período de transição, tornando-se obrigatório apenas a partir de 31 de março de 2025. A lógica foi dar tempo às organizações para implementar controles que exigiam mudança de processo, de arquitetura ou de fornecedor.
Essa data já passou. Em qualquer avaliação conduzida hoje, não existe mais distinção entre requisito imediato e requisito futuro: todos são plenamente exigíveis. A janela em que um avaliador podia registrar um requisito com data futura como ainda não aplicável foi encerrada em março de 2025.
Os requisitos que ficaram nesse grupo de transição tocam áreas que costumam demandar mais esforço de implementação. Entre os temas recorrentes:
- Autenticação e MFA. Reforço da autenticação multifator para acesso ao ambiente de dados de cartão e revisão de políticas de senha.
- Segurança de páginas de pagamento. Gestão e monitoramento de scripts executados no navegador e detecção de alterações não autorizadas em páginas que recebem dados de cartão, mitigando ataques de skimming digital.
- Gestão de vulnerabilidades e risco. Análises de risco direcionadas para justificar a frequência de determinados controles e cobertura ampliada de varreduras e testes.
- Papéis e responsabilidades. Atribuição formal e documentada de responsabilidades para cada requisito.
O efeito colateral mais comum é subestimar o prazo de implementação desses controles. Ajustar um pipeline de páginas de pagamento ou fechar todas as lacunas de MFA não é uma tarefa de última hora — e, com a data já vencida, uma lacuna nesses pontos é uma não conformidade direta, não um item em transição.
O que o Requisito 11.4 exige de teste de invasão?
O Requisito 11.4 é o coração do teste de invasão no PCI DSS. Ele determina que a organização mantenha uma metodologia documentada e execute testes externos e internos com regularidade, além de corrigir e retestar o que for encontrado. Não basta rodar um scanner: o padrão exige teste de invasão conduzido por profissional qualificado, com independência organizacional em relação ao alvo.
Os subrequisitos do 11.4 formam um conjunto coerente:
- 11.4.1 — Metodologia definida. Deve existir uma metodologia de pentest documentada que cubra o perímetro do ambiente de dados de cartão (CDE) e os sistemas críticos, testes a partir de dentro e de fora da rede, validação dos controles de segmentação e de redução de escopo, testes de camada de aplicação e de camada de rede, consideração das ameaças dos últimos doze meses e retenção dos resultados e das evidências de correção.
- 11.4.2 — Pentest interno. Executado conforme a metodologia, ao menos a cada doze meses e após qualquer mudança ou upgrade significativo de infraestrutura ou aplicação.
- 11.4.3 — Pentest externo. Também ao menos a cada doze meses e após mudanças significativas, conduzido por recurso qualificado com independência organizacional.
- 11.4.4 — Correção e reteste. Vulnerabilidades exploráveis e fragilidades encontradas são corrigidas segundo a avaliação de risco da organização, e o teste é repetido para confirmar a correção.
- 11.4.5 — Teste de segmentação. Quando a segmentação isola o CDE, os controles de segmentação são testados ao menos a cada doze meses e após alterações, para comprovar que continuam efetivos.
- 11.4.6 e 11.4.7 — Provedores de serviço. Provedores testam os controles de segmentação em intervalo mais curto e, no caso de ambientes multitenant, apoiam o teste de invasão externo de seus clientes.
O ponto que mais gera achado em avaliação é o reteste do 11.4.4. Encontrar e corrigir a vulnerabilidade não fecha o requisito: é preciso repetir o teste e documentar que a falha foi de fato eliminada. Um pentest que termina no relatório inicial, sem evidência de reteste, deixa o requisito incompleto.
Vale lembrar que o pentest do 11.4 se soma às varreduras de vulnerabilidade do Requisito 11.3 — são atividades distintas. A varredura é automatizada e recorrente; o teste de invasão é conduzido por especialista e prova a exploração encadeada. Cumprir uma não substitui a outra.
Como a Berghem executa o pentest para PCI DSS
Na Berghem, o teste de invasão para PCI DSS parte do escopo do ambiente de dados de cartão e do que um adversário buscaria dentro dele. Estruturamos o engajamento para atender diretamente aos subrequisitos do 11.4 — pentest externo, pentest interno, validação de segmentação e o reteste que comprova a correção — e entregamos a documentação no formato que o avaliador espera ver.
O que isso significa na prática:
- Metodologia mapeada ao 11.4.1. Cobrimos camada de rede e camada de aplicação, testes de dentro e de fora do perímetro e a validação dos controles de segmentação que sustentam a redução de escopo.
- Independência organizacional. Atuamos como terceiro qualificado, atendendo à exigência de independência dos requisitos 11.4.2 e 11.4.3.
- Correção e reteste documentados. Cada achado traz evidência, passos de reprodução, severidade e recomendação priorizada — e o reteste confirma, com evidência, que a falha foi eliminada, fechando o 11.4.4.
- Escopo alinhado ao negócio. Ambientes de pagamento raramente vivem isolados: conectamos o trabalho ao serviço de adequação ao PCI DSS e, quando faz sentido, aos testes de rede, cloud e API que compõem a superfície real do CDE.
Somos uma empresa de segurança da informação em São Paulo e conduzimos avaliações de conformidade que também dialogam com ISO 27001, PCI MPoC e segurança em Open Finance. O objetivo é o mesmo em todos: reduzir risco real e dar ao seu time o caminho claro para sustentar a conformidade entre um ciclo e outro.
A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.
Perguntas frequentes
Preciso migrar da v4.0 para a v4.0.1?
Você não precisa reimplementar controles, porque a v4.0.1 não criou novos requisitos — ela apenas corrige e esclarece a v4.0. O que muda é a referência: a v4.0.1 é hoje a versão vigente, então a documentação interna, os modelos e o Attestation of Compliance devem citar a versão correta e usar a redação esclarecida.
Os requisitos com data futura ainda podem ser marcados como não aplicáveis?
Não. O período em que esses requisitos eram tratados como boa prática terminou em 31 de março de 2025. Em qualquer avaliação a partir dessa data, todos os requisitos da v4.0.1 são plenamente exigíveis, e uma lacuna em um requisito antes "futuro" é uma não conformidade, não um item em transição.
Qual a diferença entre a varredura do 11.3 e o pentest do 11.4?
A varredura de vulnerabilidade do Requisito 11.3 é automatizada, recorrente e identifica falhas conhecidas. O teste de invasão do Requisito 11.4 é conduzido por especialista, prova a exploração e o encadeamento de falhas e valida os controles de segmentação. São atividades complementares e obrigatórias: cumprir uma não dispensa a outra.