SAQ P2PE: Who Qualifies, What It Covers, and How to Confirm It

“Our processor said the terminals encrypt everything, so PCI is basically handled.” If you’ve heard some version of that, this guide is for you. Encrypted and PCI-listed are two different claims, and SAQ P2PE only follows from the second. Here’s who fits, what disqualifies you, and how to check your solution against the list before you attest to anything.

Who SAQ P2PE fits

SAQ P2PE was written for merchants who take cards in person and let a validated encryption solution do the heavy lifting. If any of these sound like your business, you’re in the right neighborhood:

• The counter-service business. A restaurant, salon, or retail store where every card is dipped, tapped, or swiped on terminals your processor supplied as part of a named P2PE solution, and nothing else in the business touches card data.
• The multi-location retailer. A chain that standardized on one listed P2PE solution across stores so clear-text card data never touches store networks, registers, or back-office systems.
• The practice that takes payment at the desk. A medical, dental, legal, or professional office using a bank-provided P2PE terminal for in-person payments, with no card numbers kept anywhere else.

The common thread: cards go into the validated solution, and your own systems never see a readable card number. When that’s genuinely your setup, SAQ P2PE is one of the lightest questionnaires a card-present merchant can honestly claim, because the validated solution absorbed most of the risk before it ever reached you.

The exact eligibility criteria

Per the PCI SSC SAQ Instructions and Guidelines for PCI DSS v4.0, SAQ P2PE is for merchants that meet all of the following:

• Your only card acceptance runs through a PCI SSC-listed P2PE solution. Every transaction, every location, every terminal. If cards also come in through a website checkout, a virtual terminal, or an old dial-out machine in the back room, SAQ P2PE alone doesn’t describe your environment.
• No electronic storage of cardholder data. Not in a database, a spreadsheet, an application log, or a call recording. This assumption runs through every reduced SAQ, and losing it generally lands you in SAQ D.
• No access to clear-text cardholder data. Nobody on your side can read unencrypted card numbers from the payment flow. The card is encrypted at the point of interaction, and decryption happens with the solution provider, away from your environment.

There’s an operating condition attached: use the solution the way it was validated. Listed solutions come with instructions from the solution provider covering how devices are received, stored, inspected, and returned. Following those instructions is part of what your eligibility rests on, not an optional extra.

The listing is the test, not the word “encryption”

Plenty of terminals encrypt card data in some fashion, and plenty of processors sell end-to-end encryption that has never been validated against the PCI P2PE standard. The encryption may be perfectly good security. It still doesn’t grant SAQ P2PE, because eligibility is tied to one specific fact: the solution appears on the PCI Security Standards Council’s list of validated P2PE solutions.

A listed solution has been assessed as a whole: the devices, how they’re managed, and how decryption is handled away from your environment. That end-to-end validation is what lets the card brands accept a much shorter questionnaire from you. No listing, no shortcut.

How to check your solution against the PCI SSC list

• Ask your processor or terminal vendor for the exact solution name. You want the solution name and solution provider as they appear on the PCI SSC listing, not the marketing name on your invoice. The two often differ.
• Look it up yourself. The PCI SSC publishes its list of validated P2PE solutions on its website. Confirm the solution is listed, not just the terminal hardware.
• Confirm you’re using it as validated. The right devices, deployed and handled per the solution provider’s instructions.
• Treat “it’s encrypted end to end” as unconfirmed. If your vendor can’t point to the listing, don’t claim SAQ P2PE. Ask your acquiring bank which SAQ actually fits your setup.

SAQ P2PE vs SAQ B-IP: the boundary that trips people

Both SAQs cover in-person, terminal-based acceptance with no electronic storage of cardholder data, which is exactly why they get confused. The qualifying test is different, and it’s worth getting right before you attest.

If your encrypting terminal turns out not to be part of a listed solution, you haven’t lost everything. A standalone, PTS-approved terminal with an IP connection to your processor points to SAQ B-IP. A standalone terminal that dials out over a phone line points to SAQ B. A payment-application system connected to the internet points to SAQ C. Each of those is still a reduced SAQ. They cover more of your own environment than SAQ P2PE does, because less of the risk was handed to a validated solution.

What disqualifies you

Four things take SAQ P2PE off the table, and the first one catches the most merchants:

• The solution isn’t on the PCI SSC list. Encrypted-but-unlisted setups typically point to SAQ B-IP or SAQ C instead, depending on the terminal type and connection. The security may be fine; the SAQ P2PE eligibility isn’t there.
• You store cardholder data electronically. A database, a spreadsheet, an app log, a call recording, card numbers sitting in an email inbox. Electronic storage generally moves you to SAQ D no matter what your terminals do.
• Someone on your side can access clear-text card data. If readable card numbers from the payment flow are available to your staff or your systems, the no-clear-text condition fails and SAQ P2PE doesn’t fit.
• You take cards another way too. A checkout on your website points toward SAQ A or SAQ A-EP, a third-party-hosted virtual terminal toward SAQ C-VT. Multiple channels can mean your environment spans more than one SAQ, and your acquiring bank confirms how to validate the whole picture.

What you answer, at a high level

We don’t quote question counts because they vary by SAQ version. The qualitative picture: a shorter SAQ covers fewer requirements, and SAQ P2PE sits at the short end for card-present merchants because the listed solution carries so much of the load. What remains is the part only you can do:

• Physical care of the devices. Keeping terminals deployed the way the solution provider instructs, knowing where each one is, and controlling who handles them.
• Keeping cardholder data out of your systems. The no-electronic-storage condition is yours to maintain. The solution encrypts the payment flow; it can’t stop someone from saving card numbers in a spreadsheet.
• Security policy basics. Who is responsible for what, written down, and actually followed.

That’s the trade at the heart of this SAQ: the solution provider proved the hard parts to an assessor so that your remaining obligations stay small, specific, and physical.

How to confirm SAQ P2PE is yours

Three checks, in order:

• Confirm the listing. Get the exact solution name from your processor or terminal vendor and verify it against the PCI SSC’s published list of validated P2PE solutions.
• Confirm with your acquiring bank. Eligibility criteria are defined by the PCI SSC, but your acquirer or the card brands confirm which questionnaire you submit and your validation level. Their acceptance is the one that counts.
• Sanity-check with the free check. About two minutes, likely SAQ on screen, no email needed to see the result. It’s indicative, not a QSA assessment. If you want an assessor’s formal read, a Qualified Security Assessor is the right call.

Frequently asked questions

Related guides