Ser PCI DSS compliant vai além de um selo: comprova que seus controles técnicos e administrativos atendem aos requisitos da versão 4.0 do PCI DSS. Este guia mostra, de forma objetiva, como definir se sua organização está no escopo da conformidade e quais artefatos reunir para avançar rumo à certificação. Também esclarece termos que costumam confundir equipes, como o Questionário de Autoavaliação (SAQ), e quando um Qualified Security Assessor (QSA) pode pedir um Relatório de Conformidade (ROC).
Resumo rápido
Precisa de um roteiro direto para começar? Abaixo estão os passos que aceleram a decisão e reduzem o trabalho para ficar pci dss compliant. Use-os como referência rápida antes de montar o projeto completo.
- Mapeie o CDE: crie um diagrama de escopo com fluxos de pagamento, sistemas que tocam PAN e conexões com PSPs para priorizar controles.
- Decida SAQ vs QSA: aplique critérios objetivos (volume, armazenamento de PAN, exigência do adquirente) e calcule o volume mensal para escolher entre SAQ ou auditoria por QSA.
- Reúna artefatos essenciais: mantenha diagrama de rede, inventário de sistemas, lista de integrações e logs que comprovem transmissão ou armazenamento de PAN.
- Reduza o escopo: implemente tokenização, criptografia e segmentação de rede; elimine armazenamento desnecessário para minimizar o alcance da auditoria.
- Implemente proteção contínua: adote EDR/AV, gestão de vulnerabilidades, políticas de patch e monitoramento com runbooks e evidências operacionais.
Como saber se sua empresa está no escopo do PCI DSS
Identificar o escopo evita esforço desnecessário. O primeiro passo é determinar o papel da organização no fluxo de pagamento e o volume de transações. Merchants e providers são classificados em níveis de 1 a 4 conforme o volume anual e regras das bandeiras; nível 1 normalmente exige o Relatório de Conformidade (ROC) e testes mais rigorosos, enquanto níveis 2 a 4 costumam preencher um Questionário de Autoavaliação (SAQ). Confirme sempre com o adquirente: ele pode exigir um ROC por risco percebido, contrato ou incidentes anteriores.
Mapear o CDE é onde a maioria das equipes perde tempo e dinheiro quando a identificação não é completa. Documente fluxos de pagamento, identifique gateways, PSPs e integrações terceiras que tocam PAN. Combine entrevistas com produto e engenharia, varreduras de rede, análise de logs e ferramentas de discovery para localizar endpoints que armazenam, processam ou transmitem dados do titular do cartão.
Artefatos iniciais aceleram decisões e suportam a redução de escopo: elabore um diagrama de rede do CDE, um inventário autoritativo dos sistemas no escopo e uma lista de integrações e APIs que lidam com PAN. Ferramentas úteis incluem scanners de porta, inventário automatizado, análise de logs e revisões de código ou de SDKs de pagamento. Esses documentos também servem como evidência para QSAs e adquirentes ao demonstrar conformidade.
Use o mini-checklist a seguir para decidir hoje se sua organização está no escopo. Baseie as respostas em evidências (logs, inventário, entrevistas) e documente onde cada indicação foi encontrada.
- Há armazenamento de PAN em qualquer banco de dados, arquivo ou backup?
- Aplicações ou servidores conectam-se diretamente a gateways de pagamento sem tokenização?
- Logs indicam transmissão ou exibição de PAN em texto simples?
- Terceiros processam pagamentos em seu ambiente sem isolamento claro do CDE?
Se respondeu sim a qualquer item, planeje conformidade PCI DSS e priorize o mapeamento do CDE. Com o escopo definido, avance para escolher entre SAQ ou QSA e para montar o plano de projeto.
Escolha entre SAQ ou auditoria por QSA e monte o plano de projeto
Decidir entre SAQ e auditoria por QSA exige critérios objetivos e contabilização do esforço. Leve em conta volume de transações, armazenamento de PAN e exigência do adquirente. Se você processa baixos volumes, usa um gateway totalmente hospedado e não armazena dados sensíveis, um SAQ provavelmente basta; caso contrário, contrate um QSA para a avaliação.
Os tipos de SAQ mais comuns são A, B, C, C‑VT e D, cada um aplicável a fluxos de pagamento específicos. SAQ A atende lojas que redirecionam pagamentos a provedores; SAQ B a terminais sem armazenamento; SAQ C a ambientes segregados por rede; SAQ C‑VT a terminais virtuais; SAQ D a ambientes complexos que armazenam ou processam PAN. Integrações múltiplas podem exigir avaliações separadas, porque os requisitos aplicáveis dependem do fluxo adotado.
Contrate um QSA quando houver gatilhos claros: merchant nível 1, exigência do adquirente, armazenamento de PAN ou incidentes envolvendo dados de cartão. Inclua no escopo contratual entrevistas com times, testes presenciais, amostragem de sistemas e um cronograma detalhado de remediação. Exija também um plano de evidências e prazos para revisão de controles após correções.
Um plano mínimo de projeto deixa a jornada previsível. Siga estas etapas sequenciais:
- Descoberta e inventário (1–2 semanas): identificação dos ativos, fluxos de pagamento e pontos que tocam PAN.
- Gap analysis com estimativa de esforço (1 semana): avaliação do que falta para atender aos requisitos e priorização das correções.
- Remediação iterativa (2–12 semanas conforme complexidade): execução das correções com entregas incrementais e validação contínua.
- Coleta de evidências e avaliação final pelo QSA (1–3 semanas): preparar pacote de auditoria e realizar avaliação final.
Planeje entregas quinzenais, responsáveis e checkpoints para reduzir atrasos. A seguir, controles técnicos recomendados para os requisitos 1–4.
Controles técnicos: redes, configurações e proteção de dados (requisitos 1–4)
Comece pelos controles que reduzem a superfície de exposição e evitam armazenamento indevido de PAN. Aplicar medidas alinhadas à PCI DSS 4.0 gera artefatos que aceleram auditorias e ajuda a ficar pci dss compliant. Consulte o documento oficial do PCI DSS v4.0 em português para os critérios completos: PCI DSS v4.0 (PT).
Requisito 1: firewalls, segmentação e regras práticas. Aplique um modelo de bloqueio por padrão (deny‑by‑default) e permita apenas o tráfego necessário por serviço e por origem, documentando fluxos norte‑sul e leste‑oeste. Use regras stateful, listas de controle de acesso e microsegmentação para isolar o CDE e reduzir o escopo. Como evidência, exportações de regras, diagramas de rede com zonas e resultados de testes de conectividade e varreduras de portas funcionam bem.
Requisito 2: configurações seguras e inventário de ativos. Defina baselines com benchmarks reconhecidos, remova credenciais e serviços padrão e aplique templates imutáveis via infraestrutura como código. Mantenha um inventário automatizado (CMDB e discovery agents) para provar quais componentes estão no escopo e quando foram alterados; artefatos úteis incluem templates de configuração, relatórios de scan de conformidade e tickets de mudança vinculados a deployments.
Requisitos 3 e 4: proteger dados armazenados e em trânsito exige criptografia forte e gestão de chaves. Use algoritmos e tamanhos de chave aprovados, implante KMS/HSM para rotação de chaves e aplique tokenização sempre que possível; nunca armazene CVV. Em trânsito, exija TLS 1.2 ou 1.3 com certificados válidos e curvas modernas; registre políticas e procedimentos de criptografia, logs de rotação de chaves e amostras de handshakes TLS como evidência.
Proteção contínua: antivírus, patches e desenvolvimento seguro (requisitos 5–6)
Controles técnicos precisam provar operação contínua, não apenas instalação. Foque em EDR/AV centralizado, gestão de vulnerabilidades com cadência definida e um SDLC que incorpore segurança na pipeline. Produção e desenvolvimento devem compartilhar evidências para auditores e para a operação, conectando detecção a correção e prevenção.
Requisito 5 exige proteção contra malware em endpoints e servidores, com EDR centralizado, assinaturas e regras atualizadas e processos documentados de resposta. Registre logs de detecção, workflows de contenção e validação pós‑mitigação para demonstrar efetividade. Evidências típicas são alertas mitigados com ticket vinculado, capturas do console EDR e relatórios periódicos de varredura e inventário de agentes.
Requisito 6 cobre gestão de vulnerabilidades e SDLC seguro: defina cadências de patch (críticos: 7 dias, alto: 30 dias), integre SAST e DAST no CI/CD e exija revisão de código para mudanças que tocam dados sensíveis. Automatize scans e impeça builds quando vulnerabilidades críticas aparecerem; registre testes, aprovações e tickets de correção. Para ficar pci dss compliant, mantenha artefatos claros como tickets, changelogs e resultados automatizados de scans.
Documentar efetividade requer um inventário autoritativo, trilhas de tickets e métricas operacionais: taxa de patching, tempo médio de remediação (MTTR) e percentil de detecções fechadas. Inclua amostras de incidentes tratados com timeline e lições aprendidas para auditores e para o QSA/Relatório de Conformidade (ROC). Em seguida ligaremos essas evidências ao controle de acesso e à segregação de rede para reduzir o escopo operacional.
Controle de acesso, autenticação, monitoramento e testes (requisitos 7–11)
Limitar quem pode ver e tocar dados de cartão é essencial e deve ser comprovado com evidências operacionais. Um QSA vai pedir artefatos que mostrem atividade real, não apenas políticas; direcione esforços para controles reproduzíveis e registros claros.
Requisitos 7 e 8 exigem controle granular de privilégios: implemente RBAC e o princípio do menor privilégio para funções e serviços críticos. Contas administrativas devem ser individuais, com revisão periódica e MFA obrigatório para administração e consoles em nuvem. Demonstre matrizes de acesso, logs de autenticação e exemplos de revisões automatizadas de permissões. Ao operar em nuvem, alinhe controles ao modelo de responsabilidade compartilhada para dividir obrigações entre provedores e clientes.
Requisitos 9 e 10 combinam segurança física e registro de eventos. Controles físicos evitam acesso direto a servidores, enquanto logs permitem detectar atividades suspeitas; mantenha timestamps sincronizados e processos de revisão. Como evidência, forneça gravações de câmeras com retenção, registros de controle de visitantes e alertas do SIEM com playbooks de triagem.
Requisito 11 pede testes regulares: varreduras ASV trimestrais, pentests anuais e avaliação de redes sem fio. Entregue relatórios ASV, relatórios de pentest com provas de exploração quando aplicável e um plano de remediação. Mostre também evidência de correção em tracker de vulnerabilidades e testes que verifiquem tokenização e criptografia. Além das avaliações, mantenha rotinas de teste de vulnerabilidades e varreduras periódicas.
Governança, redução de escopo e preparar para a auditoria final (requisito 12 e checklist pré-auditoria)
Requisito 12 exige que a organização governe riscos com políticas e responsabilidades claras. Tenha políticas de segurança atualizadas, registros de treinamentos com datas e provas de simulações de phishing para demonstrar prática dos controles. Mantenha versões assinadas das políticas e um índice de mudanças que o QSA possa revisar rapidamente. Para estruturar esse trabalho, consulte nossa página sobre Governança, Gestão de Risco e Conformidade – Access Security, que descreve papéis, processos e artefatos recomendados.
Para reduzir o escopo do CDE considere segmentação de rede para isolar sistemas que tratam PAN, tokenização do PAN para eliminar armazenamento local ou terceirização para PSPs certificados quando fizer sentido operacional. Cada opção tem trade‑offs: segmentação exige investimento em redes e monitoramento, tokenização reduz risco mas implica custo de integração, e terceirizar troca controle por redução de responsabilidade operacional. Use critérios claros para decidir: volume de transações, dependência de latência, controles internos existentes e impacto no roadmap do produto.
Em um projeto com um cliente, a Access Security realizou diagnóstico em duas semanas, aplicou segmentação e implementou tokenização em seis semanas, e automatizou coleta de evidências em quatro semanas para preparar o Relatório de Conformidade. O resultado foi redução do escopo em 65% dos sistemas que antes processavam PAN, queda para 20% do número de servidores no CDE e aceitação para auditoria em 12 semanas desde o início. Os artefatos entregues incluíram diagrama de rede atualizado, política assinada, logs de SIEM, relatório ASV, pentest resolvido, amostras de tickets e plano de remediação.
Antes da auditoria, execute uma verificação final e entregue um pacote completo ao auditor. Reúna ASV, relatórios de pentest e evidências de correção em um repositório organizado para facilitar a revisão. Itens faltantes ou evidências fracas costumam gerar pedidos de retrabalho que atrasam a emissão do ROC.
- ASV verde: scans sem falhas abertas críticas.
- Pentest resolvido: evidência de correções aplicadas.
- Diagrama de rede e inventário: sistemas atualizados e autoritativos.
- Evidências de logs e retenção: SIEM/export logs para o período pedido.
- Amostras de tickets: mudanças e incidentes com evidência de remediação.
- Treinamentos e RACI: registros de treinamentos, simulações de phishing e revisão do RACI.
- Configurações de proteção: tokenização/criptografia e contratos com PSPs quando aplicável.
Com políticas claras, treinamento contínuo e a checklist pronta, você entrega ao auditor o pacote que ele precisa para concluir a avaliação. Mantenha o ciclo com evidências automatizadas, revisões periódicas e um plano de melhoria contínua para reduzir risco após a atestação.
Próximos passos para ficar pci dss compliant
Esta checklist transforma requisitos em ações práticas: primeiro identifique se sua organização está no escopo mapeando o fluxo de pagamento e documentando o papel de cada sistema. Em seguida escolha entre SAQ ou auditoria por QSA com base no volume de transações e na exposição de dados, e implemente controles técnicos essenciais para atender aos requisitos 1–4. Para orientação prática sobre como lidar com os diferentes SAQs em cenários reais, consulte recomendações de provedores de pagamento: como lidar com SAQs.
Por fim, estruture um plano de governança e métricas (RACI, treinamentos, incident response) e institucionalize revisões periódicas. Se quiser aprofundar a abordagem de avaliação e priorização dos riscos, veja nossas recomendações de Gestão de Risco – Access Security para exemplos de artefatos e processos aplicáveis.
