PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

Prioritized_Approach_for_PCI_DSS_3.2.1r1.pdf → Prioritized-Approach-For-PCI-DSS-v4-0.pdf
22% similar
24 → 51 Pages
11584 → 16825 Words
183 Content Changes

Content Changes

183 content changes. 16 administrative changes (dates, page numbers) hidden.

Added p. 1
What Is the Prioritized Approach? The Prioritized Approach maps all PCI DSS requirements into six risk-based security milestones that are intended to help organizations incrementally protect against the highest risk factors and escalating threats while on the road to PCI DSS compliance. No single milestone in the Prioritized Approach provides comprehensive security but following its guidelines will help organizations to secure payment account data more quickly. The Prioritized Approach and its milestones (described on page 2) are intended to provide the following benefits:

• Allows for “quick wins” using a pragmatic approach

• Helps promote consistency among assessors Objectives of the Prioritized Approach The Prioritized Approach provides a roadmap of PCI DSS requirements based on the risk associated with storing, processing, and/or transmitting payment account data. The roadmap helps organizations to prioritize efforts to achieve compliance, establish milestones, and lower the risk of payment account data breaches sooner in the compliance process. …
Added p. 2
Organizations are urged to refer to PCI DSS v4.0 to see the Applicability Notes and other important information included therein.

Requirement 1: Install and Maintain Network Security Controls 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.
Added p. 3
• Shows all account data flows across systems and networks.

• Updated as needed upon changes to the environment.
Added p. 4
PCI DSS Requirements v4.0 1 2 3 4 5 6 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.
Added p. 4
• Secured from unauthorized access.

• Kept consistent with active network configurations.
Added p. 4
• To only traffic that is necessary.

• To only traffic that is necessary.

• All other traffic is specifically denied.

• All other traffic is specifically denied.
Added p. 4
• All wireless traffic from wireless networks into the CDE is denied by default.

• Only wireless traffic with an authorized business purpose is allowed into the CDE.
Added p. 4
• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.

• Stateful responses to communications initiated by system components in a trusted network.

• All other traffic is denied.
Added p. 5
PCI DSS Requirements v4.0 1 2 3 4 5 6 1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.
Added p. 5
• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.

• Security controls are actively running.

• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.

Requirement 2: Apply Secure Configurations to All System Components 2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.
Added p. 6
PCI DSS Requirements v4.0 1 2 3 4 5 6 2.2.1 Configuration standards are developed, implemented, and maintained to:

• Cover all system components.

• Address all known security vulnerabilities.

• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.

• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.

• Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
Added p. 6
• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.

• If the vendor default account(s) will not be used, the account is removed or disabled.
Added p. 6
• Only one primary function exists on a system component, OR

• Primary functions with differing security levels that exist on the same system component are isolated from each other, OR

• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
Added p. 6
• Business justification is documented.

• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
Added p. 7
PCI DSS Requirements v4.0 1 2 3 4 5 6 2.3 Wireless environments are configured and managed securely.
Added p. 7
• Default wireless encryption keys.

• Passwords on wireless access points.

• Any other security-related wireless vendor defaults.
Added p. 7
• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.

• Whenever a key is suspected of or known to be compromised.

Requirement 3: Protect Stored Account Data 3.1 Processes and mechanisms for protecting stored account data are defined and understood.
Added p. 8
PCI DSS Requirements v4.0 1 2 3 4 5 6 3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:

• Coverage for all locations of stored account data.

• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.

• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.

• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.

• A process for verifying, at least once every three months, that stored account data exceeding the defined retention period …
Added p. 9
PCI DSS Requirements v4.0 1 2 3 4 5 6 3.3.3 Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is:

• Limited to that which is needed for a legitimate issuing business need and is secured.

• Encrypted using strong cryptography. This bullet is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 9
• One-way hashes based on strong cryptography of the entire PAN.

• Truncation (hashing cannot be used to replace the truncated segment of PAN).

• If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.

• Strong cryptography with associated key-management processes and procedures.
Added p. 10
PCI DSS Requirements v4.0 1 2 3 4 5 6 3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:

• On removable electronic media OR

• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 10
• Logical access is managed separately and independently of native operating system authentication and access control mechanisms.

• Decryption keys are not associated with user accounts.

• Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely.
Added p. 10
• Access to keys is restricted to the fewest number of custodians necessary.

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

• Key-encrypting keys are stored separately from data-encrypting keys.

• Keys are stored securely in the fewest possible locations and forms.

PCI DSS Requirements v4.0 1 2 3 4 5 6 3.6.1.1 Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:

• Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date.

• Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

• Description of the key usage for each key.

• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) …
Added p. 11
• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key.

• Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device.

• As at least two full-length key components or key shares, in accordance with an industry-accepted method.
Added p. 12
PCI DSS Requirements v4.0 1 2 3 4 5 6 3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:

• A defined cryptoperiod for each key type in use.

• A process for key changes at the end of the defined cryptoperiod.
Added p. 12
• The key has reached the end of its defined cryptoperiod.

• The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.

• The key is suspected of or known to be compromised.

• Retired or replaced keys are not used for encryption operations.
Added p. 12
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
Added p. 13
• Only trusted keys and certificates are accepted.

• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.

• The encryption strength is appropriate for the encryption methodology in use.
Added p. 13
Requirement 5: Protect All Systems and Networks from Malicious Software 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
Added p. 14
• Detects all known types of malware.

• Removes, blocks, or contains all known types of malware.
Added p. 14
• A documented list of all system components not at risk for malware.

• Identification and evaluation of evolving malware threats for those system components.

• Confirmation whether such system components continue to not require anti-malware protection.
Added p. 15
PCI DSS Requirements v4.0 1 2 3 4 5 6 5.3.2 The anti-malware solution(s):

• Performs periodic scans and active or real-time scans. OR

• Performs continuous behavioral analysis of systems or processes.
Added p. 15
• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 15
Requirement 6: Develop and Maintain Secure Systems and Software 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
Added p. 16
• Based on industry standards and/or best practices for secure development.

• In accordance with PCI DSS (for example, secure authentication and logging).

• Incorporating consideration of information security issues during each stage of the software development lifecycle.
Added p. 16
• On software security relevant to their job function and development languages.

• Including secure software design and secure coding techniques.

• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
Added p. 16
• Code reviews ensure code is developed according to secure coding guidelines.

• Code reviews look for both existing and emerging software vulnerabilities.

• Appropriate corrections are implemented prior to release.
Added p. 16
• Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.

• Reviewed and approved by management prior to release.

PCI DSS Requirements v4.0 1 2 3 4 5 6 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

• Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.

• Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.

• Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.

• Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols …
Added p. 17
• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).

• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.

• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.

• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
Added p. 18
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).
Added p. 18
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:

• At least once every 12 months and after significant changes.

• By an entity that specializes in application security.

• Including, at a minimum, all common software attacks in Requirement 6.2.4.

• All vulnerabilities are ranked in accordance with requirement 6.3.1.

• All vulnerabilities are corrected.

• The application is re-evaluated after the corrections OR

• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:

• Installed in front of public-facing web applications to detect and prevent web-based attacks.

• Actively running and up to date as applicable.

• Generating audit logs.

• Configured to either block web-based attacks or generate an alert that is immediately investigated.

• Actively running and up to date as applicable.

• Generating audit logs.

PCI DSS Requirements v4.0 1 2 3 4 5 6 6.4.2 For public-facing web applications, an automated technical solution is …
Added p. 19
• A method is implemented to confirm that each script is authorized.

• A method is implemented to assure the integrity of each script.

• An inventory of all scripts is maintained with written justification as to why each is necessary. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 19
• Reason for, and description of, the change.

• Documentation of security impact.

• Documented change approval by authorized parties.

• Testing to verify that the change does not adversely impact system security.

• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.

• Procedures to address failures and return to a secure state.
Added p. 20
PCI DSS Requirements v4.0 1 2 3 4 5 6 6.5.4 Roles and functions are separated between production and pre- production environments to provide accountability such that only reviewed and approved changes are deployed.
Added p. 20
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.
Added p. 20
• Appropriate access depending on the entity’s business and access needs.

• Access to system components and data resources that is based on users’ job classification and functions.

• The least privileges required (for example, user, administrator) to perform a job function.
Added p. 20
• Job classification and function.

• Least privileges necessary to perform job responsibilities.

PCI DSS Requirements v4.0 1 2 3 4 5 6 7.2.3 Required privileges are approved by authorized personnel. 4 7.2.4 All user accounts and related access privileges, including third- party/vendor accounts, are reviewed as follows:

• At least once every six months.

• To ensure user accounts and access remain appropriate based on job function.

• Any inappropriate access is addressed.

• Any inappropriate access is addressed.

• Management acknowledges that access remains appropriate. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

• Management acknowledges that access remains appropriate. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 21
• Based on the least privileges necessary for the operability of the system or application.

• Access is limited to the systems, applications, or processes that specifically require their use. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 21
• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

• The application/system access remains appropriate for the function being performed.
Added p. 21
• Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.

• Only the responsible administrator(s) can directly access or query repositories of stored CHD.
Added p. 22
• Account use is prevented unless needed for an exceptional circumstance.

• Use is limited to the time needed for the exceptional circumstance.

• Business justification for use is documented.

• Use is explicitly approved by management.

• Individual user identity is confirmed before access to an account is granted.

• Every action taken is attributable to an individual user.

PCI DSS Requirements v4.0 1 2 3 4 5 6 8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
Added p. 23
• Authorized with the appropriate approval.

• Implemented with only the privileges specified on the documented approval.
Added p. 23
• Enabled only during the time period needed and disabled when not in use.

• Use is monitored for unexpected activity.
Added p. 23
• Something you know, such as a password or passphrase.

• Something you have, such as a token device or smart card.

• Something you are, such as a biometric element.
Added p. 23
• Locking out the user ID after not more than 10 attempts.

• Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.

PCI DSS Requirements v4.0 1 2 3 4 5 6 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:

• Set to a unique value for first-time use and upon reset.

• Forced to be changed immediately after the first use.
Added p. 24
• A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
Added p. 24
• Guidance on selecting strong authentication factors.

• Guidance for how users should protect their authentication factors.

• Instructions not to reuse previously used passwords/passphrases.

• Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
Added p. 24
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
Added p. 25
PCI DSS Requirements v4.0 1 2 3 4 5 6 8.3.10 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including:

• Guidance for customers to change their user passwords/passphrases periodically.

• Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
Added p. 25
• The security posture of accounts is dynamically analyzed, and real- time access to resources is automatically determined accordingly. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 25
• Factors are assigned to an individual user and not shared among multiple users.

• Physical and/or logical controls ensure only the intended user can use that factor to gain access.
Added p. 25
• All remote access by all personnel, both users and administrators, originating from outside the entity’s network.

• All remote access by third parties and vendors.

PCI DSS Requirements v4.0 1 2 3 4 5 6 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.
Added p. 26
• The MFA system is not susceptible to replay attacks.

• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.

• At least two different types of authentication factors are used.

• Success of all authentication factors is required before access is granted. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 26
• Interactive use is prevented unless needed for an exceptional circumstance.

• Interactive use is limited to the time needed for the exceptional circumstance.

• Business justification for interactive use is documented.

• Interactive use is explicitly approved by management.

• Individual user identity is confirmed before access to account is granted.

• Every action taken is attributable to an individual user. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 27
PCI DSS Requirements v4.0 1 2 3 4 5 6 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:

• Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.

• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

Requirement 9: Restrict Physical Access to Cardholder Data 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
Added p. 27
• Entry and exit points to/from sensitive areas within the CDE are monitored.

• Monitoring devices or mechanisms are protected from tampering or disabling.

• Collected data is reviewed and correlated with other entries.

• Collected data is stored for at least three months, unless otherwise restricted by law.
Added p. 28
• Identifying personnel.

• Managing changes to an individual’s physical access requirements.

• Revoking or terminating personnel identification.

• Limiting access to the identification process or system to authorized personnel.
Added p. 28
• Access is authorized and based on individual job function.

• Access is revoked immediately upon termination.

• All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination.
Added p. 28
• Visitors are authorized before entering.

• Visitors are escorted at all times.

• Visitors are clearly identified and given a badge or other identification that expires.

• Visitor badges or other identification visibly distinguishes visitors from personnel.
Added p. 29
PCI DSS Requirements v4.0 1 2 3 4 5 6 9.3.4 A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas, including:

• The visitor’s name and the organization represented.

• The date and time of the visit.
Added p. 29
• Media sent outside the facility is logged.

• Media is sent by secured courier or other delivery method that can be accurately tracked.

• Offsite tracking logs include details about media location.
Added p. 29
• Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.

• Materials are stored in secure storage containers prior to destruction.

PCI DSS Requirements v4.0 1 2 3 4 5 6 9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following:

• The electronic media is destroyed.

• The cardholder data is rendered unrecoverable so that it cannot be reconstructed.
Added p. 30
• Maintaining a list of POI devices.

• Periodically inspecting POI devices to look for tampering or unauthorized substitution.

• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.
Added p. 30
• Make and model of the device.

• Location of device.

• Device serial number or other methods of unique identification.
Added p. 31
PCI DSS Requirements v4.0 1 2 3 4 5 6 9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.

• Procedures to ensure devices are not installed, replaced, or returned without verification.

• Being aware of suspicious behavior around devices.

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
Added p. 32
PCI DSS Requirements v4.0 1 2 3 4 5 6 10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to:

• Creation of new accounts.

• Elevation of privileges.

• All changes, additions, or deletions to accounts with administrative access.
Added p. 32
• All initialization of new audit logs, and

• All starting, stopping, or pausing of the existing audit logs.
Added p. 32
• User identification.

• Success and failure indication.

• Origination of event.

• Identity or name of affected data, system component, resource, or service (for example, name and protocol).
Added p. 33
• All security events.

• Logs of all system components that store, process, or transmit CHD and/or SAD.

• Logs of all critical system components.

• Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).
Added p. 34
PCI DSS Requirements v4.0 1 2 3 4 5 6 10.6 Time-synchronization mechanisms support consistent time settings across all systems.
Added p. 34
• One or more designated time servers are in use.

• Only the designated central time server(s) receives time from external sources.

• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC).

• The designated time server(s) accept time updates only from specific industry-accepted external sources.

• Where there is more than one designated time server, the time servers peer with one another to keep accurate time.

• Internal systems receive time information only from designated central time server(s).
Added p. 34
• Access to time data is restricted to only personnel with a business need.

• Any changes to time settings on critical systems are logged, monitored, and reviewed.
Added p. 34
• Anti-malware solutions.

• Physical access controls.

• Logical access controls.

• Audit logging mechanisms.

• Segmentation controls (if used).

• Anti-malware solutions.

• Physical access controls.

• Logical access controls.

• Audit logging mechanisms.

• Segmentation controls (if used).

PCI DSS Requirements v4.0 1 2 3 4 5 6 10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:

• Change-detection mechanisms.

• Audit log review mechanisms.

• Automated security testing tools (if used). This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 35
• Restoring security functions.

• Identifying and documenting the duration (date and time from start to end) of the security failure.

• Identifying and documenting the cause(s) of failure and documenting required remediation.

• Identifying and addressing any security issues that arose during the failure.

• Determining whether further actions are required as a result of the security failure.

• Implementing controls to prevent the cause of failure from reoccurring.
Added p. 35
Requirement 11: Test Security of Systems and Networks Regularly 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
Added p. 36
• The presence of wireless (Wi-Fi) access points is tested for,

• All authorized and unauthorized wireless access points are detected and identified,

• Testing, detection, and identification occurs at least once every three months.

• If automated monitoring is used, personnel are notified via generated alerts.
Added p. 36
• At least once every three months.

• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

• Rescans are performed that confirm all high-risk and critical vulnerabilities (as noted above) have been resolved.

• Scan tool is kept up to date with latest vulnerability information.

• Scans are performed by qualified personnel and organizational independence of the tester exists.

• At least once every three months.

• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

PCI DSS Requirements v4.0 1 2 3 4 5 6 11.3.1.1 All other applicable vulnerabilities (those not ranked as high- risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows:

• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

• Rescans are conducted as needed. This …
Added p. 37
• Systems that are unable to accept credentials for authenticated scanning are documented.

• Sufficient privileges are used for those systems that accept credentials for scanning.

• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 37
• Rescans are conducted as needed.

• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
Added p. 37
• By a PCI SSC Approved Scanning Vendor (ASV).

• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.

• Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.

• Rescans are conducted as needed.

• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

PCI DSS Requirements v4.0 1 2 3 4 5 6 11.3.2.1 External vulnerability scans are performed after any significant change as follows:

• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
Added p. 38
• Industry-accepted penetration testing approaches.

• Coverage for the entire CDE perimeter and critical systems.

• Testing from both inside and outside the network.

• Testing to validate any segmentation and scope-reduction controls.

• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.

• Network-layer penetration tests that encompass all components that support network functions as well as operating systems.

• Review and consideration of threats and vulnerabilities experienced in the last 12 months.

• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.

• Retention of penetration testing results and remediation activities results for at least 12 months.
Added p. 38
• Per the entity’s defined methodology,

• At least once every 12 months

• After any significant infrastructure or application upgrade or change

• By a qualified internal resource or qualified external third-party
Added p. 39
• At least once every 12 months

• After any significant infrastructure or application upgrade or change

PCI DSS Requirements v4.0 1 2 3 4 5 6 11.4.3 External penetration testing is performed:

• Per the entity’s defined methodology

• By a qualified internal resource or qualified external third party
Added p. 39
• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.

• Penetration testing is repeated to verify the corrections.
Added p. 39
• At least once every 12 months and after any changes to segmentation controls/methods

• Covering all segmentation controls/methods in use.

• According to the entity’s defined penetration testing methodology.

• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.

• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).

• Performed by a qualified internal resource or qualified external third party.

• Covering all segmentation controls/methods in use.

• According to the entity’s defined penetration testing methodology.

• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.

• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).

• Performed by a qualified internal resource or qualified external third party.

PCI DSS Requirements v4.0 1 2 3 4 5 6 11.4.6 Additional requirement for service providers only: If segmentation …
Added p. 40
• All traffic is monitored at the perimeter of the CDE.

• All traffic is monitored at critical points in the CDE.

• Personnel are alerted to suspected compromises.
Added p. 41
PCI DSS Requirements v4.0 1 2 3 4 5 6 11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:

• To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.

• To perform critical file comparisons at least once weekly.
Added p. 41
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.

• The mechanism is configured to evaluate the received HTTP header and payment page.

• The mechanism functions are performed as follows:

• At least once every seven days OR

• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

Requirement 12: Support Information Security with Organizational Policies and Programs 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.
Added p. 41
• Disseminated to all relevant personnel, as well as to relevant vendors and business partners.
Added p. 41
• Reviewed at least once every 12 months.

• Updated as needed to reflect changes to business objectives or risks to the environment.

PCI DSS Requirements v4.0 1 2 3 4 5 6 12.1.3 The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities.
Added p. 42
• Explicit approval by authorized parties.

• Acceptable uses of the technology.

• List of products approved by the company for employee use, including hardware and software.
Added p. 42
• Identification of the assets being protected.

• Identification of the threat(s) that the requirement is protecting against.

• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.

• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.

• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.

• Performance of updated risk analyses when needed, as determined by the annual review. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

PCI DSS Requirements v4.0 1 2 3 4 5 6 12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include:

• Documented evidence detailing …
Added p. 43
• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.

• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.

• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 43
• Analysis that the technologies continue to receive security fixes from vendors promptly.

• Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.

• Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology.

• Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 43
• Overall accountability for maintaining PCI DSS compliance.

• Defining a charter for a PCI DSS compliance program and communication to executive management.

PCI DSS Requirements v4.0 1 2 3 4 5 6 12.4.2 Additional requirement for service providers only: Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks:

• Configuration reviews for network security controls.

• Applying configuration standards to new systems.

• Responding to security alerts.

• Change-management processes.
Added p. 44
• Results of the reviews.

• Documented remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2.

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.
Added p. 45
PCI DSS Requirements v4.0 1 2 3 4 5 6 12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).

• Updating all data-flow diagrams per Requirement 1.2.4.

• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.

• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.

• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including …
Added p. 46
PCI DSS Requirements v4.0 1 2 3 4 5 6 12.6 Security awareness education is an ongoing activity.
Added p. 46
• Reviewed at least once every 12 months, and

• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s CDE, or the information provided to personnel about their role in protecting cardholder data. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 46
• Upon hire and at least once every 12 months.

• Multiple methods of communication are used.

• Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures.
Added p. 46
• Phishing and related attacks.

• Social engineering. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Added p. 47
PCI DSS Requirements v4.0 1 2 3 4 5 6 12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
Added p. 47
• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.

• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
Added p. 47
• PCI DSS compliance status information for any service the TPSP performs on behalf of customers (Requirement 12.8.4).

• Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities (Requirement 12.8.5).

PCI DSS Requirements v4.0 1 2 3 4 5 6 12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
Added p. 48
• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.

• Incident response procedures with specific containment and mitigation activities for different types of incidents.

• Business recovery and continuity procedures.

• Data backup processes.

• Analysis of legal requirements for reporting compromises.

• Coverage and responses of all critical system components.

• Reference or inclusion of incident response procedures from the payment brands.
Added p. 48
• Reviewed and the content is updated as needed.

• Tested, including all elements listed in Requirement 12.10.1.
Added p. 49
PCI DSS Requirements v4.0 1 2 3 4 5 6 12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to:

• Intrusion-detection and intrusion-prevention systems.

• Change-detection mechanisms for critical files.

• The change-and tamper-detection mechanism for payment pages. This bullet is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

• Detection of unauthorized wireless access points.
Added p. 49
• Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable.

• Identifying whether sensitive authentication data is stored with PAN.

• Determining where the account data came from and how it ended up where it was not expected.

• Remediating data leaks or process gaps that resulted in the account data being where it was not expected. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.

Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers A1.1 Multi-tenant service providers protect and separate all customer environments and data.

A1.1.1 Logical separation is implemented as follows:

• The provider cannot access its customers’ environments without authorization.

• Customers cannot access the provider’s environment without authorization. This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS …
Removed p. 1
What Is the Prioritized Approach? The Prioritized Approach provides six security milestones that will help merchants and other organizations incrementally protect against the highest risk factors and escalating threats while on the road to PCI DSS compliance. The Prioritized Approach and its milestones (described on page 2) are intended to provide the following benefits:

• Pragmatic approach that allows for “quick wins”

• Helps promote consistency among assessors Objectives of the Prioritized Approach The Prioritized Approach provides a roadmap of compliance activities based on risk associated with storing, processing, and/or transmitting cardholder data. The roadmap helps to prioritize efforts to achieve compliance, establish milestones, lower the risk of cardholder data breaches sooner in the compliance process, and helps acquirers objectively measure compliance activities and risk reduction by merchants, service providers, and others. The Prioritized Approach was devised after factoring data from actual breaches, and feedback from Qualified Security Assessors, forensic investigators, and …
Modified p. 1
• Roadmap that an organization can use to address its risks in priority order
• Provides a roadmap that an organization can use to address its risks in priority order
Removed p. 2
Milestone Goals Remove sensitive authentication data and limit data retention. This milestone targets a key area of risk for entities that have been compromised. Remember

• if sensitive authentication data and other cardholder data are not stored, the effects of a compromise will be greatly reduced. If you don’t need it, don’t store it Protect systems and networks, and be prepared to respond to a system breach. This milestone targets controls for points of access to most compromises, and the processes for responding.

Secure payment card applications. This milestone targets controls for applications, application processes, and application servers. Weaknesses in these areas offer easy prey for compromising systems and obtaining access to cardholder data.

Monitor and control access to your systems. Controls for this milestone allow you to detect the who, what, when, and how concerning who is accessing your network and cardholder data environment.

Protect stored cardholder data. For those organizations that have …
Modified p. 2
Milestones for Prioritizing PCI DSS Compliance Efforts The Prioritized Approach includes six milestones. The matrix below summarizes the high-level goals and intentions of each milestone. The rest of this document maps the milestones to each of all twelve PCI DSS requirements and their sub-requirements.
August 2022 Milestones for Prioritizing PCI DSS Compliance Efforts The Prioritized Approach includes six milestones. The following table summarizes the high- level goals of each milestone.
Modified p. 2
PCI SSC PARTICIPATING PAYMENT BRANDS PARTICIPATING ORGANIZATIONS Merchants, banks, processors, developers and point of sale vendors
PARTICIPATING ORGANIZATIONS Merchants, service providers, banks, processors, developers, and point of sale vendors.
Modified p. 2
PCI DSS COMPLIANCE IS A CONTINUOUS PROCESS REMEDIATE REPORT
PCI DSS COMPLIANCE IS A CONTINUOUS PROCESS
Removed p. 3
Requirement 1: Install and maintain a firewall configuration to protect cardholder data 1.1 Establish and implement firewall and router configuration standards that include the following:
Removed p. 3
Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity’s ability to control or manage.
Removed p. 3
(For example, block traffic originating from the Internet with an internal source address.) 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. 2 1.3.5 Permit only “established” connections into the network. 2
Modified p. 3
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6
PCI DSS Requirements v4.0 1 2 3 4 5 6
Removed p. 4
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. 2 1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.

Note: Methods to obscure IP addressing may include, but are not limited to: y Network Address Translation (NAT) y Placing servers containing cardholder data behind proxy servers/firewalls, y Removal or filtering of route advertisements for private networks that employ registered addressing, y Internal use of RFC1918 address space instead of registered addresses.
Removed p. 4
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point- of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).
Removed p. 4
Sources of industry-accepted system hardening standards may include, but are not limited to: y Center for Internet Security (CIS) y International Organization for Standardization (ISO) y SysAdmin Audit Network Security (SANS) Institute y National Institute of Standards Technology (NIST).
Removed p. 5
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.
Removed p. 5
Requirement 3: Protect stored cardholder data 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: y Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements y Specific retention requirements for cardholder data y Processes for secure deletion of data when no longer needed y A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if: y There is a business justification and y The data is stored securely.

Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:
Removed p. 6
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: y The cardholder’s name y Primary account number (PAN) y Expiration date y Service code To minimize risk, store only these data elements as needed for business.
Removed p. 6
Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point-of-sale (POS) receipts.
Removed p. 6
Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Removed p. 6
Note: This requirement applies in addition to all other PCI DSS encryption and key- management requirements.

Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys•such key-encrypting keys must be at least as strong as the data-encrypting key.
Removed p. 7
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes: y Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date y Description of the key usage for each key. y Inventory of any HSMs and other SCDs used for key management 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary. 5 3.5.3 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: y Encrypted with a key-encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key y Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) …
Removed p. 7
Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
Removed p. 7
Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). Archived cryptographic keys should only be used for decryption/verification purposes.

PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.
Removed p. 8
Requirement 4: Encrypt transmission of cardholder data across open, public networks 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following: y Only trusted keys and certificates are accepted. y The protocol in use only supports secure versions or configurations. y The encryption strength is appropriate for the encryption methodology in use.

Examples of open, public networks include but are not limited to: y The Internet y Wireless technologies, including 802.11 and Bluetooth y Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA) y General Packet Radio Service (GPRS). y Satellite communications.
Removed p. 8
Requirement 5: Use and regularly update anti-virus software or programs 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). 2 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. 2 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.
Removed p. 9
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 5.2 Ensure that all anti-virus mechanisms are maintained as follows: y Are kept current, y Perform periodic scans y Generate audit logs which are retained per PCI DSS Requirement 10.7.

Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.
Removed p. 9
Requirement 6: Develop and maintain secure systems and applications 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as high, medium, or low) to newly discovered security vulnerabilities.

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected.

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organizations environment and risk-assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a high risk to the environment. In addition to the risk ranking, vulnerabilities may be considered critical if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not …
Removed p. 9
Note: This applies to all software developed internally as well as bespoke or custom software developed by a third party.
Modified p. 9 → 18
Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.
• Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
Removed p. 10
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: y Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. y Code reviews ensure code is developed according to secure coding guidelines y Appropriate corrections are implemented prior to release. y Code-review results are reviewed and approved by management prior to release.

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as …
Removed p. 10
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or external).

PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. 3 6.5.2 Buffer overflows 3 6.5.3 Insecure cryptographic storage 3 6.5.4 Insecure communications 3 6.5.5 Improper error handling 3 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). 3

Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal …
Removed p. 11
Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2. y 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.
Removed p. 11
Requirement 7: Restrict access to cardholder data by business need to know 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
Removed p. 12
Requirement 8: Assign a unique ID to each person with computer access 8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:
Modified p. 12 → 22
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 7.1.4 Require documented approval by authorized parties specifying required privileges. 4 7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
PCI DSS Requirements v4.0 1 2 3 4 5 6 7.3.1 An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components.
Removed p. 13
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 8.2.3 Passwords/passphrases must meet the following: y Require a minimum length of at least seven characters. y Contain both numeric and alphabetic characters.

Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.
Removed p. 13
Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.
Removed p. 13
Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows: y Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. y Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
Removed p. 14
Requirement 9: Restrict physical access to cardholder data 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. 2 9.1.1 Use either video cameras or access control mechanisms (or both) to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

Note: “Sensitive areas” refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of-sale terminals are present, such as the cashier areas in a retail store.

For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network …
Removed p. 15
Procedures should include the following:
Removed p. 15
Note: These requirements apply to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.
Modified p. 15 → 29
Document the visitor’s name, the firm represented, and the onsite personnel authorizing physical access on the log.
• The name of the personnel authorizing physical access.
Modified p. 15 → 29
Retain this log for a minimum of three months, unless otherwise restricted by law.
• Retaining the log for at least three months, unless otherwise restricted by law.
Modified p. 15 → 33
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 9.4 Implement procedures to identify and authorize visitors.
PCI DSS Requirements v4.0 1 2 3 4 5 6 10.4 Audit logs are reviewed to identify anomalies or suspicious activity.
Removed p. 16
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.
Removed p. 16
Requirement 10: Track and monitor all access to network resources and cardholder data 10.1 Implement audit trails to link all access to system components to each individual user. 4 10.2 Implement automated audit trails for all system components to reconstruct the following events:
Removed p. 16
• including but not limited to creation of new accounts and elevation of privileges

•and all changes, additions, or deletions to accounts with root or administrative privileges 10.2.6 Initialization, stopping, or pausing of the audit logs 4 10.2.7 Creation and deletion of system-level objects 4 10.3 Record at least the following audit trail entries for all system components for each event:
Removed p. 17
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

Note: One example of time synchronization technology is Network Time Protocol (NTP).
Removed p. 17
Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.
Removed p. 18
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: y Firewalls y Anti-virus y Physical access controls y Logical access controls y Audit logging mechanisms y Segmentation controls (if used) 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include: y Restoring security functions y Identifying and documenting the duration (date and time start to end) of the security failure y Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause y Identifying and addressing any security issues that arose during the failure y Performing a risk assessment to determine whether further …
Removed p. 19
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For subsequent years after the initial PCI …
Removed p. 19
Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.
Removed p. 20
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
Removed p. 20
Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).
Removed p. 20
Requirement 12: Maintain a policy that addresses information security for all personnel 12.1 Establish, publish, maintain, and disseminate a security policy. 6 12.1.1 Review the security policy at least annually and update the policy when the environment changes. 6 12.2 Implement a risk-assessment process that: y Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.), y Identifies critical assets, threats, and vulnerabilities, and y Results in a formal, documented analysis of risk.

Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
Modified p. 20 → 40
Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.
• All intrusion-detection and prevention engines, baselines, and signatures are kept up to date.
Removed p. 21
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 12.3 Develop usage policies for critical technologies and define proper use of these technologies.

Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

Ensure these usage policies require the following:
Removed p. 21
Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.
Removed p. 22
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures. 6 12.6.1 Educate personnel upon hire and at least annually.

Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.
Removed p. 22
Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.
Removed p. 22
Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.
Removed p. 23
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: y Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum y Specific incident response procedures y Business recovery and continuity procedures y Data backup processes y Analysis of legal requirements for reporting compromises y Coverage and responses of all critical system components y Reference or inclusion of incident response procedures from the payment brands.
Removed p. 23
A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.

Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 A1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment. 3 A1.2 Restrict each entity’s access and privileges to its own cardholder data environment only. 3 A1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10. 3 A1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider. 3 Appendix A2: Additional PCI DSS Requirements for …
Modified p. 24 → 50
A2.1 Where POS POI terminals (at the merchant or payment acceptance location) use SSL and/or early TLS, the entity must confirm the devices are not susceptible to any known exploits for those protocols.
A2.1.1 Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols.
Modified p. 24 → 51
A2.2 Requirement for Service Providers Only: All service providers with existing connection points to POS POI terminals referred to in A2.1 that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
PCI DSS Requirements v4.0 1 2 3 4 5 6 A2.1.2 Additional requirement for service providers only: All service providers with existing connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place that includes:
Modified p. 24 → 51
A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering. 2
A2.1.3 Additional requirement for service providers only: All service providers provide a secure service offering.