PCI DSS e Compliance: Não Deixe a Segurança Para Depois

Resumo: Se a sua empresa toca em dados de cartão, o PCI DSS não é opcional, e adiar a conformidade custa mais caro do que implementá-la. Veja o que mudou na versão atual, os prazos que já venceram e como o modelo white label encolhe o seu escopo de auditoria.

Introdução

Compliance de segurança costuma entrar na conversa tarde demais: depois do incidente, depois da notificação do adquirente, depois de um cliente perguntar "onde vocês guardam meu cartão?". A essa altura, o custo já não é técnico: é jurídico, financeiro e reputacional.

O ponto é direto. Se a sua empresa armazena, processa ou transmite dados de cartão (o que inclui receber um número de cartão numa tela de checkout), o padrão PCI DSS se aplica a você. Não é uma lei brasileira, mas uma exigência contratual das bandeiras e dos adquirentes. Descumprir significa multas repassadas pelo adquirente, suspensão do credenciamento para processar cartões e exposição direta a fraude e vazamento.

Este post é para quem vai ter de responder por isso: o time técnico e o time de compliance. Vamos cobrir o que é o PCI DSS, qual versão está valendo, quais prazos já passaram, como funcionam os níveis de conformidade e, principalmente, como o modelo white label transfere boa parte desse peso para fora da sua operação.

Contexto

O PCI DSS (Payment Card Industry Data Security Standard) é o conjunto de requisitos de segurança mantido pelo PCI Security Standards Council (PCI SSC), fórum criado pelas principais bandeiras (Visa, Mastercard, American Express, Discover e JCB). Ele padroniza como dados de portador de cartão devem ser protegidos ao longo de todo o ciclo de pagamento.

A versão em vigor é a PCI DSS v4.0.1, publicada em junho de 2024. Ela não introduz novos requisitos: traz esclarecimentos e correções em relação à v4.0, publicada em 31 de março de 2022. Em outras palavras, quem se organizou pela v4.0 continua no caminho certo.

Dois marcos de transição já ficaram para trás e valem o alerta:

• A versão anterior, v3.2.1, foi aposentada em 31 de março de 2024. Desde então, a v4.x é a única referência válida.
• Os requisitos "future-dated" (aqueles que a v4.0 introduziu com prazo estendido para adaptação) passaram a ser obrigatórios após 31 de março de 2025. Ou seja: hoje eles não são mais "boas práticas recomendadas", são exigências plenas.

Vale dimensionar o risco. O setor de cartões no Brasil movimentou mais de R$ 4,1 trilhões em 2024, com cerca de 45,7 bilhões de transações (dados ABECS). Um volume desse tamanho é, por definição, um alvo atraente para fraude. Conformidade não é burocracia: é o que mantém sua operação de pé e o que os adquirentes cobram antes de liberar o processamento.

O que o padrão exige e como a conformidade é medida

Na prática, o PCI DSS organiza a segurança em torno de objetivos como manter uma rede segura, proteger os dados armazenados do portador, gerenciar vulnerabilidades, controlar acessos, monitorar e testar redes continuamente e manter uma política formal de segurança da informação. Traduzindo para a rotina: criptografia, segmentação de rede, controle de quem acessa o quê, registro de logs, testes periódicos e processos documentados.

O ponto que mais gera confusão é como você comprova que está em conformidade. Isso depende de quanto sua empresa "toca" em dados de cartão e do volume de transações, e as bandeiras classificam os participantes em níveis. De forma geral:

• Volumes menores normalmente permitem a autoavaliação via SAQ (Self-Assessment Questionnaire). É um questionário formal em que a própria empresa atesta o cumprimento dos requisitos aplicáveis ao seu cenário. Existem diferentes tipos de SAQ conforme o modelo de aceitação (por exemplo, quem redireciona o pagamento para um provedor externo responde a um SAQ bem mais curto do que quem digita o cartão no próprio ambiente).
• Volumes maiores exigem auditoria presencial conduzida por um QSA (Qualified Security Assessor), um avaliador credenciado pelo PCI SSC, que emite um relatório formal de conformidade (ROC).

Os limites exatos de transações que definem cada nível são estabelecidos por cada bandeira (Visa, Mastercard etc.), e não pelo próprio PCI SSC. Por isso o número que vale para a sua empresa deve ser confirmado com o seu adquirente. A lógica, porém, é sempre a mesma: quanto maior o volume e quanto mais dados sensíveis você manipula diretamente, mais rigorosa e cara é a comprovação. Some-se a isso o exame trimestral de vulnerabilidade (ASV scan) exigido para quem tem componentes expostos à internet.

O que não muda em nenhum nível: em caso de incidente ou não conformidade comprovada, o adquirente pode aplicar multas contratuais, reter repasses e, no limite, encerrar o credenciamento, deixando a empresa sem capacidade de processar cartões da noite para o dia.

Aplicação Prática

Um checklist objetivo para sair do "vamos ver depois":

• Mapeie o fluxo de dados de cartão. Onde o número entra, por onde trafega, onde (e se) é armazenado. Sem esse mapa, qualquer estimativa de escopo é chute.
• Reduza o escopo antes de tentar cumpri-lo. O dado de cartão mais seguro é o que você nunca guarda. Tokenização e redirecionamento para um provedor certificado tiram servidores inteiros de dentro da sua auditoria.
• Descubra seu nível e o SAQ aplicável junto ao adquirente. Isso define se o caminho é autoavaliação ou auditoria QSA.
• Feche os requisitos future-dated. Eles já são obrigatórios desde 31/03/2025: trate qualquer pendência como dívida vencida.
• Estabeleça a rotina, não o evento. Scans trimestrais, revisão de acessos, gestão de logs e testes não são tarefa de uma vez ao ano.

Erros comuns que custam caro:

• Tratar PCI DSS como projeto com data de fim, e não como processo contínuo.
• Armazenar dados que nunca deveriam ser guardados (como o código de segurança do cartão após a autorização, algo vedado pelo padrão).
• Assumir que "está na nuvem, então é do provedor". Infraestrutura em nuvem certificada cobre a camada dela; a responsabilidade sobre a sua aplicação continua sendo sua.
• Confundir SAQ preenchido com segurança real: o questionário atesta controles que precisam existir de fato.

Como o modelo white label reduz o seu escopo de PCI

Aqui está o argumento prático mais importante para o negócio. O escopo de PCI DSS de uma empresa é proporcional ao contato dela com dados de cartão. Quando você opera sobre uma infraestrutura white label já certificada, é o provedor quem mantém o ambiente sensível: captura, tokenização, armazenamento e transmissão dos dados do portador acontecem dentro do perímetro dele, já auditado.

Na prática, isso costuma mover a sua empresa do cenário mais pesado (ambiente próprio manipulando cartão, sujeito a auditoria QSA extensa) para um cenário de escopo reduzido, muitas vezes elegível a um SAQ mais simples. Você continua responsável pelos seus próprios controles (acesso, governança, o pedaço da integração que é seu), mas deixa de carregar sozinho a parte mais cara e arriscada da conformidade. É diferença de meses de projeto e de custo de auditoria. Ainda assim, exija do provedor o Attestation of Compliance (AOC) atualizado: certificação alegada não é certificação comprovada.

Próximos Passos

Comece pelo mapa de dados e pela conversa com o seu adquirente para definir nível e SAQ. Essas duas ações já revelam 80% do trabalho pela frente. Se o volume aponta para auditoria QSA, avalie seriamente se faz sentido manter dados de cartão dentro de casa ou migrar para uma base white label certificada e cortar escopo.

Com a segurança endereçada, a próxima pergunta natural é como transformar essa operação em receita sustentável. É exatamente isso que abordamos no próximo post: Modelos de Receita: Como Ganhar Dinheiro com White Label de Pagamentos.

Conclusão / CTA

Compliance de pagamentos não é o freio do negócio: é a licença para operar. Quem trata segurança como prioridade desde o início gasta menos, cresce mais rápido e não corre o risco de perder o credenciamento no pior momento possível. Quer entender como a infraestrutura certificada da Plutech reduz o seu escopo de PCI DSS? Fale com o nosso time e peça uma demonstração.

Fontes

• Document Library: versão atual PCI DSS v4.0.1 (jun/2024) (PCI Security Standards Council).
• Securing the Future of Payments: PCI SSC Publishes PCI DSS v4.0 (PCI SSC, 31/03/2022).
• Countdown to PCI DSS v4.0 (PCI SSC Blog: v3.2.1 aposentada em 31/03/2024; requisitos future-dated obrigatórios após 31/03/2025).
• Balanço do setor de meios de pagamento 2024 (ABECS).