O 31 de março de 2025 é a data que tornou obrigatórios todos os requisitos do PCI DSS v4 anteriormente classificados como "com data futura". Para muitos comerciantes europeus, este prazo passou despercebido, mas as consequências práticas são concretas. As novas obrigações modificam a forma como devem ser geridos os pagamentos online, os call centers e qualquer sistema que interaja com dados de cartão. A tokenização continua a ser a forma mais eficaz de absorver estas mudanças sem redesenhar toda a infraestrutura.
Os requisitos v4 que se tornaram obrigatórios em 2025
Os requisitos "com data futura" do PCI DSS v4 que se tornaram obrigatórios em março de 2025 afetam áreas específicas e com elevado impacto operacional. O requisito 6.4.3 exige um inventário documentado de todos os scripts JavaScript presentes nas páginas de pagamento, com mecanismos para verificar a sua integridade. Este requisito surge como resposta aos ataques de e-skimming que afetaram milhares de sites de e-commerce nos anos anteriores. O requisito 11.6.1 acrescenta a monitorização contínua das páginas de pagamento para detetar modificações não autorizadas nos scripts e nos cabeçalhos HTTP.
No âmbito da autenticação, o requisito 8.4.2 alarga a obrigação de MFA a todos os acessos ao CDE, incluindo os de redes internas. Na versão 3.2.1, o MFA era obrigatório principalmente para acessos remotos. Esta extensão tem um impacto direto nas políticas de acesso aos sistemas de pagamento internos e nas ferramentas de administração. Os comerciantes que gerem sistemas próprios pelos quais transitam dados de cartão devem rever as suas políticas de autenticação para estarem alinhados.
O impacto prático nos comerciantes de e-commerce e MOTO
Para os comerciantes de e-commerce, o requisito com maior impacto é o 6.4.3 relativo aos scripts. Se o site de pagamento carrega bibliotecas JavaScript de terceiros, CSS externos ou píxeis de rastreamento, cada um destes elementos deve ser inventariado e monitorizado para verificar a sua integridade. Isto inclui também os scripts de fornecedores como o Google Analytics ou o Meta Pixel se estiverem presentes na página de pagamento. Muitos comerciantes descobrem que têm dezenas de dependências externas não documentadas que exigem uma revisão completa do seu processo de pagamento.
Para os comerciantes MOTO (Mail Order/Telephone Order), os novos requisitos de MFA afetam os postos dos operadores de call center que introduzem dados de cartão. Cada acesso ao sistema que gere os PAN deve agora estar protegido por autenticação multifator. Isto requer habitualmente uma atualização das plataformas de gestão de encomendas telefónicas e uma revisão dos procedimentos operativos dos agentes. A solução mais direta é eliminar completamente os dados de cartão do ambiente do call center utilizando tecnologias de mascaramento ou tokenização em tempo real.
Como a tokenização absorve os novos requisitos
A tokenização com um fornecedor certificado PCI DSS Level 1 elimina na origem muitos dos problemas criados pelos novos requisitos v4. Se os dados do cartão nunca entram no ambiente do comerciante, o requisito 6.4.3 relativo aos scripts aplica-se a um perímetro muito reduzido ou não se aplica de todo, consoante a arquitetura do processo de pagamento. Com uma hosted payment page ou um formulário de tokenização gerido pelo fornecedor, as páginas de pagamento do comerciante não contêm scripts que processem dados de cartão, eliminando grande parte da obrigação de monitorização.
Do mesmo modo, a extensão da obrigação de MFA ao CDE perde relevância prática se o próprio CDE for reduzido ao mínimo ou eliminado da infraestrutura do comerciante. Um comerciante com arquitetura SAQ A não tem sistemas próprios que armazenem, transmitam ou processem dados de cartão: o seu perímetro de conformidade é limitado e os novos requisitos v4 mais onerosos não se aplicam. Isto torna a redução do âmbito na estratégia de adaptação ao v4 mais vantajosa, tanto em termos de custos imediatos como de encargos recorrentes.
Perguntas frequentes
O meu adquirente vai exigir PCI DSS v4 de imediato?
Depende do adquirente e do contrato em vigor. Muitos adquirentes europeus estão já a atualizar os seus processos de alta e de renovação anual para solicitar SAQ conformes com a v4. Se tiver uma renovação anual próxima, verifique com o seu adquirente que versão do questionário é exigida. Não espere que seja ele a assinalar o incumprimento: o risco de sanções contratuais é real.
Tenho de refazer o SAQ com o PCI DSS v4?
Sim, o próximo SAQ que preencher deve basear-se nos modelos v4. Os modelos SAQ atualizados estão disponíveis no site do PCI Security Standards Council. O tipo de SAQ (A, A-EP, B, D, etc.) depende da arquitetura de aceitação de pagamentos, não da versão da norma: se já utiliza tokenização com hosted fields, pode já estar em condições de optar pelo SAQ A mais simples.
Os requisitos v4 aplicam-se também aos comerciantes de Nível 4?
Sim. Os comerciantes de Nível 4 (menos de 20.000 transações de e-commerce anuais ou até 1 milhão de transações de qualquer tipo) estão igualmente sujeitos ao PCI DSS v4. A diferença em relação aos níveis superiores refere-se ao método de validação (SAQ em vez de ROC), não à aplicabilidade da norma. Os novos requisitos v4 aplicam-se a todos os comerciantes que aceitam cartões das principais redes.
Conformidade PCI DSS v4 sem redesenhar a infraestrutura: a tokenização é o caminho mais rápido para a maioria dos comerciantes. Descubra a PCI Proxy EU.
Precisa de apoio na conformidade PCI?
A nossa equipa ajuda a mapear o seu CDE, escolher o SAQ adequado e implementar tokenização com residência de dados na UE.
Contacte-nos