PCI DSS 4.0.1 e risco de terceiros: como proteger a cadeia de pagamentos
O fim do prazo de transição não encerrou o desafio. Desde 31 de março de 2025, requisitos do PCI DSS 4.x antes classificados como futuros passaram a ser considerados nas avaliações aplicáveis. Para empresas que vendem pela internet, isso ampliou a atenção sobre elementos que nem sempre recebem o mesmo cuidado que os servidores: páginas de pagamento, scripts executados no navegador, integrações e prestadores de serviços.
Em 2026, a questão central já não é apenas se a organização está preparada para o PCI DSS 4.0.1. O desafio é manter controles eficazes em uma operação que depende de fornecedores, plataformas e componentes externos, alguns dos quais podem influenciar diretamente a segurança dos dados de cartão.
O checkout também pode ser comprometido por terceiros
Uma página de pagamento pode continuar aparentemente normal mesmo quando um componente externo foi alterado. Scripts de marketing, ferramentas de análise, bibliotecas de terceiros e outros recursos autorizados podem executar código no navegador do cliente. Se um deles for adulterado, poderá capturar informações inseridas no checkout sem que seja necessário invadir o servidor da loja.
Esse tipo de ataque, conhecido como *e-skimming*, explora a confiança depositada nos códigos carregados pela página. O navegador do consumidor se torna parte importante da superfície de risco: é ali que os dados são digitados e onde scripts potencialmente comprometidos podem ter acesso ao conteúdo exibido ou preenchido.
Por isso, verificar apenas se o servidor da empresa sofreu alterações não é suficiente. Também é necessário entender quais scripts chegam ao navegador, se são realmente necessários e se continuam íntegros ao longo do tempo.
O que os requisitos 6.4.3 e 11.6.1 pedem
Em março de 2025, o PCI Security Standards Council publicou orientações voltadas à proteção de páginas de pagamento e à prevenção de e-skimming, com atenção especial aos requisitos 6.4.3 e 11.6.1.
O requisito 6.4.3 determina que os scripts executados nas páginas de pagamento sejam gerenciados de forma controlada. Na prática, a organização precisa manter um inventário dos scripts autorizados, registrar a justificativa para sua utilização e empregar mecanismos que permitam verificar sua integridade.
Já o requisito 11.6.1 se concentra na identificação de alterações não autorizadas. Os mecanismos de detecção devem ajudar a perceber mudanças que possam afetar a página de pagamento ou os cabeçalhos HTTP relacionados à segurança. Juntos, os dois requisitos ampliam a proteção: um organiza o que pode ser executado; o outro ajuda a detectar quando algo muda indevidamente.
Terceirizar o pagamento não transfere a responsabilidade
Gateways, processadores, serviços de hospedagem, plataformas de comércio eletrônico e ferramentas de segurança podem participar da operação de pagamentos ou influenciar a proteção dos dados. O risco aumenta quando a empresa conhece os termos comerciais do contrato, mas não sabe com clareza quais componentes o fornecedor administra e quais controles continuam sob sua responsabilidade.
O requisito 12.8 aborda a gestão de prestadores de serviços relevantes. Isso inclui avaliar o fornecedor antes da contratação, estabelecer acordos adequados, definir a divisão de responsabilidades e acompanhar periodicamente seu status de conformidade. A empresa precisa saber, por exemplo, quais requisitos são atendidos pelo prestador e quais ainda dependem de processos internos.
Nem todo fornecedor de código é automaticamente um Third-Party Service Provider (TPSP). Segundo o PCI SSC, o simples fornecimento de um script não relacionado ao processamento de pagamentos não torna um prestador um TPSP quando ele não pode afetar a segurança dos dados do portador do cartão ou de autenticação. A classificação deve considerar o serviço e seu impacto real, não apenas o fato de existir uma relação com terceiros.
Como reduzir o risco na prática
O primeiro passo é mapear a cadeia de pagamentos de ponta a ponta. A empresa deve identificar sistemas, fornecedores, integrações, scripts, páginas envolvidas e fluxos de dados. Esse inventário ajuda a revelar dependências esquecidas, como ferramentas antigas ainda carregadas no checkout ou integrações que continuam ativas sem uma finalidade clara.
Em seguida, cada script presente nas páginas de pagamento deve ter um responsável, uma justificativa de negócio e uma aprovação formal. A lista precisa ser revisada sempre que houver mudanças na página, contratação de uma nova ferramenta ou alteração nas funções de um fornecedor. Código sem finalidade definida deve ser removido, pois amplia a superfície de ataque sem oferecer benefício conhecido.
Também é importante controlar mudanças. Atualizações de scripts, componentes e configurações devem seguir um processo documentado, com autorização e registro. Quando tecnicamente adequado, medidas como restrições de conteúdo, verificação de integridade e limitação das permissões dos scripts podem dificultar a execução de código não aprovado.
A detecção precisa complementar a prevenção. Monitorar alterações na página de pagamento e nos cabeçalhos HTTP permite investigar desvios com mais rapidez. Os alertas devem ser encaminhados a equipes capazes de avaliar a ocorrência, determinar se houve impacto e iniciar a resposta a incidentes. Um mecanismo que apenas gera notificações, sem processo de análise, oferece proteção limitada.
Contratos, avaliação e resposta a incidentes
A gestão de fornecedores não deve terminar na assinatura do contrato. A organização precisa solicitar informações sobre controles de segurança, escopo dos serviços e responsabilidades relacionadas ao PCI DSS. Também deve verificar se o prestador comunicará incidentes, mudanças relevantes e alterações que possam afetar a página de pagamento ou o ambiente de dados do cartão.
É recomendável estabelecer uma rotina de reavaliação baseada no risco. Um fornecedor que apenas presta um serviço administrativo não necessariamente merece o mesmo nível de escrutínio que um componente capaz de executar código no checkout. A análise deve levar em conta o acesso concedido, os dados envolvidos e a possibilidade de afetar a confidencialidade ou integridade do pagamento.
Um plano de resposta deve prever o que fazer quando um script não autorizado é detectado. Entre as medidas possíveis estão suspender temporariamente o componente, preservar registros para investigação, avaliar se dados foram expostos, acionar os responsáveis internos e comunicar fornecedores envolvidos. A rapidez depende de funções e canais de contato definidos com antecedência.
Conformidade como capacidade operacional
O PCI DSS 4.0.1 não deve ser tratado como uma tarefa pontual para a auditoria. Uma página de pagamento muda continuamente: novos recursos são adicionados, fornecedores atualizam componentes e equipes ajustam campanhas e funcionalidades. Por isso, controles eficazes precisam acompanhar essas mudanças e fazer parte das rotinas de desenvolvimento, operação, compras e segurança.
Proteger a cadeia de pagamentos exige visibilidade sobre o que é executado no navegador, entendimento claro das responsabilidades dos terceiros e capacidade de detectar e responder a alterações suspeitas. A conformidade se torna mais consistente quando esses elementos funcionam juntos – e não apenas quando documentos estão atualizados.