Resumo: o âmbito do PCI SSF face ao PCI DSS para comerciantes
- Não são intercambiáveis: 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 que o 4.0.1 acrescentou: 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.
- Qual se aplica a si: 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.
Sem tempo? Veja o cside PCI Shield. Cobre tudo o que se segue numa única implementação.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
| Área | PCI SSF | PCI DSS |
|---|---|---|
| Público principal | Fornecedores de software de pagamento | Comerciantes, fornecedores SaaS, fornecedores de serviços |
| Âmbito | Software seguro + SDLC seguro | Armazenamento, processamento e transmissão seguros de dados de cartão |
| O que protege | A aplicação e o seu código | Os dados do titular do cartão e os ambientes onde 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 um SDK de checkout | Uma loja online que aceita cartões com um checkout hospedado |
| Objetivo | Prevenir vulnerabilidades baseadas em software | Prevenir o roubo, a fuga e as violações de dados |
| Ponto de contacto | Equipa de desenvolvimento + produto + conformidade | DevOps + segurança + jurídico + experiência do cliente |
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.
A situação em 2026
O PCI DSS 4.0.1 tornou-se obrigatório em abril de 2025. Os requisitos 6.4.3 e 11.6.1 estão agora a ser aplicados, o que significa que os adquirentes e as marcas de cartões podem assinalar o incumprimento durante os seus ciclos de revisão. Para a maioria dos comerciantes, a prioridade imediata é reunir evidências para esses dois requisitos da camada do browser, e não avaliar o PCI SSF, que só é relevante para os fornecedores de software de pagamento.
No lado do SSF, o PA-DSS chegou ao fim de vida em outubro de 2022. Os fornecedores de software ainda listados ao abrigo do PA-DSS deveriam ter concluído a migração para o Secure Software Standard do PCI SSF. Os novos produtos de software que entram no mercado de software de pagamento validado devem usar o caminho SSF desde o início.
Se não tiver a certeza de qual framework se aplica à sua organização, o teste mais rápido é: vende ou distribui software de pagamento a terceiros? Se sim, o SSF aplica-se. Aceita, armazena, processa ou transmite dados de cartão? Se sim, o PCI DSS aplica-se. Ambos podem ser verdadeiros ao mesmo tempo.
