Document Comparison
Prioritized-Approach-For-PCI-DSS-v4-0.pdf
→
Prioritized-Approach-For-PCI-DSS-v4_0_1.pdf
98% similar
51 → 51
Pages
16825 → 16942
Words
105
Content Changes
Content Changes
105 content changes. 11 administrative changes (dates, page numbers) hidden.
Added
p. 42
• 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 the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact 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.
• Resulting analysis that determines, and includes justification for, how the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact 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.
Modified
p. 2
January 2025 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
Mapping the Prioritized Approach Milestones to PCI DSS v4.0 Requirements The rest of this document maps the milestones to each PCI DSS v4.0 requirement and sub- requirement. Note that the PCI DSS v4.0 requirements in the following section do not include the Applicability Notes and other important information found in PCI DSS. Applicability Notes include information that can affect how a requirement is interpreted and are considered an integral part of PCI DSS that must be fully considered during an …
Mapping the Prioritized Approach Milestones to PCI DSS v4.0.1 Requirements The rest of this document maps the milestones to each PCI DSS v4.0.1 requirement and sub-requirement. Note that the PCI DSS v4.0.1 requirements in the following section do not include the Applicability Notes and other important information found in PCI DSS. Applicability Notes include information that can affect how a requirement is interpreted and are considered an integral part of PCI DSS that must be fully considered during an assessment.
Modified
p. 2
Organizations are urged to refer to PCI DSS v4.0 to see the Applicability Notes and other important information included therein.
Organizations are urged to refer to PCI DSS v4.0.1 to see the Applicability Notes and other important information included therein.
Modified
p. 3
PCI DSS Requirements v4.0 1 2 3 4 5 6
PCI DSS Requirements v4.0.1 1 2 3 4 5 6
Modified
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.
PCI DSS Requirements v4.0.1 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.
Modified
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.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.
Modified
p. 6
PCI DSS Requirements v4.0 1 2 3 4 5 6 2.2.1 Configuration standards are developed, implemented, and maintained to:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 2.2.1 Configuration standards are developed, implemented, and maintained to:
Modified
p. 6
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations. • Be updated as new vulnerability issues are identified, as defined in
Modified
p. 6
• 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.
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.
• 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.
Modified
p. 6
• Only one primary function exists on a system component, OR
• Only one primary function exists on a system component,
Modified
p. 7
PCI DSS Requirements v4.0 1 2 3 4 5 6 2.3 Wireless environments are configured and managed securely.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 2.3 Wireless environments are configured and managed securely.
Modified
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:
PCI DSS Requirements v4.0.1 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:
Modified
p. 8
• 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.
• 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.
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
Modified
p. 8
• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
• 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 has been securely deleted or rendered unrecoverable.
Modified
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:
PCI DSS Requirements v4.0.1 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.
Removed
p. 10
• On removable electronic media OR
Modified
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:
PCI DSS Requirements v4.0.1 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
Modified
p. 11
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:
PCI DSS Requirements v4.0.1 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.
Modified
p. 11
• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4.
• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, to support meeting Requirement 12.3.4.
Modified
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:
PCI DSS Requirements v4.0.1 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.
Modified
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.
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 understood.
Modified
p. 13
• 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.
• 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.
Modified
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 periodic scans and active or real-time scans.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 5.3.2 The anti-malware solution(s):
• Performs periodic scans and active or real-time scans.
• Performs periodic scans and active or real-time scans.
Modified
p. 16
• Code reviews look for both existing and emerging software vulnerabilities.
• Code reviews look for both existing and emerging software vulnerabilities. • Appropriate corrections are implemented prior to release.
Modified
p. 17
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:
PCI DSS Requirements v4.0.1 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 …
• Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared …
Modified
p. 17
• Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
• Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF). • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
• Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification …
• Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification …
Modified
p. 17
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
• 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.
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
Removed
p. 18
• 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.
Modified
p. 18
PCI DSS Requirements v4.0 1 2 3 4 5 6 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
Modified
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).
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity’s assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1.
Modified
p. 19
PCI DSS Requirements v4.0 1 2 3 4 5 6 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: • Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
Modified
p. 19
• 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.
• An inventory of all scripts is maintained with written business or technical 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.
Modified
p. 19
• Testing to verify that the change does not adversely impact system security.
• 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.
• Procedures to address failures and return to a secure state.
Modified
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.
PCI DSS Requirements v4.0.1 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.
Modified
p. 21
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:
PCI DSS Requirements v4.0.1 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.
Modified
p. 22
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.
PCI DSS Requirements v4.0.1 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.
Modified
p. 22
• Account use is prevented unless needed for an exceptional circumstance.
• ID use is prevented unless needed for an exceptional circumstance.
Modified
p. 22
• Individual user identity is confirmed before access to an account is granted.
• Individual user identity is confirmed before access to an account is granted. • Every action taken is attributable to an individual user.
Modified
p. 23
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.
PCI DSS Requirements v4.0.1 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.
Modified
p. 23
• Enabled only during the time period needed and disabled when not in use.
• Enabled only during the time period needed and disabled when not in use. • Use is monitored for unexpected activity.
Modified
p. 24
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:
PCI DSS Requirements v4.0.1 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:
Removed
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.
• All remote access by third parties and vendors.
Modified
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:
PCI DSS Requirements v4.0.1 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:
Modified
p. 25
• Guidance for customers to change their user passwords/passphrases periodically.
• Guidance for customers to change their user passwords/passphrases periodically. • Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
Modified
p. 25
• Factors are assigned to an individual user and not shared among multiple users.
• 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.
Modified
p. 26
PCI DSS Requirements v4.0 1 2 3 4 5 6 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse.
Modified
p. 26
• Interactive use is prevented unless needed for an exceptional circumstance.
• 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.
• Business justification for interactive use is documented.
Removed
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:
Modified
p. 28
PCI DSS Requirements v4.0 1 2 3 4 5 6 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
Modified
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:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 9.3.4 Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas, including:
Modified
p. 29
• Media is sent by secured courier or other delivery method that can be accurately tracked.
• Media is sent by secured courier or other delivery method that can be accurately tracked. • Offsite tracking logs include details about media location.
Modified
p. 29
• Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed.
• 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.
Modified
p. 30
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:
PCI DSS Requirements v4.0.1 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:
Modified
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:
PCI DSS Requirements v4.0.1 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.
• Procedures to ensure devices are not installed, replaced, or returned without verification.
Modified
p. 31
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.
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 understood.
Modified
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:
PCI DSS Requirements v4.0.1 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:
Modified
p. 33
PCI DSS Requirements v4.0 1 2 3 4 5 6 10.4 Audit logs are reviewed to identify anomalies or suspicious activity.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 10.4 Audit logs are reviewed to identify anomalies or suspicious activity.
Modified
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.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 10.6 Time-synchronization mechanisms support consistent time settings across all systems.
Modified
p. 35
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:
PCI DSS Requirements v4.0.1 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:
Modified
p. 35
• Identifying and documenting the cause(s) of failure and documenting required remediation.
• 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.
• Determining whether further actions are required as a result of the security failure.
Modified
p. 36
• All authorized and unauthorized wireless access points are detected and identified,
• 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.
• If automated monitoring is used, personnel are notified via generated alerts.
Modified
p. 36
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
• Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
Removed
p. 37
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:
Modified
p. 37
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
• Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved. • Rescans are conducted as needed.
Modified
p. 37
• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.
• 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.
Modified
p. 38
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:
PCI DSS Requirements v4.0.1 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.
• Rescans are conducted as needed.
• Rescans are conducted as needed.
Modified
p. 38
• Rescans are conducted as needed.
• 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.
• …
• 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.
• 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.
Modified
p. 39
PCI DSS Requirements v4.0 1 2 3 4 5 6 11.4.3 External penetration testing is performed:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 11.4.3 External penetration testing is performed:
Modified
p. 39
• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.
• 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.
Modified
p. 39
• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).
• 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.
• Organizational independence of the tester exists (not required to be a QSA or ASV).
• Organizational independence of the tester exists (not required to be a QSA or ASV).
Modified
p. 40
PCI DSS Requirements v4.0 1 2 3 4 5 6 11.4.6 Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 11.4.6 Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: • At least once every six months and after any changes to segmentation controls/methods.
Modified
p. 40
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.
• 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).
Modified
p. 40
• Performed by a qualified internal resource or qualified external third party.
• Performed by a qualified internal resource or qualified external third party. • Organizational independence of the tester exists (not required to be a QSA or ASV).
Removed
p. 41
• The mechanism is configured to evaluate the received HTTP header and payment page.
• At least once every seven days OR
• At least once every seven days OR
Modified
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:
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:
Modified
p. 41
• 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.
• At least weekly 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.
• 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.
Removed
p. 42
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
Modified
p. 42
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.
PCI DSS Requirements v4.0.1 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.
Modified
p. 42
This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Modified
p. 43
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:
PCI DSS Requirements v4.0.1 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 each element specified in Appendix D:
Modified
p. 43
Customized Approach (including, at a minimum, a controls matrix and risk analysis).
Modified
p. 43
• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.
• 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.
• Documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities.
• Documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities.
Modified
p. 43
This requirement is a best practice until 31 March 2025; refer to Applicability Notes in PCI DSS for details.
Modified
p. 43
• 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.
• 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 …
• 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 …
Modified
p. 44
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:
PCI DSS Requirements v4.0.1 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:
Modified
p. 44
• Documented remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2.
• 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.
Modified
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:
PCI DSS Requirements v4.0.1 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).
Modified
p. 45
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.
• 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 justification for environments being out of scope.
Modified
p. 45
• Identifying all connections from third-party entities with access to the CDE.
• Identifying all connections from third-party entities with access to the CDE. • Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope.
Modified
p. 46
PCI DSS Requirements v4.0 1 2 3 4 5 6 12.6 Security awareness education is an ongoing activity.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 12.6 Security awareness education is an ongoing activity.
Modified
p. 46
• 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.
• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s cardholder data and/or sensitive authentication data, or the information provided to personnel about their role in protecting cardholder data.
Removed
p. 47
• 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.
Modified
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.
PCI DSS Requirements v4.0.1 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.
Modified
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 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 TPSPs 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 TPSPs could impact the security of the entity’s cardholder data and/or sensitive authentication data.
Modified
p. 47
• PCI DSS compliance status information for any service the TPSP performs on behalf of customers (Requirement 12.8.4).
• PCI DSS compliance status information (Requirement 12.8.4).
Modified
p. 47
• 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).
• 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), for any service the TPSP provides that meets a PCI DSS requirement(s) on behalf of customers or that can impact security of customers’ cardholder data and/or sensitive authentication data.
Modified
p. 48
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.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
Modified
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:
PCI DSS Requirements v4.0.1 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:
Modified
p. 49
• 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.
• 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.
Modified
p. 49
• The provider cannot access its customers’ environments without authorization.
• 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 for details.
Modified
p. 50
PCI DSS Requirements v4.0 1 2 3 4 5 6 A1.1.3 Controls are implemented such that each customer can only access resources allocated to them.
PCI DSS Requirements v4.0.1 1 2 3 4 5 6 A1.1.3 Controls are implemented such that each customer can only access resources allocated to them.
Modified
p. 50
A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including:
A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including: • Customers can securely report security incidents and vulnerabilities to the provider.
Modified
p. 51
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:
PCI DSS Requirements v4.0.1 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: • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, and type of environment.
Modified
p. 51
• Description of processes to monitor for new vulnerabilities associated with SSL/early TLS.
• Description of processes to monitor for new vulnerabilities associated with SSL/early TLS. • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments.