Simplificando: o PCI SSF é para o software, e o PCI DSS é para todo o resto.
Se você desenvolve ou vende software relacionado a pagamentos, o PCI SSF se aplica a você. Se você armazena, processa ou de qualquer forma lida com dados de titulares de cartão (incluindo seu site, servidor ou stack de hospedagem), você precisa estar em conformidade com o PCI DSS.
Esses dois frameworks vêm do mesmo conselho (PCI SSC), mas tratam de problemas bem diferentes no ecossistema.
A maioria das pessoas só ouve falar dos requisitos do PCI DSS porque é o que impacta comerciantes, empresas SaaS e praticamente qualquer um que opere uma página de pagamento. Mas o PCI SSF? Esse é voltado para as empresas que desenvolvem o software de pagamento que alimenta esses sistemas.
Vamos detalhar.
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 foca na proteção dos dados, o PCI SSF é voltado para a proteção do software que manipula esses dados. Isso inclui o código que roda no seu sistema de ponto de venda, aplicativo de carteira digital ou módulo de checkout baseado em navegador.
O PCI SSF é composto por dois padrões:
- Secure Software Standard: Foca na segurança do próprio software. Ele está protegido? Protege os dados do titular do cartão? Possui controle de acesso adequado?
- Secure Software Lifecycle (Secure SLC): Analisa como o software é desenvolvido. O seu SDLC (ciclo de vida de desenvolvimento de software) é seguro? Você corrige vulnerabilidades rapidamente? A segurança é tratada como prioridade?
Em outras palavras: o PCI SSF se preocupa com como o seu software é escrito, mantido e atualizado. Se o seu código é bagunçado, não espere passar em uma avaliação SSF.
Para quem é o PCI SSF?
Faça este teste:
- Você vende ou distribui aplicações de pagamento?
- O seu software processa pagamentos diretamente (mesmo que nunca armazene dados do titular do cartão)?
- Você quer ser listado na lista de software de pagamento validado do PCI SSC?
Se você respondeu sim a qualquer uma dessas perguntas, o requisito PCI SSF se aplica a você.
Que tipo de software está no escopo?
Se você desenvolve ferramentas distribuídas que participam do fluxo de dados do titular do cartão, provavelmente está no escopo.
O que geralmente se enquadra:
- Sistemas POS: Software instalado em terminais físicos de checkout.
- Aplicativos de pagamento móvel: Apps que aceitam pagamentos com cartão por meio de uma interface móvel.
- SDKs de checkout: Componentes ou bibliotecas de pagamento prontos para uso que os comerciantes incorporam em seus sites ou apps.
- Thin clients: Aplicativos leves que gerenciam o roteamento de transações ou a entrada de dados do usuário, mas dependem de APIs externas.
- Software para quiosques ou terminais: Qualquer código que alimente sistemas voltados ao público que aceitam cartões.
O que geralmente não está no escopo:
- Aplicações de uso interno: Ferramentas desenvolvidas e usadas exclusivamente dentro da sua organização, sem distribuição.
- Sistemas de back-office: ERPs ou ferramentas de análise que não participam do fluxo de pagamento.
- Páginas hospedadas sem lógica incorporada: Se o seu software simplesmente redireciona ou enquadra uma página hospedada em conformidade com PCI, isso por si só pode não acionar o SSF.
Se o seu software é vendido, white-labeled ou distribuído e suporta pagamentos com cartão, o SSF quase certamente se aplica.
Exemplos de empresas que precisam do PCI SSF:
Alguns exemplos. Não temos nenhuma afiliação com as empresas listadas abaixo:
- Fornecedores de sistemas POS
Exemplo: Toast, Lightspeed, Square (stack de software de hardware).
- Criam software distribuído instalado em dispositivos físicos em ambientes de varejo e hospitalidade.
- O software aceita pagamentos com cartão e se comunica diretamente com leitores de cartão.
- Geralmente se enquadra no Secure Software Standard.
- Desenvolvedores de aplicativos de pagamento móvel
Exemplo: SumUp, Zettle (by PayPal), Revolut Business.
- Aplicativos móveis que permitem que pequenas empresas ou pessoas físicas aceitem pagamentos com cartão.
- Frequentemente envolvem leitores de cartão via Bluetooth e lidam com a entrada de dados do cartão por telefone ou tablet.
- A segurança do software nesses apps deve ser verificada de ponta a ponta.
- Provedores de SDK de checkout ou biblioteca de pagamento
Exemplo:
- Essas empresas fornecem componentes incorporáveis que os comerciantes usam para aceitar pagamentos.
- Mesmo que os dados do cartão sejam tokenizados rapidamente, o SDK ainda lida com lógica sensível.
- A validação comprova que o SDK não cria novas superfícies de ataque.
- Plataformas de comércio com pagamentos integrados
Exemplo: Shopify, BigCommerce, Ecwid.
- Plataformas que oferecem módulos de checkout integrados que os comerciantes usam "prontos para uso".
- O software subjacente que viabiliza esse checkout frequentemente precisa de validação SSF se for distribuído.
- Empresas de software para quiosques e terminais
Exemplo: Nayax, Ingenico, Verifone (para builds de software personalizados)
- Usados em máquinas de venda automática, quiosques de bilheteria e terminais de autoatendimento.
- O software deve atender aos requisitos de resistência a adulteração, integridade de atualização e comunicações seguras.
- Esses ambientes costumam ser "sem atendente", tornando o SSF ainda mais relevante.
- Soluções de gateway white-labeled
Exemplo: Payrix, BlueSnap, Corepay
- Oferecem infraestrutura de pagamento que outras plataformas incorporam ou revendem.
- O componente de software distribuído (campos hospedados, SDKs, plugins) frequentemente precisa de validação.
- Também ajuda clientes corporativos a reduzir seu próprio escopo PCI.
- Ferramentas de pagamento com foco em segurança
Exemplo: Very Good Security (VGS), Basis Theory, TokenEx
- Essas empresas lidam com dados sensíveis em ambientes de proxy ou cofres.
- Seus SDKs client-side ou bibliotecas de navegador podem exigir validação SSF dependendo de como os dados do cartão fluem.
O que o PCI SSF realmente exige?
Estar em conformidade com o PCI SSF não é apenas ter um código limpo ou boas intenções. O framework define objetivos de segurança claros que o seu software deve atender. E eles são verificados por meio de avaliação.
Algumas expectativas principais:
- Sem armazenamento de dados sensíveis: O software nunca deve armazenar números completos de cartão, códigos CVV ou dados de tarja magnética em texto simples.
- Criptografia correta: São exigidos algoritmos aceitos pelo setor com gerenciamento adequado de chaves.
- Integridade das atualizações: As atualizações de software devem ser autenticadas e assinadas para evitar adulterações.
- Configurações seguras por padrão: Senhas de administrador, configurações e políticas de acesso devem ser entregues em estado protegido.
- Proteção contra adulteração: O seu app deve detectar e responder a tentativas de alterar o comportamento em tempo de execução (ex.: injeção, scraping de memória).
- Controle de acesso: Funções e permissões devem ser claramente definidas, aplicadas e registradas.
- Logs e rastreabilidade: Os logs de auditoria devem estar disponíveis, seguros e resistentes a modificações.
- SDLC documentado: O seu ciclo de desenvolvimento precisa demonstrar que a segurança está incorporada em todas as etapas. Do design à entrega.
Em resumo: os avaliadores vão exigir que você 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 publicação do seu produto no site do PCI SSC.
Uma visão geral do processo:
-
Definição do escopo: Defina quais produtos ou componentes serão submetidos. Você precisará esclarecer quais funcionalidades estão no escopo e como se encaixam no fluxo de pagamento.
-
Análise de lacunas (opcional): Alguns fornecedores começam com uma pré-avaliação para identificar as principais lacunas antes do início do processo formal. Não é obrigatório, mas pode economizar tempo depois.
-
Avaliação formal: O avaliador analisa:
-
Remediação (se necessário): Se forem encontrados problemas, você os corrige, atualiza a documentação e envia evidências das mudanças.
-
Submissão ao PCI SSC: Quando o avaliador estiver satisfeito, ele envia 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 leva de algumas semanas a alguns meses, dependendo do escopo, 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) é o que a maioria já ouviu falar e é voltado para todas as outras empresas que realizam transações em seus sites.
Em essência, o PCI DSS diz:
Se você lida com dados de titulares de cartão, você precisa protegê-los, ..., e aqui estão 12 maneiras de como fazer isso.
E se você leu nosso guia completo sobre o PCI DSS 4.0.1, sabe que essas 12 maneiras não são exatamente itens de "marcar uma caixinha". Estamos falando de:
- Controles de segurança de rede
- Proteção contra malware
- Gestão de vulnerabilidades
- Monitoramento e registro de logs
- Desenvolvimento seguro de software
- Inventário de scripts (olá, PCI 6.4.3 👋)
- Proteção de cabeçalhos de pagamento (olá de novo, 11.6.1 👋)
Seja você um comerciante com SAQ A, um provedor de serviços ou um desenvolvedor de app Shopify usando campos hospedados, o PCI DSS é o framework que se aplica ao seu ambiente de processamento de cartões em produção.
Aqui estão alguns links para conteúdos anteriores que escrevemos sobre o PCI DSS, na ordem em que você deve lê-los:
- Como estar em conformidade com o PCI 6.4.3 e 11.6.1
- A grande atualização do PCI DSS de janeiro de 2025
- O guia completo do PCI DSS 4.0.1
- Como ser uma empresa SAQ A?
- O risco de proteger apenas suas páginas de pagamento
Então, qual é a diferença?
Veja lado a lado:
| Aspecto | PCI SSF | PCI DSS |
|---|---|---|
| Público principal | Fornecedores de software de pagamento | Comerciantes, provedores SaaS, provedores de serviços |
| Escopo | Software seguro + SDLC seguro | Armazenamento, processamento e transmissão seguros de dados de cartão |
| O que protege | A aplicação e seu código | Os dados do titular do cartão e os ambientes onde eles residem |
| Tipo de avaliação | Revisões por Secure Software Assessor (SSA) | Autoavaliação (SAQ) ou auditorias por QSA |
| Exemplo | Uma empresa que vende um sistema POS ou SDK de checkout | Uma loja online que aceita cartões com um checkout hospedado |
| Objetivo | Prevenir vulnerabilidades baseadas em software | Prevenir roubo, vazamento e violações de dados |
| Ponto de contato | Time de desenvolvimento + produto + compliance | DevOps + segurança + jurídico + experiência do cliente |
Uma empresa pode estar sujeita aos dois?
Com certeza. Digamos que você desenvolve 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 você precisa lidar com os dois: proteger o seu código e também proteger a sua infraestrutura.
Mesmo que você não lide diretamente com dados de cartão (ex.: comerciantes SAQ A usando Stripe ou concorrentes com campos hospedados), você ainda está sujeito ao PCI DSS, provavelmente aos requisitos da versão 4.0 como o 6.4.3 e o 11.6.1, que tornam você responsável por scripts de terceiros e pela integridade do DOM.
