Document Comparison
PCI-DSS-v4-0-SAQ-C-r1.pdf
→
PCI-DSS-v4-0-1-SAQ-C.pdf
94% similar
77 → 77
Pages
19940 → 19872
Words
51
Content Changes
Content Changes
51 content changes. 36 administrative changes (dates, page numbers) hidden.
Added
p. 2
PCI DSS Version SAQ Revision Description
Added
p. 2
Added ASV Resource Guide to section “Additional PCI SSC Resources.” Deleted Requirement 10.3.3 added in v4.0 of this SAQ, because the requirement is not relevant for SAQ C merchants.
Added
p. 7
Note: A legal exception is a legal restriction due to a local or regional law, regulation, or regulatory requirement, where meeting a PCI DSS requirement would violate that law, regulation, or regulatory requirement.
Added
p. 43
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Added
p. 48
Applicability Notes This requirement does not apply to locations that are publicly accessible by consumers (cardholders).
Added
p. 50
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 9.4.3 Media with cardholder data sent outside the facility is secured as follows:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place SAQ Completion Guidance:
These requirements do not apply to:
• Components used only for manual PAN key entry.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place SAQ Completion Guidance:
These requirements do not apply to:
• Components used only for manual PAN key entry.
Added
p. 55
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.4.1.1 Automated mechanisms are used to perform audit log reviews.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.5 Audit log history is retained and available for analysis.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.6.3 Time synchronization settings and data are protected as follows:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.5 Audit log history is retained and available for analysis.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.6.3 Time synchronization settings and data are protected as follows:
Added
p. 67
The TPSP’s written acknowledgment is a confirmation that states the TPSP is responsible for the security of the account data it may store, process, or transmit on behalf of the customer or to the extent the TPSP may impact the security of a customer’s cardholder data and/or sensitive authentication data.
Added
p. 77
Note: The PCI Security Standards Council is a global standards body that provides resources for payment security professionals developed collaboratively with our stakeholder community. Our materials are accepted in numerous compliance programs worldwide. Please check with your individual compliance-accepting organization to ensure that this form is acceptable in its program. For more information about PCI SSC and our stakeholder community please visit: https://www.pcisecuritystandards.org/about_us/.
Modified
p. 4
This SAQ includes only those requirements that apply to a specific type of merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to the cardholder data environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for the merchant’s environment.
This SAQ includes only those requirements that apply to a specific type of merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to the cardholder data environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for the merchant’s environment Defining Account Data, Cardholder Data, and Sensitive Authentication Data
Modified
p. 5 → 4
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). Cardholder data and sensitive authentication data are considered account data and are defined as follows:
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of cardholder data and/or sensitive authentication data. Cardholder data and sensitive authentication data are considered account data and are defined as follows:
Removed
p. 7
Note: A legal restriction is one where meeting the PCI DSS requirement would violate a local or regional law or regulation.
Modified
p. 8
− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary of Payment and Information Security Terms − PCI Firewall Basics These and other resources can be found on the PCI SSC website (www.pcisecuritystandards.org).
− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary of Payment and Information Security Terms − PCI Firewall Basics − ASV Resource Guide These and other resources can be found on the PCI SSC website (www.pcisecuritystandards.org).
Modified
p. 11
Name of PCI SSC- validated Product or Version of Product or
Name of PCI SSC validated Product or Version of Product or
Modified
p. 11
PCI SSC listing Expiry date of listing (YYYY-MM-DD) YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD ♦ For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or components appearing on the PCI SSC website (www.pcisecuritystandards.org)for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Payment Applications (PA-DSS), Point to Point Encryption (P2PE) solutions, Software-Based PIN Entry on COTS (SPoC) solutions, and Contactless Payments on COTS (CPoC) solutions.
PCI SSC listing Expiry date of listing (YYYY-MM-DD) YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD ♦ For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or components, appearing on the PCI SSC website (www.pcisecuritystandards.org)for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Point to Point Encryption (P2PE) solutions, Software-Based PIN Entry on COTS (SPoC) solutions, Contactless Payments on COTS (CPoC) solutions, and Mobile Payments on …
Modified
p. 22
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 3.4 Access to displays of full PAN and ability to copy PAN is restricted.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 3.4 Access to displays of full PAN and ability to copy PAN are restricted.
Removed
p. 24
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 4.2.1 (cont.) There could be occurrences where an entity receives cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of receiving sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or implement measures to prevent the channel from being used for cardholder data.
Modified
p. 24
A self-signed certificate may also be acceptable if the certificate is issued by an internal CA within the organization, the certificate’s author is confirmed, and the certificate is verified
•for example, via hash or signature
•and has not expired.Note that self-signed certificates where the Distinguished Name (DN) field in the “issued by” and “issued to” field is the same are not acceptable.
•for example, via hash or signature
•and has not expired.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 4.2.1 (cont.) A self-signed certificate may also be acceptable if the certificate is issued by an internal CA within the organization, the certificate’s author is confirmed, and the certificate is verified
•for example, via hash or signature
•and has not expired.
•for example, via hash or signature
•and has not expired.
Removed
p. 28
Applicability Notes This requirement applies to the automated mechanism. It is not intended that the systems and services providing such automated mechanisms (such as e-mail servers) are brought into scope for PCI DSS.
Modified
p. 28
The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS.
Applicability Notes The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS.
Modified
p. 32
Applicability Notes This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
Applicability Notes This requirement is not achieved by, and is in addition to, performing vulnerability scans according to Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
Modified
p. 32
• 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.
• 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. 37
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.2.2 Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
Modified
p. 37
• Account use is prevented unless needed for an exceptional circumstance.
• ID use is prevented unless needed for an exceptional circumstance.
Modified
p. 38
Applicability Notes This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).
Applicability Notes This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Modified
p. 39
Applicability Notes This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).
Applicability Notes This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Modified
p. 40
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Removed
p. 42
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE.
Modified
p. 42
Applicability Notes This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements.
Applicability Notes This requirement does not apply to in-scope system components where MFA is used.
Modified
p. 42
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Modified
p. 43
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.2 MFA is implemented for all access into the CDE.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.2 MFA is implemented for all non-console access into the CDE.
Modified
p. 43
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access. If an individual first connects to the entity’s network via …
• User accounts that are only authenticated with phishing-resistant authentication factors. MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access. If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual …
Modified
p. 43
MFA for remote access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE.
MFA for access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE.
Removed
p. 44
• 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. 44
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.3 MFA is implemented for all remote access originating from outside the entity’s network that could access or impact the CDE.
Modified
p. 44
• Observe personnel (for example, users and administrators) connecting remotely to the network.
• Observe personnel (for example, users and administrators) and third parties connecting remotely to the network.
Modified
p. 44
Applicability Notes The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE.
Applicability Notes The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE. This includes all remote access by personnel (users and administrators), and third parties (including, but not limited to, vendors, suppliers, service providers, and customers).
Modified
p. 49 → 50
Applicability Notes (continued) 9.4.4 (cont.) Individuals approving media movements should have the appropriate level of management authority to grant this approval. However, it is not specifically required that such individuals have “manager” as part of their title.
Applicability Notes 9.4.4 Individuals approving media movements should have the appropriate level of management authority to grant this approval. However, it is not specifically required that such individuals have “manager” as part of their title.
Modified
p. 50
• Examine the periodic media destruction policy.
• Examine the media destruction policy.
Modified
p. 51
Applicability Notes These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped). This requirement is not intended to apply to manual PAN key-entry components such as computer keyboards.
Applicability Notes These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped).
Modified
p. 51
• Commercial off-the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.
Removed
p. 54
• Examine backup configurations or log files.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.4.1 The following audit logs are reviewed at least once daily:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.4.1 The following audit logs are reviewed at least once daily:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Modified
p. 58
Applicability Notes The requirement applies even when a policy exists that prohibits the use of wireless technology since attackers do not read and follow company policy.
Applicability Notes The requirement applies even when a policy exists that prohibits the use of wireless technology.
Modified
p. 59
• 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.
Modified
p. 59
• 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.
Modified
p. 60
Applicability Notes For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
Applicability Notes For the initial PCI DSS assessment against this requirement, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
Modified
p. 65
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the 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.
Modified
p. 67
• 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.
• 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 the TPSP could impact the security of the entity’s cardholder data and/or sensitive authentication data.
Modified
p. 67
Applicability Notes The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Applicability Notes The exact wording of an agreement will depend the details of the service being provided, and the responsibilities assigned to each party. The agreement does not have to include the exact wording provided in this requirement.
Modified
p. 67
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements is not the same as a written acknowledgment specified in this requirement. For example, a PCI DSS Attestation of Compliance (AOC), a declaration on a company’s website, a policy statement, a responsibility matrix, or other evidence not included in a written agreement is not a written acknowledgment.
Modified
p. 76
PCI DSS Self-Assessment Questionnaire C, Version 4.0 was completed according to the instructions therein.
PCI DSS Self-Assessment Questionnaire C, Version 4.0.1, was completed according to the instructions therein.