Precisa de PCI SSF ou de PCI DSS? Eis a diferença

Resumo: o âmbito do PCI SSF face ao PCI DSS para comerciantes

• A maioria das equipas trata o PCI SSF e o PCI DSS como intercambiáveis. Não são. O PCI SSF é para os fornecedores de software que criam sistemas POS, SDKs de checkout e bibliotecas de pagamento. O PCI DSS é para todos os comerciantes, SaaS ou fornecedores de serviços que tocam em dados de titulares de cartão, incluindo comerciantes SAQ A que usam campos hospedados.
• O PCI DSS 4.0.1 introduziu o 6.4.3, para inventário e autorização de scripts, e o 11.6.1, para deteção de adulteração nos cabeçalhos HTTP e scripts das páginas de pagamento, ambos visando a camada do browser onde as CSPs e os scanners tradicionais são cegos. A cside é a fornecedora preferencial da AWS para estes dois requisitos.
• Se constrói e vende software de pagamento, precisa de PCI SSF e de um Secure Software Assessor. Se aceita pagamentos por cartão, precisa de evidências para o PCI DSS 6.4.3 e 11.6.1, e a cside PCI Shield produz essas evidências junto com o Shopify, o Stripe ou qualquer gateway de campos hospedados.

Vamos simplificar: o PCI SSF é para o software, e o PCI DSS é para tudo o resto.

Se está a construir ou a vender software relacionado com pagamentos, o PCI SSF aplica-se a si. Se armazena, processa ou de alguma forma toca em dados de titulares de cartão (incluindo o seu site, servidor ou stack de alojamento), está perante uma questão de conformidade com o PCI DSS.

Estes dois frameworks vêm do mesmo conselho (PCI SSC), mas abordam problemas muito diferentes no ecossistema.

A maioria das pessoas só ouve falar dos requisitos do PCI DSS porque é o que afeta comerciantes, empresas SaaS e praticamente qualquer entidade que opere uma página de pagamento. Mas o PCI SSF? Esse é para as empresas que escrevem o próprio software de pagamento que alimenta esses sistemas.

Vamos decompor isto.

O que é o PCI SSF?

O PCI SSF significa Payment Card Industry Software Security Framework. É o substituto mais recente e flexível do PA-DSS, a versão anterior.

Enquanto o PCI DSS se foca em proteger os dados, o PCI SSF centra-se em proteger o software que toca nesses dados. Ou seja, o código que corre no seu sistema de ponto de venda, na sua app de carteira móvel ou no módulo de checkout baseado em browser.

O PCI SSF é, na verdade, composto por dois padrões:

• Secure Software Standard: foca-se na segurança do próprio software. Está protegido? Protege os dados do titular do cartão? Tem controlo de acesso adequado incorporado?
• Secure Software Lifecycle (Secure SLC): analisa como o software é feito. O seu SDLC (ciclo de vida de desenvolvimento de software) é seguro? Corrige vulnerabilidades com rapidez? A segurança é tratada como prioridade?

Por outras palavras, o PCI SSF preocupa-se com a forma como o seu software é escrito, mantido e atualizado. Se o seu código é desorganizado, não conte passar numa avaliação SSF.

Para quem é o PCI SSF?

Eis o teste:

• Vende ou distribui aplicações de pagamento?
• O seu software processa pagamentos diretamente (mesmo que nunca armazene dados de titulares de cartão)?
• Pretende ser listado na lista de software de pagamento validado do PCI SSC?

Se respondeu sim a qualquer uma destas perguntas, o requisito PCI SSF aplica-se.

Que tipo de software está no âmbito?

Se constrói ferramentas que são distribuídas e envolvidas no fluxo de dados de titulares de cartão, é provável que esteja no âmbito.

Eis o que normalmente se qualifica:

• Sistemas POS: software instalado em terminais físicos de checkout.
• Apps de pagamento móvel: apps que aceitam pagamentos por cartão através de uma interface móvel.
• SDKs de checkout: componentes ou bibliotecas de pagamento prontos a integrar que os comerciantes incorporam nos seus sites ou apps.
• Thin clients: apps ligeiras que gerem o encaminhamento de transações ou a introdução de dados pelo utilizador, mas que dependem de APIs externas.
• Software de quiosque ou terminal: qualquer código que alimente sistemas de acesso público que aceitem cartões.

E eis o que normalmente não está no âmbito:

• Aplicações de uso exclusivamente interno: ferramentas desenvolvidas para uso dentro da sua própria organização, sem distribuição.
• Sistemas de back-office: ERPs ou ferramentas de análise que não tocam no fluxo de pagamento.
• Páginas hospedadas sem lógica incorporada: se o seu software se limita a redirecionar ou a enquadrar uma página hospedada em conformidade com o PCI, isso por si só pode não desencadear o SSF.

Se o seu software é vendido, distribuído em white-label ou de outra forma distribuído, e suporta pagamentos por cartão, o SSF aplica-se quase de certeza.

Exemplos de empresas que precisam de PCI SSF:

Eis alguns exemplos. Note-se que não temos qualquer afiliação com as empresas listadas abaixo:

1. Fornecedores de sistemas POS

Exemplo: Toast, Lightspeed, Square (stack de hardware e software).

• Criam software distribuído, instalado em dispositivos físicos em ambientes de retalho e hotelaria.
• O software aceita pagamentos por cartão e interage diretamente com leitores de cartão.
• Normalmente enquadra-se no Secure Software Standard.

2. Programadores de apps de pagamento móvel

Exemplo: SumUp, Zettle (by PayPal), Revolut Business.

• Apps móveis que permitem a pequenas empresas ou a particulares aceitar pagamentos por cartão.
• Envolvem frequentemente leitores de cartão por Bluetooth e tratam a introdução de dados de cartão através de telemóvel ou tablet.
• A segurança do software nestas apps tem de ser verificada de ponta a ponta.

3. Fornecedores de SDKs de checkout ou bibliotecas de pagamento

• Estas empresas fornecem componentes integráveis que os comerciantes usam para aceitar pagamentos.
• Mesmo que os dados do cartão sejam tokenizados rapidamente, o SDK continua a lidar com lógica sensível.
• A validação comprova que o SDK não cria novas superfícies de ataque.

4. Plataformas de comércio com pagamentos incorporados

Exemplo: Shopify, BigCommerce, Ecwid.

• Plataformas que oferecem módulos de checkout incorporados que os comerciantes usam "prontos a usar".
• O software subjacente que viabiliza esse checkout precisa frequentemente de validação SSF, se for distribuído.

5. Empresas de software para quiosques e terminais

Exemplo: Nayax, Ingenico, Verifone (para desenvolvimentos de software personalizados)

• Usados em máquinas de venda automática, quiosques de bilheteira e terminais de autoatendimento.
• O software tem de cumprir requisitos de resistência a adulteração, integridade de atualizações e comunicações seguras.
• Estes ambientes são frequentemente "não vigiados", o que torna o SSF ainda mais relevante.

6. Soluções de gateway em white-label

Exemplo: Payrix, BlueSnap, Corepay

• Oferecem infraestrutura de pagamento que outras plataformas incorporam ou revendem.
• O componente de software distribuído (campos hospedados, SDKs, plugins) precisa frequentemente de validação.
• Também ajuda os clientes empresariais a reduzir o seu próprio âmbito PCI.

7. Ferramentas de pagamento focadas em segurança

Exemplo: Very Good Security (VGS), Basis Theory, TokenEx

• Estas empresas lidam com dados sensíveis em ambientes tipo proxy ou cofres.
• Os seus SDKs client-side ou bibliotecas de browser podem exigir validação SSF, consoante a forma como os dados do cartão fluem.

O que exige realmente o PCI SSF?

Estar em conformidade com o PCI SSF não é apenas ter código limpo ou boas intenções. O framework estabelece objetivos de segurança claros que o seu software tem de cumprir. E são verificados através de avaliação.

Algumas expectativas fundamentais:

• Sem armazenamento de dados sensíveis: o software nunca deve armazenar números completos de cartão, códigos CVV ou dados de banda magnética em texto simples.
• Criptografia bem feita: são exigidos algoritmos aceites pela indústria com gestão adequada de chaves.
• Integridade das atualizações: as atualizações de software devem ser autenticadas e assinadas para impedir adulterações.
• Predefinições seguras: palavras-passe de administrador, configurações e políticas de acesso devem vir num estado protegido.
• Proteção contra adulteração: a sua app tem de detetar e responder a tentativas de alterar o comportamento em tempo de execução (por exemplo, injeção, scraping de memória).
• Controlo de acesso: funções e permissões têm de estar claramente definidas, aplicadas e registadas.
• Registo e rastreabilidade: os registos de auditoria têm de estar disponíveis, seguros e resistentes a modificações.
• SDLC documentado: o seu ciclo de desenvolvimento tem de demonstrar que a segurança está incorporada de ponta a ponta. Da conceção à entrega.

Em suma: os avaliadores vão exigir que prove que a segurança não é uma reflexão tardia.

Como é o processo de validação?

A validação do PCI SSF é formal e estruturada. É realizada por um Secure Software Assessor (SSA). Não é uma autoavaliação! O resultado é a listagem do seu produto no site do PCI SSC.

Eis uma visão geral do processo:

• Definição do âmbito: defina quais os produtos ou componentes que serão submetidos. Terá de clarificar que funcionalidades estão no âmbito e como se enquadram no fluxo de pagamento.

• Análise de lacunas (opcional): alguns fornecedores começam com uma pré-avaliação para identificar as principais lacunas antes de o processo formal começar. Não é obrigatório, mas pode poupar tempo mais tarde.

• Avaliação formal: o avaliador analisa:

• Correção (se necessária): se forem encontrados problemas, corrige-os, atualiza a documentação e submete evidências das alterações.

• Submissão ao PCI SSC: quando o avaliador estiver satisfeito, apresenta um relatório ao PCI SSC para revisão.

• Listagem: se aprovado, o seu software é publicado na lista oficial de aplicações de pagamento validadas.

Os prazos variam, mas a maioria das avaliações demora de algumas semanas a alguns meses, dependendo do âmbito, da maturidade do código e da clareza da documentação.

O que é o PCI DSS?

O PCI DSS (Payment Card Industry Data Security Standard) é aquele de que a maioria já ouviu falar e destina-se a todas as outras empresas que processam transações no seu site.

O PCI DSS diz:

Se toca em dados de titulares de cartão, tem de os proteger, ..., e aqui estão 12 formas de o fazer.

E se leu a nossa análise aprofundada do PCI DSS 4.0.1, sabe que essas 12 formas não são exatamente itens de "marcar uma caixa". Estamos a falar de:

• Controlos de segurança de rede
• Proteção antimalware
• Gestão de vulnerabilidades
• Monitorização e registo
• Desenvolvimento seguro de software
• Inventário de scripts (olá, PCI 6.4.3)
• Proteção dos cabeçalhos de pagamento (novamente, olá, 11.6.1)

Quer seja um comerciante com SAQ A, um fornecedor de serviços ou um programador de apps Shopify que usa campos hospedados, o PCI DSS é o framework que se aplica ao seu ambiente de processamento de cartões em produção.

Eis alguns links para conteúdos anteriores que escrevemos sobre o PCI DSS, pela ordem em que deve lê-los:

• Como cumprir o PCI 6.4.3 e o 11.6.1
• A grande atualização do PCI DSS de janeiro de 2025
• A análise completa do PCI DSS 4.0.1
• Como ser uma empresa SAQ A?
• O risco de proteger apenas as suas páginas de pagamento

Então, qual é a diferença?

Vejamos lado a lado:

Uma empresa pode estar sujeita a ambos?

Sem dúvida. Digamos que constrói e vende um plugin de checkout (PCI SSF), mas também usa esse plugin no seu próprio site de e-commerce (PCI DSS). Agora tem de tratar de ambos: proteger o seu código e também proteger a sua infraestrutura.

Mesmo que não lide diretamente com dados de cartão (por exemplo, comerciantes SAQ A que usam Stripe ou concorrentes com campos hospedados), continua sujeito ao PCI DSS — provavelmente a requisitos da versão 4.0 como 6.4.3 e 11.6.1, que o tornam responsável por scripts de terceiros e pela integridade do DOM.