PCI DSS Requirements

Overview of the 12 PCI DSS requirements

The Payment Card Industry Data Security Standard (PCI DSS) organizes its controls into 12 high-level requirements. These requirements apply to every entity that stores, processes, or transmits cardholder data, and they form the backbone of every PCI DSS compliance assessment. Understanding each requirement is the first step toward building a sustainable compliance program.

The requirements are grouped into six overarching goals that progress from building a secure network to maintaining an information security policy. Whether you are a Level 1 merchant completing a Report on Compliance or a smaller merchant filing a Self-Assessment Questionnaire, the same 12 requirements apply.

Goal 1: build and maintain a secure network and systems

Requirement 1 - Install and maintain network security controls

Requirement 1 mandates that organizations deploy firewalls, network security appliances, and segmentation controls to protect the cardholder data environment (CDE). In PCI DSS v4.0, the language shifted from "firewalls" to "network security controls" to acknowledge modern architectures such as cloud-native security groups, micro-segmentation, and software-defined networking. Organizations must document all network connections into and out of the CDE, review rule sets at least every six months, and restrict traffic to only what is business-justified.

Requirement 2 - Apply secure configurations to all system components

Default passwords, unnecessary services, and insecure protocols create easy attack vectors. Requirement 2 requires organizations to harden every system component by removing defaults, disabling unnecessary services, and configuring security parameters according to industry-accepted hardening standards such as CIS Benchmarks. PCI DSS v4.0 expanded this to explicitly cover all system components, not just vendor-supplied defaults.

Goal 2: protect account data

Requirement 3 - Protect stored account data

If your organization stores cardholder data, Requirement 3 dictates how it must be protected. This includes encryption, truncation, masking, and hashing. Sensitive authentication data such as full track data, CVV codes, and PINs must never be stored after authorization. PCI DSS v4.0 introduced more prescriptive guidance on keyed cryptographic hashes and disk-level encryption limitations, reinforcing that storage should be minimized wherever possible.

Requirement 4 - Protect cardholder data with strong cryptography during transmission

Cardholder data transmitted over open, public networks must be encrypted using strong cryptography. Requirement 4 specifies the use of trusted certificates and secure protocols such as TLS 1.2 or higher. PCI DSS v4.0 clarified that this applies to all networks where data could be intercepted, including internal networks where risk is present, and deprecated older protocols like early TLS and SSL.

Goal 3: maintain a vulnerability management program

Requirement 5 - Protect all systems and networks from malicious software

Anti-malware solutions must be deployed on all systems commonly affected by malicious software. Requirement 5 in v4.0 expanded its scope beyond traditional endpoints to include any system component that could be impacted. Organizations must ensure that anti-malware mechanisms are actively running, generating audit logs, and cannot be disabled by users without authorization. Phishing protections were also added as a new focus area.

Requirement 6 - Develop and maintain secure systems and software

Requirement 6 addresses secure software development and timely patching. Critical security patches must be applied within one month of release. Organizations developing payment applications must follow a secure development lifecycle. PCI DSS v4.0 introduced a significant new sub-requirement mandating that public-facing web applications be protected by automated technical solutions that detect and prevent web-based attacks, such as web application firewalls (WAFs).

Goal 4: implement strong access control measures

Requirement 7 - Restrict access to system components and cardholder data by business need to know

Access to cardholder data and CDE systems must follow the principle of least privilege. Only personnel whose job functions require access should have it, and access must be granted through a formal authorization process. PCI DSS v4.0 requires that access reviews occur at least every six months and that all access is revoked promptly when no longer needed.

Requirement 8 - Identify users and authenticate access to system components

Every user must have a unique identifier, and authentication mechanisms must be strong enough to prevent unauthorized access. PCI DSS v4.0 significantly expanded multi-factor authentication (MFA) requirements, mandating MFA for all access into the CDE rather than just remote access. Password requirements were also updated to a minimum of 12 characters, with encouragement to adopt passphrases.

Requirement 9 - Restrict physical access to cardholder data

Physical security controls protect servers, workstations, paper records, and networking equipment within the CDE. Requirement 9 covers visitor management, media destruction, and point-of-interaction device inspections. Organizations must maintain logs of physical access and periodically inspect POS devices for tampering or unauthorized substitution.

Goal 5: regularly monitor and test networks

Requirement 10 - Log and monitor all access to system components and cardholder data

Comprehensive logging is essential for detecting breaches and supporting forensic investigations. Requirement 10 mandates that audit trails capture all individual user access to cardholder data, all actions by administrators, and all access to audit trails themselves. PCI DSS v4.0 introduced automated mechanisms for reviewing audit logs and detecting anomalies, moving beyond manual log review toward security information and event management (SIEM) integration.

Requirement 11 - Test security of systems and networks regularly

Vulnerability scanning and penetration testing validate that security controls are functioning as intended. Requirement 11 specifies quarterly internal and external vulnerability scans (external scans by an Approved Scanning Vendor), annual penetration tests, and intrusion detection or prevention systems. PCI DSS v4.0 added authenticated internal scanning requirements and a new mandate for detecting and alerting on unauthorized changes to payment pages, addressing the growing threat of Magecart-style attacks on e-commerce sites.

Goal 6: maintain an information security policy

Requirement 12 - Support information security with organizational policies and programs

Requirement 12 requires a comprehensive information security policy that addresses all PCI DSS requirements. It covers security awareness training, incident response planning, risk assessments, and third-party service provider management. PCI DSS v4.0 expanded the risk assessment requirements and introduced a targeted risk analysis approach where organizations perform formal risk analyses to determine the frequency of certain recurring activities.

Key changes in PCI DSS v4.0

PCI DSS v4.0 brought several cross-cutting changes that affect multiple requirements:

Customized approach - Organizations can now meet requirement objectives through alternative controls validated by a customized approach, rather than following only the defined prescriptive approach.
Targeted risk analysis - A new methodology lets organizations determine the appropriate frequency for activities like log reviews and password changes based on documented risk analysis.
Expanded MFA - Multi-factor authentication is now required for all access into the CDE, not just remote access.
E-commerce protections - New requirements address script integrity monitoring and management for payment pages.
Phishing defenses - Explicit requirements for anti-phishing mechanisms were added under Requirement 5.

For a complete walkthrough of the transition, see the PCI DSS v4.0 changes topic.

Building a sustainable compliance program

Meeting the 12 PCI DSS requirements is not a one-time project. Organizations in the fintech industry and beyond should treat compliance as an ongoing program with continuous monitoring, regular training, and periodic reassessment. Automating evidence collection, mapping controls to specific requirements, and integrating compliance workflows with engineering tools reduces the burden on security teams and ensures readiness for every assessment cycle.