PCI DSS v4.0.1 Self-Assessment Questionnaire (SAQ P2PE)

Why does it matter?

A P2PE solution encrypts account data inside the terminal, so the merchant never handles clear-text card data on its own systems. SAQ P2PE turns that architecture into a short self-assessment: the Council limits it to the PCI DSS requirements that still apply to such a merchant, which are stored paper records (Requirement 3), physical protection of media and terminals (Requirement 9) and policies, awareness, third parties and incident response (Requirement 12). The condition is that the solution is on the PCI SSC list of validated P2PE solutions and that the merchant has implemented every control in the Instruction Manual the solution provider supplies. A solution whose validation has expired no longer counts as validated under the P2PE Program Guide.

Key benefits include:

• Five eligibility criteria

All payment processing via a validated PCI-listed P2PE solution; the listed terminals are the only systems touching account data; no other electronic receipt, transmission or storage; any retained account data on paper and not received electronically; all PIM controls implemented (Merchant Eligibility Criteria and AOC Part 2h).

• Three requirements instead of twelve

Section 2 contains Requirements 3, 9 and 12 only, and Part 2g of the AOC summarizes responses for those three; Requirement 3 applies only to merchants with paper records that include account data.

• Terminal controls spelled out

Requirement 9.5.1 asks for a list of POI devices with make, model, location and serial number (9.5.1.1), periodic inspection of device surfaces (9.5.1.2) and training to spot tampering or substitution (9.5.1.3); the SAQ notes these apply to the POI devices used as part of the P2PE solution.

• Guidance sized for small merchants

The SAQ Completion Guidance under 12.1.1 and 12.1.2 says the security policy can be a simple document on protecting the store and payment devices per the solution provider's instructions and whom to call in an emergency; under 12.6.1 an awareness program can be a flyer in the back office or a periodic e-mail.

• Solution details recorded once

Part 2e of the AOC captures the P2PE solution provider, the solution name, its listing reference number, the listed POI devices in use and the solution reassessment date, which is where an expired validation becomes visible.

How does it work?

The Assessment Information in Section 1 doubles as Parts 1 and 2 of the AOC. Part 1 names the assessed merchant and any assessor; Part 2 covers payment channels (2a), how the business handles account data (2b), the environment (2c), in-scope locations (2d), the validated P2PE solution (2e), third-party service providers, to all of which Requirement 12.8 applies (2f), the summary of responses for Requirements 3, 9 and 12 (2g) and the certification of the five eligibility criteria (2h). The completion steps are the five the Council uses in every SAQ: confirm the right SAQ, confirm scope, assess, complete Sections 1 to 3, and submit the SAQ and AOC with any requested documentation to the acquirer or payment brand.

Section 2 mirrors the PCI DSS wording for each included requirement, with Expected Testing and one response: In Place, In Place with CCW, Not Applicable or Not in Place. Not Tested is not offered, because every requirement here must be tested. Requirement 3 items such as 3.2.1 (retention and disposal) and 3.3.1.2 (card verification code not stored) carry guidance that a merchant without paper records marks them Not Applicable and explains why in Appendix C; the same applies to the 9.4 media requirements. The future-dated bullet of 3.2.1 on sensitive authentication data was a best practice until March 31, 2025. A compensating control requires the worksheet in Appendix B; the customized approach cannot be documented in an SAQ.

Requirement 12 asks for an information security policy that is published, reviewed at least once every 12 months and defines information security roles (12.1.1 to 12.1.3), a security awareness program (12.6.1), third-party service provider management (12.8.1 to 12.8.5) and an incident response plan ready to be activated (12.10.1). Section 3 is Parts 3 and 4 of the AOC: the merchant selects Compliant, Non-Compliant or Compliant but with Legal exception, acknowledges that SAQ P2PE Version 4.0.1 was completed per its instructions (3a), an executive officer signs (3b), QSA or ISA roles are recorded (3c, 3d) and Part 4 lists remediation dates for Requirements 3, 9 and 12 if the acquirer asks for it.

Key Elements

• Validated, PCI-listed P2PE solution

The solution must appear on the PCI SSC list of validated P2PE solutions; solutions on the list of Point-to-Point Solutions with Expired Validations are no longer validated under the P2PE Program Guide, and a merchant using one must ask its acquirer or payment brands whether this SAQ is still acceptable.

• P2PE Instruction Manual (PIM)

The solution provider's document whose controls the merchant must have implemented in full; it is the fifth eligibility criterion and the reason Requirements 3.3 and 4.2 left this SAQ in April 2016.

• Requirement 3: stored account data

Only for merchants with paper records that include account data: policies (3.1.1), retention and disposal (3.2.1) and no storage of the card verification code after authorization (3.3.1.2).

• Requirement 9: physical access

Policies (9.1.1), secure storage, classification, transport, approval and destruction of paper media (9.4.1 to 9.4.6) and the POI device list, inspections and training at 9.5.1; 9.5.1.2.1 is intentionally left blank for this SAQ.

• Requirement 12: policies and programs

Security policy and roles (12.1.1 to 12.1.3), awareness (12.6.1), third-party service providers (12.8.1 to 12.8.5) and the incident response plan (12.10.1).

• Appendices

A1 is not used for merchant assessments, A2 is not used for SAQ P2PE and A3 applies only to entities designated by a payment brand or acquirer; B is the Compensating Controls Worksheet, C explains Not Applicable responses and D is reserved for Not Tested, which this SAQ does not allow.

• Attestation of Compliance

Section 1 (Parts 1 and 2) and Section 3 (Parts 3 and 4) together form the AOC that the merchant submits with the questionnaire.

What does it cover?

SAQ P2PE applies to a merchant payment channel in which all payment processing goes through a validated PCI-listed P2PE solution and the terminals of that solution are the only systems that store, process or transmit account data. Card-present stores qualify, and so do mail or telephone order operations that key paper or spoken card details only into such a terminal. E-commerce channels are excluded, as are service providers, who use SAQ D for Service Providers. A merchant with other channels validates them separately. As with every SAQ, the acquirer or payment brand decides whether a merchant may self-assess and whether SAQ P2PE is acceptable for its environment.

What are its objectives?

The questionnaire is designed to confirm that a merchant relying on a listed P2PE solution:

Uses the solution exactly as listed, with the provider, listing reference, device models and reassessment date recorded in Part 2e.

Has implemented every control in the P2PE Instruction Manual and keeps the terminals inventoried, inspected and staffed by trained personnel (9.5.1 to 9.5.1.3).

Protects any paper that carries account data and never keeps the card verification code after authorization (3.2.1, 3.3.1.2, 9.4.1 to 9.4.6).

Maintains a security policy, an awareness program, oversight of third-party service providers and an incident response plan proportionate to its size (Requirement 12).

Attests the result each year through an executive officer signature in Part 3b and submits the SAQ and AOC to the acquirer.

Framework in Context

SAQ P2PE is the merchant-side counterpart of the PCI P2PE standard, under which the Council validates and lists solutions and their providers. Among the v4.0.1 SAQs it is the smallest form a card-present merchant can use; the other merchant questionnaires (A, A-EP, B, B-IP, C, C-VT and D) exist for other payment channels, and the SAQ Instructions and Guidelines document, republished with the v4.0.1 SAQs, explains their eligibility criteria and how to choose. A merchant whose solution loses its validation, or that introduces any other system that touches account data, falls out of SAQ P2PE eligibility and should ask its acquirer which form applies. The requirement text it reproduces is that of PCI DSS v4.0.1 (June 2024).

Common Framework Mappings

Merchants using a listed P2PE solution rarely run a large security program, but those that do map the Requirement 3, 9 and 12 items to it so that the same policies, device records and third-party files serve the PCI attestation and other reviews. The list below is indicative; the SAQ itself, the PIM and the solution listing are what the acquirer looks at.

Mapped frameworks include:

ISO 27001:2022

ISO 27002:2022

NIST CSF 2.0

NIST 800-53 Rev.5

PCI DSS 4.0.1

PCI P2PE Standard

PCI PIN Security Requirements

SOC 2