compliance.tf

PCI DSS v3.2.1

Deprecated Framework

This framework has been superseded by PCI DSS v4.0. Organizations should migrate to the newer version, which became mandatory for compliance assessments after March 31, 2024.

The Payment Card Industry Data Security Standard (PCI DSS) version 3.2.1 is an information security standard for organizations that handle branded credit cards from major card schemes. Maintained by the PCI Security Standards Council, this version provides requirements for securing cardholder data including network security, access control, and vulnerability management. It applies globally to all entities that store, process, or transmit cardholder data including merchants, processors, acquirers, issuers, and service providers.

Mandatory?Mandatory for any entity processing card data
Who validates?QSA (Level 1 merchants/SPs); SAQ self-assessment (Levels 2–4)
RenewalAnnual
ScopeCardholder data environment (CDE) and connected systems

Controls by Category

1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic (32 controls)

Firewall rules should prohibit ingress from 0.0.0.0/0 to DNS port 53Firewall rules should prohibit ingress from 0.0.0.0/0 to FTP port 21Firewall rules should prohibit ingress from 0.0.0.0/0 to HTTP port 80Firewall rules should prohibit ingress from 0.0.0.0/0 to Microsoft DS port 445Firewall rules should prohibit ingress from 0.0.0.0/0 to MySQL DB port 3306Firewall rules should prohibit ingress from 0.0.0.0/0 to Oracle DB port 1521Firewall rules should prohibit ingress from 0.0.0.0/0 to POP3 port 110Firewall rules should prohibit ingress from 0.0.0.0/0 to PostgreSQL port 5432Firewall rules should prohibit ingress from 0.0.0.0/0 to SMTP port 25Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP ports 137-139Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP ports 27017-27019Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP ports 61620 or 61621Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 636Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 6379Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP ports 7000 or 7001Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 7199Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 8888Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 9042Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 9090Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP port 9160Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP ports 9200 or 9300Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP or UDP port 11211Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP or UDP ports 11214-11215Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP or UDP ports 2483-2484Firewall rules should prohibit ingress from 0.0.0.0/0 to TCP or UDP port 389Firewall rules should prohibit ingress from 0.0.0.0/0 to Telnet port 23Firewall rules should prohibit ingress from 0.0.0.0/0 to any portCompute Engine instances should not have public IP addressesGKE clusters should have 'Master authorized networks' set to 'Enabled'Firewall rules should prohibit unrestricted SSH access from the internetFirewall rules should prohibit unrestricted TCP/UDP access from the internet to all portsCloud SQL instances should have IP assignment set to private

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment (1 control)

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ (2 controls)

1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet (1 control)

1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties (1 control)

10.4.1 Critical systems have the correct and consistent time (1 control)

10.4.3 Time settings are received from industry-accepted time sources (1 control)

2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network (1 control)

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards (3 controls)

3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse (1 control)

3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary (1 control)

4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks (3 controls)

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by methods like reviewing public-facing web applications via manual or installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic (1 control)

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access (2 controls)

NIST Cybersecurity Framework v2.0 — 🟢 High overlap (87%)

CIS GCP Benchmark v2.0.0 — ⚪ Low overlap (25%)

CIS GCP Benchmark v3.0.0 — ⚪ Low overlap (23%)

On this page

Controls by Category1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic (32)1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment (1)1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ (2)1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet (1)1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties (1)10.1 Implement audit trails to link all access to system components to each individual user. (3)10.2 Implement automated audit trails for all system components to reconstruct the events (3)10.4.1 Critical systems have the correct and consistent time (1)10.4.3 Time settings are received from industry-accepted time sources (1)10.5 Secure audit trails so they cannot be altered (3)2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network (1)2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards (3)3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse (1)3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary (1)4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks (3)6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by methods like reviewing public-facing web applications via manual or installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic (1)7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access (2)7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities (3)Other (4)Related Frameworks

Ask AI about this

Help improve this page