PCI DSS v4.0.1 Norma — pagamentos

63 controles, organizados por grupo, com resumo em português.

Padrão de segurança de dados do setor de cartões de pagamento, exigido de qualquer organização que armazene, processe ou transmita dado de titular de cartão. Organizado em 6 objetivos e 12 requisitos: rede segura, configuração segura, proteção de dados armazenados e em trânsito, proteção contra malware, desenvolvimento seguro, controle de acesso físico e lógico, log/monitoramento, testes de segurança regulares e política de segurança da informação.

Fonte oficial · A cor indica o perfil em que cada controle entra: Básico Intermediário Avançado.

Números e nomes dos 12 requisitos e das seções são referências factuais, verificadas contra o documento oficial (v4.0.1, jun/2024 — revisão editorial da v4.0, sem mudança de estrutura). As descrições em português são redigidas pela InfoCuestaSec (o texto de requisito/procedimento de teste é material licenciado pelo PCI SSC, não reproduzido). Divisão em perfis é didática.

1 Requisito 1 — Controles de Segurança de Rede

1.1
Documentar políticas e procedimentos de segurança de rede, com papéis e responsabilidades definidos. Sem política e papel definidos, controle de rede vira responsabilidade de ninguém em particular — cada mudança depende de quem estiver de plantão.
Intermediário
1.2
Configurar e manter os controles de segurança de rede (firewall/NSC): padrão de configuração, aprovação de mudanças, diagramas de rede e fluxo de dados atualizados, portas e serviços permitidos documentados. Regra de firewall sem padrão documentado tende a acumular exceções ao longo do tempo até virar rede sem controle real algum.
Básico
1.3
Restringir o tráfego de rede de/para o ambiente de dados do cartão (CDE), inclusive em redes sem fio. O ambiente de dados do cartão (CDE) é o alvo mais valioso da rede — restringir tráfego de/para ele é a primeira linha de defesa.
Básico
1.4
Controlar as conexões entre redes confiáveis e não confiáveis, com anti-spoofing e isolamento dos componentes que armazenam dado de cartão. Sem isolamento entre rede confiável e não confiável, um comprometimento externo chega direto aos sistemas mais sensíveis.
Intermediário
1.5
Mitigar o risco de dispositivos que se conectam tanto a redes não confiáveis quanto ao CDE. Um notebook que conecta tanto na internet quanto no CDE é uma ponte que ignora todo o resto do controle de rede.
Intermediário

2 Requisito 2 — Configurações Seguras

2.1
Documentar políticas e procedimentos, com papéis definidos, para configuração segura de sistemas. Sem procedimento documentado, cada time configura sistema à sua maneira — inconsistência é terreno fértil pra vulnerabilidade.
Intermediário
2.2
Configurar e gerenciar sistemas com segurança: padrões de configuração, troca de credenciais padrão de fornecedor, desabilitar serviços desnecessários, criptografar acesso administrativo remoto. Senha padrão de fábrica é a primeira coisa que um atacante tenta — é surpreendente quantos incidentes começam exatamente aí.
Básico
2.3
Configurar e gerenciar ambientes sem fio com segurança: trocar credenciais padrão na instalação, trocar chaves de criptografia quando alguém sai da equipe. Rede sem fio mal configurada é um ponto de entrada que nem exige acesso físico ao prédio.
Intermediário

3 Requisito 3 — Proteção de Dados de Titular Armazenados

3.1
Documentar políticas e procedimentos para proteção de dados de titular de cartão armazenados. Sem política clara, cada área decide sozinha como tratar dado de cartão — e normalmente decide errado, por excesso de cautela ou de descuido.
Intermediário
3.2
Minimizar o armazenamento: política de retenção e descarte limita o tempo e a quantidade de dado guardado. Dado que não precisa ser guardado é dado que não pode vazar — minimizar armazenamento reduz o tamanho do problema pela raiz.
Básico
3.3
Não armazenar dado sensível de autenticação (trilha completa, código de verificação, PIN) após a autorização da transação. Dado sensível de autenticação (CVV, trilha completa, PIN) nunca deveria sobreviver à transação — é o dado mais valioso pra fraude, e a norma proíbe guardá-lo.
Básico
3.4
Restringir a exibição e a cópia do número do cartão (PAN): mascarar ao exibir, impedir cópia via acesso remoto. PAN exibido sem máscara na tela, ou copiável via acesso remoto, vaza mesmo sem nenhum ataque técnico — só por descuido operacional.
Intermediário
3.5
Proteger o PAN onde quer que esteja armazenado, tornando-o ilegível (hash, truncamento, tokenização ou criptografia forte). Se o banco de dados vazar, o que protege o titular do cartão é justamente o PAN estar ilegível — hash, truncamento ou criptografia forte.
Básico
3.6
Proteger as chaves criptográficas que protegem dados armazenados: acesso restrito, armazenamento seguro, poucos custodiantes. Chave de criptografia mal protegida anula toda a proteção que ela deveria dar ao dado — é o cofre da proteção do dado em si.
Intermediário
3.7
Seguir procedimentos de ciclo de vida da chave: geração forte, distribuição e armazenamento seguros, troca periódica, destruição quando comprometida. Chave nunca trocada, ou comprometida e nunca substituída, vira ponto único de falha permanente da proteção de dados.
Intermediário

4 Requisito 4 — Proteção de Dados em Trânsito

4.1
Documentar políticas e procedimentos para proteção de dados de cartão em trânsito. Sem procedimento definido, a proteção do dado em trânsito fica sujeita a improviso a cada nova integração.
Intermediário
4.2
Proteger o PAN durante a transmissão em redes públicas abertas com criptografia forte, inclusive em mensageria de usuário final e redes sem fio. Dado de cartão trafegando sem criptografia forte por rede pública pode ser interceptado por qualquer um no caminho.
Básico

5 Requisito 5 — Proteção contra Software Malicioso

5.1
Documentar políticas e procedimentos de proteção contra software malicioso. Sem política, a decisão de ter (ou não) antimalware fica a critério de cada sistema, não da organização.
Intermediário
5.2
Prevenir, detectar e tratar malware: solução antimalware implantada, capaz de detectar e remover os tipos conhecidos. Malware é um dos vetores mais comuns e mais antigos de comprometimento — proteção contra ele é básica, não opcional.
Básico
5.3
Manter os mecanismos antimalware ativos, atualizados automaticamente e com varredura periódica ou contínua. Antimalware desatualizado ou nunca escaneando é proteção só de nome — precisa estar ativo e atualizado de verdade.
Intermediário
5.4
Usar mecanismos automatizados para detectar e proteger o pessoal contra phishing. Phishing continua sendo a porta de entrada mais comum pra comprometimento inicial, inclusive em ambientes bem protegidos tecnicamente.
Avançado

6 Requisito 6 — Desenvolvimento e Manutenção Segura

6.1
Documentar políticas e procedimentos para desenvolvimento e manutenção segura de sistemas e software. Sem procedimento documentado, segurança no desenvolvimento depende só da boa vontade de cada desenvolvedor.
Intermediário
6.2
Desenvolver software próprio com segurança: processo baseado em padrão da indústria, treinamento anual dos desenvolvedores, revisão de código antes do lançamento. Vulnerabilidade introduzida no código é muito mais barata de corrigir antes do lançamento do que depois, em produção.
Básico
6.3
Identificar e corrigir vulnerabilidades de segurança: processo por fontes confiáveis, inventário de componentes de software, correções aplicadas no prazo definido. Vulnerabilidade conhecida e não corrigida no prazo é a porta de entrada mais previsível — e mais evitável — que existe.
Intermediário
6.4
Proteger aplicações web voltadas ao público: gestão contínua de ameaças, solução técnica automatizada (ex.: WAF), scripts da página de pagamento controlados. Aplicação web pública é o alvo mais exposto de todos — sem proteção dedicada, é a primeira coisa que um atacante testa.
Intermediário
6.5
Gerenciar mudanças com segurança: processo formal de gestão de mudança, separação entre produção e pré-produção, dados de teste removidos antes de ir ao ar. Mudança sem processo formal (e sem separar produção de teste) é onde erro de configuração vira incidente real.
Intermediário

7 Requisito 7 — Restrição de Acesso por Necessidade

7.1
Documentar políticas e procedimentos para restrição de acesso por necessidade de conhecimento. Sem procedimento, o acesso tende a crescer com o tempo e nunca ser revisto — vira acúmulo de privilégio não intencional.
Intermediário
7.2
Definir e atribuir o acesso adequadamente: modelo de menor privilégio, atribuição por função, aprovação formal, revisão periódica de contas e privilégios. Dar acesso amplo 'pra facilitar' é a forma mais comum de violar o princípio de necessidade de conhecimento.
Básico
7.3
Manter sistema(s) de controle de acesso que cubram todos os componentes e neguem acesso por padrão. Um sistema de controle de acesso que nega por padrão obriga toda concessão a ser explícita — o oposto é sempre mais arriscado.
Intermediário

8 Requisito 8 — Identificação e Autenticação

8.1
Documentar políticas e procedimentos para identificação de usuários e autenticação de acesso. Sem política, cada sistema decide sua própria regra de autenticação — inconsistência que o atacante aprende a explorar.
Intermediário
8.2
Gerenciar contas e identificadores de usuário durante todo o ciclo de vida: ID único por pessoa, revogação imediata ao desligamento, remoção de contas inativas em 90 dias. Conta compartilhada ou nunca desativada depois que a pessoa sai é uma das formas mais comuns de acesso indevido persistente.
Básico
8.3
Estabelecer e gerenciar autenticação forte: segundo fator, senha complexa, bloqueio por tentativas inválidas, troca periódica ou análise de risco dinâmica. Senha fraca ou sem bloqueio por tentativa continua sendo um dos vetores de ataque mais simples e mais usados.
Básico
8.4
Implementar múltiplo fator de autenticação (MFA) para todo acesso administrativo e remoto ao ambiente de dados do cartão. MFA é o controle isolado que mais reduz o risco de conta comprometida — uma senha vazada sozinha já não basta pro atacante.
Básico
8.5
Configurar os sistemas de MFA para prevenir uso indevido (independência dos fatores, sem contorno sem aprovação). MFA mal configurado (ex.: os dois fatores dependem do mesmo dispositivo) dá falsa sensação de segurança sem reduzir o risco de verdade.
Intermediário
8.6
Gerenciar contas de aplicação/sistema com login interativo e proteger suas senhas contra divulgação e uso indevido. Conta de sistema/aplicação costuma ter senha nunca trocada e privilégio alto — alvo atraente e mal vigiado.
Intermediário

9 Requisito 9 — Restrição de Acesso Físico

9.1
Documentar políticas e procedimentos para restrição de acesso físico a dados de titular de cartão. Sem política, controle de acesso físico vira regra informal, decidida caso a caso pela segurança da portaria, inconsistente entre turnos e locais.
Intermediário
9.2
Controlar o acesso físico às instalações e sistemas: controle de entrada, monitoramento de áreas sensíveis, restrição a pontos de rede e hardware. Quem entra fisicamente no data center ou na sala de servidores pode ignorar todo controle lógico da rede.
Básico
9.3
Autorizar e gerenciar o acesso físico de funcionários e visitantes: procedimento de autorização, crachá de visitante devolvido, log de visitantes mantido. Visitante sem crachá controlado, ou crachá nunca devolvido, é uma porta física deixada aberta por descuido.
Intermediário
9.4
Armazenar, acessar, distribuir e destruir mídia com segurança: classificação por sensibilidade, controle de saída da instalação, inventário e destruição segura. Mídia com dado de cartão (backup, HD, papel) fora de controle físico é vazamento potencial sem precisar de nenhum ataque digital.
Intermediário
9.5
Proteger dispositivos de ponto de interação (POI) contra adulteração e substituição: lista atualizada, inspeção periódica, pessoal treinado para detectar adulteração. Dispositivo de ponto de venda adulterado captura dado de cartão direto na origem, antes mesmo de qualquer proteção de rede entrar em ação.
Avançado

10 Requisito 10 — Log e Monitoramento

10.1
Documentar políticas e procedimentos de log e monitoramento. Sem procedimento, cada sistema loga (ou não loga) o que achar melhor — inconsistência que trava qualquer investigação depois.
Intermediário
10.2
Implementar logs de auditoria para apoiar a detecção de anomalias e incidentes, cobrindo todos os componentes e o próprio dado de cartão. Sem log detalhado de quem acessou o quê, uma investigação de incidente não tem de onde partir.
Básico
10.3
Proteger os logs de auditoria contra destruição e modificação não autorizada: acesso restrito, backup centralizado, monitoramento de integridade. Um atacante que apaga o próprio rastro no log torna a investigação impossível — por isso o log precisa ser protegido contra alteração.
Intermediário
10.4
Revisar os logs de auditoria regularmente para identificar anomalias, com revisão diária das áreas críticas. Log que ninguém revisa é dado morto — a revisão diária é o que transforma log em detecção de verdade.
Intermediário
10.5
Reter o histórico de logs de auditoria por pelo menos 12 meses, com os últimos 3 meses imediatamente disponíveis. Um incidente descoberto tarde precisa de histórico longo o bastante pra reconstruir o que aconteceu desde o início.
Intermediário
10.6
Manter mecanismos de sincronização de horário entre os sistemas, com essas configurações protegidas. Logs com horários dessincronizados entre sistemas tornam impossível reconstruir a sequência real de um incidente.
Avançado
10.7
Detectar e responder prontamente a falhas nos sistemas críticos de controle de segurança. Um controle crítico de segurança que falha silenciosamente (ex.: antimalware parado) é pior do que não ter o controle — ninguém percebe.
Avançado

11 Requisito 11 — Testes de Segurança Regulares

11.1
Documentar políticas e procedimentos para testes regulares de segurança. Sem procedimento, testes de segurança viram evento esporádico, não prática recorrente.
Intermediário
11.2
Identificar e monitorar pontos de acesso sem fio, autorizados e não autorizados. Ponto de acesso sem fio não autorizado, plantado por engano ou por má intenção, contorna todo o controle de rede cabeada.
Intermediário
11.3
Identificar, priorizar e corrigir vulnerabilidades: varreduras internas trimestrais, varreduras externas trimestrais por scanner autorizado (ASV). Varredura de vulnerabilidade regular é o que encontra a brecha antes que um atacante a encontre primeiro.
Intermediário
11.4
Realizar testes de intrusão (pentest) regularmente: metodologia definida, testes internos e externos ao menos anuais, testes de segmentação de rede. Teste de intrusão simula um ataque real e valida, na prática, se os controles resistem — não é a mesma coisa que só ter os controles no papel.
Intermediário
11.5
Detectar intrusões de rede e mudanças de arquivo: mecanismos de detecção de intrusão e de detecção de mudança (integridade de arquivo). Sem detecção de intrusão e de mudança de arquivo, um comprometimento pode ficar ativo por meses sem que ninguém perceba.
Avançado
11.6
Detectar mudanças não autorizadas nas páginas de pagamento, com verificação semanal no mínimo. Uma página de pagamento adulterada (ex.: script malicioso injetado) pode capturar dado de cartão do cliente sem que o sistema por trás perceba nada.
Avançado

12 Requisito 12 — Política de Segurança da Informação

12.1
Estabelecer uma política geral de segurança da informação, publicada, revisada anualmente e com papéis definidos. Sem política geral aprovada e comunicada, segurança da informação não tem uma referência única que todo mundo segue.
Básico
12.2
Manter políticas de uso aceitável para as tecnologias usadas pelos usuários finais. Sem regra clara de uso aceitável, o comportamento de risco do usuário final fica sem limite definido.
Intermediário
12.3
Documentar a abordagem baseada em risco: análise de risco direcionada para requisitos de frequência flexível ou abordagem personalizada. Nem todo requisito tem uma frequência fixa ideal — a análise de risco direcionada é o que justifica formalmente a frequência ou abordagem escolhida.
Avançado
12.4
Gerenciar a conformidade com o PCI DSS (para prestadores de serviço): responsabilidade da alta direção, revisões trimestrais de conformidade da equipe. Sem responsabilidade executiva clara, conformidade PCI DSS vira tarefa de TI isolada, sem apoio nem cobrança da liderança.
Avançado
12.5
Documentar o escopo do PCI DSS: inventário de componentes em escopo, confirmação anual do escopo. Escopo mal definido é a causa mais comum de auditoria PCI DSS que falha — sistema relevante fica de fora sem ninguém perceber.
Intermediário
12.6
Manter programa formal de conscientização em segurança, com treinamento na contratação e ao menos anual, incluindo phishing. A maioria dos incidentes de segurança envolve alguma falha humana evitável — conscientização é a defesa contra isso.
Intermediário
12.7
Fazer triagem do pessoal com acesso ao ambiente de dados do cartão antes da contratação. Triagem antes da contratação reduz o risco de dar acesso a dado de cartão pra alguém com histórico problemático.
Intermediário
12.8
Gerenciar o risco de prestadores de serviço terceirizados: lista mantida, contratos formais, due diligence, monitoramento anual de conformidade. Prestador terceirizado mal gerido é dado de cartão saindo do controle direto da instituição sem visibilidade equivalente.
Intermediário
12.9
Cumprir obrigações de suporte a clientes como prestador de serviço: reconhecimento por escrito da responsabilidade, suporte a pedidos de status de conformidade. Sem reconhecimento formal de responsabilidade, fica ambíguo quem responde pela segurança do dado quando o prestador terceiriza.
Avançado
12.10
Manter prontidão de resposta a incidentes: plano existente e testado anualmente, equipe designada, treinada e atualizada com lições aprendidas. Sem plano testado e equipe pronta, a resposta a um incidente real começa do zero, sob pressão — o pior momento pra improvisar.
Básico