Sign in
Menu
Sign up
Docs

PCI DSS v3.2.1

Deprecated

Best for: The PCI-DSS standard applies to any organization, no matter what size, that accepts, transmits, or stores cardholder data. Its scope includes all systems, networks, and applications that process, store, or transmit cardholder data, and systems used to secure and log access to them.

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
Governing bodyPCI Security Standards Council, PCI DSS v3.2.1 (superseded by v4.0). Official source

Controls by category

60 controls are Mapped to PCI DSS v3.2.1.

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

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

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

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ

1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet

1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties

10.2 Implement automated audit trails for all system components to reconstruct the events

10.4.1 Critical systems have the correct and consistent time

10.4.3 Time settings are received from industry-accepted time sources

10.5 Secure audit trails so they cannot be altered

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

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.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse

3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary

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

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

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

7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities

Other

FrameworkControl overlapNote
NIST Cybersecurity Framework v2.0High 87%
CIS GCP Benchmark v2.0.0Low 25%
CIS GCP Benchmark v3.0.0Low 23%

Frequently asked questions

Who created PCI DSS and why?

The PCI Security Standards Council created it. The major credit card associations (Visa, MasterCard, American Express, Discover, JCB) established the Council as a separate organization to define practices that merchants and service providers should follow to protect cardholder data.

What systems fall within the scope of PCI DSS?

The scope includes all systems, networks, and applications that process, store, or transmit cardholder data. It also covers systems that are used to secure and log access to the systems in scope.

Is the customer still responsible for PCI DSS compliance when using Google Cloud services?

Yes, customers remain responsible for ensuring that their applications are PCI DSS compliant. Google Cloud services provide infrastructure on which customers may build services that store, process, or transmit cardholder data. A shared responsibility matrix explains the split.

How often does Google Cloud undergo a PCI DSS audit, and how can customers get the reports?

Google Cloud undergoes at least an annual third-party audit to certify individual products against the PCI DSS. PCI DSS reports may be requested via the Compliance Reports Manager for Google Cloud.

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 traffic1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties10.1 Implement audit trails to link all access to system components to each individual user.10.2 Implement automated audit trails for all system components to reconstruct the events10.4.1 Critical systems have the correct and consistent time10.4.3 Time settings are received from industry-accepted time sources10.5 Secure audit trails so they cannot be altered2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network2.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 standards3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks6.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 traffic7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilitiesOtherRelated frameworksFrequently asked questions

Ask AI about this

Help improve this page