Document Comparison
SAQ-InstrGuidelines-v3-2-1-r1.pdf
→
SAQ-Instructions-Guidelines-PCI-DSS-v4-0.pdf
16% similar
21 → 29
Pages
5979 → 9181
Words
82
Content Changes
Content Changes
82 content changes. 39 administrative changes (dates, page numbers) hidden.
Added
p. 5
PCI DSS and its supporting documents represent a common set of industry tools to help ensure the safe handling of cardholder account data. The standard itself provides an actionable framework for developing a robust security process•including preventing, detecting, and reacting to security incidents. To reduce the risk of compromise and mitigate the impact if it does occur, it is important for all entities that store, process, or transmit account data to protect that data by implementing applicable PCI DSS requirements.
• Is eligible to conduct self-assessments to validate their PCI DSS compliance, according to payment brand compliance programs,
• Meets the SAQ Eligibility Criteria specified in the chosen SAQ.
Organizations are responsible to confirm they meet all eligibility criteria for a particular SAQ before commencing their self-assessment.
Note: All entities completing SAQs are encouraged to contact the organizations that manage compliance programs and to which the SAQ will be submitted⎯for example, an acquirer (merchant …
• Is eligible to conduct self-assessments to validate their PCI DSS compliance, according to payment brand compliance programs,
• Meets the SAQ Eligibility Criteria specified in the chosen SAQ.
Organizations are responsible to confirm they meet all eligibility criteria for a particular SAQ before commencing their self-assessment.
Note: All entities completing SAQs are encouraged to contact the organizations that manage compliance programs and to which the SAQ will be submitted⎯for example, an acquirer (merchant …
Added
p. 10
Why some PCI DSS requirements in SAQs include multiple response checkboxes For most PCI DSS requirements in the SAQs, there is only a single checkbox for an entity to select; however, a few requirements include a checkbox for each bullet of that requirement (for example, PCI DSS Requirement 6.4.3). This approach was taken only for certain requirements in the SAQs, usually for new and/or complex requirements where each bullet requires a different testing approach, and to emphasize that each bullet should be considered on its own.
Additional guidance and information about SAQ format is provided in the “Completing the Self- Assessment Questionnaire” section of each SAQ.
How will the SAQ updates impact my organization? With PCI DSS v4.0, there is a new SAQ as well as clarified eligibility criteria for existing SAQs. Organizations will need to review the eligibility criteria to understand which SAQ is right for them. For example, the new …
Additional guidance and information about SAQ format is provided in the “Completing the Self- Assessment Questionnaire” section of each SAQ.
How will the SAQ updates impact my organization? With PCI DSS v4.0, there is a new SAQ as well as clarified eligibility criteria for existing SAQs. Organizations will need to review the eligibility criteria to understand which SAQ is right for them. For example, the new …
Added
p. 11
The listing of SPoC Solutions can be found here: PCI SPoC Solutions What is the intent of SAQ SPoC? SAQ SPoC was developed for card-present merchants using general purpose commercial off-the-shelf (COTS) mobile devices. This means that the mobile device (for example, a phone or tablet) does not have to be used only for payment nor does the mobile device have to be dedicated to a payment channel. The COTS mobile device is used along with a PCI-listed Secure Card Reader-PIN (SCRP) device as part of a PCI SSC SPoC Solution to securely process account data. Note that this SAQ is not applicable for SPoC solutions with non-PTS listed magnetic-stripe readers (MSRs). This SAQ may be used with PTS-listed SCRPs that include MSR functionality.
SAQ SPoC significantly reduces the number of applicable PCI DSS requirements for merchants using a PCI SSC listed SPoC solution.
How does SAQ SPoC compare to SAQ P2PE? …
SAQ SPoC significantly reduces the number of applicable PCI DSS requirements for merchants using a PCI SSC listed SPoC solution.
How does SAQ SPoC compare to SAQ P2PE? …
Added
p. 12
PCI SPoC Solutions PTS SCRP PIN Transaction Security (PTS) Standard Secure Card Reader-PIN (SCRP) Approval Class Approved PTS Devices * Listed solutions and devices are confirmed to meet the requirements defined within that PCI Standard and related Program Guide.
Added
p. 13
SAQ A-EP is intended for merchants that have partially outsourced management of their e-commerce transactions but have functionality on their websites that impacts the security of the payment transaction.
As with SAQ A, SAQ A-EP merchants do not electronically store, process, or transmit any account data on their systems or premises, but rely entirely on a TPSP to handle these functions. All processing of account data is outsourced to a PCI DSS validated TPSP/payment processor for both SAQ A and SAQ A-EP.
SAQ A-EP includes additional security controls needed to secure merchant websites that control or manage the payment transaction, even though these websites do not store, process, or transmit account data. This is to reduce the likelihood that breaches of these websites can be used to compromise account data.
What types of e-commerce implementations are eligible for SAQ A vs. SAQ A-EP? To be eligible for SAQ A, e-commerce merchants must meet …
As with SAQ A, SAQ A-EP merchants do not electronically store, process, or transmit any account data on their systems or premises, but rely entirely on a TPSP to handle these functions. All processing of account data is outsourced to a PCI DSS validated TPSP/payment processor for both SAQ A and SAQ A-EP.
SAQ A-EP includes additional security controls needed to secure merchant websites that control or manage the payment transaction, even though these websites do not store, process, or transmit account data. This is to reduce the likelihood that breaches of these websites can be used to compromise account data.
What types of e-commerce implementations are eligible for SAQ A vs. SAQ A-EP? To be eligible for SAQ A, e-commerce merchants must meet …
Added
p. 14
E-commerce Method SAQ Type for Eligible Merchants Number of PCI DSS v4.0 Requirements Fully outsourced. Merchant has no access to own website.
Fully outsourced. Merchant website redirects customers to a compliant TPSP (for example, a URL redirect).
Fully outsourced. Merchant website includes a compliant TPSP’s embedded payment page/form (for example, an iframe).
Fully outsourced, except for the payment page.
Merchant website creates the payment form, and payment data is delivered directly from the consumer browser to the TPSP (often called a “Direct Post”).
SAQ A-EP 139 Fully outsourced, except for the payment page.
Merchant website loads or delivers a script(s) that runs in the consumer browser (for example, JavaScript).
All other e-commerce methods and implementations. SAQ D for Merchants All PCI DSS Requirements Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this table.
* Applicable requirements are identified via explanatory notes in SAQ A.
Importance of new requirements added to SAQ A for PCI DSS …
Fully outsourced. Merchant website redirects customers to a compliant TPSP (for example, a URL redirect).
Fully outsourced. Merchant website includes a compliant TPSP’s embedded payment page/form (for example, an iframe).
Fully outsourced, except for the payment page.
Merchant website creates the payment form, and payment data is delivered directly from the consumer browser to the TPSP (often called a “Direct Post”).
SAQ A-EP 139 Fully outsourced, except for the payment page.
Merchant website loads or delivers a script(s) that runs in the consumer browser (for example, JavaScript).
All other e-commerce methods and implementations. SAQ D for Merchants All PCI DSS Requirements Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this table.
* Applicable requirements are identified via explanatory notes in SAQ A.
Importance of new requirements added to SAQ A for PCI DSS …
Added
p. 15
SAQ A SAQ A-EP All Account Data Functions Completely Outsourced Partially Outsourced E-commerce Payment Channel Applies to: Card-not-present merchants (e-commerce or mail/telephone-order)* E-commerce merchants Functions Outsourced All processing of account data is entirely outsourced to PCI DSS compliant third- party service provider (TPSP)/payment All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant TPSP/payment processor All elements of all payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor Each element of the payment page(s) delivered to the customer’s browser originates from either the merchant’s website or a PCI DSS compliant TPSP Third-Party Compliance Merchant confirmed that all TPSPs are PCI DSS compliant for the services being used by the merchant Merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a …
Added
p. 16
SAQ B-IP is intended for merchants using only standalone payment terminals that connect to their payment processors via an IP-based connection. To be eligible for SAQ B-IP, merchants must be using payment terminals that are PCI-listed approved PIN Transaction Security (PTS) point-of- interaction (POI) devices. Note that merchants using the PTS POI devices classified as Secure Card Readers (SCR) or Secure Card Readers for PIN (SCRP) are NOT eligible for SAQ B-IP.
Other eligibility criteria for SAQ B-IP include that the approved PTS POI devices are not connected to any other types of systems in the merchant environment. This can be achieved via segmentation that isolates the PTS POI devices from other systems within the environment. Connections to other types of systems that would not meet SAQ B-IP eligibility criteria include, but are not limited to, connections to cash register systems, and if the PTO POI devices rely on any other …
Other eligibility criteria for SAQ B-IP include that the approved PTS POI devices are not connected to any other types of systems in the merchant environment. This can be achieved via segmentation that isolates the PTS POI devices from other systems within the environment. Connections to other types of systems that would not meet SAQ B-IP eligibility criteria include, but are not limited to, connections to cash register systems, and if the PTO POI devices rely on any other …
Added
p. 17
SAQ C is intended for merchants with payment application systems (for example, point-of-sale systems) connected to the Internet. SAQ C merchants may be either brick-and-mortar (card-present) or mail/telephone order merchants. To be eligible for this SAQ, the merchant’s payment application systems do not connect to other systems in the merchant environment, and the physical location of the environment is not connected to other premises or locations (single store only).
How does SAQ C-VT compare to SAQ C? The following table provides a high-level overview of some of the key similarities and differences between SAQ C-VT and SAQ C.
SAQ C-VT SAQ C Web-Based Third-Party Virtual Payment Terminal Solution Payment Application System Connected to the Internet Applies to: Brick-and-mortar (card-present) or mail/telephone order (card-not-present) merchants Account data is manually entered into a third-party virtual payment terminal Isolated computing device and securely connected web browser Point-of-sale (POS) or other payment application system Connections Connected …
How does SAQ C-VT compare to SAQ C? The following table provides a high-level overview of some of the key similarities and differences between SAQ C-VT and SAQ C.
SAQ C-VT SAQ C Web-Based Third-Party Virtual Payment Terminal Solution Payment Application System Connected to the Internet Applies to: Brick-and-mortar (card-present) or mail/telephone order (card-not-present) merchants Account data is manually entered into a third-party virtual payment terminal Isolated computing device and securely connected web browser Point-of-sale (POS) or other payment application system Connections Connected …
Added
p. 18
• The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant; and
• The merchant accepts only e-commerce transactions;
• All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP)/payment processor;
• The merchant’s e-commerce website does not receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP/payment processor;
• If the merchant website is hosted by a TPSP, the TPSP is compliant with all applicable PCI DSS requirements (including PCI DSS Appendix A if the TPSP is a multi-tenant hosting provider);
• Each element of the payment page(s) delivered to the customer’s browser originates from either the merchant’s website or a PCI DSS compliant TPSP;
• The merchant does not electronically store, …
• The merchant accepts only e-commerce transactions;
• All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP)/payment processor;
• The merchant’s e-commerce website does not receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP/payment processor;
• If the merchant website is hosted by a TPSP, the TPSP is compliant with all applicable PCI DSS requirements (including PCI DSS Appendix A if the TPSP is a multi-tenant hosting provider);
• Each element of the payment page(s) delivered to the customer’s browser originates from either the merchant’s website or a PCI DSS compliant TPSP;
• The merchant does not electronically store, …
Added
p. 22
A virtual payment terminal is a third-party solution used to submit payment card transactions for authorization to a PCI DSS compliant third-party service provider (TPSP) website. Using this solution, the merchant manually enters account data from an isolated computing device via a securely connected web browser. Unlike physical terminals, virtual payment terminals do not read data directly from a payment card.
• The payment application system is not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
SAQ P2PE merchants may be either brick-and-mortar (card- present) or mail/telephone-order (card-not-present) merchants. For example, a mail/telephone-order merchant could be eligible for SAQ P2PE if they receive account data on paper or over a telephone, and key it directly and only into payment terminal from a validated3 PCI-listed P2PE solution.
• The merchant does not otherwise receive, transmit, or …
• The payment application system is not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
SAQ P2PE merchants may be either brick-and-mortar (card- present) or mail/telephone-order (card-not-present) merchants. For example, a mail/telephone-order merchant could be eligible for SAQ P2PE if they receive account data on paper or over a telephone, and key it directly and only into payment terminal from a validated3 PCI-listed P2PE solution.
• The merchant does not otherwise receive, transmit, or …
Added
p. 25
SAQ SPoC merchants do not have access to clear-text account data on any computer system and only enter account data via an SCRP as part of a PCI-listed SPoC solution, using a merchant COTS mobile device. These COTS mobile devices are general-purpose mobile devices
• this means that the mobile device does not have to be used only for payment or dedicated to a payment channel.
SAQ SPoC merchants process card-present transactions (contact chip transactions, contactless transactions, and SCRP-based magnetic stripe transactions).
An exception applies for merchants using non-PTS listed magnetic stripe readers (MSRs); these merchants are not eligible for this SAQ. This SAQ may be used for PTS-listed SCRPs that include MSR functionality.
This SAQ is not applicable to unattended card-present⎯for example, kiosks, self- checkout⎯mail-order/telephone order (MOTO), or e-commerce channels.
SAQ SPoC merchants will confirm that they meet the following eligibility criteria for this payment channel:
• All payment processing is only via a card-present …
• this means that the mobile device does not have to be used only for payment or dedicated to a payment channel.
SAQ SPoC merchants process card-present transactions (contact chip transactions, contactless transactions, and SCRP-based magnetic stripe transactions).
An exception applies for merchants using non-PTS listed magnetic stripe readers (MSRs); these merchants are not eligible for this SAQ. This SAQ may be used for PTS-listed SCRPs that include MSR functionality.
This SAQ is not applicable to unattended card-present⎯for example, kiosks, self- checkout⎯mail-order/telephone order (MOTO), or e-commerce channels.
SAQ SPoC merchants will confirm that they meet the following eligibility criteria for this payment channel:
• All payment processing is only via a card-present …
Added
p. 26
Note that, for PCI DSS v4.0, SAQ D for Service Providers now requires additional documentation in Section 2a and specifies that service providers “Describe Results” for each PCI DSS requirement.
Added
p. 29
• A “Defining Account Data, Cardholder Data, and Sensitive Authentication Data” table was added from PCI DSS v4.0 to define the various terms used in PCI DSS.
• A “Reporting Responses” table was added to describe the meaning of each reporting response that entities select for each PCI DSS requirement when completing a SAQ.
• The requirements in each SAQ have been updated to reflect changes made to PCI DSS v4.0, and to align more closely with other PCI DSS v4.0 documents. For example:
The wording for each PCI DSS requirement now mirrors the wording in PCI DSS v4.0, rather than being stated in the form of questions.
Some complex requirements were broken into sub-requirements, and other requirements were clarified.
The reporting responses for each PCI DSS requirement were updated to align with the language in the PCI DSS v4.0 Report on Compliance (ROC) Template
• for example, “Yes” is now “In Place.” …
• A “Reporting Responses” table was added to describe the meaning of each reporting response that entities select for each PCI DSS requirement when completing a SAQ.
• The requirements in each SAQ have been updated to reflect changes made to PCI DSS v4.0, and to align more closely with other PCI DSS v4.0 documents. For example:
The wording for each PCI DSS requirement now mirrors the wording in PCI DSS v4.0, rather than being stated in the form of questions.
Some complex requirements were broken into sub-requirements, and other requirements were clarified.
The reporting responses for each PCI DSS requirement were updated to align with the language in the PCI DSS v4.0 Report on Compliance (ROC) Template
• for example, “Yes” is now “In Place.” …
Modified
p. 1
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 3.2.1 Revision 1
Payment Card Industry Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 4.0
Removed
p. 2
August 2022 3.2.1 Revision 1 Updated to reflect the inclusion of UnionPay as a Participating Payment Brand.
This document aligns with PCI DSS v3.2.1 r1.
This document aligns with PCI DSS v3.2.1 r1.
Modified
p. 2
October 28, 2010 2.0 To align content with new PCI DSS v2.0 and clarify SAQ environment types and eligibility criteria.
October 28, 2010 2.0 To align content with new PCI DSS v2.0 and clarify SAQ environment types and eligibility criteria. Addition of SAQ C-VT for Web-based Virtual Terminal merchants.
Removed
p. 5
PCI DSS Self-Assessment: How it All Fits Together The PCI DSS and supporting documents represent a common set of industry tools to help ensure the safe handling of cardholder data. The standard itself provides an actionable framework for developing a robust security process•including preventing, detecting, and reacting to security incidents. To reduce the risk of compromise and mitigate the impact if it does occur, it is important for all entities that store process, or transmit cardholder data to be compliant.
Modified
p. 5
The chart below outlines the tools in place to help organizations with PCI DSS compliance and self- assessment.
The chart below outlines the tools in place to help organizations understand PCI DSS and the self- assessment process.
Removed
p. 6
1. Questions correlating to the PCI DSS requirements, as appropriate for different environments:
See “Selecting the SAQ and Attestation that Best Apply to Your Organization” in this document. This section also includes a column for “Expected Testing” which is based on the testing procedures in PCI DSS.
2. Attestation of Compliance: The Attestation includes your declaration of eligibility for completing the applicable SAQ and the subsequent results of a PCI DSS self-assessment.
See “Selecting the SAQ and Attestation that Best Apply to Your Organization” in this document. This section also includes a column for “Expected Testing” which is based on the testing procedures in PCI DSS.
2. Attestation of Compliance: The Attestation includes your declaration of eligibility for completing the applicable SAQ and the subsequent results of a PCI DSS self-assessment.
Modified
p. 6
The PCI DSS SAQ is a validation tool for merchants and service providers not required by their respective acquirers or payment brand(s) to submit a PCI DSS Report on Compliance (ROC). Please consult your acquirer or payment brand for details regarding PCI DSS validation requirements.
The PCI DSS SAQs are alternate validation tools for merchants and service providers that are not required by an acquirer or payment brand(s) to submit a PCI DSS Report on Compliance (ROC). Being “SAQ-eligible” means that the merchant or service provider:
Modified
p. 6
Each PCI DSS SAQ consists of the following components:
Each PCI DSS SAQ consists of the following sections:
Removed
p. 7
A security breach and subsequent compromise of payment card data has far-reaching consequences for affected organizations, including:
1. Regulatory notification requirements,
2. Loss of reputation,
3. Loss of customers,
4. Potential financial liabilities (for example, regulatory and other fees and fines), and
Forensic analysis of compromises has shown that common security weaknesses, which are addressed by PCI DSS controls, are often exploited because the PCI DSS controls either were not in place or were poorly implemented when the compromise occurred. PCI DSS was designed and includes detailed requirements for exactly this reason•to minimize the chance of compromise and the effects if a compromise does occur.
Examples of common PCI DSS control failures include, but are not limited to:
• Storage of sensitive authentication data (SAD), such as track data, after authorization (Requirement 3.2). Many compromised entities were unaware that their systems were storing this data.
• Inadequate access controls due to improperly installed point-of-sale (POS) systems, allowing malicious …
1. Regulatory notification requirements,
2. Loss of reputation,
3. Loss of customers,
4. Potential financial liabilities (for example, regulatory and other fees and fines), and
Forensic analysis of compromises has shown that common security weaknesses, which are addressed by PCI DSS controls, are often exploited because the PCI DSS controls either were not in place or were poorly implemented when the compromise occurred. PCI DSS was designed and includes detailed requirements for exactly this reason•to minimize the chance of compromise and the effects if a compromise does occur.
Examples of common PCI DSS control failures include, but are not limited to:
• Storage of sensitive authentication data (SAD), such as track data, after authorization (Requirement 3.2). Many compromised entities were unaware that their systems were storing this data.
• Inadequate access controls due to improperly installed point-of-sale (POS) systems, allowing malicious …
Removed
p. 8
Additionally, the PCI DSS security requirements are intended for the protection of payment card data, and your organization may have other sensitive data and assets that need protecting which could be outside of the scope of PCI DSS. Therefore, while PCI DSS compliance, if properly maintained, can certainly contribute to overall security, it should not be viewed as a replacement for a robust, organization-wide security program.
General Tips and Strategies for PCI DSS Compliance Following are some general tips and strategies for beginning your PCI DSS compliance efforts. These tips may help you eliminate storage of cardholder data you do not need, isolate the data you do need to defined and controlled centralized areas, and may allow you to limit the scope of your PCI DSS compliance validation effort. For example, by eliminating cardholder data that you don’t need and/or isolating the data that you do need to defined and controlled …
General Tips and Strategies for PCI DSS Compliance Following are some general tips and strategies for beginning your PCI DSS compliance efforts. These tips may help you eliminate storage of cardholder data you do not need, isolate the data you do need to defined and controlled centralized areas, and may allow you to limit the scope of your PCI DSS compliance validation effort. For example, by eliminating cardholder data that you don’t need and/or isolating the data that you do need to defined and controlled …
Removed
p. 10
• The PCI DSS Glossary of Terms, Abbreviations and Acronyms
• Frequently Asked Questions (FAQs)
• Information Supplements and Guidelines
• Frequently Asked Questions (FAQs)
• Information Supplements and Guidelines
Modified
p. 10 → 7
A Compensating Controls Worksheet must be completed for each requirement that is met with a compensating control. d. Submit all completed Compensating Controls Worksheets, along with your completed SAQ and/or Attestation of Compliance, according to instructions from your acquirer or payment brand.
A Compensating Controls Worksheet (CCW) must be completed for each requirement that is met with a compensating control.
Modified
p. 10 → 7
Professional Assistance and Training If you would like to engage a security professional for help with your self-assessment, we encourage you to consider contacting a Qualified Security Assessor (QSA). QSAs have been trained by PCI SSC to conduct PCI DSS assessments and are listed on the PCI SSC website.
Modified
p. 10 → 7
• SAQ forms and Attestations of Compliance c. PCI SSC also provides a number of training programs to help build awareness for an organization’s personnel. Examples include PCI Awareness, the PCI Professional (PCIP) program, and the Internal Security Assessor (ISA) program.
• PCI SSC also provides several training programs to help build awareness for an organization’s personnel. Examples include PCI Awareness, the PCI Professional (PCIP) program, and the Internal Security Assessor (ISA) program.
Modified
p. 10 → 7
• Payment-related training programs and resources may also be available from the payment brands and/or your merchant acquirer.
Modified
p. 10 → 7
Note: Information Supplements complement the PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements•they do not change, eliminate, or supersede the PCI DSS or any of its requirements.
Note: Information Supplements complement PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements•they do not change, eliminate, or supersede PCI DSS or any of its requirements.
Removed
p. 11
Note for all SAQs except SAQ D: These SAQs include questions that apply to a specific type of merchant environment, as defined in the related SAQ eligibility criteria. If there are PCI DSS requirements applicable to your environment that are not covered in a given SAQ, it may be an indication that this SAQ is not suitable for your environment. Additionally, you must comply with all applicable PCI DSS requirements in order to be PCI DSS compliant.
A-EP E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of cardholder data on merchant’s systems or premises.
C-VT Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based, virtual payment terminal solution that is provided and hosted …
A-EP E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of cardholder data on merchant’s systems or premises.
C-VT Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based, virtual payment terminal solution that is provided and hosted …
Modified
p. 11 → 8
SAQ Description A Card-not-present merchants (e-commerce or mail/telephone-order), that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
SAQ Description A Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated and compliant third parties. No electronic storage, processing, or transmission of account data on their systems or premises.
Modified
p. 11 → 8
Not applicable to face-to-face channels.
Not applicable to face-to-face channels. Not applicable to service providers.
Modified
p. 11 → 8
Applicable only to e-commerce channels.
Applicable only to e-commerce channels. Not applicable to service providers.
Modified
p. 11 → 8
• Imprint machines with no electronic cardholder data storage, and/or
• Imprint machines with no electronic account data storage, and/or
Modified
p. 11 → 8
• Standalone, dial-out terminals with no electronic cardholder data storage.
• Standalone, dial-out terminals with no electronic account data storage.
Modified
p. 11 → 8
C Merchants with payment application systems connected to the Internet, no electronic account data storage.
Removed
p. 13
• Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
Modified
p. 13 → 18
SAQ A merchants may be either e-commerce or mail/telephone- order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.
SAQ A merchants may be either e-commerce or mail/telephone- order merchants (card-not-present) and do not store, process, or transmit any account data in electronic format on their systems or premises.
Modified
p. 13 → 18
• Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
• The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
Modified
p. 13 → 18
• All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers;
• All processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor;
Modified
p. 13 → 18
• Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;
• The merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a TPSP(s) to handle all these functions;
Modified
p. 13 → 18
• Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically.
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.
Modified
p. 13 → 18
• All elements of all payment pages delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s).
• All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.
Removed
p. 14
• Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
• Your company accepts only e-commerce transactions;
• All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;
• Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;
• If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);
• Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s);
• Your company does not electronically store, process, or transmit any cardholder data on your systems or …
• Your company accepts only e-commerce transactions;
• All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;
• Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;
• If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);
• Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s);
• Your company does not electronically store, process, or transmit any cardholder data on your systems or …
Modified
p. 14 → 19
SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.
SAQ A-EP merchants are e-commerce merchants that partially outsource their e-commerce payment channel to PCI DSS validated and compliant third parties and do not electronically store, process, or transmit any account data on their systems or premises.
Modified
p. 14 → 19
Note: For the purposes of SAQ A-EP, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how the payment card data is transmitted, even though the website itself does not receive cardholder data.
Note: For the purposes of SAQ A-EP, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how the account data is transmitted, even though the website itself does not receive account data.
Removed
p. 15
• Your company does not transmit cardholder data over a network (either an internal network or the Internet);
Modified
p. 15 → 19
SAQ B merchants may be either brick-and-mortar (card-present) or mail/telephone order (card-not-present) merchants, and do not store cardholder data on any computer system. SAQ B merchants will confirm that they meet the following eligibility criteria for this payment channel:
This SAQ is not applicable to service providers SAQ A-EP merchants will confirm that they meet the following eligibility criteria for this payment channel:
Modified
p. 15 → 20
• Your company uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information;
• The merchant uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to the merchant processor) to take customers’ payment card information;
Modified
p. 15 → 20
• The standalone, dial-out terminals are not connected to any other systems within your environment;
• The standalone, dial-out terminals are not connected to any other systems within the merchant environment;
Modified
p. 16 → 21
SAQ B-IP merchants may be either brick-and-mortar (card- present) or mail/telephone-order (card-not-present) merchants, and do not store cardholder data on any computer system.
SAQ B-IP merchants may be either brick-and-mortar (card-present) or mail/telephone-order (card-not- present) merchants, and do not store account data on any computer system.
Modified
p. 16 → 21
• Your company uses only standalone, PTS-approved point-of-interaction (POI) devices (excludes SCRs) connected via IP to your payment processor to take your customers’ payment card information;
• The merchant uses only standalone, PCI-listed approved1 PTS POI devices (excludes SCRs and SCRPs) connected via IP to merchant’s payment processor to take customers’ payment card information;
Modified
p. 16 → 21
• The standalone, IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (excludes SCRs);
• The standalone, IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (excludes SCRs and SCRPs);
Modified
p. 16 → 21
• The standalone, IP-connected POI devices are not connected to any other systems within your environment (this can be achieved via network segmentation to isolate POI devices from other systems);
• The standalone, IP-connected PTS POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate PTS POI devices from other systems)2;
Modified
p. 16 → 21
• The only transmission of cardholder data is from the PTS-approved POI devices to the payment processor;
• The only transmission of account data is from the approved PTS POI devices to the payment processor;
Modified
p. 16 → 21
• The POI device does not rely on any other device (e.g., computer, mobile phone, tablet, etc.) to connect to the payment processor;
• The PTS POI device does not rely on any other device⎯e.g., computer, mobile phone, tablet, etc.⎯to connect to the payment processor;
Removed
p. 17
A virtual payment terminal is web-browser-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions, where the merchant manually enters payment card data via a securely connected web browser. Unlike physical terminals, virtual payment terminals do not read data directly from a payment card. Payment card transactions are entered manually.
SAQ C-VT merchants process cardholder data only via a virtual payment terminal and do not store cardholder data on any computer system. These virtual terminals are connected to the Internet to access a third party that hosts the virtual terminal payment-processing function. This third party may be a processor, acquirer, or other third-party service provider who stores, processes, and/or transmits cardholder data to authorize and/or settle merchants’ virtual terminal payment transactions.
• Your company does not store cardholder data in electronic format.
SAQ C-VT merchants process cardholder data only via a virtual payment terminal and do not store cardholder data on any computer system. These virtual terminals are connected to the Internet to access a third party that hosts the virtual terminal payment-processing function. This third party may be a processor, acquirer, or other third-party service provider who stores, processes, and/or transmits cardholder data to authorize and/or settle merchants’ virtual terminal payment transactions.
• Your company does not store cardholder data in electronic format.
Modified
p. 17 → 22
This SAQ option is intended to apply only to merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution. SAQ C-VT merchants may be brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants.
This SAQ option is intended to apply only to merchants that manually enter a single transaction at a time via a keyboard into an Internet-based virtual payment terminal solution. SAQ C-VT merchants may be brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants, and do not store account data on any computer system.
Modified
p. 17 → 22
• Your company’s only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser;
• The only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser;
Modified
p. 17 → 22
• Your company’s virtual payment terminal solution is provided and hosted by a PCI DSS validated third-party service provider;
• The virtual payment terminal solution is provided and hosted by a PCI DSS compliant third-party service provider;
Modified
p. 17 → 22
• Your company accesses the PCI DSS-compliant virtual payment terminal solution via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems);
• The PCI DSS compliant virtual payment terminal solution is only accessed via a computing device that is isolated in a single location, and is not connected to other locations or systems;
Modified
p. 17 → 22
• Your company’s computer does not have software installed that causes cardholder data to be stored (for example, there is no software for batch processing or store-and-forward);
• The computing device does not have software installed that causes account data to be stored (for example, there is no software for batch processing or store-and-forward);
Modified
p. 17 → 22
• Your company’s computer does not have any attached hardware devices that are used to capture or store cardholder data (for example, there are no card readers attached);
• The computing device does not have any attached hardware devices that are used to capture or store account data (for example, there are no card readers attached);
Modified
p. 17 → 22
• Your company does not otherwise receive or transmit cardholder data electronically through any channels (for example, via an internal network or the Internet);
• The merchant does not otherwise receive, transmit, or store account data electronically through any channels (for example, via an internal network or the Internet); and
Modified
p. 17 → 22
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment” on page 18.
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment” on pages 23 and 24.
Removed
p. 18
• The payment application system/Internet device is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
Modified
p. 18 → 23
SAQ C merchants process cardholder data via a point-of-sale (POS) system or other payment application systems connected to the Internet, do not store cardholder data on any computer system, and may be either brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants.
SAQ C merchants process account data via a point-of-sale (POS) system or other payment application systems connected to the Internet, do not store account data on any computer system, and may be either brick-and-mortar (card-present) or mail/telephone- order (card-not-present) merchants.
Modified
p. 18 → 23
SAQ C merchants will confirm that they meet the following eligibility criteria for this payment channel:
SAQ C merchants will confirm that they met the following eligibility criteria for this payment channel:
Modified
p. 18 → 23
• Your company has a payment application system and an Internet connection on the same device and/or same local area network (LAN);
• The merchant has a payment application system and an Internet connection on the same device and/or same local area network (LAN);
Removed
p. 19
PCI SSC-listed P2PE Solution, No Electronic Cardholder Data Storage SAQ P2PE has been developed to address requirements applicable to merchants who process cardholder data only via payment terminals included in a validated and PCI SSC-listed Point-to-Point Encryption (P2PE) solution.
SAQ P2PE merchants do not have access to clear-text account data on any computer system, and only enter account data via hardware payment terminals from a PCI SSC-approved P2PE solution. SAQ P2PE merchants may be either brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants. For example, a mail/telephone-order merchant could be eligible for SAQ P2PE if they receive cardholder data on paper or over a telephone, and key it directly and only into a P2PE validated hardware device.
• There is no legacy storage of electronic cardholder data in the environment;
SAQ P2PE merchants do not have access to clear-text account data on any computer system, and only enter account data via hardware payment terminals from a PCI SSC-approved P2PE solution. SAQ P2PE merchants may be either brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants. For example, a mail/telephone-order merchant could be eligible for SAQ P2PE if they receive cardholder data on paper or over a telephone, and key it directly and only into a P2PE validated hardware device.
• There is no legacy storage of electronic cardholder data in the environment;
Modified
p. 19 → 24
• All payment processing is via a validated PCI P2PE solution approved and listed by the PCI SSC;
• All payment processing is via a validated3 PCI-listed P2PE solution;
Modified
p. 19 → 24
• The only systems in the merchant environment that store, process or transmit account data are the Point of Interaction (POI) devices which are approved for use with the validated and PCI- listed P2PE solution;
• The only systems in the merchant environment that store, process, or transmit account data are the payment terminals from a validated3 PCI-listed P2PE solution;
Modified
p. 19 → 24
• Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically; and
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically; and
Modified
p. 19 → 24
• Your company has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
• The merchant has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
Modified
p. 19 → 25
• Your company does not otherwise receive or transmit cardholder data electronically.
• The merchant does not otherwise receive, transmit or store account data electronically;
Modified
p. 19 → 25
This SAQ is not applicable to e-commerce channels.
This SAQ is not applicable to service providers.
Removed
p. 20
Examples of merchant environments that would use SAQ D may include but are not limited to:
Note for SAQ D for Merchants and SAQ D for Service Providers: While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. For example, a company that does not use wireless technology in any capacity would not be expected to validate compliance with the sections of the PCI DSS that are specific to managing wireless technology. See the specific guidance in the respective SAQ D for information about the exclusion of other, specific requirements.
Note for SAQ D for Merchants and SAQ D for Service Providers: While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. For example, a company that does not use wireless technology in any capacity would not be expected to validate compliance with the sections of the PCI DSS that are specific to managing wireless technology. See the specific guidance in the respective SAQ D for information about the exclusion of other, specific requirements.
Modified
p. 20 → 26
• E-commerce merchants who accept cardholder data on their website;
• E-commerce merchants that accept account data on their website;
Modified
p. 20 → 26
• Merchants with electronic storage of cardholder data;
• Merchants with electronic storage of account data;
Modified
p. 20 → 26
• Merchants that don’t store cardholder data electronically but that do not meet the criteria of another SAQ type;
• Merchants that do not store account data electronically but that do not meet the criteria of another SAQ type;
Modified
p. 20 → 26
SAQ D for Service Providers
• SAQ-Eligible Service Providers SAQ D for Service Providers applies to all service providers defined by a payment brand as beingSAQ-eligible.
• SAQ-Eligible Service Providers SAQ D for Service Providers applies to all service providers defined by a payment brand as being
SAQ D for Service Providers
• SAQ-Eligible Service Providers SAQ D for Service Providers applies to all service providers defined by a payment brand as being eligible to complete a self-assessment questionnaire.
• SAQ-Eligible Service Providers SAQ D for Service Providers applies to all service providers defined by a payment brand as being eligible to complete a self-assessment questionnaire.