PCI DSS 4.0: O que Mudou e Como Garantir a Conformidade

O PCI DSS 4.0 e sua atualização 4.0.1 representam a maior revisão do padrão de segurança de dados do setor de pagamentos em uma década. Entender as mudanças e os novos requisitos é essencial para empresas que processam, armazenam ou transmitem dados de cartão.

O Payment Card Industry Data Security Standard (PCI DSS) é um conjunto de requisitos de segurança criado e mantido pelo PCI Security Standards Council (PCI SSC) — organismo fundado pelas principais bandeiras de cartão: Visa, Mastercard, American Express, Discover e JCB.

Toda organização que processa, armazena ou transmite dados de cartão de pagamento está sujeita às exigências do padrão, independentemente do porte ou volume de transações. O não cumprimento pode resultar em multas contratuais, suspensão da capacidade de aceitar cartões e exposição a responsabilidades em caso de violação de dados.

Quem precisa estar em conformidade com o PCI DSS?

A obrigatoriedade se aplica a:

• Comerciantes que aceitam pagamentos com cartão (físico ou digital)
• Provedores de serviço que processam, armazenam ou transmitem dados de portadores de cartão em nome de terceiros
• Instituições financeiras e adquirentes
• Desenvolvedores de software cujos sistemas integram fluxos de pagamento

O nível de conformidade exigido varia conforme o volume anual de transações, definido pelos quatro níveis (Levels 1 a 4) do PCI SSC.

O impacto regulatório e de negócio

Além do aspecto contratual com as bandeiras, a conformidade com o PCI DSS contribui diretamente para a postura geral de segurança da informação. Empresas certificadas reduzem a superfície de ataque, fortalecem controles de acesso e ganham credibilidade junto a parceiros e clientes. Em contextos regulados , como o sistema financeiro supervisionado pelo Banco Central do Brasil , a aderência ao padrão complementa exigências de frameworks como a Resolução BCB nº 85/2021 e a Circular 3.909.

A versão 4.0, publicada em março de 2022 pelo PCI SSC, substituiu definitivamente a versão 3.2.1 em março de 2024. As mudanças refletem a evolução do cenário de ameaças, a adoção de arquiteturas em nuvem e a necessidade de controles mais flexíveis e orientados a resultados.

Principais mudanças estruturais

1. Abordagem personalizada (Customized Approach) A versão 4.0 introduz oficialmente a possibilidade de implementar controles alternativos para atender ao objetivo de cada requisito, desde que documentados e validados por um QSA (Qualified Security Assessor). Isso oferece maior flexibilidade para empresas com arquiteturas complexas ou ambientes em nuvem.

2. Autenticação multifator (MFA) expandida O MFA, antes exigido apenas para acesso remoto ao ambiente de dados do portador de cartão (CDE), passa a ser obrigatório para todos os acessos administrativos ao CDE, incluindo acessos internos.

3. Segurança de scripts do lado do cliente (e-commerce) Um dos requisitos mais impactantes para o setor de e-commerce: o Requisito 6.4.3 exige inventário, controle de integridade e justificativa de negócio para todos os scripts executados em páginas de pagamento , endereçando ataques de Magecart e web skimming.

4. Testes de penetração orientados a objetivos O Requisito 11.4 fortalece a exigência de pentest, incluindo cobertura de todos os vetores de entrada, sistemas críticos e a validação de controles de segmentação de rede.

5. Gestão de senhas e políticas de autenticação Requisitos mais rígidos para comprimento mínimo de senhas (agora 12 caracteres), revisão de contas inativas e controles de autenticação em serviços e contas de sistema.

A versão 4.0.1, publicada em junho de 2024, não introduz novos requisitos. Trata-se de uma revisão editorial que corrige ambiguidades, esclarece intenções de controles e harmoniza a linguagem de alguns itens que geraram interpretações divergentes entre QSAs e organizações auditadas.

O padrão é organizado em 6 objetivos e 12 requisitos principais. A versão 4.0 manteve essa estrutura, mas expandiu significativamente o detalhamento e os controles específicos.

Requisitos com prazo de implementação imediata (Best Practices → Obrigatório)

Dos 64 novos controles introduzidos no PCI DSS 4.0, uma parte teve prazo de implementação até 31 de março de 2025. Entre os mais críticos:

• Req. 6.4.3 , Gestão e integridade de scripts em páginas de pagamento
• Req. 11.6.1 , Monitoramento de mudanças não autorizadas em páginas de pagamento (HTTP headers e conteúdo)
• Req. 8.3.6 , Comprimento mínimo de senha de 12 caracteres
• Req. 8.4.2 , MFA para todos os acessos não administrativos ao CDE

A jornada de conformidade com PCI DSS 4.0 exige planejamento estruturado, envolvimento de múltiplas áreas e, frequentemente, o suporte de um parceiro especializado.

Etapa 1 — Escopo e descoberta do CDE

O primeiro passo é delimitar com precisão o Cardholder Data Environment (CDE): todos os sistemas, redes e processos que armazenam, processam ou transmitem dados de cartão, além dos sistemas que podem impactar a segurança do CDE.

Uma descoberta incompleta é a principal causa de não conformidades em auditorias. Ferramentas de varredura de rede, entrevistas com equipes de desenvolvimento e revisão de fluxos de dados são indispensáveis nessa fase.

Etapa 2 — Gap Analysis

Com o escopo definido, realiza-se uma análise de lacunas (gap analysis) comparando o estado atual dos controles com os requisitos do PCI DSS 4.0.1. O resultado é um plano de remediação priorizado por risco e prazo.

Para organizações que já possuíam conformidade com a versão 3.2.1, o foco deve estar nos 64 novos requisitos e nas mudanças de requisitos existentes , especialmente os relacionados a MFA, gestão de scripts e testes de penetração.

Etapa 3 — Implementação e remediação

A fase de implementação envolve desde ajustes de configuração e hardening de sistemas até o desenvolvimento de novas políticas, treinamentos e controles tecnológicos. Recomenda-se integrar os controles do PCI DSS à estrutura de segurança já existente , como o programa de gestão de vulnerabilidades , para evitar redundâncias e reduzir o custo total de conformidade.

Etapa 4 — Avaliação formal (QSA ou SAQ)

Dependendo do nível da organização, a conformidade é atestada por um QSA ou por meio de um Self-Assessment Questionnaire (SAQ). O relatório resultante (ROC para Level 1 ou SAQ para demais níveis) é submetido ao adquirente ou bandeira.

Conhecer os erros mais frequentes ajuda a evitar retrabalho e custos desnecessários.

Subestimar o escopo do CDE

Muitas organizações incluem no CDE apenas os servidores de pagamento, ignorando sistemas de monitoramento, ferramentas de suporte, ambientes de desenvolvimento com dados reais e conexões de terceiros. Qualquer sistema com conectividade ao CDE pode expandir o escopo.

Tratar conformidade como evento, não como processo

PCI DSS exige evidências contínuas: logs de acesso, relatórios de varredura de vulnerabilidades (ASV scans trimestrais), revisões de políticas e treinamentos periódicos. Organizações que tratam a certificação como um projeto pontual frequentemente se encontram fora de conformidade entre ciclos de auditoria.

Negligenciar fornecedores e terceiros

O Requisito 12.8 exige gestão ativa de prestadores de serviços que impactam a segurança do CDE. Isso inclui inventário, avaliação periódica, contrato com cláusulas de responsabilidade e monitoramento de conformidade dos fornecedores , uma área frequentemente negligenciada.

Ignorar a segurança de aplicações web e APIs

Com o crescimento do e-commerce e das APIs de pagamento, vulnerabilidades em aplicações tornaram-se o principal vetor de comprometimento de dados de cartão. O pentest de aplicações web e a análise de código-fonte são controles essenciais, não opcionais.

O PCI DSS não existe em isolamento. Para organizações no Brasil, ele coexiste com outras obrigações regulatórias que demandam atenção simultânea.

PCI DSS e LGPD

A Lei Geral de Proteção de Dados (LGPD) e o PCI DSS compartilham objetivos em torno da proteção de dados sensíveis, mas possuem escopos distintos. O PCI DSS foca especificamente em dados de pagamento (PAN, CVV, trilha magnética), enquanto a LGPD abrange toda categoria de dado pessoal.

Na prática, os controles de acesso, criptografia, retenção e resposta a incidentes implementados para PCI DSS frequentemente satisfazem também requisitos da LGPD — gerando eficiências no programa de privacidade.

PCI DSS e ISO 27001

Organizações certificadas em ISO 27001 possuem uma base sólida de controles que facilita a implementação do PCI DSS. Os domínios de gestão de acesso, segurança física, gestão de ativos e continuidade de negócios mapeiam diretamente para requisitos do padrão de pagamentos. Saiba como integrar ISO 27001 e PCI DSS em um programa unificado de segurança.

PCI DSS e regulações do Banco Central

Instituições de pagamento (IPs) reguladas pelo Bacen estão sujeitas às normas de segurança cibernética do Conselho Monetário Nacional. A conformidade com PCI DSS é reconhecida como evidência de maturidade em segurança no contexto das avaliações do regulador, especialmente para IPs que operam no ecossistema do PIX e de cartões.

O PCI DSS 4.0 e sua versão atualizada 4.0.1 elevam significativamente o patamar de segurança exigido de todas as organizações que participam do ecossistema de pagamentos com cartão. As mudanças não são apenas técnicas: elas refletem uma mudança de filosofia, com maior ênfase em controles contínuos, abordagem baseada em risco e responsabilização de toda a cadeia de fornecedores.

Para CISOs, diretores de TI e equipes de compliance, o momento de agir é agora. As organizações que investiram na conformidade com PCI DSS 4.0 como parte de uma estratégia ampla de segurança , e não apenas como uma obrigação contratual , colhem benefícios tangíveis: menor exposição a violações, processos de auditoria mais ágeis e maior confiança de parceiros e clientes.

A Access Security apoia organizações em todas as etapas da jornada PCI DSS: da avaliação de escopo e gap analysis à remediação técnica e preparação para auditoria formal com QSAs certificados.