PCI DSS 4.0: o que é e quem precisa de cumprir

O que é o PCI DSS

O Payment Card Industry Data Security Standard é um conjunto de requisitos de segurança para proteger dados de cartões de pagamento. É mantido pelo PCI Security Standards Council, uma organização criada pelas principais marcas de cartões: American Express, Discover, JCB, Mastercard e Visa. A versão em vigor é a 4.0.1, publicada em junho de 2024, que corrigiu e clarificou a versão 4.0 sem acrescentar requisitos novos.

Ao contrário do RGPD ou da NIS2, o PCI DSS não é legislação. A obrigação de o cumprir chega através dos contratos: as marcas de cartões impõem-no aos bancos adquirentes, e estes impõem-no aos comerciantes e prestadores de serviços com quem trabalham. Quem não cumpre arrisca penalizações contratuais, aumento de comissões ou, em casos extremos, perder a capacidade de aceitar cartões. Após uma fuga de dados, a falta de conformidade torna a situação muito mais cara.

Quem precisa de cumprir

O PCI DSS aplica-se a qualquer entidade que armazene, processe ou transmita dados de titulares de cartões ou dados sensíveis de autenticação, e também a entidades que possam afetar a segurança desse ambiente. Na prática, isto abrange dois grandes grupos.

Os comerciantes: lojas físicas com terminais, lojas online, hotéis, restaurantes, empresas de subscrições, qualquer negócio que aceite Visa ou Mastercard. Os prestadores de serviços: empresas de alojamento, centros de contacto que recebem dados de cartão por telefone, gateways de pagamento, empresas de software que gerem pagamentos para terceiros, prestadores de serviços geridos com acesso ao ambiente de cartões.

Um ponto importante para PME: externalizar o pagamento reduz muito o âmbito, mas não o elimina. Uma loja online que redireciona o cliente para a página de um prestador de pagamentos continua a ser responsável pela integridade do seu próprio site, porque um atacante que o comprometa pode alterar o redirecionamento.

Os 12 requisitos em linguagem simples

Os requisitos estão agrupados em seis objetivos. Cada requisito desdobra-se em dezenas de sub-requisitos testáveis, mas a estrutura de topo é esta:

• 1. Instalar e manter controlos de segurança de rede (firewalls e equivalentes)
• 2. Aplicar configurações seguras a todos os componentes do sistema
• 3. Proteger os dados de conta armazenados
• 4. Proteger os dados do titular com criptografia forte durante a transmissão em redes públicas
• 5. Proteger sistemas e redes contra software malicioso
• 6. Desenvolver e manter sistemas e software seguros
• 7. Restringir o acesso aos dados de acordo com a necessidade de conhecer
• 8. Identificar utilizadores e autenticar o acesso
• 9. Restringir o acesso físico aos dados do titular
• 10. Registar e monitorizar todos os acessos a componentes do sistema e aos dados
• 11. Testar regularmente a segurança de sistemas e redes
• 12. Suportar a segurança com políticas e programas organizacionais

O que mudou com a versão 4.0 e porque 31 de março de 2025 importa

A versão 4.0 introduziu cerca de 60 requisitos novos ou alterados. Muitos foram classificados como «future-dated», ou seja, eram apenas boas práticas até 31 de março de 2025. Desde essa data são obrigatórios e entram em qualquer avaliação. Para muitas empresas, foi nesse momento que a versão 4 se tornou realmente exigente.

Entre as mudanças com mais impacto estão as seguintes. A autenticação multifator passou a ser exigida para todo o acesso ao ambiente de dados de cartão (requisito 8.4.2), e não só ao acesso remoto. As palavras-passe passam a ter, em regra, um mínimo de 12 caracteres (8.3.6). As lojas online têm de inventariar e autorizar todos os scripts executados nas páginas de pagamento (6.4.3) e implementar um mecanismo que detete alterações não autorizadas a essas páginas (11.6.1), uma resposta direta aos ataques de skimming no browser. Surgem também requisitos de análise de risco direcionada, que permitem justificar a frequência de certas atividades, e a obrigação de confirmar o âmbito do PCI DSS pelo menos uma vez por ano (12.5.2).

Outra novidade é a abordagem personalizada: em vez de implementar um controlo exatamente como descrito, uma entidade madura pode demonstrar que atinge o objetivo do requisito de outra forma. É uma opção exigente, pensada para organizações com equipas de segurança sólidas, e não um atalho.

Níveis de comerciante e tipos de SAQ

A forma de demonstrar conformidade depende do volume de transações e do modelo de pagamento. Os níveis de comerciante são definidos por cada marca de cartões, não pelo PCI SSC, e normalmente vão do nível 1 (maior volume) ao nível 4. Os comerciantes de nível 1 precisam, em regra, de um relatório de conformidade (ROC) elaborado por um avaliador qualificado (QSA) ou por um auditor interno certificado (ISA). Os restantes podem, em muitos casos, usar um questionário de autoavaliação, mas o banco adquirente tem a última palavra. Confirme sempre com ele o que lhe é exigido.

Os questionários de autoavaliação (SAQ) existem em várias versões consoante o modelo de pagamento. Escolher o SAQ errado é um dos erros mais frequentes.

• SAQ A: comércio eletrónico totalmente externalizado, com redirecionamento ou iframe do prestador
• SAQ A-EP: comércio eletrónico em que o site do comerciante controla elementos da página de pagamento
• SAQ B e B-IP: terminais de pagamento autónomos, ligados por linha telefónica ou por IP
• SAQ C e C-VT: aplicações de pagamento ligadas à internet ou terminais virtuais introduzidos manualmente
• SAQ P2PE: soluções validadas de cifragem ponto a ponto
• SAQ D: todos os restantes casos, incluindo prestadores de serviços elegíveis

Lacunas típicas em PME

Nas empresas mais pequenas, os problemas raramente estão na tecnologia de pagamento em si, que normalmente é fornecida por um prestador certificado. Estão à volta dela. O primeiro é o âmbito mal definido: ninguém sabe ao certo por onde passam os dados de cartão. Encontram-se números de cartão em emails, folhas de cálculo de reservas, gravações de chamadas ou notas de encomendas por telefone.

O segundo é a segmentação de rede. Se o terminal de pagamento está na mesma rede que os computadores do escritório e o Wi-Fi dos clientes, todo esse ambiente entra no âmbito. O terceiro é a gestão de terceiros: o PCI DSS exige uma lista de prestadores de serviços com acesso a dados de cartão, a confirmação anual do seu estado de conformidade e uma matriz clara de responsabilidades (requisito 12.8). Por fim, o requisito 12 exige políticas escritas, formação anual de sensibilização e um plano de resposta a incidentes, documentos que muitas PME simplesmente não têm.

Como se preparar, passo a passo

Comece por mapear os fluxos de pagamento: todos os canais onde a empresa recebe dados de cartão, incluindo telefone, email e encomendas manuais. Elimine o que não for necessário: a forma mais eficaz de reduzir esforço é não tocar em dados de cartão. Depois confirme com o banco adquirente o seu nível e o SAQ aplicável, e peça aos prestadores de pagamento o seu atestado de conformidade.

Com o âmbito definido, faça uma análise de lacunas requisito a requisito, dê prioridade aos requisitos que passaram a obrigatórios em 2025, como MFA e proteção das páginas de pagamento, e construa a evidência: configurações, registos, relatórios de análises de vulnerabilidades por um fornecedor aprovado (ASV) quando aplicável, políticas aprovadas e registos de formação.

Se a empresa também está a trabalhar na ISO/IEC 27001 ou na NIS2, há uma sobreposição importante de controlos, embora o PCI DSS seja mais prescritivo. Uma autoavaliação gratuita na baltum.ai ajuda a ter uma visão geral da maturidade de segurança antes de avançar para o SAQ.

Este artigo é informativo e não constitui aconselhamento jurídico. O baltum.ai é um software independente, não um organismo de certificação.