Document Comparison
SAQ-Instructions-Guidelines-PCI-DSS-v4-0.pdf
→
SAQ-Instructions-Guidelines-PCI-DSS-v4-0-1-r1.pdf
82% similar
29 → 30
Pages
9181 → 9573
Words
54
Content Changes
Content Changes
54 content changes. 32 administrative changes (dates, page numbers) hidden.
Added
p. 2
Updated the number of applicable PCI DSS requirements for the different SAQ A e-commerce methods in the table on page 10.
For SAQ C-VT, updated the Eligibility Criteria that refers to “network segmentation” to align with SAQ C-VT wording restored from SAQ C- VT for PCI DSS v3.2.1, and added additional clarifying guidance.
April 2025 4.0.1 r1 Corrected table (Common e-commerce methods and applicable SAQs) to accurately reflect the number of applicable PCI DSS requirements.
Removed Requirements 6.4.3 and 11.6.1 from section “Importance of new requirements added to SAQ A for PCI DSS v4.x.” Added the new SAQ A Eligibility Criteria for e-commerce merchants in the following two places:
To the table for “How does SAQ A compare to SAQ A-EP?” To the SAQ Eligibility Criteria section for SAQ A.
For SAQ C-VT, updated the Eligibility Criteria that refers to “network segmentation” to align with SAQ C-VT wording restored from SAQ C- VT for PCI DSS v3.2.1, and added additional clarifying guidance.
April 2025 4.0.1 r1 Corrected table (Common e-commerce methods and applicable SAQs) to accurately reflect the number of applicable PCI DSS requirements.
Removed Requirements 6.4.3 and 11.6.1 from section “Importance of new requirements added to SAQ A for PCI DSS v4.x.” Added the new SAQ A Eligibility Criteria for e-commerce merchants in the following two places:
To the table for “How does SAQ A compare to SAQ A-EP?” To the SAQ Eligibility Criteria section for SAQ A.
Added
p. 15
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 TPSP(s) to handle all these functions Data Retention Any account data retained by merchant is on paper (for example, printed reports or receipts), and these documents are not received electronically * Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this comparison.
To be eligible for this SAQ, the merchant only accesses the PCI DSS compliant virtual payment terminal solution via a computing device that is isolated in a single location, and that is not connected to any other locations or systems in the merchant …
To be eligible for this SAQ, the merchant only accesses the PCI DSS compliant virtual payment terminal solution via a computing device that is isolated in a single location, and that is not connected to any other locations or systems in the merchant …
Added
p. 24
The merchant has a payment application system and an Internet connection on the same device and/or same local area network (LAN); 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); The physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single store only; The merchant does not store account data in electronic format; and Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.
All payment processing is via a validated4 PCI-listed P2PE solution; The only systems in the merchant environment that store, process, or transmit account data are the payment terminals from a validated4 PCI-listed P2PE …
All payment processing is via a validated4 PCI-listed P2PE solution; The only systems in the merchant environment that store, process, or transmit account data are the payment terminals from a validated4 PCI-listed P2PE …
Modified
p. 1
Payment Card Industry Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 4.0
Payment Card Industry Data Security Standard Self-Assessment Questionnaire Instructions and Guidelines Version 4.0.1 Revision 1
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. Addition of SAQ C-VT for Web-based Virtual Terminal merchants.
October 28, 2010 2.0 To align content with new PCI DSS v2.0 and clarify SAQ environment types and eligibility criteria.
Removed
p. 6
• Meets the SAQ Eligibility Criteria specified in the chosen SAQ.
Modified
p. 6
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.
Modified
p. 6
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 bank) or the payment brands⎯to confirm they are eligible to complete an SAQ to validate PCI DSS compliance, and to understand any specific requirements or instructions.
Note: All entities completing SAQs are encouraged to contact the organizations that manage compliance programs and to which the SAQ will be submittedfor example, an acquirer (merchant bank) or the payment brandsto confirm they are eligible to complete an SAQ to validate PCI DSS compliance, and to understand any specific requirements or instructions.
Modified
p. 7
The PCI SSC website is a primary source for additional resources, including:
Modified
p. 7
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. 7
Please refer to www.pcisecuritystandards.org for more information.
Modified
p. 7
Payment-related training programs and resources may also be available from the payment brands and/or your merchant acquirer.
Removed
p. 8
• Standalone, dial-out terminals with no electronic account data storage.
Modified
p. 8
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 bank) or the payment brands⎯to confirm they are eligible to complete an SAQ to validate PCI DSS compliance, and to understand any specific requirements or instructions.
Note: All entities completing SAQs are encouraged to contact the organizations that manage compliance programs and to which the SAQ will be submittedfor example, an acquirer (merchant bank) or the payment brandsto confirm they are eligible to complete an SAQ to validate PCI DSS compliance, and to understand any specific requirements or instructions.
Modified
p. 8
Imprint machines with no electronic account data storage, and/or Standalone, dial-out terminals with no electronic account data storage.
Modified
p. 9
* New SAQ for PCI DSS v4.0
* New SAQ for PCI DSS v4.x
Modified
p. 10
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 SAQ may be better aligned with an organization’s particular environment than the SAQ used previously. Similarly, an organization that previously completed one type of SAQ will need to review the updated eligibility criteria for …
How will the SAQ updates impact my organization? With PCI DSS v4.x, 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 SAQ may be better aligned with an organization’s particular environment than the SAQ used previously. Similarly, an organization that previously completed one type of SAQ will need to review the updated eligibility criteria for …
Modified
p. 10
Some SAQs were updated to include additional PCI DSS requirements that were not in that SAQ for PCI DSS version 3.2.1. This will impact how the merchant approaches their self-assessment.
Some SAQs were updated to include additional PCI DSS requirements that were not in that SAQ for PCI DSS version 3.2.1. This will have an impact on how the merchant approaches their self- assessment.
Modified
p. 10
To understand why new requirements were added to SAQ A for PCI DSS v4.0, see Overview: SAQ A and SAQ A-EP below.
To understand why new requirements were added to SAQ A for PCI DSS v4.x, see Overview: SAQ A and SAQ A-EP below.
Modified
p. 10
Merchants should continue to choose an applicable SAQ based upon the defined eligibility criteria for each SAQ, and according to instructions from their acquirer or payment brand(s). Merchants are encouraged to read the relevant PCI DSS v4.0 SAQ to 1) confirm the merchant still meets the eligibility criteria and 2) to familiarize themselves with all the updated wording and all requirements included in that SAQ.
Merchants should continue to choose an applicable SAQ based upon the defined eligibility criteria for each SAQ, and according to instructions from their acquirer or payment brand(s). Merchants are encouraged to read the relevant PCI DSS v4.x SAQ to 1) confirm the merchant still meets the eligibility criteria and 2) to familiarize themselves with all the updated wording and all requirements included in that SAQ.
Modified
p. 10
Merchants should not assume that a particular SAQ for both PCI DSS v3.2.1 and v4.0 are the same.
Merchants should not assume that a particular SAQ for both PCI DSS v3.2.1 and v4.x are the same.
Modified
p. 13
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 all eligibility criteria detailed in SAQ A, including that there are no programs or application code that capture payment information on the merchant website. Examples of e-commerce implementations addressed by SAQ A include:
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 all eligibility criteria detailed in SAQ A, including that there are no programs or application code that capture payment information on the merchant webpage. Examples of e-commerce implementations addressed by SAQ A include:
Modified
p. 13
Merchant has no access to their webpage, and the webpage is entirely hosted and managed by a compliant TPSP/payment processor.
Modified
p. 13
Merchant webpage provides an inline frame (iframe) to a PCI DSS compliant TPSP/processor facilitating the payment process.
Modified
p. 13
Merchant webpage redirects users (for example, with a URL redirect) to a PCI DSS compliant TPSP/processor facilitating the payment process.
Modified
p. 13
Merchant website creates the payment form, and the payment data is delivered directly from the consumer browser to the payment processor (often referred to as “Direct Post”).
Modified
p. 13
Merchant website loads or delivers a script(s) that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.
Removed
p. 14
• PCI DSS Requirement 6.4.3 to manage payment page scripts. The intent is for a merchant to manage any payment page scripts present on the merchant’s website.
• PCI DSS Requirement 11.3.2 for external vulnerability scans at least once every 90 days and Requirement 11.3.2.1 for external vulnerability scans after significant changes. The intent is for a merchant to scan for and resolve any vulnerabilities on the merchant’s website.
• PCI DSS Requirement 11.6.1 for a change and tamper-detection mechanism deployed to detect and provide alerts for unauthorized modifications to HTTP headers and the contents of payment pages. The intent is for merchants to deploy this mechanism on the merchant’s website and respond to alerts.
• PCI DSS Requirement 11.3.2 for external vulnerability scans at least once every 90 days and Requirement 11.3.2.1 for external vulnerability scans after significant changes. The intent is for a merchant to scan for and resolve any vulnerabilities on the merchant’s website.
• PCI DSS Requirement 11.6.1 for a change and tamper-detection mechanism deployed to detect and provide alerts for unauthorized modifications to HTTP headers and the contents of payment pages. The intent is for merchants to deploy this mechanism on the merchant’s website and respond to alerts.
Modified
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.
E-commerce Method SAQ Type for Eligible Merchants Number of PCI DSS v4.x Requirements Fully outsourced. Merchant has no access to own webpage.
Modified
p. 14
Fully outsourced. Merchant website redirects customers to a compliant TPSP (for example, a URL redirect).
Fully outsourced. Merchant webpage redirects customers to a compliant TPSP (for example, a URL redirect).
Modified
p. 14
Fully outsourced. Merchant website includes a compliant TPSP’s embedded payment page/form (for example, an iframe).
Fully outsourced. Merchant webpage includes a compliant TPSP’s embedded payment page/form (for example, an iframe).
Modified
p. 14
Importance of new requirements added to SAQ A for PCI DSS v4.0 SAQ A for PCI DSS v4.0 includes additional security controls needed to address common breaches that are targeting SAQ A merchants, specifically to secure websites that 1) redirect payment transactions to a PCI DSS compliant TPSP or 2) include a PCI DSS compliant TPSP’s embedded payment page/form. To mitigate these common breaches, the following new requirements are included in SAQ A (Note: This list highlights requirements added to …
Importance of new requirements added to SAQ A for PCI DSS v4.x SAQ A for PCI DSS v4.x includes additional security controls needed to address common breaches that are targeting SAQ A merchants, specifically to secure webpages that 1) redirect payment transactions to a PCI DSS compliant TPSP or 2) include a PCI DSS compliant TPSP’s embedded payment page/form. To mitigate these common breaches, Requirements 11.3.2 and 11.3.2.1 are included in SAQ A (Note: This list highlights requirements added to …
Modified
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 …
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 …
Modified
p. 17 → 18
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 to the Internet No connections to other locations or Connected to the Internet No connections to other merchant systems No connections to other premises or locations …
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 to the Internet No connections to other locations or systems Connected to the Internet No connections to other merchant systems No connections to other premises or …
Modified
p. 18 → 19
The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions; All processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor; 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; The merchant has confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant; and Any account …
Modified
p. 18 → 19
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.
Modified
p. 19 → 20
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 …
Removed
p. 20
• 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;
• The standalone, dial-out terminals are not connected to any other systems within the merchant environment;
• The standalone, dial-out terminals are not connected to the Internet;
• The merchant does not store account data in electronic format; and
• The standalone, dial-out terminals are not connected to any other systems within the merchant environment;
• The standalone, dial-out terminals are not connected to the Internet;
• The merchant does not store account data in electronic format; and
Modified
p. 21 → 22
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; The standalone, IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (excludes SCRs and SCRPs); 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 …
Removed
p. 22
• The only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser;
• The virtual payment terminal solution is provided and hosted by a PCI DSS compliant third-party service provider;
• 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;
• 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);
• 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);
• 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
• The virtual payment terminal solution is provided and hosted by a PCI DSS compliant third-party service provider;
• 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;
• 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);
• 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);
• 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. 22 → 23
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment” on pages 23 and 24.
For a graphical guide to choosing your SAQ type, please see “Which SAQ Best Applies to My Environment” on pages 24 and 25.
Removed
p. 23
• The merchant does not store account data in electronic format; and
• The merchant has a payment application system and an Internet connection on the same device and/or same local area network (LAN);
• 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);
• The physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single store only;
• The merchant has a payment application system and an Internet connection on the same device and/or same local area network (LAN);
• 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);
• 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. 24
• All payment processing is via a validated3 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;
• The merchant does not otherwise receive, transmit, or store account data electronically;
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically; and
• The merchant has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
• 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;
• The merchant does not otherwise receive, transmit, or store account data electronically;
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically; and
• The merchant has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
Modified
p. 24 → 25
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.
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 validated4 PCI-listed P2PE solution.
Removed
p. 25
• Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically; and
• All payment processing is only via a card-present payment channel;
• All cardholder data entry is via an SCRP that is part of a validated SPoC solution approved and listed by PCI SSC;
• The only systems in the merchant’s SPoC environment that store, process, or transmit account data are those used as part of the validated4 SPoC solution approved and listed by PCI SSC;
• The merchant does not otherwise receive, transmit or store account data electronically;
• This payment channel is not connected to any other systems/networks within the merchant environment;
• The merchant has implemented all controls in the SPoC user guide provided by the SPoC Solution Provider.
• All payment processing is only via a card-present payment channel;
• All cardholder data entry is via an SCRP that is part of a validated SPoC solution approved and listed by PCI SSC;
• The only systems in the merchant’s SPoC environment that store, process, or transmit account data are those used as part of the validated4 SPoC solution approved and listed by PCI SSC;
• The merchant does not otherwise receive, transmit or store account data electronically;
• This payment channel is not connected to any other systems/networks within the merchant environment;
• The merchant has implemented all controls in the SPoC user guide provided by the SPoC Solution Provider.
Modified
p. 25 → 26
This SAQ is not applicable to unattended card-present⎯for example, kiosks, self- checkout⎯mail-order/telephone order (MOTO), or e-commerce channels.
This SAQ is not applicable to unattended card-presentfor example, kiosks, self- checkoutmail-order/telephone order (MOTO), or e-commerce channels.
Removed
p. 26
• E-commerce merchants that accept account data on their website;
• Merchants with electronic storage of account data;
• Merchants that do not store account data electronically but that do not meet the criteria of another SAQ type;
• Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.
• Merchants with electronic storage of account data;
• Merchants that do not store account data electronically but that do not meet the criteria of another SAQ type;
• Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.
Modified
p. 29 → 30
A “Defining Account Data, Cardholder Data, and Sensitive Authentication Data” table was added from PCI DSS v4.x to define the various terms used in PCI DSS.
Modified
p. 29 → 30
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.
Modified
p. 29 → 30
The requirements in each SAQ have been updated to reflect changes made to PCI DSS v4.x, and to align more closely with other PCI DSS v4.x documents. For example:
Modified
p. 29 → 30
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.
The wording for each PCI DSS requirement now mirrors the wording in PCI DSS v4.x, rather than being stated in the form of questions.
Modified
p. 29 → 30
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.” The Attestation of Compliance (AOC) sections were updated to align with the wording and content of the ROC AOCs.
• for example, “Yes” is now “In Place.” The Attestation of Compliance (AOC) sections were updated to align with the wording and content of the ROC AOCs.
The reporting responses for each PCI DSS requirement were updated to align with the language in the PCI DSS v4.x Report on Compliance (ROC) Template
• for example, “Yes” is now “In Place.” The Attestation of Compliance (AOC) sections were updated to align with the wording and content of the ROC AOCs.
• for example, “Yes” is now “In Place.” The Attestation of Compliance (AOC) sections were updated to align with the wording and content of the ROC AOCs.
Modified
p. 29 → 30
For some of the more complicated requirements, explanations were added6 to help merchants understand how to evaluate that requirement in the context of a given SAQ.
Modified
p. 29 → 30
New appendices were added for completion of additional information about specific reporting responses.