Document Comparison

PCI-DSS-v3-2-1-SAQ-P2PE%20-r2.pdf PCI-DSS-v4-0-SAQ-P2PE-r1.pdf
31% similar
24 → 31 Pages
6394 → 8287 Words
132 Content Changes

Content Changes

132 content changes. 42 administrative changes (dates, page numbers) hidden.

Added p. 2
December 2022 4.0 1 Removed “In Place with Remediation” as a reporting option from Requirement Responses table, Attestation of Compliance (AOC) Part 2g, SAQ Section 2 Response column, and AOC Section 3. Also removed former Appendix C.

Added “In Place with CCW” to AOC Section 3.

Added guidance for responding to future-dated requirements.

Added minor clarifications and addressed typographical errors.
Added p. 4
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 validated♦ PCI-listed P2PE solution.

This SAQ is not applicable to service providers.

 All payment processing is via a validated♦ PCI-listed P2PE solution;  The only systems in the merchant environment that store, process or transmit account data are the payment terminals from a validated♦ 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.

♦ P2PE solutions …
Added p. 5
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). Cardholder data and sensitive authentication data are considered account data and are defined as follows:

Account Data Cardholder Data includes: Sensitive Authentication Data includes:

• Primary Account Number (PAN)

• Full track data (magnetic-stripe data or equivalent on a chip)

• Card verification code

• PINs/PIN blocks Refer to PCI DSS Section 2, PCI DSS Applicability Information, for further details.

1. Confirm by review of the eligibility criteria in this SAQ and the Self-Assessment Questionnaire Instructions and Guidelines document on the PCI SSC website that this is the correct SAQ for the merchant’s environment.

2. Confirm that the merchant environment is properly scoped.

 Section 1: Assessment Information (Parts 1 & 2 of the Attestation of Compliance (AOC)

• Contact Information and Executive Summary).

5. Submit the SAQ and …
Added p. 6
The testing methods are intended to allow the merchant to demonstrate how it has met a requirement. The specific items to be examined or observed and personnel to be interviewed should be appropriate for both the requirement being assessed and the merchant’s particular implementation.

Full details of testing procedures for each requirement can be found in PCI DSS.

Requirement Responses For each requirement item, there is a choice of responses to indicate the merchant’s status regarding that requirement. Only one response should be selected for each requirement item.

Not Tested This response is not applicable to, and not included as an option for, this SAQ.

This SAQ was created for a specific type of environment based on how the merchant stores, processes, and/or transmits account data and defines the specific PCI DSS requirements that apply for this environment. Consequently, all requirements in this SAQ must be tested.

This response is also used if a requirement …
Added p. 7
For each response where Not Applicable is selected in this SAQ, complete Appendix C: Explanation of Requirements Noted as Not Applicable.
Added p. 7
Note: A legal restriction is one where meeting the PCI DSS requirement would violate a local or regional law or regulation.

Contractual obligations or legal advice are not legal restrictions.

Use of the Customized Approach SAQs cannot be used to document use of the Customized Approach to meet PCI DSS requirements. For this reason, the Customized Approach Objectives are not included in SAQs. Entities wishing to validate using the Customized Approach may be able to use the PCI DSS Report on Compliance (ROC) Template to document the results of their assessment.

The use of the customized approach may be regulated by organizations that manage compliance programs, such as payment brands and acquirers. Questions about use of a customized approach should always be referred to those organizations. This includes whether an entity that is eligible for an SAQ may instead complete a ROC to use a customized approach, and whether an entity is required …
Added p. 8
PCI Data Security Standard Requirements and Testing Procedures (PCI DSS)  Guidance on Scoping  Guidance on the intent of all PCI DSS Requirements  Details of testing procedures  Guidance on Compensating Controls  Appendix G: Glossary of Terms, Abbreviations, and Acronyms SAQ Instructions and Guidelines  Information about all SAQs and their eligibility criteria  How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs)  Guidance and information about SAQs.

Online PCI DSS Glossary  PCI DSS Terms, Abbreviations, and Acronyms Information Supplements and Guidelines  Guidance on a variety of PCI DSS topics including:

− Understanding PCI DSS Scoping and Network Segmentation − Third-Party Security Assurance − Multi-Factor Authentication Guidance − Best Practices for Maintaining PCI DSS Compliance Getting Started with PCI  Resources for smaller merchants including:

− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary …
Added p. 10
Indicate all payment channels used by the business that are included in this assessment.

Mail order/telephone order (MOTO) Card-present Are any payment channels not included in this assessment? If yes, indicate which channel(s) is not included in the assessment and provide a brief explanation about why the channel was excluded.

Part 2b. Description of Role with Payment Cards For each payment channel included in this assessment as selected in Part 2a above, describe how the business stores, processes and/or transmits account data.

Channel How Business Stores, Processes, and/or Transmits Account Data Part 2c. Description of Payment Card Environment Provide a high-level description of the environment covered by this assessment. For example:

• Connections into and out of the cardholder data environment (CDE).

• Critical system components within the CDE, such as POI devices, databases, web servers, etc., and any other necessary payment components, as applicable.

• System components that could impact the security of account data.

Indicate …
Added p. 11
Facility Type Total number of locations (How many locations of this type are in scope) Location(s) of facility (city, country) Example: Data centers 3 Boston, MA, USA Part 2e. PCI Validated P2PE Solution Provide the following information regarding the validated♦ PCI-listed P2PE solution used by the merchant:

P2PE Solution listing “Reference #”:

P2PE Solution “Reassessment Date”:

♦ P2PE solutions on the PCI list of Point-to-Point Solutions with Expired Validations are no longer considered “validated” per the P2PE Program Guide. Merchants using an expired P2PE solution should check with their acquirer or individual payment brands about acceptability of this SAQ.

• Store, process, or transmit account data on the merchant’s behalf (for example, payment gateways, payment processors, payment service providers (PSPs), and off-site storage)

• Manage system components included in the scope of the merchant’s PCI DSS assessmentfor example, via network security control services, anti-malware services, security incident and event management (SIEM), contact and call centers, …
Added p. 13
PCI DSS Requirement * Requirement Responses More than one response may be selected for a given requirement.

Indicate all responses that apply.

In Place In Place with CCW Not Applicable Not in Place

* PCI DSS Requirements indicated above refer to the requirements in Section 2 of this SAQ.

Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.

Note: The following requirements mirror the requirements in the PCI DSS Requirements and Testing Procedures document.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 3.1 Processes and mechanisms for protecting stored account data are defined and understood.

• Kept up to date.

• In use.
Added p. 14
Selection of any of the In Place responses for Requirement 3.1.1 means that, if the merchant has paper storage of account data, the merchant has policies and procedures in place that govern merchant activities for Requirement 3. This helps to ensure personnel are aware of and following security policies and documented operational procedures for managing the secure storage of any paper records with account data.

If merchant does not store paper records with account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
Added p. 15
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 3.2 Storage of account data is kept to a minimum.
Added p. 15
• Coverage for all locations of stored account data.

• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.

• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.

• A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

• Examine the data retention and disposal policies, procedures, and processes.

• Examine files and system records on system components where account data is stored.

• Observe the mechanisms used to render account data unrecoverable.

Applicability Notes Where account data is stored by a TPSP (for example, in a cloud environment), entities are responsible for working with their service providers to understand how the TPSP meets this requirement for the entity. Considerations …
Added p. 16
• Examine data sources.

• Kept up to date.

• In use.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
Added p. 17
Selection of any of the In Place responses for Requirement 9.1.1 means that the merchant has policies and procedures in place that govern merchant activities for Requirement 9, including how any paper media with cardholder data is secured, and how POI devices are protected.
Added p. 17
• Examine documented procedures.

• Examine logs or other documentation.

• Interview responsible personnel at the storge location(s).

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows:

• Materials are stored in secure storage containers prior to destruction.

• Examine the periodic media destruction policy.

Applicability Notes These requirements for media destruction when that media is no longer needed for business or legal reasons are separate and distinct from PCI DSS Requirement 3.2.1, which is for securely deleting cardholder data when no longer needed per the entity’s cardholder data retention policies.

Selection of any of the In Place responses for Requirements at 9.4 means that the merchant securely stores any paper media with account data, for example by storing the paper in a locked drawer, cabinet, …
Added p. 19
• Maintaining a list of POI devices.

• Periodically inspecting POI devices to look for tampering or unauthorized substitution.

• Examine documented policies and procedures.

Applicability Notes These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped). This requirement is not intended to apply to manual PAN key-entry components such as computer keyboards.

This requirement is recommended, but not required, for manual PAN key-entry components such as computer keyboards. This requirement does not apply to commercial off-the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.
Added p. 19
• Make and model of the device.

• Location of device.

• Device serial number or other methods of unique identification.

• Observe POI devices and device locations.
Added p. 20
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.

• Procedures to ensure devices are not installed, replaced, or returned without verification.

• Being aware of suspicious behavior around devices.

• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel.

Selection of any of the In Place responses for Requirements at 9.5 means that the merchant has policies and procedures in place for Requirements 9.5.1, 9.5.1.1, 9.5.1.2, and 9.5.1.3, and that they maintain a current list of devices, conduct periodic device inspections, and train employees about what to look for to detect tampered …
Added p. 21
• Disseminated to all relevant personnel, as well as to relevant vendors and business partners.
Added p. 21
• Updated as needed to reflect changes to business objectives or risks to the environment
Added p. 22
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 12.1.3 The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities.

• Examine documented evidence.
Added p. 22
• Examine the security awareness program.
Added p. 22
• Examine list of TPSPs.

Applicability Notes The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 12.8.2 Written agreements with TPSPs are maintained as follows:

• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.

Applicability Notes The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in …
Added p. 23
• Examine policies and procedures.

Applicability Notes Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.
Added p. 24
• Examine policies and procedures.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.
Added p. 24
• Examine documentation from previously reported incidents.

Note: This can be, but is not required to be, the stated Customized Approach Objective listed for this requirement in PCI DSS.

Requirement 3.5.1 Account data is never stored electronically
Added p. 29
Target Date for Compliance: YYYY-MM-DD A merchant submitting this form with a Non-Compliant status may be required to complete the Action Plan in Part 4 of this document. Confirm with the entity to which this AOC will be submitted before completing Part 4.

Compliant but with Legal exception: One or more requirements in the PCI DSS SAQ are marked as Not in Place due to a legal restriction that prevents the requirement from being met and all other requirements are marked as being either 1) In Place, 2) In Place with CCW, or 3) Not Applicable, resulting in an overall COMPLIANT BUT WITH LEGAL EXCEPTION rating; thereby (Merchant Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ except those noted as Not in Place due to a legal restriction.

This option requires additional review from the entity to which this AOC will be submitted. If selected, complete …
Added p. 30
PCI DSS controls will be maintained at all times, as applicable to the merchant’s environment.

QSA performed testing procedures.

QSA provided other assistance.

If selected, describe all role(s) performed:

If selected, describe all role(s) performed:

Signature of Lead QSA  Date: YYYY-MM-DD Lead QSA Name:

ISA(s) performed testing procedures.

ISA(s) provided other assistance.
Added p. 31
If asked to complete this section, select the appropriate response for “Compliant to PCI DSS Requirements” for each requirement below. For any “No” responses, include the date the merchant expects to be compliant with the requirement and a brief description of the actions being taken to meet the requirement.
Removed p. 2
This document aligns with PCI DSS v3.2.1 r1.
Removed p. 4
SAQ P2PE merchants do not have access to clear-text cardholder 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 validated P2PE hardware device.

• 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;

• Any …
Modified p. 4
This shortened version of the SAQ includes questions that apply to a specific type of small-merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to your environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment.
This SAQ includes only those requirements that apply to a specific type of merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to the cardholder data environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for the merchant’s environment.
Modified p. 4 → 5
4. Assess your environment for compliance with the applicable PCI DSS requirements.
3. Assess the environment for compliance with PCI DSS requirements.
Modified p. 4 → 5
5. Complete all sections of this document:
4. Complete all sections of this document:
Modified p. 4 → 5
• PCI DSS Self-Assessment Questionnaire (SAQ P2PE)
 Section 2: Self-Assessment Questionnaire P2PE.
Modified p. 4 → 5
Validation and Attestation Details, and Action Plan for Non-Compliant Requirements (if applicable)
 Section 3: Validation and Attestation Details (Parts 3 & 4 of the AOC

• PCI DSS Validation
and Action Plan for Non-Compliant Requirements (if Part 4 is applicable)).
Removed p. 5
6. Submit the SAQ and the Attestation of Compliance (AOC), along with any other requested documentation, to your acquirer, payment brand, or other requester.

Understanding the Self-Assessment Questionnaire The questions contained in the “PCI DSS Question” column in this self-assessment questionnaire are based on the requirements in the PCI DSS.

Additional resources that provide guidance on PCI DSS requirements and how to complete the self- assessment questionnaire have been provided to assist with the assessment process. An overview of some of these resources is provided below:

(PCI Data Security Standard Requirements and Security Assessment Procedures)

• Guidance on Scoping

• Guidance on the intent of all PCI DSS Requirements

• Details of testing procedures

• Guidance on Compensating Controls SAQ Instructions and Guidelines documents

• Information about all SAQs and their eligibility criteria

• How to determine which SAQ is right for your organization

PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms

• Descriptions and definitions of terms used …
Modified p. 5
Expected Testing The instructions provided in the “Expected Testing” column are based on the testing procedures in the PCI DSS, and provide a high-level description of the types of testing activities that should be performed in order to verify that a requirement has been met. Full details of testing procedures for each requirement can be found in the PCI DSS.
Expected Testing The instructions provided in the “Expected Testing” column are based on the testing procedures in PCI DSS and provide a high-level description of the types of testing activities that a merchant is expected to perform to verify that a requirement has been met.
Removed p. 6
Guidance for Non-Applicability of Certain, Specific Requirements If any requirements are deemed not applicable to your environment, select the “N/A” option for that specific requirement, and complete the “Explanation of Non-Applicability” worksheet in Appendix C for each “N/A” entry.
Modified p. 6
A description of the meaning for each response is provided in the table below:
A description of the meaning for each response and when to use each response is provided in the table below:
Modified p. 6
Yes The expected testing has been performed, and all elements of the requirement have been met as stated.
In Place The expected testing has been performed, and all elements of the requirement have been met as stated.
Modified p. 6
Yes with CCW (Compensating Control Worksheet) The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.
In Place with CCW (Compensating Controls Worksheet) The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.
Modified p. 6
All responses in this column require completion of a Compensating Control Worksheet (CCW) in Appendix B of the SAQ.
All responses in this column require completion of a Compensating Controls Worksheet (CCW) in Appendix B of this SAQ.
Modified p. 6
Information on the use of compensating controls and guidance on how to complete the worksheet is provided in the PCI DSS.
Information on the use of compensating controls and guidance on how to complete the worksheet is provided in PCI DSS in Appendices B and C.
Modified p. 6
No Some or all elements of the requirement have not been met, or are in the process of being implemented, or require further testing before it will be known if they are in place.
Not in Place Some or all elements of the requirement have not been met, or are in the process of being implemented, or require further testing before the merchant can confirm they are in place. Responses in this column may require the completion of Part 4, if requested by the entity to which this SAQ will be submitted.
Modified p. 6
(Not Applicable) The requirement does not apply to the organization’s environment. (See Guidance for Non-Applicability of Certain, Specific Requirements below for examples.) All responses in this column require a supporting explanation in Appendix C of the SAQ.
Not Applicable The requirement does not apply to the merchant’s environment. (See “Guidance for Not Applicable Requirements” below for examples.) All responses in this column require a supporting explanation in Appendix C of this SAQ.
Modified p. 6 → 7
Legal Exception If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, check the “No” column for that requirement and complete the relevant attestation in Part 3.
Legal Exception If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, select Not in Place for that requirement and complete the relevant attestation in Section 3, Part 3 of this SAQ.
Removed p. 7
Part 1. Merchant and Qualified Security Assessor Information Part 1a. Merchant Organization Information Company Name: DBA (doing business as):

Business Address: City:

Business Address: City:

State/Province: Country: Zip:

State/Province: Country: Zip:

Lead QSA Contact Name: Title:

Part 2. Executive Summary Part 2a. Type of Merchant Business (check all that apply) Retailer Telecommunication Grocery and Supermarkets Petroleum Mail/Telephone Order (MOTO) Others (please specify):

What types of payment channels does your business serve?

Mail order/telephone order (MOTO) E-Commerce Card-present (face-to-face) Which payment channels are covered by this SAQ? Mail order/telephone order (MOTO) E-Commerce Card-present (face-to-face)
Modified p. 7 → 9
Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the merchant’s self-assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS). Complete all sections: The merchant is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact your acquirer (merchant bank) or the payment brands to determine reporting and submission procedures.
Section 1: Assessment Information Instructions for Submission This document must be completed as a declaration of the results of the merchant’s self-assessment against the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures. Complete all sections. The merchant is responsible for ensuring that each section is completed by the relevant parties, as applicable. Contact the entity(ies) to which the Attestation of Compliance (AOC) will be submitted for reporting and submission procedures.
Modified p. 7 → 9
Part 1b. Qualified Security Assessor Company Information (if applicable) Company Name:
Qualified Security Assessor Company name:
Modified p. 7 → 10
Note: If your organization has a payment channel or process that is not covered by this SAQ, consult your acquirer or payment brand about validation for the other channels.
Note: If the organization has a payment channel that is not covered by this SAQ, consult with the entity(ies) to which this AOC will be submitted about validation for the other channels.
Removed p. 8
Type of facility Number of facilities of this type Location(s) of facility (city, country) Example: Retail outlets 3 Boston, MA, USA Part 2d. P2PE Solution Provide the following information regarding the validated PCI P2PE solution your organization uses:

Part 2e. Description of Environment Provide a high-level description of the environment covered by this assessment.

• Critical system components within the CDE, such as POS devices, databases, web servers, etc., and any other necessary payment components, as applicable.

Does your business use network segmentation to affect the scope of your PCI DSS environment? (Refer to “Network Segmentation” section of PCI DSS for guidance on network segmentation.)
Modified p. 8 → 11
PCI SSC Reference Number Listed P2PE POI Devices used by Merchant (PTS Device Dependencies):
Listed POI Devices used by Merchant (found under “PTS POI Devices Supported”):
Removed p. 9
Description of services provided by QIR:

Does your company share cardholder data with any third-party service providers (for example, Qualified Integrator & Resellers (QIR), gateways, airline booking agents, loyalty program agents, etc.)? Name of service provider: Description of services provided:

Merchant verifies there is no legacy storage of electronic cardholder data in the environment.
Modified p. 9 → 13
Part 2g. Eligibility to Complete SAQ P2PE Merchant certifies eligibility to complete this shortened version of the Self-Assessment Questionnaire because, for this payment channel:
Part 2h. Eligibility to Complete SAQ P2PE Merchant certifies eligibility to complete this Self-Assessment Questionnaire because, for this payment channel:
Modified p. 9 → 13
All payment processing is via the validated PCI P2PE solution approved and listed by the PCI SSC (per above).
All payment processing is via a validated PCI-listed P2PE solution (per Part 2e above).
Modified p. 9 → 13
The only systems in the merchant environment that store, process or transmit account data are the Point of Interaction (POI) devices that 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 validated PCI-listed P2PE solution.
Modified p. 9 → 13
Merchant does not otherwise receive or transmit cardholder data electronically.
The merchant does not otherwise receive, transmit, or store account data electronically.
Modified p. 9 → 13
If Merchant does store cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically, and Merchant 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.
Removed p. 10
Note: The following questions are numbered according to the PCI DSS requirements and testing procedures, as defined in the PCI DSS Requirements and Security Assessment Procedures document. As only a subset of PCI DSS requirements are provided in this SAQ P2PE, the numbering of these questions may not be consecutive.

PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 3.1 Are data-retention and disposal policies, procedures, and processes implemented as follows:

(b) Are there defined processes in place for securely deleting cardholder data when no longer needed for legal, regulatory, and/or business reasons?

• Review policies and procedures.

(d) Is there a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements?

• Review policies and procedures.

(e) Does all stored cardholder data meet the requirements defined in the data-retention policy?

• Examine files and system records.
Modified p. 10 → 14
Self-assessment completion date: Protect Cardholder Data
Self-assessment completion date: YYYY-MM-DD Protect Account Data
Modified p. 10 → 14
Requirement 3: Protect stored cardholder data
Requirement 3: Protect Stored Account Data
Modified p. 10 → 14
• Examine deletion mechanism.
• Examine documentation.
Modified p. 10 → 15
(a) Is data storage amount and retention time limited to that required for legal, regulatory, and/or business requirements?

• Review data retention and disposal policies and procedures.
• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
Modified p. 10 → 15
(c) Are there specific retention requirements for cardholder data? For example, cardholder data needs to be held for X period for Y business reasons.
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
Modified p. 10 → 17
Note: Requirement 3 applies only to SAQ P2PE merchants that have paper records (for example, receipts, printed reports, etc.) with account data, including primary account numbers (PANs).
Note: For SAQ P2PE, Requirements at 9.4 only apply to merchants with paper records (for example, receipts or printed reports) with account data, including primary account numbers (PANs).
Modified p. 10 → 19
• Observe deletion processes.
• Observe inspection processes.
Modified p. 10 → 22
Review policies and procedures.
Examine policies and procedures.
Modified p. 10 → 23
• Examine retention requirements.
• Examine written agreements with TPSPs.
Removed p. 11
Guidance: Guidance: A “Yes” answer to Requirement 3.7 means that, if the merchant has paper storage of account data, the merchant has policies and procedures in place for Requirements 3.1, 3.2.2, and 3.3. This helps to ensure personnel are aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis.
Modified p. 11 → 14
• Known to all affected parties?

• Review security policies and operational procedures.
• Known to all affected parties.
Modified p. 11 → 16
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A Guidance: “Yes” answers for requirements at 3.1 mean that if a merchant stores any paper (for example, receipts or paper reports) that contain account data, the merchant only stores the paper as long as it is needed for business, legal, and/or regulatory reasons and destroys the paper once it is no longer needed.
Selection of any of the In Place responses for Requirement 3.2.1 means that the merchant has data disposal policies that govern account data storage and if a merchant stores any paper (for example, receipts or paper reports) that contain account data, the merchant stores the paper per that policy (for example, only as long as it is needed for business, legal, and/or regulatory reasons) and destroys the paper once it is no longer needed.
Modified p. 11 → 16
If a merchant never prints or stores any paper containing account data, the merchant should mark the “N/A” column and complete the “Explanation of Non- Applicability” worksheet in Appendix C.
If a merchant never prints or stores any paper containing account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
Modified p. 11 → 16
Guidance: Guidance: A “Yes” answer for Requirement 3.2.2 means that if the merchant writes down the card security code while a transaction is being conducted, the merchant either securely destroys the paper (for example, with a shredder) immediately after the transaction is complete, or obscures the code (for example, by “blacking it out” with a marker) before the paper is stored.
Selection of any of the In Place responses for Requirement 3.3.1.2 means that if the merchant writes down the card verification code while a transaction is being conducted, the merchant either securely destroys the paper (for example, with a shredder) immediately after the transaction is complete, or obscures the code (for example, by “blacking it out” with a marker) before the paper is stored.
Modified p. 11 → 16
If the merchant never requests the three-digit or four-digit number printed on the front or back of a payment card (“card security code”), the merchant should mark the “N/A” column and complete the “Explanation of Non-Applicability” worksheet in Appendix C.
If the merchant never requests the three-digit or four-digit number printed on the front or back of a payment card (“card verification code”), mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
Removed p. 12
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 9.5 Are all media physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes)? For purposes of Requirement 9, “media” refers to all paper and electronic media containing cardholder data.
Removed p. 12
(c) Is media destruction performed as follows:

Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents?

• Review periodic media destruction policies and procedures.

Guidance: “Yes” answers for requirements at 9.5 and 9.8 mean that the merchant securely stores any paper with account data, for example by storing them in a locked drawer, cabinet, or safe, and that the merchant destroys such paper when no longer needed for business purposes. This includes a written document or policy for employees so they know how to secure paper with account data and how to destroy the paper when no longer needed.
Modified p. 12 → 14
Note: Requirements 9.5 and 9.8 apply only to SAQ P2PE merchants that have paper records (for example, receipts, printed reports, etc.) with account data, including primary account numbers (PANs).
Note: For SAQ P2PE, Requirement 3 applies only to merchants with paper records that include account data (for example, receipts or printed reports).
Modified p. 12 → 17
Requirement 9: Restrict physical access to cardholder data
Requirement 9: Restrict Physical Access to Cardholder Data
Modified p. 12 → 18
Examine security of storage containers.
Observe storage containers.
Modified p. 12 → 18
If the merchant never stores any paper with account data, the merchant should mark the “N/A” column and complete the “Explanation of Non-Applicability” worksheet in Appendix C.
If the merchant never stores any paper with account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
Modified p. 12 → 23
Review policies and procedures for physically securing media.
Examine policies and procedures.
Removed p. 13
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 9.9 Are devices that capture payment card data via direct physical interaction with the card protected against tampering and substitution as follows? Note: This requirement applies to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

(a) Do policies and procedures require that a list of such devices be maintained?

• Review policies and procedures.

(b) Do policies and procedures require that devices are periodically inspected to look for tampering or substitution?

• Review policies and procedures.
Removed p. 13
(b) Is the list accurate and up to date?

• Observe devices and device locations and compare to list.

(c) Is the list of devices updated when devices are added, relocated, decommissioned, etc.?

• Interview personnel.
Modified p. 13 → 19
(c) Do policies and procedures require that personnel are trained to be aware of suspicious behavior and to report tampering or substitution of devices?

• Review policies and procedures.
• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.
Modified p. 13 → 19
• Examine the list of devices.
• Examine the list of POI devices.
Removed p. 14
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 9.9.2 (a) Are device surfaces periodically inspected to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device) as follows? Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

• Observe inspection processes and compare to defined processes.

(b) Are personnel aware of procedures for inspecting devices?

• Interview personnel.
Modified p. 14 → 19
• Interview personnel.
• Interview responsible personnel.
Modified p. 14 → 20
• Review training materials.
• Review training materials for personnel in POI environments.
Removed p. 15
PCI DSS Question Expected Testing Response (Check one response for each question) CCW No N/A 9.9.3 (cont.) (b) Have personnel at point-of-sale locations received training, and are they aware of procedures to detect and report attempted tampering or replacement of devices?

• Interview personnel at POS locations.

Guidance: “Yes” answers to requirements at 9.9 mean the merchant has policies and procedures in place for Requirements 9.9.1

• 9.9.3, and that they maintain a current list of devices, conduct periodic device inspections, and train employees about what to look for to detect tampered or replaced devices.

Guidance: A “Yes” answer to Requirement 9.10 means that the merchant has policies and procedures in place for Requirements 9.5, 9.8, and 9.9, as applicable for your environment. This helps to ensure personnel are aware of and following security policies and documented operational procedures.
Modified p. 15 → 17
• Known to all affected parties?

• Examine security policies and operational procedures.
• Known to all affected parties.
Modified p. 15 → 20
• Interview personnel.
• Interview responsible personnel.
Removed p. 16
Requirement 12: Maintain a policy that addresses information security for all personnel

PCI DSS Question Expected Testing Response (Check one response for each question) Yes Yes with 12.1 Is a security policy established, published, maintained, and disseminated to all relevant personnel?

• Review the information security policy.
Removed p. 16
Guidance: A “Yes” answer for Requirement 12.5.3 means that the merchant has a person designated as responsible for the incident-response and escalation plan required at 12.9.
Modified p. 16 → 21
Note: Requirement 12 specifies that merchants must have information security policies for their personnel, but these policies can be as simple or complex as needed for the size and complexity of the merchant’s operations. The policy document must be provided to all personnel so they are aware of their responsibilities for protecting the, payment terminals, any paper documents with cardholder data, etc. If a merchant has no employees, then it is expected that the merchant understands and acknowledges their responsibility …
Note: Requirement 12 specifies that merchants have information security policies for their personnel, but these policies can be as simple or complex as needed for the size and complexity of the merchant’s operations. The policy document must be provided to all personnel so they are aware of their responsibilities for protecting payment terminals, any paper documents with account data, etc. If a merchant has no employees, then it is expected that the merchant understands and acknowledges their responsibility for security …
Modified p. 16 → 21
Guidance: “Yes” answers for requirements at 12.1 mean that the merchant has a security policy that is reasonable for the size and complexity of the merchant’s operations, and that the policy is reviewed annually and updated if needed. For example, such a policy could be a simple document that covers how to protect the store and payment devices in accordance with the P2PE Instruction Manual (PIM), and who to call in an emergency.
Selection of any of the In Place responses for Requirements 12.1.1 and 12.1.2 means that the merchant has a security policy that is reasonable for the size and complexity of the merchant’s operations, and that the policy is reviewed at least once every 12 months and updated if needed. For example, such a policy could be a simple document that covers how to protect the store and payment devices in accordance with the solution provider’s guidance/instruction manual, and who to …
Modified p. 16 → 22
• Interview a sample of responsible personnel.
• Interview responsible personnel.
Modified p. 16 → 22
Guidance: A “Yes” answer for Requirement 12.4 means that the merchant’s security policy defines basic security responsibilities for all personnel, consistent with the size and complexity of the merchant’s operations. For example, security responsibilities could be defined according to basic responsibilities by employee levels, such as the responsibilities expected of a manager/owner and those expected of clerks.
Selection of any of the In Place responses for Requirement 12.1.3 means that the merchant’s security policy defines basic security responsibilities for all personnel, consistent with the size and complexity of the merchant’s operations. For example, security responsibilities could be defined according to basic responsibilities by employee levels, such as the responsibilities expected of a manager/owner and those expected of clerks.
Removed p. 17
PCI DSS Question Expected Testing Response (Check one response for each question) Yes Yes with 12.6 (a) Is a formal security awareness program in place to make all personnel aware of the cardholder data security policy and procedures?

• Review security awareness program.
Removed p. 17
• Observe written agreements.
Modified p. 17 → 21
Review list of service providers.
Reviewed at least once every 12 months.
Modified p. 17 → 22
Guidance: A Yes” answer for Requirement 12.6 means that the merchant has a security awareness program in place, consistent with the size and complexity of the merchant’s operations. For example, a simple awareness program could be a flyer posted in the back office, or a periodic e-mail sent to all employees. Examples of awareness program messaging include descriptions of security tips all employees should follow, such as how to lock doors and storage containers, how to determine whether a payment …
Selection of any of the In Place responses for Requirement 12.6.1 means that the merchant has a security awareness program in place, consistent with the size and complexity of the merchant’s operations. For example, a simple awareness program could be a flyer posted in the back office, or a periodic e-mail sent to all employees. Examples of awareness program messaging include descriptions of security tips all employees should follow, such as how to lock doors and storage containers, how to …
Modified p. 17 → 23
Review policies and procedures.
Examine policies and procedures.
Removed p. 18
PCI DSS Question Expected Testing Response (Check one response for each question) Yes Yes with 12.8.4 Is a program maintained to monitor service providers’ PCI DSS compliance status at least annually?

• Review policies and procedures and supporting documentation.
Modified p. 18 → 24
Guidance: “Yes” answers for requirements at 12.8 mean that the merchant has a list of, and agreements with, service providers they share cardholder data with. For example, such agreements would be applicable if a merchant uses a document-retention company to store paper documents that include account data.
Selection of any of the In Place responses for Requirements 12.8.1 through 12.8.5 means that the merchant has a list of, and agreements with, service providers they share account data with or that could impact the security of the merchant’s cardholder data environment. For example, such agreements would be applicable if a merchant uses a document-retention company to store paper documents that include account data or if a merchant’s vendor accesses merchant systems remotely to perform maintenance.
Modified p. 18 → 24
Review incident response plan procedures.
Examine the incident response plan.
Modified p. 18 → 24
Guidance: “Yes” answers for requirements at 12.10 mean that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. For example, such a plan could be a simple document posted in the back office that lists who to call in the event of various situations with an annual review to confirm it is still accurate, but could extend all the way to a full incident …
Selection of any of the In Place responses for Requirement 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. For example, such a plan could be a simple document posted in the back office that lists who to call in the event of various situations with an annual review to confirm it is still accurate, but could extend all the way …
Modified p. 19 → 25
Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card-Present POS POI Terminal Connections This appendix is not used for SAQ P2PE merchant assessments.
Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS for Card-Present POS POI Terminal Connections This Appendix is not used for SAQ P2PE merchant assessments.
Modified p. 20 → 26
Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.
Note: Only entities that have a legitimate and documented technological or business constraint can consider the use of compensating controls to achieve compliance.
Modified p. 20 → 26
Refer to Appendices B, C, and D of PCI DSS for information about compensating controls and guidance on how to complete this worksheet.
Refer to Appendices B and C in PCI DSS for information about compensating controls and guidance on how to complete this worksheet.
Modified p. 20 → 26
1. Constraints List constraints precluding compliance with the original requirement.
1. Constraints Document the legitimate technical or business constraints precluding compliance with the original requirement.
Modified p. 20 → 26
2. Objective Define the objective of the original control; identify the objective met by the compensating control.
3. Objective Define the objective of the original control.
Modified p. 20 → 26
3. Identified Risk Identify any additional risk posed by the lack of the original control.
4. Identified Risk Identify any additional risk posed by the lack of the original control.
Modified p. 20 → 26
4. Definition of Compensating Controls Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any.
2. Definition of Compensating Controls Define the compensating controls: explain how they address the objectives of the original control and the increased risk, if any.
Modified p. 20 → 26
6. Maintenance Define process and controls in place to maintain compensating controls.
6. Maintenance Define process(es) and controls in place to maintain compensating controls.
Modified p. 21 → 27
Requirement Reason Requirement is Not Applicable 12.8 Cardholder data is never shared with service providers.
Requirement Reason Requirement is Not Applicable
Removed p. 22
An entity submitting this form with a status of Non-Compliant may be required to complete the Action Plan in Part 4 of this document Check with your acquirer or the payment brand(s) before completing Part 4, since not all payment brands require this section.

Compliant but with Legal exception: One or more requirements are marked “No” due to a legal restriction that prevents the requirement from being met. This option requires additional review from acquirer or payment brand.

If checked, complete the following:

I have read the PCI DSS and I recognize that I must maintain PCI DSS compliance, as applicable to my environment, at all times.

If my environment changes, I recognize I must reassess my environment and implement any additional PCI DSS requirements that apply.
Modified p. 22 → 29
Section 3: Validation and Attestation Details Part 3. PCI DSS Validation This AOC is based on results noted in SAQ P2PE (Section 2), dated (SAQ completion date).
Section 3: Validation and Attestation Details Part 3. PCI DSS Validation This AOC is based on results noted in SAQ P2PE (Section 2), dated (Self-assessment completion date YYYY-MM-DD).
Modified p. 22 → 29
Based on the results documented in the SAQ P2PE noted above, the signatories identified in Parts 3b-3d, as applicable, assert(s) the following compliance status for the entity identified in Part 2 of this document: (check one):
Based on the results documented in the SAQ P2PE noted above, each signatory identified in any of Parts 3b−3d, as applicable, assert(s) the following compliance status for the merchant identified in Part 2 of this document.
Modified p. 22 → 29
Compliant: All sections of the PCI DSS SAQ P2PE are complete, all questions answered affirmatively, resulting in an overall COMPLIANT rating; thereby (Merchant Company Name) has demonstrated full compliance with the PCI DSS.
Compliant: All sections of the PCI DSS SAQ are complete and all requirements are marked as being either 1) In Place, 2) In Place with CCW, or 3) Not Applicable, resulting in an overall COMPLIANT rating; thereby (Merchant Company Name) has demonstrated compliance with all PCI DSS requirements included in this SAQ.
Modified p. 22 → 29
Non-Compliant: Not all sections of the PCI DSS SAQ P2PE are complete, or not all questions are answered affirmatively, resulting in an overall NON-COMPLIANT rating, thereby (Merchant Company Name) has not demonstrated full compliance with the PCI DSS.
Non-Compliant: Not all sections of the PCI DSS SAQ are complete, or one or more requirements are marked as Not in Place, resulting in an overall NON-COMPLIANT rating; thereby (Merchant Company Name) has not demonstrated compliance with the PCI DSS requirements included in this SAQ.
Modified p. 22 → 29
Affected Requirement Details of how legal constraint prevents requirement being met Part 3a. Acknowledgement of Status Signatory(s) confirms:
Affected Requirement Details of how legal constraint prevents requirement from being met
Modified p. 22 → 30
(Check all that apply)
(Select all that apply)
Modified p. 22 → 30
PCI DSS Self-Assessment Questionnaire P2PE, Version (version of SAQ), was completed according to the instructions therein.
PCI DSS Self-Assessment Questionnaire P2PE, Version 4.0, was completed according to the instructions therein.
Modified p. 22 → 30
All information within the above-referenced SAQ and in this attestation fairly represents the results of my assessment in all material respects.
All information within the above-referenced SAQ and in this attestation fairly represents the results of the merchant’s assessment in all material respects.
Modified p. 23 → 30
Part 3b. Merchant Attestation Signature of Merchant Executive Officer  Date:
Part 3b. Merchant Attestation Signature of Merchant Executive Officer  Date: YYYY-MM-DD Merchant Executive Officer Name: Title:
Modified p. 23 → 30
Part 3c. Qualified Security Assessor (QSA) Acknowledgement (if applicable) If a QSA was involved or assisted with this assessment, describe the role performed:
Part 3c. Qualified Security Assessor (QSA) Acknowledgement If a QSA was involved or assisted with this assessment, indicate the role performed:
Modified p. 23 → 30
Signature of Duly Authorized Officer of QSA Company  Date:
Signature of Duly Authorized Officer of QSA Company  Date: YYYY-MM-DD Duly Authorized Officer Name: QSA Company:
Modified p. 23 → 30
Part 3d. Internal Security Assessor (ISA) Involvement (if applicable) If an ISA(s) was involved or assisted with this assessment, identify the ISA personnel and describe the role performed:
Part 3d. PCI SSC Internal Security Assessor (ISA) Involvement If an ISA(s) was involved or assisted with this assessment, indicate the role performed:
Removed p. 24
Check with your acquirer or the payment brand(s) before completing Part 4, since not all payment brands require this section.
Modified p. 24 → 31
PCI DSS Requirement* Description of Requirement Compliant to PCI DSS Requirements (Select One) Remediation Date and Actions (If “NO” selected for any Requirement) YES NO 3 Protect stored cardholder data.
PCI DSS Requirement * Description of Requirement Compliant to PCI DSS Requirements (Select One) Remediation Date and Actions (If “NO” selected for any Requirement) YES NO 3 Protect stored account data 9 Restrict physical access to cardholder data.