cm/controlmapping
Português
Fontes
Framework

PCI DSS v4.0.1

O que é

O Payment Card Industry Data Security Standard, mantido pelo PCI SSC: 12 requisitos principais para a proteção dos dados de contas de pagamento. A versão 4.0.1 (junho de 2024) é a atual; os requisitos da v4.0 que tinham data futura tornaram-se obrigatórios em 31 de março de 2025.

Quem precisa

Qualquer comerciante ou prestador de serviços que armazene, processe ou transmita dados do titular do cartão, ou que possa afetar a sua segurança. As bandeiras de cartão exigem o cumprimento por meio dos contratos com as adquirentes; não se trata de uma lei.

Como é avaliado

Dependendo do volume de transações e das regras das bandeiras de cartão, pode ser um Relatório de Conformidade elaborado por um Avaliador de Segurança Qualificado (QSA) ou um Questionário de Autoavaliação, cada um acompanhado de um Atestado de Conformidade, além de varreduras trimestrais de vulnerabilidades externas realizadas por um Fornecedor de Varredura Aprovado (ASV). Avaliado anualmente.

260
Requisitos
77
Mapeado para outro framework
92%
Tópicos cobertos (46/50)

Comparações

Requisitos

Os IDs e títulos dos requisitos são exibidos como cada framework os publica, em inglês.

PCI DSS v4.0.1 requisitos
IDRequisitoTópicosMapeado em
Requirement 1: Install and maintain network security controls · 19
1.1.1Network security policies documented and kept current—0
1.1.2Roles for network security controls assigned—0
1.2.1Configuration standards for network security controlsFirewall / Segmentação de rede9 de 13
1.2.2Network connection changes go through change control—nenhum
1.2.3Accurate network diagram maintainedFirewall / Segmentação de rede9 de 13
1.2.4Accurate account-data flow diagram maintained—0
1.2.5Allowed services, protocols and ports approved—nenhum
1.2.6Security features defined for insecure services—nenhum
1.2.7Network security control rules reviewed every six months—nenhum
1.2.8Network security control configuration files secured—nenhum
1.3.1Inbound traffic to the CDE restrictedFirewall / Segmentação de rede9 de 13
1.3.2Outbound traffic from the CDE restricted—nenhum
1.3.3Network controls between wireless networks and the CDE—nenhum
1.4.1Network controls between trusted and untrusted networksFirewall / Segmentação de rede9 de 13
1.4.2Inbound traffic from untrusted networks restricted—nenhum
1.4.3Anti-spoofing measures in place—nenhum
1.4.4Stored cardholder data not reachable from untrusted networks—nenhum
1.4.5Internal IP addresses and routing not disclosed—nenhum
1.5.1Controls on devices connecting to untrusted networks and the CDE—nenhum
Requirement 2: Apply secure configurations to all system components · 11
2.1.1Secure configuration policies documented and kept current—0
2.1.2Roles for secure configuration assigned—0
2.2.1System configuration standards developed and maintainedConfiguração Segura9 de 13
2.2.2Vendor default accounts managed or removedConfiguração Segura9 de 13
2.2.3Functions with different security levels kept apart—nenhum
2.2.4Only necessary services and functions enabled—nenhum
2.2.5Insecure services justified and secured—nenhum
2.2.6System security parameters set to prevent misuse—nenhum
2.2.7Non-console administrative access encrypted—nenhum
2.3.1Wireless vendor defaults changed—0
2.3.2Wireless keys changed when key holders leave—nenhum
Requirement 3: Protect stored account data · 29
3.1.1Stored account data policies documented and kept current—0
3.1.2Roles for protecting stored account data assigned—0
3.2.1Account data storage minimised, with retention and disposalProteção de Dados11 de 13
3.3.1Sensitive authentication data not kept after authorisationProteção de Dados11 de 13
3.3.1.1Full track data not kept after authorisation—nenhum
3.3.1.2Card verification code not kept after authorisation—nenhum
3.3.1.3PIN and PIN block not kept after authorisation—nenhum
3.3.2Sensitive authentication data encrypted before authorisation—nenhum
3.3.3Issuer storage of sensitive authentication data limited and protected—nenhum
3.4.1PAN masked when displayedProteção de Dados11 de 13
3.4.2PAN copying prevented over remote-access technologiesDLP7 de 13
3.5.1PAN rendered unreadable wherever storedCriptografia10 de 13
3.5.1.1Hashes of PAN are keyed cryptographic hashes—nenhum
3.5.1.2Disk-level encryption used only where it suffices—nenhum
3.5.1.3Disk encryption access managed separately from OS access—0
3.6.1Procedures protect keys that secure stored account dataCriptografia10 de 13
3.6.1.1Service providers document their cryptographic architecture—0
3.6.1.2Secret and private keys stored in approved forms—0
3.6.1.3Cleartext key components accessible to fewest custodians—0
3.6.1.4Keys stored in the fewest possible locations—0
3.7.1Key management: strong key generationCriptografia10 de 13
3.7.2Key management: secure key distribution—nenhum
3.7.3Key management: secure key storage—nenhum
3.7.4Key management: key changes at end of cryptoperiodCriptografia10 de 13
3.7.5Key management: retiring weakened or compromised keys—nenhum
3.7.6Key management: split knowledge and dual control—nenhum
3.7.7Key management: preventing unauthorised key substitution—nenhum
3.7.8Key custodians formally acknowledge their responsibilities—nenhum
3.7.9Service providers give customers key-handling guidance—nenhum
Requirement 4: Protect cardholder data with strong cryptography during transmission · 6
4.1.1Data-in-transit policies documented and kept current—0
4.1.2Roles for protecting data in transit assigned—0
4.2.1Strong cryptography for PAN over open, public networksCriptografia10 de 13
4.2.1.1Inventory of trusted keys and certificates keptCriptografia10 de 13
4.2.1.2Strong cryptography on wireless networks carrying PAN—nenhum
4.2.2PAN secured when sent by end-user messaging—nenhum
Requirement 5: Protect all systems and networks from malicious software · 13
5.1.1Anti-malware policies documented and kept current—0
5.1.2Roles for malware protection assigned—0
5.2.1Anti-malware deployed on system componentsProteção de endpoints10 de 13
5.2.2Anti-malware detects, removes or contains known malwareProteção de endpoints10 de 13
5.2.3Systems without anti-malware periodically re-evaluated—0
5.2.3.1Re-evaluation frequency set by targeted risk analysis—0
5.3.1Anti-malware kept up to date—nenhum
5.3.2Periodic scans or continuous behavioural analysisProteção de endpoints10 de 13
5.3.2.1Scan frequency set by targeted risk analysis—0
5.3.3Removable media scanned or analysed—nenhum
5.3.4Anti-malware audit logs enabled and retained—nenhum
5.3.5Users cannot disable or alter anti-malware—nenhum
5.4.1Mechanisms to detect and protect against phishingSegurança de e-mail8 de 13
Requirement 6: Develop and maintain secure systems and software · 19
6.1.1Secure systems and software policies documented—0
6.1.2Roles for secure systems and software assigned—0
6.2.1Bespoke and custom software developed securelyDesenvolvimento Seguro8 de 13
6.2.2Developers trained in secure software developmentDesenvolvimento Seguro8 de 13
6.2.3Custom code reviewed before releaseDesenvolvimento Seguro, Segurança de APIs8 de 13
6.2.3.1Manual code reviews approved by someone else—0
6.2.4Coding techniques prevent common software attacksSegurança de APIs4 de 13
6.3.1Vulnerabilities identified and risk-rankedGestão de Vulnerabilidades, Inteligência de Ameaças, Gestão de Patches13 de 13
6.3.2Inventory of custom software and its componentsRisco na cadeia de suprimentos, Gestão de Ativos13 de 13
6.3.3Security patches installed promptlyGestão de Patches10 de 13
6.4.1Public web applications protected against attacksSegurança Web6 de 13
6.4.2Automated solution blocks attacks on public web appsWAF5 de 13
6.4.3Payment page scripts authorised and integrity-checkedSegurança Web6 de 13
6.5.1Production changes follow change control procedures—nenhum
6.5.2PCI DSS requirements re-confirmed after significant changes—nenhum
6.5.3Pre-production environments separated from production—nenhum
6.5.4Duties separated between production and pre-production—nenhum
6.5.5Live PANs not used in pre-production—nenhum
6.5.6Test data and accounts removed before go-live—nenhum
Requirement 7: Restrict access to system components and cardholder data by business need to know · 12
7.1.1Access restriction policies documented and kept current—0
7.1.2Roles for access restriction assigned—0
7.2.1Access control model definedControle de acesso, Confiança Zero11 de 13
7.2.2Access assigned by job function and least privilegeControle de acesso, Acesso privilegiado12 de 13
7.2.3Privileges approved by authorised personnel—nenhum
7.2.4User accounts and privileges reviewed every six monthsControle de acesso11 de 13
7.2.5System and application accounts least privilege—nenhum
7.2.5.1System and application account access periodically reviewed—0
7.2.6Access to cardholder data repositories restricted—nenhum
7.3.1Access control system restricts access by need—nenhum
7.3.2Access control system enforces assigned permissions—nenhum
7.3.3Access control system set to deny by default—nenhum
Requirement 8: Identify users and authenticate access to system components · 29
8.1.1Identification and authentication policies documented—0
8.1.2Roles for identification and authentication assigned—0
8.2.1Every user has a unique IDControle de acesso11 de 13
8.2.2Shared or generic accounts only by documented exception—0
8.2.3Service providers use unique credentials per customer—nenhum
8.2.4User ID changes authorised and controlled—nenhum
8.2.5Access revoked immediately on termination—0
8.2.6Inactive user accounts disabled within 90 days—0
8.2.7Third-party remote access accounts enabled only when needed—nenhum
8.2.8Re-authentication after 15 minutes idle—0
8.3.1User and admin access requires an authentication factorConfiança Zero7 de 13
8.3.2Authentication factors unreadable in transit and storage—nenhum
8.3.3Identity verified before changing authentication factors—nenhum
8.3.4Account lockout after repeated failed attempts—nenhum
8.3.5First-use and reset passwords unique and changed—0
8.3.6Minimum password length and complexity—0
8.3.7Recent passwords cannot be reused—0
8.3.8Authentication guidance communicated to users—0
8.3.9Password-only access: change every 90 days or analyse risk—0
8.3.10Service providers give customers password guidance—0
8.3.10.1Service provider customer passwords: rotation or analysis—0
8.3.11Tokens, smart cards and certificates assigned to individuals—nenhum
8.4.1MFA for non-console administrative access to the CDEAutenticação multifator10 de 13
8.4.2MFA for all access into the CDEAutenticação multifator10 de 13
8.4.3MFA for remote network accessAutenticação multifator10 de 13
8.5.1MFA systems configured to resist misuseAutenticação multifator10 de 13
8.6.1Interactive use of system accounts managed—nenhum
8.6.2No hard-coded passwords for system accounts—0
8.6.3System account passwords protected and changed—0
Requirement 9: Restrict physical access to cardholder data · 27
9.1.1Physical security policies documented and kept current—0
9.1.2Roles for physical security assigned—0
9.2.1Facility entry controls restrict CDE accessSegurança Física8 de 13
9.2.1.1Access to sensitive areas monitored by camera or access controlSegurança Física8 de 13
9.2.2Publicly accessible network jacks restricted—nenhum
9.2.3Physical access to network hardware restrictedSegurança Física8 de 13
9.2.4Consoles in sensitive areas locked when unattended—0
9.3.1Personnel physical access authorised and managedSegurança Física8 de 13
9.3.1.1Sensitive-area access authorised and revoked promptlySegurança Física8 de 13
9.3.2Visitor access authorised, escorted and identifiableSegurança Física8 de 13
9.3.3Visitor badges returned or deactivated—nenhum
9.3.4Visitor log maintained and retained—nenhum
9.4.1Media with cardholder data physically secured—nenhum
9.4.1.1Offline backup media stored securelyBackup e recuperação11 de 13
9.4.1.2Security of offline backup location reviewed annually—0
9.4.2Media classified by data sensitivityClassificação de Dados9 de 13
9.4.3Media sent off site tracked and secured—nenhum
9.4.4Management approves media moved off site—nenhum
9.4.5Inventory logs of electronic media kept—nenhum
9.4.5.1Electronic media inventories at least annually—nenhum
9.4.6Hard-copy media destroyed when no longer needed—0
9.4.7Electronic media destroyed or made unrecoverable—0
9.5.1Card-reading (POI) devices protected from tampering—nenhum
9.5.1.1Inventory of POI devices kept—0
9.5.1.2POI devices inspected for tampering—0
9.5.1.2.1Inspection frequency set by targeted risk analysis—0
9.5.1.3Staff trained to spot POI tampering—nenhum
Requirement 10: Log and monitor all access to system components and cardholder data · 27
10.1.1Logging and monitoring policies documented—0
10.1.2Roles for logging and monitoring assigned—0
10.2.1Audit logs enabled and activeRegistro e Auditoria, Ameaça interna11 de 13
10.2.1.1Logs capture user access to cardholder data—nenhum
10.2.1.2Logs capture administrative actions—nenhum
10.2.1.3Logs capture access to audit logs—nenhum
10.2.1.4Logs capture invalid access attempts—nenhum
10.2.1.5Logs capture credential and privilege changes—nenhum
10.2.1.6Logs capture starting, stopping or pausing logging—nenhum
10.2.1.7Logs capture system-level object changes—nenhum
10.2.2Log entries record who, what, when, where and outcome—0
10.3.1Read access to logs limited to need—0
10.3.2Logs protected from modificationRegistro e Auditoria, Perícia forense10 de 13
10.3.3Logs promptly backed up to a central server—0
10.3.4File-integrity monitoring on logs—0
10.4.1Security event and critical logs reviewed dailyMonit. contínuo, SIEM / SOC10 de 13
10.4.1.1Automated mechanisms for log reviewDetecção de Anomalias9 de 13
10.4.2Other logs reviewed periodically—nenhum
10.4.2.1Review frequency set by targeted risk analysis—0
10.4.3Exceptions and anomalies addressed—nenhum
10.5.1Audit logs retained 12 months, three immediately availableRegistro e Auditoria10 de 13
10.6.1System clocks synchronisedRegistro e Auditoria10 de 13
10.6.2Time configuration correct and consistent—nenhum
10.6.3Time settings protected from change—0
10.7.1Service providers detect security control failures—0
10.7.2Critical security control failures detected and reported—0
10.7.3Security control failures responded to promptly—nenhum
Requirement 11: Test security of systems and networks regularly · 21
11.1.1Security testing policies documented and kept current—0
11.1.2Roles for security testing assigned—0
11.2.1Wireless access points detected and unauthorised ones handled—0
11.2.2Inventory of authorised wireless access points—nenhum
11.3.1Internal vulnerability scans every three monthsGestão de Vulnerabilidades13 de 13
11.3.1.1Lower-ranked vulnerabilities handled by risk analysis—0
11.3.1.2Internal scans use authenticated scanning—nenhum
11.3.1.3Internal scans after significant changes—nenhum
11.3.2External ASV scans every three monthsGestão de Vulnerabilidades13 de 13
11.3.2.1External scans after significant changes—nenhum
11.4.1Penetration testing methodology defined—nenhum
11.4.2Internal penetration test at least annually—nenhum
11.4.3External penetration test at least annually—nenhum
11.4.4Penetration test findings corrected and retested—0
11.4.5Segmentation controls tested at least annually—nenhum
11.4.6Service providers test segmentation every six months—nenhum
11.4.7Multi-tenant providers support customer penetration tests—nenhum
11.5.1Intrusion detection or prevention on network trafficDetecção de intrusão9 de 13
11.5.1.1Service providers detect covert malware communication—nenhum
11.5.2Change-detection on critical files—nenhum
11.6.1Payment page changes and tampering detected—0
Requirement 12: Support information security with organizational policies and programs · 37
12.1.1Information security policy established and publishedPolítica de governança9 de 13
12.1.2Security policy reviewed at least annuallyPolítica de governança9 de 13
12.1.3Security roles and responsibilities definedFunções e responsabilidades9 de 13
12.1.4Executive responsibility for information security assignedFunções e responsabilidades9 de 13
12.2.1Acceptable use policies for end-user technologies—nenhum
12.3.1Targeted risk analysis for flexible-frequency requirementsGestão de Riscos, Avaliação de riscos10 de 13
12.3.2Targeted risk analysis for customised approach—0
12.3.3Cipher suites and protocols reviewed annually—0
12.3.4Hardware and software technologies reviewed annually—0
12.4.1Service providers: executive responsibility for PCI DSS compliance—nenhum
12.4.2Service providers: quarterly reviews of operational tasksConformidade10 de 13
12.4.2.1Service providers: quarterly review results documented—0
12.5.1Inventory of in-scope system componentsGestão de Ativos13 de 13
12.5.2PCI DSS scope confirmed annually and on changeAmbiente de Negócios5 de 13
12.5.2.1Service providers confirm scope every six months—nenhum
12.5.3Service providers review scope after organisational change—0
12.6.1Formal security awareness programmeConscientização e treinamento10 de 13
12.6.2Awareness programme reviewed annually—nenhum
12.6.3Awareness training on hire and at least annuallyConscientização e treinamento10 de 13
12.6.3.1Training covers phishing and social engineering—nenhum
12.6.3.2Training covers acceptable use of technology—nenhum
12.7.1Personnel screened before hireAmeaça interna8 de 13
12.8.1List of third-party service providers keptRisco na cadeia de suprimentos, Segurança em Nuvem, Gestão de Risco de Fornecedores12 de 13
12.8.2Written agreements with service providersGestão de Risco de Fornecedores10 de 13
12.8.3Due diligence before engaging service providersGestão de Risco de Fornecedores10 de 13
12.8.4Service provider compliance monitored annuallyGestão de Risco de Fornecedores10 de 13
12.8.5Responsibilities split with each provider documentedSegurança em Nuvem, Gestão de Risco de Fornecedores12 de 13
12.9.1Service providers acknowledge responsibilities to customers—0
12.9.2Service providers support customer compliance requests—0
12.10.1Incident response plan ready to activateResposta a Incidentes, Mitigação, Notificação, Planejamento de Recuperação, Continuidade de Negócios, Recuperação de desastres12 de 13
12.10.2Incident response plan reviewed and tested annuallyResposta a Incidentes12 de 13
12.10.3Incident response staff available around the clockResposta a Incidentes12 de 13
12.10.4Incident response staff trainedResposta a Incidentes12 de 13
12.10.4.1Training frequency set by targeted risk analysis—0
12.10.5Plan covers alerts from security monitoring—0
12.10.6Plan updated from lessons learned and industry changesLições Aprendidas9 de 13
12.10.7Procedures for PAN found where it shouldn't be—0
Appendix A: additional requirements · 10
A1.1.1Multi-tenant providers: separate provider and customer environments—nenhum
A1.1.2Multi-tenant providers: customers confined to their own environment—nenhum
A1.1.3Multi-tenant providers: customers reach only their own data—nenhum
A1.1.4Multi-tenant providers: separation tested every six months—nenhum
A1.2.1Multi-tenant providers: audit logging for each customer—nenhum
A1.2.2Multi-tenant providers: support customer forensic investigations—nenhum
A1.2.3Multi-tenant providers: report suspected incidents to customers—nenhum
A2.1.1POI terminals using SSL or early TLS not exploitable—nenhum
A2.1.2Service providers: migration plan off SSL and early TLS—nenhum
A2.1.3Service providers offer a secure connection option—nenhum

Cobertura do tópico

Tópicos com requisitos mapeados de PCI DSS (46):

Sem mapeamento em nossos dados Nenhum requisito de PCI DSS (4):