PCI DSS 4.0: tudo o que sua empresa precisa saber para proteger dados de cartão

O que é PCI DSS e quem precisa cumprir

O PCI DSS — Payment Card Industry Data Security Standard — é um padrão técnico criado em 2004 e mantido pelo PCI Security Standards Council (PCI SSC), consórcio formado por Visa, Mastercard, American Express, Discover e JCB. Seu objetivo é estabelecer um nível mínimo de proteção para o ecossistema de pagamentos com cartão em escala global.

A obrigação de cumprir o PCI DSS não depende do porte da empresa nem de um ato regulatório específico: ela nasce do contrato com o adquirente (como Cielo, Rede ou Stone) e das regras das próprias bandeiras. Qualquer organização que armazene dados de portadores de cartão (número PAN, data de validade, nome do titular), que processe transações de pagamento ou que transmita esses dados por suas redes está no escopo — seja uma startup de pagamentos, um e-commerce, uma fintech regulada pelo Banco Central, uma empresa de SaaS que gerencia cobriança ou um provedor de serviços que hospeda sistemas de terceiros.

Na prática, isso inclui: adquirentes, gateways de pagamento, facilitadores de pagamento (PayFacs), provedores de serviço que tocam dados de cartão, operadores de e-commerce com checkout próprio e aplicativos móveis que capturam dados de cartão diretamente. Terceirizar o processamento para uma PSP ou usar um gateway certificado reduz o escopo, mas não elimina a responsabilidade — a empresa ainda precisa demonstrar conformidade sobre o trecho da jornada que permanece sob seu controle.

Os 12 requisitos do PCI DSS explicados

O PCI DSS organiza seus controles em 12 requisitos agrupados em seis objetivos de controle. O primeiro objetivo — construir e manter uma rede e sistemas seguros — abrange os requisitos 1 e 2: instalar e manter controles de segurança de rede (firewall, listas de acesso, segmentação) e aplicar configurações seguras a todos os componentes do sistema, eliminando credenciais padrão de fabricante e funcionalidades desnecessárias.

O segundo objetivo trata da proteção dos dados de conta (requisitos 3 e 4). O requisito 3 exige que dados de portador armazenados sejam minimizados e, quando necessário, protegidos por criptografia forte, hash ou truncamento — sendo expressamente proibido armazenar o código de segurança (CVV/CVC) após a autorização. O requisito 4 determina criptografia em trânsito com protocolos modernos (TLS 1.2 no mínimo, preferencialmente TLS 1.3) em toda transmissão de dados de cartão por redes públicas.

O terceiro objetivo aborda manutenção de um programa de gerenciamento de vulnerabilidades (requisitos 5 e 6): proteção de todos os sistemas contra malware com soluções atualizadas, e desenvolvimento e manutenção de sistemas e softwares seguros, incluindo correção de vulnerabilidades identificadas em prazos definidos por criticidade e verificação do código de aplicações voltadas à internet.

O quarto objetivo cobre controles de acesso (requisitos 7, 8 e 9). O requisito 7 limita o acesso a dados de conta ao princípio de menor privilégio. O requisito 8 — profundamente reformulado na v4.0 — exige identificação única por usuário, autenticação multifator (MFA) obrigatória para todos os acessos ao CDE e senhas com complexidade e rotação definidas. O requisito 9 controla o acesso físico a sistemas que armazenam ou processam dados de cartão, incluindo câmeras, registros de visitantes e proteção de mídias.

O quinto objetivo trata de monitoramento e testes (requisitos 10 e 11): logging de todos os acessos a recursos de rede e dados de cartão com retenção mínima de 12 meses, e testes regulares de segurança incluindo varredura de vulnerabilidades trimestrais por ASV aprovado e testes de penetração anuais (internos e externos) cobrindo a segmentação de rede. O sexto objetivo, requisito 12, exige uma política de segurança da informação documentada, mantida e comunicada a todos os stakeholders, além de um programa formal de gerenciamento de risco, gestão de fornecedores e resposta a incidentes.

Níveis de comerciante e tipo de validação exigida

As bandeiras classificam os comerciantes em quatro níveis segundo o volume anual de transações processadas. O nível 1 compreende empresas que processam mais de 6 milhões de transações por ano com Visa ou Mastercard, ou aquelas que já sofreram uma violação de dados de cartão — independentemente do volume. Para esse grupo, a conformidade deve ser validada anualmente por um Qualified Security Assessor (QSA), auditor externo certificado pelo PCI SSC, que realiza um Report on Compliance (RoC) presencial e detalhado.

Os níveis 2, 3 e 4 atendem empresas com volumes menores — entre 1 e 6 milhões, entre 20 mil e 1 milhão, e abaixo de 20 mil transações anuais, respectivamente. Esses níveis permitem auto-avaliação por meio de Questionários de Auto-Avaliação (SAQ), documentos segmentados por tipo de ambiente: o SAQ A cobre merchants que terceirizam completamente o processamento; o SAQ A-EP inclui e-commerces com redirect; o SAQ D, o mais abrangente, aplica-se a qualquer comerciante que não se enquadre nos demais perfis. Todos os níveis exigem varredura trimestral de vulnerabilidades externas por um Approved Scanning Vendor (ASV) e a submissão de um Attestation of Compliance (AoC) ao adquirente.

Provedores de serviço — empresas que processam, armazenam ou transmitem dados de cartão em nome de terceiros — seguem uma tabela própria de níveis e, em geral, têm exigências mais rígidas. Um provedor de nível 1 que atenda mais de 300 mil transações por ano de cartão precisa de RoC completo por QSA. A correta identificação do nível e do SAQ adequado é o primeiro passo de qualquer programa de conformidade.

Novidades do PCI DSS 4.0 e 4.0.1

Publicada em março de 2022, a versão 4.0 do PCI DSS foi a maior revisão desde a criação do padrão. A principal mudança conceitual é a introdução do 'Customized Approach': em vez de seguir à risca a implementação prescritiva de cada controle, a organização pode demonstrar ao QSA que atingiu o objetivo de segurança por meio de controles alternativos, desde que documente a abordagem, realize análise de risco e valide a eficácia. Isso abre espaço para empresas com arquiteturas modernas (cloud-native, zero trust, serverless) adequarem-se sem forçar controles concebidos para ambientes on-premises tradicionais.

Na área de autenticação, o requisito 8 recebeu atualizações substanciais: MFA passou a ser obrigatório para todos os acessos interativos ao CDE — não apenas para administradores remotos, como previa a v3.2.1 — e as exigências de senha foram endurecidas. O requisito 6 incorporou controles específicos para ataques do lado do cliente (client-side): scripts de páginas de pagamento devem ser inventariados, ter sua integridade verificada e ser monitorados para detectar modificações não autorizadas — medida direta contra ataques de skimming de JavaScript (Magecart).

A versão 4.0.1, lançada em junho de 2024, trouxe correções de linguagem, esclarecimentos de escopo e ajustes em requisitos marcados como 'best practice until 31 March 2025'. A partir de 31 de março de 2025, todos os requisitos da v4.0 tornaram-se obrigatórios. Os prazos de transição da v3.2.1 para a 4.0 já expiraram — empresas que ainda validam com base na versão anterior estão tecnicamente fora de conformidade.

Escopo, segmentação e relação com LGPD e Banco Central

O conceito de escopo (scope) define quais sistemas, redes e processos precisam ser cobertos pelos controles do PCI DSS. O escopo primário é o Cardholder Data Environment (CDE) — os componentes que armazenam, processam ou transmitem dados de conta. Além disso, qualquer sistema que possa impactar a segurança do CDE (connected-to ou security-impacting) também entra no escopo, mesmo que não manipule diretamente dados de cartão.

A segmentação de rede é a principal estratégia para reduzir o escopo. Quando devidamente implementada — por firewalls, VLANs ou micro-segmentação — ela isola o CDE do restante da infraestrutura corporativa, limitando a superfície de ataque e o número de sistemas sujeitos à auditoria. A segmentação precisa ser testada pelo menos anualmente e sempre que ocorrem mudanças significativas na infraestrutura. Uma segmentação mal implementada é um dos achados mais comuns em testes de penetração de ambiente PCI e pode resultar na expansão inesperada do escopo durante a auditoria.

No Brasil, o PCI DSS convive com a LGPD (Lei 13.709/2018) e com as regulações do Banco Central, especialmente a Resolução CMN 4.893/2021 sobre política de segurança cibernética para instituições financeiras. Os três marcos são complementares: dados de cartão são dados pessoais financeiros, e os controles PCI — minimização, criptografia, controle de acesso, notificação de incidentes — atendem simultaneamente as exigências da LGPD. Para fintechs reguladas, a conformidade PCI também contribui para demonstrar ao Banco Central a maturidade do programa de segurança cibernética exigido. Um programa integrado que trate os três marcos de forma unificada é mais eficiente e menos oneroso do que três iniciativas paralelas.

Penalidades, riscos e como a Decripte apoia sua adequação

O descumprimento do PCI DSS não gera multas de órgão governamental diretamente, mas as consequências são igualmente severas. As bandeiras podem aplicar multas mensais ao adquirente — que as repassa ao comerciante — que variam de US$ 5.000 a US$ 100.000 por mês enquanto a não conformidade persistir. Em caso de violação de dados confirmada, a empresa pode perder o direito de aceitar cartões da bandeira afetada, arcar com os custos de uma investigação forense PFI (PCI Forensic Investigator), pagar pela reemissão de cartões comprometidos e responder por fraudes em um processo de chargeback massivo.

Além do impacto financeiro imediato, uma violação de dados de cartão gera dano reputacional de longa duração, responsabilidade civil perante os titulares dos dados (sob a LGPD) e potencial responsabilidade regulatória perante o Banco Central para fintechs. Para e-commerces, a perda de credenciamento equivale à interrupção total das vendas online.

A Decripte oferece suporte completo ao ciclo de adequação PCI DSS: avaliação de escopo e segmentação, análise de lacunas (gap assessment) contra os requisitos da v4.0, testes de penetração de ambiente de dados de cartão realizados por profissionais certificados, apoio na construção de políticas e evidências para o QSA, e acompanhamento contínuo da postura de conformidade. Atendemos empresas de todos os portes — do e-commerce iniciante ao provedor de serviços de nível 1 — com planos que se adequam ao volume de transações e à complexidade do ambiente. Para começar, acesse o plano gratuito de gestão de ameaças ou conheça os planos completos de conformidade.

Como se adequar

1. 1

   1. Determine seu escopo e nível de comerciante

   Mapeie todos os fluxos de dados de cartão na sua organização — onde são capturados, como trafegam, onde são armazenados ou processados — e identifique todos os sistemas que tocam ou podem influenciar o CDE. Com base no volume anual de transações, determine seu nível (1 a 4) e o tipo de validação exigida (RoC por QSA ou SAQ específico). Esse mapeamento é a base de todo o programa de conformidade.

2. 2

   2. Implemente segmentação de rede para isolar o CDE

   Separe os sistemas do CDE do restante da rede corporativa com firewalls, VLANs ou micro-segmentação bem documentada. Reduza ao mínimo os fluxos autorizados entre o CDE e outras redes, e documente cada regra de firewall com justificativa de negócio. A segmentação correta pode reduzir o escopo do PCI DSS de dezenas de sistemas para apenas aqueles estritamente necessários ao processamento de pagamentos.

3. 3

   3. Aplique configurações seguras e gerencie vulnerabilidades

   Elimine credenciais padrão, desabilite serviços desnecessários e aplique um hardening baseline documentado em todos os componentes do CDE. Estabeleça um processo formal de gestão de patches com prazos de remediação baseados na criticidade da vulnerabilidade — críticas em até 30 dias. Contrate um ASV aprovado para realizar varreduras externas trimestrais e corrija todos os achados antes de submeter os resultados ao adquirente.

4. 4

   4. Fortaleça autenticação e controle de acesso

   Implemente MFA para todos os acessos interativos ao CDE — administradores, desenvolvedores, analistas de suporte e qualquer conta com acesso remoto. Adote o princípio de menor privilégio: cada usuário ou serviço deve ter apenas as permissões estritamente necessárias. Garanta IDs únicos por usuário (nunca contas compartilhadas), políticas de senha robustas e processo formal de revisão e revogação de acessos.

5. 5

   5. Proteja dados em repouso e em trânsito

   Avalie quais dados de cartão são realmente necessários armazenar — o CVV nunca deve ser retido após a autorização. Dados que precisam ser armazenados devem ser protegidos com criptografia forte (AES-256) ou tokenização. Todas as transmissões de dados de cartão por redes públicas devem usar TLS 1.2 ou superior. Inventarie todos os certificados e monitore sua validade para evitar expiração inadvertida.

6. 6

   6. Ative logging, monitoramento e realize testes de penetração

   Configure logging centralizado de todos os acessos, eventos de autenticação e mudanças de configuração no CDE, com retenção mínima de 12 meses. Implemente alertas para eventos suspeitos e revise os logs regularmente. Realize testes de penetração anuais cobrindo a rede externa, a rede interna do CDE e — obrigatoriamente — a eficácia da segmentação. Contrate profissionais que utilizem metodologias reconhecidas (PTES, OWASP) e produzam relatórios rastreáveis para a auditoria.

7. 7

   7. Documente, treine e valide com QSA ou SAQ

   Produza e mantenha atualizadas as políticas de segurança da informação, os procedimentos operacionais e as análises de risco exigidas pelo requisito 12. Treine todos os colaboradores que interagem com dados de cartão pelo menos anualmente. Com toda a documentação e evidências em mãos, complete o SAQ correspondente ao seu perfil ou submeta-se à auditoria pelo QSA. Encaminhe o AoC assinado ao adquirente dentro do prazo definido em contrato.

Perguntas frequentes