Objectives of the Prioritized Approach:
Establishing a roadmap of the PCI Requirements based on risk.
Risk is associated with storing, processing and transmitting cardholder data.
Provides a roadmap that prioritizes efforts to achieve compliance, establishes milestones and lowers risk of breaches.
Objectively measures compliance activities and risk reduction by orgs.
Based on reviewing data from breaches and feedback from actual security assessors.
Milestone | Compliance Goals |
1 | Do not store sensitive authentication data and limit cardholder data retention. Reducing the effects of a compromise by reducing the data stored. |
2 | Protect systems and networks and be prepared to respond to a system breach. |
3 | Secure payment applications. Targets applications, application processes, and application servers. |
4 | Monitor and control access to your systems. |
5 | Protect stored cardholder data. Key for business storing Primary Account Numbers, not Sensitive Authentication Data as noted above. |
6 | Complete remaining compliance efforts and ensure all controls are in place. This milestone completes PCI DSS requirements and finishes all remaining related policies, procedures and processes needed to protect cardholder data environments. |
Detailed Explanations:
Risk Level 1 (Milestone 1) – Eliminate High-Risk Data and Limit Retention
These requirements are focused on reducing the risk and impact of a data breach by eliminating the storage of sensitive authentication data (SAD) and limiting cardholder data (CHD) retention to only what’s necessary.
Organizations must maintain accurate network and dataflow diagrams (1.2.3, 1.2.4) to clearly understand where sensitive data exists and flows. Strong data retention and disposal practices (3.2.1, 9.4.6, 9.4.7) ensure that CHD and SAD are not stored longer than needed, whether in digital or physical form. Critically, storing SAD such as CVV2, full track data, or PIN blocks after authorization is strictly prohibited (3.3.1 and sub-requirements), and if SAD must be stored briefly before authorization (for issuers), it must be strongly encrypted (3.3.2, 3.3.3).
Finally, the organization must regularly confirm and document the scope of its PCI environment (12.5.2) to ensure all data flows and storage points are properly understood and secured. Together, these controls aim to shrink the attack surface and reduce the potential fallout in the event of a breach.
Risk Level 2 (Milestone 2) – Protect Systems and Networks; Be Ready to Respond to a Breach
This risk level focuses on hardening the environment to prevent unauthorized access and limit exposure in the event of an attack. These requirements are all about building strong foundational security: configuring firewalls, routers, and network security controls (1.2.x–1.5.x) to manage traffic and secure trusted zones, ensuring wireless environments are protected (2.3.x), and enforcing encryption for data in transit (4.2.x). It also includes deploying anti-malware and endpoint protection (5.x), ensuring secure authentication (8.x), and establishing robust access controls.
Physical security also plays a big role here, with controls around restricting facility and console access (9.2.x–9.5.x). Organizations must continuously assess vulnerabilities via scanning, penetration testing, and intrusion detection systems (11.x), and manage third-party risks through formal agreements, due diligence, and oversight (12.8.x–12.9.x).
Lastly, incident response must be planned, tested, and ready to go 24/7 (12.10.x), ensuring any security event can be addressed quickly and effectively. These controls help build a secure perimeter and ensure the organization is prepared to identify and contain threats before they escalate.
Risk Level 3 (Milestone 3) – Secure Payment Applications
This risk level focuses on reducing vulnerabilities in custom software and payment applications, which are frequent targets in data breaches. The goal is to ensure that software is developed securely from the start.
Organizations must follow secure coding practices (6.2.x, 6.4.2), train developers on those practices, and conduct thorough code reviews before release to catch issues early (6.2.2–6.2.4). There's also an emphasis on identifying and managing vulnerabilities (6.3.1), maintaining an inventory of custom software (6.3.2), and keeping systems patched and up to date (6.3.3).
Web applications must be protected by firewalls (6.4.1–6.4.2), and development environments need to be logically separated from production to prevent accidental data leaks (6.5.3–6.5.6). Live cardholder data must never be used in testing, and test data must be cleaned out before software goes live. These controls help prevent insecure code and misconfigurations from becoming a point of entry for attackers.
Risk Level 4 (Milestone 4) – Control Access and Monitor Activity
This set of requirements focuses on ensuring that only the right people — and only when necessary — have access to systems and data.
Organizations must implement structured access controls (7.2.x–7.3.x), assigning access based on job roles, following approval processes, enforcing least privilege, and using systems that deny access by default. Authentication must be properly managed, with secure passwords and unique user credentials (8.3.x, 8.6.x). Access to stored cardholder data must be tightly restricted and monitored.
Logging and monitoring play a major role here: audit logs must be enabled across all systems (10.2.x), protected from tampering (10.3.x), and reviewed regularly for signs of suspicious activity (10.4.x–10.5.1). Time synchronization (10.6.x) ensures accurate event correlation, and organizations must be able to respond quickly to failures of key security controls (10.7.x).
Controls over wireless access points (11.2.x) and file integrity monitoring (11.5.2) add further visibility and protection. For multi-tenant service providers, logical separation and access boundaries between customers must be enforced (A1.x), with individualized logging and data access controls. Altogether, these requirements help ensure that any unauthorized activity is prevented, detected, and responded to in a timely manner.
Risk Level 5 (Milestone 5) – Protect Stored Cardholder Data
This milestone focuses on securing cardholder data that must be stored, especially Primary Account Numbers (PAN).
The standard requires PAN to be unreadable wherever it’s stored — whether through encryption, hashing, truncation, or tokenization (3.5.1 and sub-requirements). Additionally, PAN must be masked when displayed (3.4.1), and copy-paste of PAN must be technically restricted for remote access users (3.4.2). Cryptographic key management is a major focus, with detailed controls around secure key generation, distribution, storage, rotation, and destruction (3.6.x–3.7.x), as well as protections against key misuse or substitution.
Organizations must also safeguard the physical media that stores CHD: this includes securing it onsite (9.4.1), classifying it appropriately (9.4.2), controlling and documenting any offsite transfers (9.4.3–9.4.5), and keeping detailed inventories. Physical access to the CDE must also be controlled — both for personnel and visitors — with clear procedures, logging, and access revocation (9.3.x). These requirements reduce the likelihood that stored data could be accessed or exfiltrated, even if a system or physical asset is compromised.
Risk Level 6 (Milestone 6) – Maintain Security Policies and Ongoing Processes
These requirements are foundational for long-term security and compliance, ensuring that all controls are supported by clearly documented policies, procedures, and defined roles.
Each PCI DSS requirement must have policies in place (e.g., 1.1.1, 2.1.1, etc.) along with designated responsibilities to ensure accountability (e.g., 1.1.2, 2.1.2, etc.). These controls reinforce consistency across the organization by requiring reviews of security configurations, change management practices, and verification that updates don’t introduce new risks (6.5.x).
The broader information security program must be formally established and reviewed regularly (12.1.x–12.4.x), with executive-level ownership over cardholder data protection and compliance. Organizations are also expected to conduct quarterly reviews of critical security processes and reassess scope when significant organizational changes occur (12.4.2, 12.5.3). Security awareness is a key focus — all employees must be trained upon hire and annually thereafter (12.6.x), and training programs should evolve to address emerging threats. Lastly, background checks (12.7.1) help mitigate the risk of insider threats. These controls may not directly reduce breach impact in the short term, but they build the governance and culture needed for sustainable security.
Specific Requirements Per Risk Level
Risk Level 1 Requirements:
1.2.3 - Accurate network diagrams maintained.
1.2.4 - Accurate dataflow diagrams maintained.
3.2.1 - Account data storage is kept to a minimum through implementation of data retention and disposal.
3.3.1 - SAD is not stored after authorization.
3.3.1.1, 3.3.1.2, 3.3.1.3
3.3.2 - SAD is stored electronically prior to completion of authorization and is encrypted using strong cryptography.
3.3.3 Any storage of SAD is limited to what is needed for a legitimate issuing business need and is secured, encrypted using strong cryptography.
NOTE: This requirement is only for businesses that issue credit cards.
9.4.6 - Hard-copy materials with cardholder data are destroyed when no longer needed for business.
9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons.
12.5.2 - PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant changes to the in-scope environment.
Risk Level 2 Requirements:
1.2.1 - Configuration standards for network security controls are defined, implemented and maintained.
1.2.5 - All services, protocols and ports allowed are identified, approved and have a defined business need.
1.2.6 - security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.
1.2.8 - Configuration files for network security files (this is for routers) are secured from unauthorized access and kept consistent with active network configurations.
1.3.1 - Restrict inbound network traffic.
1.3.2 - Restrict outbound network traffic.
1.3.3 - Install network security controls between wireless environments.
1.4.1 - Implement network security controls between trusted and untrusted networks.
1.4.2 - Inbound traffic from untrusted networks to trusted networks is restricted.
1.4.3 - Anti-spoofing is enabled.
1.4.4 - System components that store cardholder data are not directly accessible from untrusted networks.
1.4.5 - Internal IP addresses are disclosed to only authorized parties.
1.5.1 - Personal firewalls are configured on computing devices.
2.2.1 - Configuration standards are developed, implemented and maintained.
2.2.2 - Vendor default accounts are hardened.
2.2.3 - Primary functions for system components are configured.
2.3.1 - Wireless environments are secure.
2.3.2 - Wireless environments have encryption keys changed.
4.2.1 - Strong cryptography and security protocols are implemented to secure data in transit.
4.2.1.1, 4.2.1.2.
4.2.2 - PAN is secured with strong cryptography when sent via end-user messaging technologies.
5.2.1 - Anti-malware solutions are deployed.
5.2.2 - Anti-malware detects, removes, locks or contains malware.
5.2.3 - System components not at risk for malware are periodically evaluated.
5.3.2.1
5.3.1 - Anti-malware is kept current via automatic updates.
5.3.2 - Anti-malware performs scans.
5.3.2.1
5.3.3 - Removable electronic media is scanned for malware.
5.3.4 - Audit logs from anti-malware are being generated.
5.3.5 - Anti-malware cannot be tampered with.
5.4.1 - Protection against phishing attacks.
6.4.3 - All payment page scripts are managed.
8.2.1 - All users are assigned a unique ID.
8.2.2 - Group accounts are managed.
8.2.3 - Remote access has unique authentication factors when accessing customer premises.
8.2.4 - Addition, deletion, and modification of users IDs are tracked.
8.2.5 - Access for terminated users is immediately revoked.
8.2.6 - Inactive users accounts are removed within 90 days.
8.2.7 - Accounts used by third parties to access in-scope CDE are restricted.
8.2.8 - User sessions timeout after 15 minutes of inactivity.
8.3.1 - user access is authenticated through something you know, have or are.
8.3.2 - Cryptography is used to render all authentication credentials unreadable.
8.3.3 - User identity is verified before modifying any authentication factor.
8.3.4 - Invalid authentication attempts are limited.
8.3.5 - First time passwords are unique, and reset after use.
8.3.6 - Password strength.
8.3.7 - Password history.
8.3.9 - Passwords are changed every 90 days.
8.3.10 - Password guidance provided to customers.
8.4.1 - MFA is enabled for non-console admin access.
8.4.2 - MFA is implemented for non-console access.
8.4.3 - MFA is implemented for all remote access originating from outside the network.
8.5.1 - MFA is not susceptible to attacks.
9.2.1 - Appropriate facility entry controls are in place to restrict physical access to CDE systems.
9.2.1.1
9.2.2 - Physical and logical access controls are implemented.
9.2.3 - Physical access to wireless access points is restricted.
9.2.4 - Access to consoles within sensitive areas is restricted.
9.3.1.1 - Physical access to sensitive areas is restricted.
9.5.1 POI inspection and tamper protection.
9.5.1.1, 9.5.1.2, 9.5.1.2.1, 9.5.1.3,
11.3.1 - Internal vulnerability scans.
11.3.1.1, 11.3.1.2, 11.3.1.3
11.3.2 - External vulnerability scans.
11.3.2.1
11.4.1 - Penetration testing methodology.
11.4.2 - Internal pen test.
11.4.3 - External penetration testing is performed.
11.4.4 - Remediation of exploitable vulnerabilities.
11.4.5 and 11.4.6 - Segmentation testing
11.4.7 - Multi-tenant service providers support customer penetration testing.
11.5.1 - IDS/IPS installed and running.
11.5.1.1
11.6.1 - Tamper protection on payment page scripts.
12.3.1 - Targeted risk analysis.
12.3.2 - Targeted risk analysis per requirement is reviewed.
12.5.1 - Maintain a PCI DSS inventory.
12.8.1 - Maintaining a third-party service provider (TPSP) inventory.
12.8.2 - TPSP written agreements are maintained.
12.8.3 - TPSP due diligence.
12.8.4 - Monitoring TPSP compliance.
12.8.5 - TPSP responsibility matrix.
12.9.1 - Service providers provide acknowledgement of PCI responsibilities within written agreements with customers.
12.9.2 - PCI compliance of Service providers is shared with its customers.
12.10.1 - Incident response (IR) plan
12.10.2 - Annual IR testing.
12.10.3 - 24/7 IR monitoring.
12.10.4 - Training for personnel on IR roles and responsibilities.
12.10.4.1
12.10.5 - IR monitoring of critical security controls.
12.10.6 - IR modification based on lessons learned.
12.10.7 - IR procedures are in place for PAN being detected outside of areas it should be.
A1.1.4 - The effectiveness of logical separation controls used to separate customer environments is confirmed through penetration testing every 6 months.
A1.2.2 - Processes or mechanisms are implemented to support forensic investigations.
A1.2.3 - Processes or mechanisms are implemented for reporting and addressing incidents.
A2.1.1 - Where POS PI terminals use SSL or early TLS, they are known not to be susceptible to exploits.
A2.1.2 - Risk mitigation for POS POI devices that connect to Service Providers and use SSL or early TLS.
A2.1.3 - All service providers provide a secure service offering.
Risk Level 3 Requirements:
6.2.1 - Bespoke and custom software is developed securely.
6.2.2 - Software development personnel are trained on secure coding techniques.
6.2.3 - Code reviews are conducted before code is released.
6.2.3.1
6.2.4 - Secure coding techniques are followed when developing software.
6.3.1 - Vulnerabilities are identified and managed.
6.3.2 - Inventory of custom and bespoke software is tracked.
6.3.3 - System components are protected through installing patches.
6.4.1 - Web application firewalls are installed.
6.4.2 - Web application firewalls are installed.
6.5.3 - Pre-production environments are separated from prod.
6.5.4 - Roles and functions are separated between production and pre-production environments.
6.5.5 - Live PANs are not used in pre-production environments.
6.5.6 - Test accounts and test data is removed before changes are released into prod.
Risk Level 4 Requirements:
7.2.1 - Access control modeled and granting access follows a procedure.
7.2.2 - Access is assigned based on job classification and least privileges.
7.2.3 - Required privileges are approved by authorized personnel
7.2.4 - All user accounts are reviewed.
7.2.5 - All application and system accounts and related access privileges are managed.
7.2.5.1
7.2.6 - All user access to query repositories of stored cardholder data is restricted.
7.3.1 - Access control systems are in place to restrict access on a user need to know basis.
7.3.2 - Access control systems are configured to enforce permissions.
7.3.3 - The access control systems are set to deny all by default.
8.3.8 - Authentication policies and procedures are documented and communicated.
8.3.11 - Authentication factors that are physical or logical tokens are not shared and intended to be used by the user that it is assigned to.
8.6.1 - System and application accounts are used for interactive login; they are managed by the points outlined within the requirement.
8.6.2 - Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded.
8.6.3 - Passwords/passphrases that are used for application and systems are changed periodically and complex.
10.2.1 - Audit logs are enabled and active on all system components.
10.2.1.1, 10.2.1.2, 10.2.1.3, 10.2.1.4, 10.2.1.5, 10.2.1.6, 10.2.1.7
10.3.1 - Read access to audit logs is limited to those with a job related need.
10.3.2 - Audit log files are prevented from modification from individuals.
10.3.3 - Audit log files are backed up promptly.
10.3.4 - FIM is installed to alert on any modifications to audit log files.
10.4.1 - Audit logs are reviewed on a daily basis.
10.4.1.1
10.4.2 - All other audit logs are reviewed on a periodic basis.
10.4.2.1
10.4.3 - Exceptions identified during audit log reviews are addressed.
10.5.1 - Retain audit logs for 12 months and have them readily available for the last 3 months of audit logs.
10.6.1 - System clocks and time are synchronized using time-synchronization technology.
10.6.2 - NTP systems are correct and consistent.
10.6.3 - NTP settings are protected from being tampered with and restricted.
10.7.1, 10.7.2 and 10.7.3 - Failures of security controls are addressed.
11.2.1 - Authorized and unauthorized wireless access points are managed.
11.2.2 - Inventory of wireless access points is maintained.
11.5.2 - Change-detection mechanisms are deployed to notify personnel of changes (FIM).
A1.1.1 - Logical separation is implemented for multi-tenant service providers.
A1.1.2 - Controls are implemented such that each customer only has permission to access their own CHD.
A1.1.3 - Controls are implemented such that each customer can only access resources allocated to them.
A1.2.1 - Audit log capability is enabled for each customer's environment.
Risk Level 5 Requirements:
3.4.1 - PAN is masked when displayed.
3.4.2 - For remote access technologies, technical controls are in-place to prevent the copy and paste of PAN.
3.5.1 - PAN is rendered unreadable anywhere it is stored through hashing, truncation, tokens or encryption.
3.5.1.1, 3.5.1.2, 3.5.1.3
3.6.1 - Define and implement procedures for cryptographic keys.
3.6.1.1, 3.6.1.2, 3.6.1.3, 3.6.1.4.
3.7.1 - Key management policies are established for the generation of keys
3.7.2 - key management policies are implemented for secure distribution of keys.
3.7.3 - Key management policies are implemented to include secure storage of cryptographic keys.
3.7.4 - key management policies and procedures are implemented for key changes.
3.7.5 - Key management policies procedures are implemented to include the retirement, replacement or destruction of keys.
3.7.6 - Cleartext cryptographic keys are protected.
3.7.7 - Key management policies and procedures prevent the unauthorized substitution of cryptographic keys.
3.7.8 - Key management policies and procedures are implemented to include key custodians acknowledgements.
3.7.9 - Service providers that share cryptographic keys with customers provide documentation and guidance to customers for protecting those keys.
9.3.1 - Procedures are implemented for authorizing and managing physical access of personnel to the CDE.
9.3.2 - Procedures are implemented for authorizing and managing visitor access to the CDE.
9.3.3 - Visitor badges or identification are surrendered or deactivated.
9.3.4 - Visitor logs are used to maintain a physical record of visitor activity.
9.4.1 - All media with cardholder data is physically secured.
9.4.1.1, 9.4.1.2
9.4.2 - All media with cardholder data is classified.
9.4.3 - Media with cardholder data sent outside of the facility is secured.
9.4.4 - Management approves all media with cardholder data that is moved outside the facility.
9.4.5 - Inventory logs of electronic media with cardholder data is maintained.
9.4.5.1.
Risk Level 6 Requirements:
1.1.1 - Policies and operational procedures for Requirement 1 are established.
1.1.2 - Roles and responsibilities for Requirement 1 are established.
1.2.2 - All changes to network connections and configurations follow Requirement 6.5.1.
1.2.7 - Configurations of network security controls are reviewed at least once every six months.
2.1.1 - Policies and operational procedures for Requirement 2 are established.
2.1.2 - Roles and responsibilities for Requirement 1 are established.
3.1.1 - Policies and operational procedures for Requirement 3 are established.
3.1.2 - Roles and responsibilities for Requirement 3 are established.
4.1.1 - Policies and operational procedures for Requirement 4 are established.
4.1.2 - Roles and responsibilities for Requirement 4 are established.
5.1.1 - Policies and operational procedures for Requirement 5 are established.
5.1.2 - Roles and responsibilities for Requirement 5 are established.
6.1.1 - Policies and operational procedures for Requirement 6 are established.
6.1.2 - Roles and responsibilities for Requirement 6 are established.
6.5.1 - Changes to all system components in the production environment follow the established procedures.
6.5.2 - Upon the completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks.
7.1.1 - Policies and operational procedures for Requirement 7 are established.
7.1.2 - Roles and responsibilities for Requirement 7 are established.
8.1.1 - Policies and operational procedures for Requirement 8 are established.
8.1.2 - Roles and responsibilities for Requirement 8 are established.
9.1.1 - Policies and operational procedures for Requirement 9 are established.
9.1.2 - Roles and responsibilities for Requirement 9 are established.
10.1.1 - Policies and operational procedures for Requirement 10 are established.
10.1.2 - Roles and responsibilities for Requirement 10 are established.
11.1.1 - Policies and operational procedures for Requirement 11 are established.
11.1.2 - Roles and responsibilities for Requirement 11 are established.
12.1.1 - Overall information security policy is established.
12.1.2 - Info sec policy is reviewed annually and updated to reflect changes to the business.
12.1.3 - The security policy clearly defines information security policy roles and responsibilities
12.1.4 - Responsibility for the information security is formally assigned to the CISO.
12.2.1 - Acceptable use policies for end-user technologies are documented.
12.3.3 - Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months.
12.3.4 - Hardware and software technologies in use are reviewed at least once every 12 months.
12.4.1 - Responsibility is established at the executive management level for protection of cardholder data and a PCI DSS Compliance program.
12.4.2 - Quarterly reviews are conducted on critical processes and procedures.
12.4.2.1
12.5.3 - Significant changes to organizational structure result in a documented review of the PCI DSS scope.
12.6.1 - A formal security awareness program is implemented to make personnel aware of the security program.
12.6.2 - Security awareness program is reviewed annually, and is updated to address new threats and vulnerabilities.
12.6.3 - Current employees are trained annually and new hires are trained upon hire.
12.6.3.1, 12.6.3.2
12.7.1 - Potential personnel who have access to the CDE are screened within the constraints of local laws, prior to hire to minimize the risk of attacks from internal sources.