Resumo
- O PCI DSS v4.0.1 é a versão obrigatória desde 31 de março de 2025. Todos os 51 requisitos antes considerados ‘future-dated’ já são plenamente aplicáveis e exigíveis em auditorias.
- Os Requisitos 7 e 8 do PCI DSS são inteiramente dedicados ao controle de acesso e à gestão de identidades, incluindo RBAC obrigatório, MFA para todo acesso ao CDE e proibição de contas compartilhadas.
- O Requisito 8.1.4 exige a desativação de contas inativas em até 90 dias, o que inclui ex-colaboradores, prestadores com contrato encerrado e contas de serviço sem uso.
- O Requisito 10 exige uma trilha de auditoria completa de todos os acessos ao ambiente de dados do cartão, com retenção mínima de 12 meses.
- O Shadow IT (SaaS não autorizados com acesso a dados de cartão) expande o escopo do CDE sem controle, gerando achados no Requisito 12.5.2 e risco regulatório real.
Toda empresa que armazena, processa ou transmite dados de cartão de pagamento está sujeita ao PCI DSS, independentemente de tamanho, volume de transações ou modelo de negócio. Fintechs, adquirentes, gateways de pagamento, marketplaces e subadquirentes estão no escopo da norma da mesma forma que os grandes emissores de cartão.
O que muitas dessas empresas descobrem durante a primeira auditoria é que os controles com mais achados são de identidade e acesso. Quem tem permissão para acessar o ambiente de dados do titular do cartão? Com qual justificativa? O ex-colaborador, desligado há dois meses, ainda tem acesso? O prestador que encerrou o contrato ainda consegue autenticar?
Este artigo explica o que o PCI DSS v4.0.1, versão vigente desde 31 de março de 2025, exige em termos de gestão de identidade e acesso, quais evidências o auditor vai verificar e como estruturar os controles necessários para garantir conformidade contínua, não apenas no dia da auditoria.
O que é o PCI DSS e quem está no escopo
O PCI DSS (Payment Card Industry Data Security Standard) é o padrão internacional de segurança de dados para a indústria de cartões de pagamento, desenvolvido e mantido pelo PCI Security Standards Council (PCI SSC), um consórcio fundado pelas principais bandeiras de cartão: Visa, Mastercard, American Express, Discover e JCB.
A versão vigente em 2026 é a PCI DSS v4.0.1, publicada em junho de 2024 como atualização de clareza da v4.0 (sem novos requisitos). A conformidade obrigatória com todos os requisitos, incluindo os 51 antes classificados como “future-dated”, passou a valer em 31 de março de 2025.
Organizações que ainda operam sob a lógica da v3.2.1 ou que não implementaram os requisitos “future-dated” estão em não-conformidade. (PCI Security Standards Council, 2025)
Quem está sujeito ao PCI DSS
A obrigação se aplica a qualquer entidade que armazene, processe ou transmita dados de conta de pagamento, o chamado CDE (Cardholder Data Environment, ou Ambiente de Dados do Titular do Cartão). No mercado brasileiro, isso inclui:
- Emissores de cartão: bancos, fintechs e cooperativas que emitem cartões de crédito, débito ou pré-pago.
- Adquirentes e subadquirentes: credenciadoras como Cielo, Stone, PagSeguro, Rede e seus parceiros de repasse.
- Gateways e facilitadores de pagamento: qualquer plataforma que processe transações de cartão em nome de terceiros.
- Marketplaces: plataformas de e-commerce que processam ou transmitem dados de cartão de compradores
- Prestadores de serviço: fornecedores de TI, processamento ou armazenagem que têm acesso ao CDE de seus clientes.
A conexão com o CDE define o escopo. Um gateway de pagamento de médio porte com acesso aos dados de cartão de seus clientes tem as mesmas obrigações que um grande emissor.
O que mudou com o PCI DSS v4.0.1 em Gestão de Identidade
A versão v4.0.1 representa a mudança mais significativa no padrão desde a v1.0, com 64 requisitos novos ou atualizados em relação à v3.2.1. Para gestão de identidade e acesso, as principais mudanças são:
MFA obrigatório para todo acesso ao CDE
Na v3.2.1, o MFA (Autenticação Multifator) era obrigatório apenas para acesso remoto ao CDE e para contas administrativas. No v4.0.1 (Requisito 8.4.1), o MFA é obrigatório para qualquer acesso de usuário ao CDE. Essa mudança foi um dos requisitos “future-dated” que se tornaram obrigatórios em março de 2025 e representa um dos maiores gaps de conformidade encontrados em auditorias de 2026.
Senhas mínimas de 12 caracteres
O Requisito 8.3.6 elevou o mínimo de 7 para 12 caracteres para senhas de usuário. Para sistemas que não suportam 12 caracteres, o mínimo é 8, mas a documentação da justificativa é obrigatória. Sistemas legados que não suportam o novo padrão precisam de plano de migração documentado.
Revisão de acessos de terceiros a cada 6 meses
O Requisito 7.2.4 do v4.0.1 introduziu a exigência de revisão semestral de todos os acessos de terceiros ao CDE, incluindo prestadores, fornecedores de serviço e parceiros de integração. Essa revisão precisa ser documentada com evidência de análise real: quem revisou, quando, o que foi mantido ou revogado e com qual justificativa.
Filosofia de conformidade contínua
A mudança para o V4.0 passou a exigir conformidade como processo contínuo. O PCI SSC descreve isso como uma transição de “compliance as a checkbox” para “security as a way of doing business”. Para gestão de identidade, isso significa que revisões de acesso, desativação de contas e geração de trilha de auditoria precisam acontecer continuamente.
Os Requisitos de Identidade e Acesso no PCI DSS v4.0.1
Os Requisitos 7, 8 e 10 do PCI DSS formam o núcleo da gestão de identidade, com exigências, implicações para controle de acesso e evidências para auditoria:
| Requisito | O que exige | Implicação para gestão de identidade | Evidência necessária |
| Requisito 7 | Restringir o acesso a componentes do sistema e dados do titular do cartão pela necessidade de saber | RBAC obrigatório: cada usuário acessa apenas o que precisa para sua função específica. Acesso amplo ou “por conveniência” não é permitido. | Lista de usuários com justificativa de acesso, revisão semestral documentada |
| Requisito 8 | Identificar usuários e autenticar o acesso a componentes do sistema | Identificadores únicos por usuário, contas compartilhadas são proibidas. MFA obrigatório para qualquer acesso ao CDE. Senhas mínimas de 12 caracteres. | Inventário de contas de usuário, logs de autenticação, evidência de MFA ativo |
| Req. 8.1.4 | Remover ou desativar contas de usuários inativas em até 90 dias | As contas de ex-colaboradores e prestadores precisam ser desativadas no prazo, sem exceção para contas de serviço ou automação. | Registro de desativações com data, varredura de contas inativas |
| Requisito 10 | Registrar e monitorar todo o acesso aos componentes do sistema e dados do titular do cartão | Trilha de auditoria completa de todos os acessos ao CDE: quem acessou, o quê, quando e de onde. Retenção mínima de 12 meses. | Logs centralizados, íntegros e exportáveis, alertas para atividades suspeitas |
| Req. 10.2 | Implementar logs de auditoria para capturar todos os acessos individuais a dados do titular do cartão | Cada acesso individual precisa ser rastreável a uma identidade específica. Contas compartilhadas invalidam essa rastreabilidade. | Log de eventos com identificação de usuário, timestamp e sistema acessado |
O CDE como perímetro de identidade
O Cardholder Data Environment (CDE) é o conjunto de sistemas, redes e pessoas que armazenam, processam ou transmitem dados de conta de pagamento. Tudo o que se conecta ao CDE, ou que, se comprometido, pode impactar o CDE, está no escopo do PCI DSS.
Do ponto de vista de gestão de identidade, o CDE define quem pode ter acesso e quais controles são obrigatórios. Qualquer identidade, humana ou não-humana, com acesso a sistemas no escopo do CDE precisa cumprir os requisitos de identificação única, autenticação forte, menor privilégio e trilha de auditoria. Isso inclui contas de serviço, tokens de API de integrações de pagamento e qualquer agente ou automação com acesso ao ambiente de pagamento.
Os Achados Mais Comuns em Identidade e Acesso nas Auditorias PCI DSS
Os achados de conformidade mais frequentes em auditorias PCI DSS no Brasil são processuais. A maioria das empresas implementa firewalls, criptografia e segmentação de rede. Onde o processo falha é na gestão do ciclo de vida das identidades que acessam o CDE.
| Achado comum | Requisito violado | Consequência na auditoria |
| Contas compartilhadas no CDE | Req. 8.2.1: cada usuário deve ter identificador único | Achado crítico. Impossibilita rastreabilidade de quem acessou o quê. |
| Ex-colaboradores com acesso ativo ao CDE | Req. 8.1.4: contas inativas desativadas em até 90 dias | Achado imediato sem exceções ou período de tolerância |
| Acesso de prestadores sem escopo definido | Req. 7.2.4: acesso de terceiros revisado a cada 6 meses | Acesso amplo de fornecedores é incompatível com princípio do menor privilégio |
| Ausência de MFA para acessos ao CDE | Req. 8.4.1: MFA obrigatório para todo acesso não-console ao CDE | Um dos novos requisitos do v4.0.1, frequentemente subestimado na transição |
| Logs incompletos ou não centralizados | Req. 10: trilha de auditoria completa e centralizada | Logs dispersos em múltiplos sistemas não atendem ao requisito de monitoramento |
| Shadow IT (SaaS não autorizados com acesso a dados de cartão) | Req. 12.5.2:escopo do CDE documentado e revisado anualmente | Ferramentas SaaS fora do inventário oficial expandem o escopo sem controle |
O problema do Shadow IT no escopo PCI DSS
O Requisito 12.5.2 do PCI DSS v4.0.1 exige que as organizações documentem e confirmem o escopo do CDE ao menos anualmente e quando houver mudanças significativas. O Shadow IT é um dos maiores vetores de expansão não controlada do escopo PCI DSS.
Quando um colaborador usa uma ferramenta de CRM, planilha ou plataforma de comunicação não autorizada para processar ou transmitir dados de cartão, mesmo que por conveniência ou acidente, essa ferramenta passa a fazer parte do escopo do CDE. Sem a visibilidade de Shadow IT, a empresa não sabe que o escopo se expandiu, o auditor provavelmente vai descobrir, e o achado resultante pode comprometer toda a certificação.
Como Implementar Gestão de Identidade em Conformidade com o PCI DSS
A conformidade com os requisitos de identidade do PCI DSS v4.0.1 é uma capacidade operacional que precisa funcionar continuamente. Cinco princípios formam a base de um programa estruturado:
- Inventário completo de identidades com acesso ao CDE
O ponto de partida é saber quem tem acesso ao CDE e o que tem acesso ao CDE. Isso inclui usuários humanos, contas de serviço, tokens de API, certificados e qualquer identidade não-humana com acesso a sistemas de pagamento. Sem esse inventário, nenhuma revisão periódica é possível, e o auditor vai solicitar exatamente essa lista como uma das primeiras evidências da auditoria.
- RBAC com escopo mínimo para o CDE
O Requisito 7 exige que o acesso seja restrito pela necessidade de saber (need-to-know) e pela necessidade de fazer (need-to-use). Isso significa definir perfis de acesso por função para o CDE, especificando quem pode visualizar dados de cartão, quem pode processar transações e quem pode administrar sistemas de pagamento, além de garantir que cada identidade tenha apenas as permissões estritamente necessárias para sua função atual.
- MFA para todo acesso ao CDE
A partir de março de 2025, o MFA é obrigatório para qualquer acesso ao CDE. Qualquer usuário que acessa sistemas no escopo do CDE, seja de dentro ou de fora do perímetro da empresa, precisa de autenticação multifator ativa e documentada. Sistemas que não suportam MFA nativo precisam de controle compensatório documentado.
- Processo estruturado de offboarding do CDE
O Requisito 8.1.4 estabelece prazo máximo de 90 dias para desativação de contas inativas, mas para colaboradores desligados, a expectativa é de revogação imediata de qualquer acesso ao CDE. O processo precisa cobrir a conta de domínio principal, contas específicas de sistemas de pagamento, tokens de API, certificados e qualquer credencial criada pelo colaborador para acessar o ambiente.
Prestadores com contrato encerrado precisam do mesmo tratamento, com evidência documentada de que o acesso foi revogado no encerramento do contrato, não dias ou semanas depois.
- Trilha de auditoria centralizada e íntegra
O Requisito 10 exige que todos os acessos ao CDE sejam registrados em uma trilha de auditoria com retenção mínima de 12 meses. Essa trilha precisa ser centralizada e íntegra, com controles que previnam modificação ou exclusão de logs. A rastreabilidade individual depende diretamente de identidades únicas: logs que misturam ações de múltiplos usuários em uma conta compartilhada não atendem ao requisito.
Como a Niuco Garante Conformidade com os Requisitos de Identidade do PCI DSS
A Niuco oferece gestão de acessos para dados sensíveis de pagamento, além de gerar trilhas de auditoria completas e controle de Shadow IT para garantir conformidade com o PCI DSS v4.0.1.
Gestão de acessos ao CDE com princípio do menor privilégio
A Niuco centraliza o controle de acesso ao ambiente de dados do titular do cartão, permitindo definir e aplicar perfis de acesso por função para sistemas de pagamento. Cada identidade, seja de colaborador, prestador ou conta de serviço, tem acesso restrito ao que sua função exige, com aprovação documentada para qualquer exceção. Isso atende diretamente ao Requisito 7 do PCI DSS v4.0.1, com evidência auditável de cada concessão de acesso ao CDE.
Trilha de auditoria completa para o Requisito 10
A Niuco gera uma trilha de auditoria centralizada de todos os acessos ao CDE: quem acessou, o quê, quando, de onde e com qual autorização. Os registros são armazenados com integridade verificável, cobrem o período mínimo de 12 meses exigido pelo Requisito 10 e são exportáveis no formato que o auditor PCI solicita. Cada acesso é vinculado a uma identidade individual, eliminando o problema de rastreabilidade causado por contas compartilhadas.
Visibilidade de Shadow IT no escopo do CDE
A Niuco oferece visibilidade de Shadow IT, identificando ferramentas SaaS em uso no ambiente, incluindo as não autorizadas. Para fins de PCI DSS, isso significa que expansões não controladas do escopo do CDE são identificadas antes da auditoria. Quando um colaborador usa uma ferramenta não autorizada para processar dados de cartão, a Niuco detecta o acesso e permite que o time de segurança tome ação, seja autorizando formalmente a ferramenta e incorporando-a ao escopo ou bloqueando o acesso e documentando a ocorrência.
FAQ: Perguntas Frequentes sobre PCI DSS e Gestão de Identidade
O que é o PCI DSS e quem precisa estar em conformidade?
O PCI DSS (Payment Card Industry Data Security Standard) é o padrão internacional de segurança de dados para a indústria de cartões de pagamento, mantido pelo PCI Security Standards Council. Toda organização que armazena, processa ou transmite dados de conta de pagamento, incluindo fintechs, adquirentes, subadquirentes, gateways, marketplaces e prestadores de serviço com acesso ao ambiente de pagamento, está sujeita ao padrão, independentemente de tamanho ou volume de transações.
Qual versão do PCI DSS está em vigor em 2026?
A versão vigente é a PCI DSS v4.0.1, obrigatória desde 31 de março de 2025. A v4.0.1 é uma atualização de clareza da v4.0 (sem novos requisitos substantivos) e substitui definitivamente a v3.2.1, que foi desativada em março de 2024. Todos os 51 requisitos antes classificados como “future-dated” são plenamente aplicáveis e exigíveis em auditorias de 2026. (PCI Security Standards Council, 2025)
O que o PCI DSS exige em termos de controle de acesso?
Os Requisitos 7 e 8 do PCI DSS cobrem integralmente o controle de acesso. O Requisito 7 exige acesso restrito pelo princípio do menor privilégio, baseado na necessidade de saber e de fazer, com RBAC documentado e revisão semestral. O Requisito 8 exige identificadores únicos por usuário (contas compartilhadas são proibidas), MFA para todo acesso ao CDE, senhas mínimas de 12 caracteres e desativação de contas inativas em até 90 dias.
O MFA é obrigatório para todos os usuários com acesso ao CDE?
Sim, desde março de 2025. O Requisito 8.4.1 do PCI DSS v4.0.1 exige MFA para qualquer acesso ao CDE. Qualquer usuário que acessa sistemas no escopo do CDE, de qualquer localização e de qualquer dispositivo, precisa de autenticação multifator ativa. Essa foi uma das principais mudanças do v4.0 em relação ao v3.2.1.
O que é o CDE e como ele define o escopo do PCI DSS?
O CDE (Cardholder Data Environment, ou Ambiente de Dados do Titular do Cartão) é o conjunto de sistemas, redes e pessoas que armazenam, processam ou transmitem dados de conta de pagamento. Tudo que se conecta ao CDE ou que, se comprometido, pode impactar o CDE, está no escopo da norma. A definição precisa do CDE é o ponto de partida de qualquer programa de conformidade PCI DSS e precisa ser documentada e confirmada anualmente.
Como o Shadow IT afeta a conformidade com o PCI DSS?
O Shadow IT (ferramentas SaaS em uso sem autorização formal) pode expandir o escopo do CDE sem que a empresa saiba. Se um colaborador usa uma ferramenta não autorizada para transmitir ou armazenar dados de cartão, essa ferramenta passa a fazer parte do CDE e precisa cumprir todos os requisitos do PCI DSS. O Requisito 12.5.2 exige revisão e documentação anuais do escopo e Shadow IT não mapeado é um achado frequente em auditorias.
Quanto tempo uma empresa tem para desativar contas de ex-colaboradores no CDE?
O Requisito 8.1.4 do PCI DSS v4.0.1 estabelece prazo máximo de 90 dias para desativação de contas de usuários inativos. Para desligamentos de colaboradores, a expectativa é de revogação imediata de qualquer acesso ao CDE, não existe prazo de tolerância para ex-colaboradores. Qualquer conta ativa de ex-colaborador no ambiente de pagamento identificada durante uma auditoria é um achado, independentemente de quanto tempo se passou desde o desligamento.
