Document Comparison
pci_dss_SAQ_Instr_Guide_v2.1.pdf
→
SAQ_InstrGuidelines_v3-1.pdf
54% similar
19 → 21
Pages
5216 → 5868
Words
48
Content Changes
Content Changes
48 content changes. 31 administrative changes (dates, page numbers) hidden.
Added
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.
The chart below outlines the tools in place to help organizations with PCI DSS compliance and self- assessment.
* Note: Information Supplements provide supplemental information and guidance only, and do not replace or supersede any requirements in PCI DSS.
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 …
The chart below outlines the tools in place to help organizations with PCI DSS compliance and self- assessment.
* Note: Information Supplements provide supplemental information and guidance only, and do not replace or supersede any requirements in PCI DSS.
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 …
Added
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 …
Added
p. 9
5. Compensating Controls Compensating controls may be considered for most PCI DSS requirements when an organization cannot meet the technical specification of a requirement, but has sufficiently mitigated the associated risk through alternative controls. If your organization does not have the exact control specified in PCI DSS but has other controls in place that satisfy the PCI DSS definition of compensating controls (see “Compensating Controls” in PCI DSS Appendix B, and also in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms), your organization should do the following: a. Follow the procedures for compensating controls as outlined in PCI DSS Appendix B. b. For all requirements that were met with the assistance of a compensating control, respond to the SAQ question by checking the “YES with CCW” column.
A Compensating Controls Worksheet must be completed for each requirement that is met with a compensating control. d. Submit all completed …
A Compensating Controls Worksheet must be completed for each requirement that is met with a compensating control. d. Submit all completed …
Added
p. 11
B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor with no electronic cardholder data storage.
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 by a PCI DSS validated third-party service provider. No electronic cardholder data storage.
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 by a PCI DSS validated third-party service provider. No electronic cardholder data storage.
Added
p. 12
Not applicable to e-commerce merchants.
D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types.
D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types.
Added
p. 13
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 will confirm that they meet the following eligibility criteria for this payment channel:
Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions; All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers; 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; 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 retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
Additionally, for e-commerce channels:
All elements of all payment pages …
SAQ A merchants will confirm that they meet the following eligibility criteria for this payment channel:
Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions; All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers; 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; 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 retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
Additionally, for e-commerce channels:
All elements of all payment pages …
Added
p. 14
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 will confirm that they meet the following eligibility criteria for this payment channel:
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 …
SAQ A-EP merchants will confirm that they meet the following eligibility criteria for this payment channel:
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 …
Added
p. 15
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:
Added
p. 16
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 will confirm that they meet the following eligibility criteria for this payment channel:
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 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 not connected to any other systems within your environment (this can be achieved via network segmentation to isolate POI devices from other systems); The only transmission of cardholder data is from the PTS-approved POI devices to the payment processor; The POI device does not rely on any other device (e.g., computer, mobile phone, tablet, etc.) to connect …
SAQ B-IP merchants will confirm that they meet the following eligibility criteria for this payment channel:
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 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 not connected to any other systems within your environment (this can be achieved via network segmentation to isolate POI devices from other systems); The only transmission of cardholder data is from the PTS-approved POI devices to the payment processor; The POI device does not rely on any other device (e.g., computer, mobile phone, tablet, etc.) to connect …
Added
p. 17
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment” on page 18.
SAQ C merchants will confirm that they meet the following eligibility criteria for this payment channel:
SAQ C merchants will confirm that they meet the following eligibility criteria for this payment channel:
Added
p. 19
SAQ P2PE merchants will confirm that they meet the following eligibility criteria for this payment channel:
All payment processing is via a validated PCI P2PE solution approved and listed by the PCI SSC; 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; Your company does not otherwise receive or transmit cardholder data electronically.
There is no legacy storage of electronic cardholder data in the environment; If your company stores cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically; and Your company has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
Examples of merchant environments that would use SAQ D may include but are not limited …
All payment processing is via a validated PCI P2PE solution approved and listed by the PCI SSC; 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; Your company does not otherwise receive or transmit cardholder data electronically.
There is no legacy storage of electronic cardholder data in the environment; If your company stores cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically; and Your company has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
Examples of merchant environments that would use SAQ D may include but are not limited …
Modified
p. 1
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 2.1
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 3.1
Removed
p. 4
PCI DSS Self-Assessment: How it All Fits Together PCI DSS: Related Documents SAQ Overview Why is Compliance with PCI DSS Important?
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 and measurements to help ensure the safe handling of sensitive information. The standard provides an actionable framework for developing a robust account data security process•including preventing, detecting and reacting to security incidents. To reduce the risk of compromise and mitigate its impacts if it does occur, it is important that all entities storing, processing, or transmitting cardholder data be compliant. The chart below outlines the tools in place to help organizations with PCI DSS compliance and self-assessment.
Removed
p. 6
PCI Data Security Standard: Related Documents The following documents were created to assist merchants and service providers in understanding the PCI DSS and the PCI DSS SAQ.
PCI Data Security Standard: Requirements and Security Assessment Procedures All merchants and service providers Navigating PCI DSS: Understanding the Intent of the Requirements All merchants and service providers
PCI Data Security Standard: Self-Assessment Guidelines and Instructions All merchants and service providers
PCI Data Security Standard: Self-Assessment Questionnaire A and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire B and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire C-VT and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire C and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire D and Attestation Eligible merchants and service providers1
PCI Data Security Standard: Self-Assessment Questionnaire P2PE-HW and Attestation Eligible merchants1
PCI Data Security Standard and Payment Application Data Security Standard: Glossary of Terms, Abbreviations, and Acronyms All merchants and service providers 1 …
PCI Data Security Standard: Requirements and Security Assessment Procedures All merchants and service providers Navigating PCI DSS: Understanding the Intent of the Requirements All merchants and service providers
PCI Data Security Standard: Self-Assessment Guidelines and Instructions All merchants and service providers
PCI Data Security Standard: Self-Assessment Questionnaire A and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire B and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire C-VT and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire C and Attestation Eligible merchants1
PCI Data Security Standard: Self-Assessment Questionnaire D and Attestation Eligible merchants and service providers1
PCI Data Security Standard: Self-Assessment Questionnaire P2PE-HW and Attestation Eligible merchants1
PCI Data Security Standard and Payment Application Data Security Standard: Glossary of Terms, Abbreviations, and Acronyms All merchants and service providers 1 …
Modified
p. 7 → 6
Each PCI DSS SAQ consists of the following components:
Modified
p. 7 → 6
1. Questions correlating to the PCI DSS requirements, appropriate for service providers and merchants: See “Selecting the SAQ and Attestation that Best Apply to Your Organization” in this document.
1. Questions correlating to the PCI DSS requirements, as appropriate for different environments:
Modified
p. 7 → 6
2. Attestation of Compliance: The Attestation is your self-certification that you are eligible to perform and have actually performed a PCI DSS self-assessment.
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.
Removed
p. 8
Inadequate access controls due to improperly installed merchant POS systems, allowing malicious users in via paths intended for POS vendors (Requirements 7.1, 7.2, 8.2 and 8.3) Default system settings and passwords not changed when system was set up (Requirement 2.1) Unnecessary and insecure services not removed or secured when system was set up (Requirements 2.2.2 and 2.2.4) Poorly coded web applications resulting in SQL injection and other vulnerabilities, which allow access to the database storing cardholder data directly from the web site (Requirement 6.5) Missing and outdated security patches (Requirement 6.1) Lack of logging (Requirement 10) Lack of monitoring (via log reviews, intrusion detection/prevention, quarterly vulnerability scans, and file integrity monitoring systems) (Requirements 10.6, 11.2, 11.4 and 11.5) Poorly implemented network segmentation resulting in the cardholder data environment being unknowingly exposed to weaknesses in other parts of the network that have not …
Modified
p. 8 → 7
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.
Modified
p. 8 → 7
Examples of common PCI DSS control failures include, but are not limited to:
Modified
p. 8 → 7
Storage of magnetic stripe data (Requirement 3.2). It is important to note that many compromised entities are unaware that their systems are storing this data.
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.
Removed
p. 9
2. If you are a merchant, ask your POS vendor about the security of your system, with the following suggested questions: a. Is my POS software validated to the Payment Application Data Security Standard (PA-DSS)?
(Refer to PCI SSC’s list of Validated Payment Applications.) b. Does my POS software store magnetic stripe data (track data) or PIN blocks? If so, this storage is prohibited, so how quickly can you help me remove it? c. Does my POS software store primary account numbers (PANs)? If so, this storage must be protected, so how is the POS protecting this data? d. Will you document the list of files written by the application with a summary of the content of each file, to verify that the above-mentioned, prohibited data is not stored? e. Does your POS system require me to install a firewall to protect my systems from unauthorized access? f. Are complex and …
(Refer to PCI SSC’s list of Validated Payment Applications.) b. Does my POS software store magnetic stripe data (track data) or PIN blocks? If so, this storage is prohibited, so how quickly can you help me remove it? c. Does my POS software store primary account numbers (PANs)? If so, this storage must be protected, so how is the POS protecting this data? d. Will you document the list of files written by the application with a summary of the content of each file, to verify that the above-mentioned, prohibited data is not stored? e. Does your POS system require me to install a firewall to protect my systems from unauthorized access? f. Are complex and …
Modified
p. 9 → 8
1. Sensitive Authentication Data (includes the full track contents of the magnetic stripe or chip, card verification codes and values, PINs and PIN blocks): a. Make sure you never store this data. b. If you don’t know for sure, ask your POS vendor whether the software product and version you use stores this data. Alternatively, consider hiring a Qualified Security Assessor that can assist you in determining whether sensitive authentication data is being stored, logged, or captured anywhere in your …
1. Sensitive Authentication Data (includes the full track contents of the magnetic stripe or equivalent data on a chip, card verification codes and values, PINs, and PIN blocks):
Removed
p. 10
5. Compensating Controls Compensating controls may be considered for most PCI DSS requirements when an organization cannot meet the technical specification of a requirement, but has sufficiently mitigated the associated risk through alternative controls. If your company does not have the exact control specified in PCI DSS but has other controls in place that satisfy the PCI DSS definition of compensating controls (see “Compensating Controls” in your applicable SAQ Appendix and the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms document at www.pcisecuritystandards.org), your company should do the following: a. Respond to the SAQ question as “YES” and in the “Special” column, note the use of each compensating control used to satisfy a requirement. b. Review “Compensating Controls” in Appendix B of the applicable SAQ, and document the use of compensating controls by completing the Compensating Controls Worksheet in Appendix C of the SAQ. c. Complete a Compensating …
Modified
p. 10 → 9
3. Cardholder data•if you don’t need it, don’t store it! a. Payment brand rules allow for the storage of Personal Account Number (PAN), expiration date, cardholder name, and service code. b. Take inventory of all the reasons and places you store this data. If the data doesn’t serve a valuable business purpose, consider eliminating it. c. Think about whether the storage of that data and the business process it supports are worth the following:
i. Can you confirm that you do not use common or default passwords for access to my system and other merchant systems you support? j. Have all the systems and databases that are part of the POS system been patched with all applicable security updates? k. Is the logging capability turned on for the systems and databases that are part of the POS system? l. If prior versions of my POS software stored sensitive authentication data, has this feature been …
Modified
p. 10 → 9
ii. The additional PCI DSS efforts that must be applied to protect that data.
ii. The additional PCI DSS controls that must be applied to protect that data.
Removed
p. 11
6. Professional Assistance and Training a. If you would like to have a security professional’s guidance to achieve compliance and complete the SAQ, you are encouraged to do so. Please recognize that, while you are free to use any security professional of your choosing, only those included on PCI SSC’s list of Qualified Security Assessors (QSAs) are recognized as QSAs and are trained by PCI SSC. This list is available at https://www.pcisecuritystandards.org. b. The PCI Security Standards Council (SSC) provides a variety of educational resources to further security awareness within the payment card industry. These resources include PCI DSS training for Internal Security Assessors (ISAs) and Standards Training. The PCI SSC website is also a primary source for additional resources, including:
The Navigating PCI DSS Guide The PCI DSS Glossary of Terms, Abbreviations and Acronyms Frequently Asked Questions (FAQs) Webinars Information Supplements and Guidelines Attestations …
The Navigating PCI DSS Guide The PCI DSS Glossary of Terms, Abbreviations and Acronyms Frequently Asked Questions (FAQs) Webinars Information Supplements and Guidelines Attestations …
Modified
p. 11 → 10
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 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.
Removed
p. 12
SAQ Description A Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.
C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage. This would never apply to e-commerce merchants.
P2PE-HW Merchants using only hardware payment terminals included in a PCI SSC-listed, validated, P2PE solution, no electronic cardholder data storage. This would never apply to e-commerce merchants.
SAQ A
• Card-not-present Merchants, All Cardholder Data Functions Outsourced SAQ A has been developed to address requirements applicable to merchants who retain only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises.
SAQ A merchants do not store cardholder data in electronic format, do not process or transmit any cardholder data on their systems or premises, and validate compliance by completing SAQ A and the associated Attestation of …
C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage. This would never apply to e-commerce merchants.
P2PE-HW Merchants using only hardware payment terminals included in a PCI SSC-listed, validated, P2PE solution, no electronic cardholder data storage. This would never apply to e-commerce merchants.
SAQ A
• Card-not-present Merchants, All Cardholder Data Functions Outsourced SAQ A has been developed to address requirements applicable to merchants who retain only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises.
SAQ A merchants do not store cardholder data in electronic format, do not process or transmit any cardholder data on their systems or premises, and validate compliance by completing SAQ A and the associated Attestation of …
Modified
p. 12 → 11
Imprint machines with no electronic cardholder data storage, and/or Standalone, dial-out terminals with no electronic cardholder data storage.
Modified
p. 12
D All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ.
SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete an SAQ.
Modified
p. 12 → 13
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment?” on page17.
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment?” on page 18.
Removed
p. 13
SAQ B merchants only process cardholder data via imprint machines or via standalone, dial-out terminals, and may be either brick-and-mortar (card-present) or e-commerce or mail/telephone order (card-not-present) merchants. Such merchants validate compliance by completing SAQ B and the associated Attestation of Compliance, confirming that:
SAQ C-VT merchants process cardholder data via virtual terminals on personal computers connected to the Internet, do not store cardholder data on any computer system, and may be brick-and-mortar For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment?” on page 17.
SAQ C-VT merchants process cardholder data via virtual terminals on personal computers connected to the Internet, do not store cardholder data on any computer system, and may be brick-and-mortar For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment?” on page 17.
Modified
p. 13 → 15
This option would never apply to e-commerce merchants.
This SAQ is not applicable to e-commerce channels.
Modified
p. 13 → 15
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment” on page 17.
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment?” on page 18.
Modified
p. 13 → 17
A virtual 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 terminals do not read data directly from a payment card. Because payment card transactions are entered manually, virtual terminals are typically used instead of physical terminals in merchant environments with low transaction volumes.
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.
Modified
p. 13 → 17
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.
Modified
p. 13 → 17
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.
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.
Removed
p. 14
1. The payment application system is on a personal computer that is connected to the Internet (for example, for e-mail or web browsing), or
2. The payment application system is connected to the Internet to transmit cardholder data.
2. The payment application system is connected to the Internet to transmit cardholder data.
Modified
p. 14 → 16
This option would never apply to e-commerce merchants.
This SAQ is not applicable to e-commerce channels.
Modified
p. 14 → 17
Your company’s only payment processing is done via a virtual terminal accessed by an Internet- connected web browser; Your company’s virtual terminal solution is provided and hosted by a PCI DSS validated third- party service provider; Your company accesses the PCI DSS-compliant virtual 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 …
Your company’s only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser; Your company’s virtual payment terminal solution is provided and hosted by a PCI DSS validated third-party service provider; 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 …
Modified
p. 14 → 18
SAQ C merchants process cardholder data via POS machines 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 e-commerce or mail/telephone-order (card-not-present) merchants. SAQ C merchants validate compliance by completing SAQ C and the associated Attestation of Compliance, confirming that:
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 e-commerce or mail/telephone-order (card-not-present) merchants.
Modified
p. 14 → 18
Your company has a payment application system and an Internet connection on the same device and/or same local area network (LAN); 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); Your company store is not connected to other store locations, and any LAN is for a single store only; Your company retains only …
Your company has a payment application system and an Internet connection on the same device and/or same local area network (LAN); 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); The physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single store only; …
Removed
p. 15
SAQ D
• All Other Merchants and All Service Providers Defined by a Payment Brand as Eligible to Complete an SAQ SAQ D has been developed for all service providers defined by a payment brand as eligible to complete an SAQ, as well as SAQ-eligible merchants who do not meet the descriptions of SAQ types A through C, above.
SAQ D service providers and merchants validate compliance by completing SAQ D and the associated Attestation of Compliance.
SAQ P2PE-HW
• Merchants with Only Hardware Payment Terminals included in a Validated, 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.
These merchants validate compliance by completing SAQ P2PE and the associated Attestation of Compliance, confirming that:
Your company does not store, process, or transmit any cardholder …
• All Other Merchants and All Service Providers Defined by a Payment Brand as Eligible to Complete an SAQ SAQ D has been developed for all service providers defined by a payment brand as eligible to complete an SAQ, as well as SAQ-eligible merchants who do not meet the descriptions of SAQ types A through C, above.
SAQ D service providers and merchants validate compliance by completing SAQ D and the associated Attestation of Compliance.
SAQ P2PE-HW
• Merchants with Only Hardware Payment Terminals included in a Validated, 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.
These merchants validate compliance by completing SAQ P2PE and the associated Attestation of Compliance, confirming that:
Your company does not store, process, or transmit any cardholder …
Modified
p. 15 → 19
SAQ P2PE-HW 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-HW merchants may be either brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants. For example, a MOTO merchant could be eligible for SAQ P2PE if they receive cardholder data on paper or over a telephone, and directly key it into a P2PE validated hardware device.
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.
Modified
p. 15 → 20
While many of the 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 guidance below for information about the exclusion of wireless technology and …
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 …
Removed
p. 16
Requirements 1.2.3, 2.1.1 and 4.1.1 (SAQs C and D): These questions specific to wireless only need to be answered if wireless is present anywhere in your network. Note that Requirement 11.1 (use of a process to identify unauthorized wireless access points) must still be answered even if wireless is not in your network, since the process detects any rogue or unauthorized devices that may have been added without your knowledge.
Requirements 6.3 and 6.5 (SAQ D): These questions are specific to custom applications and code, and only need to be answered if your organization develops its own custom applications.
Requirements 9.1 through 9.4 (SAQ D): These questions only need to be answered for facilities with “sensitive areas” as defined here. “Sensitive areas” refers to any data center, server room, or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale …
Requirements 6.3 and 6.5 (SAQ D): These questions are specific to custom applications and code, and only need to be answered if your organization develops its own custom applications.
Requirements 9.1 through 9.4 (SAQ D): These questions only need to be answered for facilities with “sensitive areas” as defined here. “Sensitive areas” refers to any data center, server room, or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale …