Does a PCI P2PE solution cut in-store PCI DSS scope for SAQ P2PE?
A PCI-listed point-to-point encryption (P2PE) solution can significantly reduce the number of PCI DSS requirements that apply to a merchant, but it does not remove PCI DSS entirely. SAQ P2PE applies only when every eligibility condition holds at the same time, so a merchant with card-present terminals should not assume a P2PE deployment automatically qualifies. The answer depends on four things: the terminal fleet, whether any clear-text account data reaches a computer system, whether mail or telephone orders are keyed into the same terminals, and whether the P2PE listing is still current. Start by inventorying every device that accepts a card, then match each one to the solution provider's P2PE Instruction Manual (PIM). Confirm that the terminals are the validated P2PE devices named in the listing, and that no card data is written to a POS application, a log, a spreadsheet or a back-office system in clear text. Check the listing status of the solution itself, because an expired validation means the solution is no longer considered validated and the merchant should ask its acquirer or payment brand whether SAQ P2PE is still acceptable.
Implementing the PIM is a merchant task, not a one-time purchase. Each control the manual assigns to the merchant must be in place and evidenced, and the merchant's internal team, its terminal provider and any implementation partner each prepare part of that evidence. A partner can help map the PIM controls to the merchant's environment, document the terminal inventory and test the data flows, but the merchant owns the controls and the partner does not issue the validation. The merchant should also confirm with its acquirer which validation it must complete. Only the acquirer or the payment brands decide whether SAQ P2PE applies, and an assessor or the merchant completes the Attestation of Compliance that goes with it. Ask the acquirer in writing to confirm eligibility for the specific solution, terminals and sales channels before scoping the work, and record the answer with the evidence file.
How a merchant moves to P2PE and SAQ P2PE step by step
The sequence takes a merchant from confirming that SAQ P2PE fits its payment channels to a signed Attestation of Compliance, with each phase producing a documented output that an acquirer or assessor can check.
Confirm SAQ P2PE eligibility with the acquirer
Start by mapping every way the business takes card payments, including card-present terminals, mail order and telephone order. Then ask the acquirer, and where needed the payment brands, whether SAQ P2PE is the right questionnaire for those channels. Only in-store terminals and keyed entry into those same terminals can qualify. Output: a written record of the acquirer's view, the channels in scope and the SAQ to be used. Keep it with the validation file.
Select a P2PE solution and check its listing
Choose a solution that appears on the PCI SSC's list of validated P2PE solutions. Confirm the specific listing covers the terminal models, the payment flows and the solution provider you intend to use. Check the listing status on the day you contract, because a solution listed as expired is no longer treated as validated under the P2PE Program Guide. Output: a dated screenshot or record of the listing and a written confirmation from the acquirer that the solution is acceptable.
Deploy the listed terminals
Install and configure the terminals exactly as the solution provider specifies, in the locations and network segments the listing describes. Keep terminals in the physical state the P2PE Instruction Manual requires, including tamper checks and controlled storage before deployment. Confirm the device inventory matches the serial numbers recorded at receipt. Output: a deployment record listing each terminal, its location, its inspection history and the person responsible for it.
Implement every P2PE Instruction Manual control
Work through the solution provider's P2PE Instruction Manual line by line and assign each control to an owner inside the merchant, such as store operations, IT or the finance team. Many controls cover device inspection, staff training, access to terminals and incident response, and the merchant must implement them in its own environment. SAQ P2PE requires every control to be in place, so partial implementation does not qualify. Output: a PIM control matrix with an owner, evidence and a completion date for each control.
Remove clear-text account data paths
Review every computer system, file share, email account, spreadsheet, log and paper process that could receive card numbers. SAQ P2PE does not allow clear-text account data on any computer system, so any path that captures card data outside the terminal must be removed or redesigned. Run a discovery sweep of the environment and document what you found and how each path was closed. Output: a signed statement of data flows showing that account data reaches only the P2PE terminals, supported by the discovery results.
Confirm no mobile or non-listed encryption overlaps
Check whether any mobile acceptance, software-based PIN entry or other encryption product shares the environment. Mobile Payments on COTS, Software-based PIN Entry on COTS and Contactless Payments on COTS solutions cannot qualify for P2PE approval, so their presence must be handled separately in the validation. Confirm with the acquirer how any non-listed encryption product is treated. Output: a written inventory of every payment device and encryption product in the environment, with its validation status.
Complete the SAQ P2PE and Attestation of Compliance
Complete the SAQ P2PE using the PCI SSC template, answering each question from the evidence gathered in the earlier phases. Have a person with authority in the organization review and sign the Attestation of Compliance, and submit it to the acquirer or payment brand as they require. Only the signed AOC is validation, not a certificate or a logo. Output: a signed SAQ P2PE and AOC, a dated evidence file, and a schedule for the annual repeat of the validation.
What must be true before a merchant completes SAQ P2PE
SAQ P2PE only holds up if the solution, the environment and the acquirer all line up. The five checks below are the conditions a merchant should confirm before signing the questionnaire and its Attestation of Compliance. Each one produces evidence that an assessor or acquirer can ask to see.
Listing is current
Confirm that the P2PE solution and its components appear as validated on the PCI SSC listing, not as expired. A solution shown as expired is no longer considered validated under the P2PE Program Guide, so the merchant should ask the acquirer or payment brand whether SAQ P2PE is still available. Save a dated copy of the listing entry and the acquirer's written answer. Repeat the check at each annual validation, because listings change.
Every PIM control owned
The P2PE Instruction Manual lists the controls the merchant must implement, and SAQ P2PE requires all of them. Assign a named owner to each control, such as terminal inventory, tamper checks, or staff handling of devices, and keep records showing the control is operating. Missing owners are the most common cause of a control being skipped during review.
No clear-text account data
Verify that no computer system in the merchant environment holds clear-text account data. This includes point-of-sale back offices, reporting databases, email, shared drives, and application logs, which often capture card numbers by accident. Run a discovery scan, review log settings, and record the results with the date and scope of the search. Any finding must be removed and investigated before the questionnaire is signed.
Keying limited to P2PE terminals
Mail order and telephone order merchants qualify only if card data is keyed directly into P2PE-validated terminals. Check that agents cannot key card numbers into a CRM, spreadsheet or softphone recording tool. Document the call and order workflow, and keep a sample of order records showing that data entered only through the terminal. Staff procedures should state this rule in writing.
Acquirer confirms eligibility
Ask the acquirer or payment brand in writing whether the merchant's solution, channels and environment qualify for SAQ P2PE. The SSC directs merchants to their acquirer for this decision, and the acquirer's answer determines which questionnaire the merchant may use. Keep the written confirmation with the AOC, and ask again if the solution, terminal fleet or payment channel changes.
What happens with expired P2PE listings and non-listed encryption
A P2PE solution whose listing has expired is no longer treated as validated under the P2PE Program Guide, so a merchant that relies on it cannot assume SAQ P2PE still applies. The first step is to ask the acquirer or the payment brands in writing whether SAQ P2PE remains available for the merchant's terminals and processing setup. Do not decide this from the solution provider's marketing or from an old attestation on file. Check the Council's listing for the solution and its version, record the expiry date, and keep the acquirer's answer with the validation evidence. If the answer is no, the merchant will usually need a different SAQ or a ROC, and the work to change that should start before the next validation cycle, not after it.
Encryption that is not PCI-listed can still reduce how much of the environment a merchant must protect, but it does not qualify the merchant for SAQ P2PE. SAQ P2PE depends on a validated, listed solution and on every control in the solution provider's P2PE Instruction Manual being in place. A custom or unlisted encryption product cannot meet that test, even if it is strong and well run. The Council recommends PCI-listed P2PE solutions and directs merchants with non-listed solutions to consult their acquirer or the payment brands, who decide what evidence and which questionnaire they will accept. Ask for that decision in writing, because the merchant carries the validation burden in that case.
The practical cost is usually in re-validation and reassessment rather than in the encryption itself. Merchants should budget for the time their internal staff, their solution provider and their assessor need to document the unlisted design, map each data flow and show which systems still touch clear-text account data. Moving to a listed solution is often the cleaner route, and the questions to put to a provider are whether the solution is currently listed, which versions the listing covers, and when it expires. Any outside consultant should be asked to separate advice on the design from the validation itself, since only the acquirer, the brands and the assessor decide what is accepted.
Which validation path fits a merchant's in-store environment
This table compares three routes for in-store card acceptance: a PCI-listed P2PE solution with SAQ P2PE, a non-listed encryption solution validated with the acquirer's agreement, and standard in-house card handling. Read each column to see when the route fits, what the merchant still owns, and what to confirm before relying on it.
| Decision point | PCI-listed P2PE with SAQ P2PE | Non-listed encryption or standard in-house handling |
|---|---|---|
| When it fits | Card-present or keyed payments taken only on terminals from a validated, currently listed P2PE solution, with no clear-text account data on any computer system | Environments that use encryption the Council has not listed, or that handle card data on general systems and need a broader SAQ or a ROC |
| Reduction in requirements | Significantly fewer PCI DSS requirements apply, though PCI DSS does not fall away entirely | Little or no reduction from the encryption alone; scope depends on where clear-text data can reach systems |
| What the merchant still owns | Implementing every control in the solution provider's P2PE Instruction Manual, protecting terminals, and keeping the environment free of clear-text account data | Validation of all in-scope requirements, the scoping decision, and proof that the encryption is effective in the real environment |
| Listing status to check | Confirm the solution is listed and not shown as expired, since expired validations are no longer treated as validated | Confirm the Council's position on the solution and whether the acquirer accepts it for reduced validation |
| What to confirm with the acquirer | Whether the merchant may use SAQ P2PE for this solution and any expiry or renewal dates that affect eligibility | Which SAQ or ROC the acquirer requires, whether the non-listed solution is acceptable, and what evidence they will request |
| Terminal and device handling | Terminals must be those covered by the listed solution; any change in device or firmware should be checked against the P2PE Instruction Manual | Device inventory, tamper checks and key management remain in scope and must be documented by the merchant |
| Mobile and software acceptance | MPoC, SPoC and CPoC solutions cannot qualify as P2PE, so they need their own validation route | Mobile or software payment apps need their own standard validation and cannot be counted as P2PE |
| Ongoing effort | Annual confirmation that the P2PE solution remains listed and that the merchant still follows the manual | Recurring scope confirmation, evidence collection and assessment against the chosen SAQ or ROC each year |
How P2PE differs from MPoC, SPoC and CPoC
A PCI-listed point-to-point encryption solution covers the payment terminals in a merchant's store. Card data is encrypted inside the terminal at the point of interaction and is decrypted only at the solution provider's secure environment, so clear-text account data does not reach the merchant's systems. This is the route that can lead to SAQ P2PE, provided the merchant uses only validated P2PE terminals for account data and follows the solution provider's P2PE Instruction Manual. The listing belongs to the solution, not to the merchant, and it is the solution's validation that the merchant relies on.
- Listed solution required: Only a PCI-listed P2PE solution supports SAQ P2PE eligibility, so the listing must be current for the specific solution in use.
- Terminal and manual alignment: The merchant must implement every control in the Instruction Manual, including terminal inspection and device management steps.
- No clear-text data on computers: Any computer system that receives account data in clear text takes the merchant outside SAQ P2PE.
- Keyed entry: Mail and telephone order merchants can qualify only when they key data into those validated terminals.
Before relying on a P2PE listing, confirm with your acquirer that the solution and version you run are still valid.
MPoC is the PCI SSC standard for accepting payments on commercial off-the-shelf mobile devices, such as a phone or tablet with a card reader or tap-to-pay capability. Its approval is separate from P2PE, and an MPoC solution cannot qualify for P2PE solution approval. A merchant that accepts payments on a phone or tablet is not validated because a P2PE terminal sits elsewhere in the store. Each acceptance channel needs its own check against the standard that governs it.
- Separate approval path: MPoC solutions are assessed under their own standard, not under the P2PE Program Guide.
- Consumer device risk: The security model depends on the solution's software and device controls, which the merchant must confirm rather than assume.
- Shared environment: An MPoC device may sit on the same network as P2PE terminals, which affects scoping decisions.
- Validation change: Adding mobile acceptance can change the SAQ that applies, because the merchant now handles a channel that P2PE does not cover.
Ask your acquirer which validation applies to each mobile acceptance product you deploy and whether the solution is listed for that purpose.
SPoC covers software-based PIN entry on commercial off-the-shelf devices, where the PIN is entered on a consumer-grade device rather than a dedicated PIN pad. Like MPoC, it is a separate standard, and SPoC solutions cannot qualify for P2PE approval. The distinction matters most for merchants that want to accept PIN debit on tablets or handheld devices. Validation for the solution does not transfer to the merchant's whole payment flow, so the merchant still assesses its own environment.
- Not a P2PE route: A SPoC solution does not supply P2PE solution validation, even when it encrypts PIN data.
- Key management scope: Keys used in software PIN entry are governed by their own requirements, and the solution's listing does not cover the merchant's key handling.
- Device environment: SPoC devices can share a merchant environment with P2PE terminals, but the two must be assessed as separate payment channels.
- SAQ implications: Introducing software PIN entry can move a merchant out of the SAQ it used for P2PE terminals.
Confirm with the solution provider exactly which SPoC listing and version applies to your devices and document that in your scope description.
CPoC covers contactless payment acceptance on commercial off-the-shelf devices, such as a phone or tablet that reads a card or device tap. It sits under its own PCI SSC standard and, like MPoC and SPoC, cannot qualify for P2PE solution approval. Merchants that combine contactless COTS acceptance with P2PE terminals in one location need to treat each channel as its own validation question, and should not assume that a P2PE listing covers the contactless acceptance path.
- Separate standard: CPoC solutions are approved under their own requirements, independent of the P2PE Program Guide.
- Mixed locations: Stores that run both P2PE terminals and CPoC devices need a scope description that names each channel.
- Network sharing: CPoC devices can connect to the same merchant network as P2PE terminals, so segmentation and data flow must be documented.
- SAQ selection: Adding contactless COTS acceptance may disqualify SAQ P2PE for the location, and the merchant must select the SAQ that matches all channels.
Before you deploy a mixed model, ask your acquirer which SAQ applies to the combined environment, and record the answer with your validation documents.
SAQ P2PE is available only when every account data path in the merchant's environment runs through validated P2PE terminals and the merchant meets the eligibility conditions. Adding MPoC, SPoC or CPoC acceptance introduces a channel that the P2PE pathway does not cover. The merchant then has to assess the environment against a different questionnaire or a Report on Compliance, depending on its acquirer's requirements. The practical risk is that a merchant keeps filing an SAQ P2PE after a new channel goes live, which would make the attestation inaccurate.
- Re-check eligibility: Review SAQ P2PE eligibility whenever a new acceptance channel, device type or location is added.
- Scope description: Document each channel, its device, its solution listing and the systems it touches.
- Shared networks: Segment or document any shared network between P2PE and COTS devices, since shared paths affect what is in scope.
- Acquirer confirmation: Confirm the required SAQ or ROC with your acquirer or payment brand before the change goes live.
- Attestation accuracy: Update the Attestation of Compliance to match the actual environment.
Before any channel change, confirm the eligibility conditions in the current SAQ P2PE and ask your acquirer which questionnaire applies to the combined environment.
Who owns P2PE controls and who prepares the evidence
A P2PE validation splits work across four parties: the merchant, the P2PE solution provider, an implementation partner and the acquirer or payment brands. Each one owns a different part of the outcome, and only the entity that signs the Attestation of Compliance can state that the merchant is compliant.
The merchant owns its environment
The merchant stays responsible for its own store, staff, terminals and the SAQ it files. It decides who can handle devices, keeps the terminal inventory current, and confirms that no clear-text account data reaches any computer system it operates. Before signing, the merchant should walk through each P2PE Instruction Manual control with its own staff and record how each one is met. The merchant answers for the SAQ it signs, even when others prepared the evidence.
The P2PE solution provider sets the rules
The solution provider publishes the P2PE Instruction Manual (PIM), which lists the controls the merchant must implement around its listed components. Listed devices, applications and key management elements come from that solution, so the merchant cannot change them without affecting eligibility. Ask the provider for the current PIM version, the listing reference and the date its validation is due to expire.
The implementation partner prepares evidence
An implementation partner such as DeployOpen can prepare systems, configuration records and evidence inside the merchant's own environment. That work covers network segmentation checks, terminal deployment records, staff procedures and log samples that the merchant then reviews and owns. The partner does not complete the SAQ, sign the AOC or issue any validation. Agree the scope, deliverables and evidence list in writing before work starts.
The acquirer and payment brands confirm eligibility
The acquirer, and where relevant the payment brands, confirm whether a merchant may file SAQ P2PE and whether a given P2PE listing is still valid. Ask them directly when a listing shows an expired validation or when the solution is not PCI-listed. They also run any enforcement programs and decide which entities must validate. Their answer should be in writing and kept with the SAQ evidence.
Only the signing entity completes the AOC
The Attestation of Compliance is completed and signed by the entity being validated, using the official PCI SSC template. A certificate, a consultant's letter or a provider's listing does not replace it. Before signing, the merchant should check that every answer matches the evidence it holds and that the AOC covers the right entity and dates. Assessors and acquirers may ask to see the supporting records.
Why the KMO Standard matters for P2PE key management
The PCI Key Management and Operations (KMO) Standard v1.0, published on 14 September 2026, sets requirements for managing the cryptographic keys that protect PINs, account data and other sensitive assets across their full lifecycle. For a merchant using a P2PE solution, the keys that matter most are the ones that encrypt card data inside the payment terminal and the keys that decrypt it at the solution provider's decryption environment. The standard initially consolidates PIN and P2PE key management into one set of requirements and addresses cloud-based and remote hardware security modules, which are the deployment models where a provider's key handling is most likely to differ from what a merchant assumed when the solution was first listed.
A merchant does not operate those keys, but the merchant's SAQ P2PE eligibility depends on the solution being validated and on the merchant following every control in the P2PE Instruction Manual. Before the next validation cycle, ask the solution provider in writing which KMO requirements apply to the specific components you use, whether the listing has been or will be updated against the standard, and what changes you must make at the terminal, store or integration level. Also ask how the provider will notify you of any change to key custody, such as a move to a cloud-hosted HSM, because that change could affect your evidence even if your own configuration is unchanged.
Confirm the effective date for your deployment with your provider and your acquirer or payment brand, since the date that applies to a given entity is set by the programs that rely on the standard rather than by the publication date alone. Record the provider's answers, the listing reference and any dated commitments in your evidence file so an assessor can see who was responsible for key management and when that responsibility changed. If the provider cannot answer these questions, treat it as a risk to plan for: an unvalidated or expired P2PE solution can remove the basis for SAQ P2PE altogether, so the merchant may need to re-scope its validation and talk to its acquirer early.
Questions merchants ask about P2PE and SAQ P2PE
Does using a P2PE solution take my business out of PCI DSS entirely?
No. A PCI-listed point-to-point encryption solution can significantly reduce the number of PCI DSS requirements that apply to a merchant, but it does not remove PCI DSS entirely. Your business still completes a validation, still answers for the systems you control, and still has to meet the requirements that the encryption solution does not cover, such as policy, access management, and monitoring of your own environment. The reduction comes from keeping clear-text card data off your systems. Confirm with your acquirer which validation type applies to your payment channels, since that determines the remaining work.
Can a merchant self-assess with SAQ P2PE?
Yes, if the merchant meets the eligibility conditions of SAQ P2PE. The merchant completes the questionnaire and its Attestation of Compliance itself rather than filing a Report on Compliance with a Qualified Security Assessor. To qualify, the merchant must process account data only through payment terminals from a validated, PCI-listed P2PE solution, keep no clear-text account data on any computer system, and implement every control in the solution provider's P2PE Instruction Manual. Mail and telephone order merchants can qualify only if they key card data into those same terminals. Whether your acquirer accepts the questionnaire for your volume and channel is a separate decision that it makes.
What work does a merchant still have to do after deploying a P2PE terminal?
The merchant has to implement every control in the P2PE Instruction Manual that applies to its environment, and it has to be able to show that it did. The manual describes duties such as terminal inventory and tamper inspection, controlling who can access and replace devices, handling terminals that are removed from service, and keeping the device and solution documentation current. The merchant also still owns its network segments, its office and back-office systems, its staff training, and its written policies. Before deployment, ask the solution provider for the manual and build a checklist from it, then assign an owner to each item. Gaps found during preparation are cheaper to fix than gaps found by an acquirer or assessor.
What happens if my P2PE solution listing has expired?
A P2PE solution listed as having an expired validation is no longer considered validated under the P2PE Program Guide, so you should not assume SAQ P2PE still applies to your environment. Ask your acquirer or payment brand whether you may continue to use SAQ P2PE with that solution, and whether they expect a different validation in the meantime. Check the PCI SSC listings for the current status of your solution and its components, and ask the solution provider for its plan to revalidate or replace the solution. Keep written records of each conversation, because the acquirer's answer, not the listing alone, will guide your next steps.
Does encryption that is not PCI-listed qualify for SAQ P2PE?
No. SAQ P2PE depends on a validated, PCI-listed P2PE solution. A merchant may use an encryption solution that the PCI SSC has not listed to reduce its validation effort, but that choice does not make the merchant eligible for SAQ P2PE. The PCI SSC recommends PCI-listed P2PE solutions and tells merchants with non-listed solutions to consult their acquirer or the payment brands. Expect the validation route to depend on how the encryption is designed, how keys are managed, and how the acquirer assesses the risk. Ask the acquirer in writing which questionnaire or assessment it will accept before you finalize the design, since changing the architecture later is costly.
Who decides whether my P2PE setup is eligible for SAQ P2PE?
Your acquirer and the payment brands decide, not the PCI Security Standards Council. The Council maintains the standard and the P2PE listings, but it does not enforce compliance or impose penalties, and the payment brands decide which entities must validate and run any enforcement programs. In practice, the acquirer tells you which questionnaire it accepts and what evidence it expects. Start that conversation early, describe your channels and terminal fleet in writing, and ask for the answer in writing. An independent Qualified Security Assessor can help you review eligibility, but the acquirer's acceptance determines whether the validation counts for your merchant account.
How DeployOpen prepares in-store environments for P2PE evidence
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the systems around in-store payment environments. Our role is to prepare systems, controls and evidence for a P2PE-based validation, while the merchant owns its controls and an independent assessor or the acquirer determines what it accepts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which systems can still see clear-text account data, so the written scope shows what sits outside the P2PE boundary.
- We confirm the P2PE solution is listed and not shown as expired before any build work begins, and flag open questions for the acquirer.
How we build
- We implement the controls the P2PE Instruction Manual assigns to the merchant, within the client's own in-store and back-office systems.
- We configure and harden the non-payment systems that connect to terminals, so no clear-text account data is stored on any computer system.
- We test the configuration against the written scope and record gaps, so the client can remediate them before an assessment.
How we hand over
- We deliver a documented record of the scope, system inventory, data-flow notes and the controls implemented under the P2PE Instruction Manual.
- We prepare the evidence folder an independent assessor will ask for, but we do not issue reports, attestations or certificates.
- Handover includes a list of responsibilities that stay with the merchant, such as staff training and annual scope confirmation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the fixed-scope work.
- We can review changes to terminals, network paths or the P2PE solution that could affect the merchant's validation.
- Questions about SAQ eligibility or acquirer requirements stay with the client, its acquirer and its assessor, and we help prepare the evidence for those conversations.
