PCI DSS for retail POS environments: what applies and why

Which PCI DSS requirements apply to retail POS, and how the answer changes by setup

For a retailer or restaurant group with terminals in every location, PCI DSS applies to each card-present terminal as part of the cardholder data environment (CDE), and the validation route depends on how those terminals and the store networks are designed, not on the number of stores. A chain with two hundred locations running standalone PIN pads on an IP link may validate under a much shorter questionnaire than a single site running a full POS server with back-office connections. The deadline usually comes from an acquirer or a contract, so the first task is to confirm which entity sets the validation level and due date. The payment brands, not the PCI SSC, decide who must validate and by when, and the PCI SSC does not enforce compliance. PCI DSS v4.0.1 is the only active version, so any gap analysis should be written against it. The organization owns its controls and its evidence. An implementation partner can prepare systems, device inventories, network segmentation, and documentation, but only a Qualified Security Assessor (QSA) or an assessor accepted by the acquirer can issue a Report on Compliance or sign the Attestation of Compliance that goes with a Self-Assessment Questionnaire. Confirm with the acquirer which assessor route it accepts before any work starts, because an attestation from the wrong party can be rejected. No fee or duration figures are supplied for this page, so ask any proposed provider for a written, fixed scope that lists the locations, device models, network paths and assessor responsibilities covered. To start the scoping work, list every store device that reads a card, including the PIN pads, POS terminals, and any mobile or tethered readers, and record for each one whether it is PTS-approved, how it connects, and whether it can reach any other merchant system. Those answers decide which questionnaire fits the setup. Store locations that share one network, or a POS application that sits on the same host as the internet connection, change the answer quickly. Map those paths before choosing an SAQ, because the questionnaire you pick must match the network you actually run.

What a retail POS PCI DSS program costs and who gets paid

This table compares each cost component of a card-present PCI DSS program by who is paid, whether the cost is one-time or recurring, and what drives it up. Use it to structure your request for written quotes, since no prices are published here and each component should be priced separately.

Cost component	Who is paid	One-time or recurring	What drives the cost
Assessor fee for a ROC or SAQ review	Qualified Security Assessor (ROC) or independent assessor reviewing an SAQ	Recurring annually for validation	Number of locations, POS architecture complexity, and whether you file a ROC or an SAQ
Network segmentation and device management work	Implementation partner, for scoped work on POS network isolation and device configuration	Mostly one-time, with periodic review	Number of POS lanes, flat versus segmented store networks, and existing firewall and VLAN maturity
PTS-approved device purchase or lease	Terminal vendor or leasing provider	Purchase is one-time; leases recur	Device count, refresh cycle, and PTS approval expiry dates that force replacement
P2PE solution fees	P2PE solution provider	Usually recurring, often per device or per transaction volume	Device count, gateway and processor integration, and whether the solution is PCI-listed for your device model
Quarterly ASV scans where required	Approved Scanning Vendor	Recurring quarterly	Number of external IP addresses in scope and whether your setup needs scans at all
Internal staff time for device inspections and training	Your own employees (cost is internal payroll)	Recurring	Store count, inspection frequency set in your targeted risk analysis, and staff turnover

What makes retail POS validation cheaper or slower

Most of the effort in a retail validation comes from how much of the store estate sits inside the cardholder data environment. The cards below cover the decisions that widen or narrow that scope, and the checks to make before choosing an assessment path.

Complex POS versus locked-down terminal

A standalone terminal that dials out or connects only to the processor carries far fewer controls than a POS system running a full operating system, back-office software and inventory tools. Every added application, service and admin interface on the register is another component the assessor will examine. Ask your acquirer and assessor which of your devices count as payment applications and which are simply terminals, and document the boundary before you pick an SAQ.

Single-store LAN isolation

The number of locations and whether they share a network changes the scope more than almost any other factor. A single store whose registers, back-office PCs and Wi-Fi guest network share one LAN puts everything on the same side of the boundary. Confirm that payment devices sit on a segment that other store systems cannot reach, that no other location connects to it, and that guest and staff Wi-Fi are separated by enforced firewall rules rather than by network naming.

Clear-text output over the Internet

If a POS system sends card data in clear text across the Internet, even briefly, the assessor will treat the whole path as a strong cryptography problem. Check every outbound route, including reporting exports, email receipts, cloud sync and remote support tunnels. Where clear-text output exists, the fix is to encrypt it before transmission or to remove the path, and both changes should be verified in the transmission traffic itself.

PTS approval and device currency

Devices carrying PTS approval that has expired create a validation and acquirer problem even when the hardware works. Record the make, model, firmware and PTS listing for every terminal, and check the listing when you deploy a device. Ask your acquirer whether expired devices are acceptable under its rules, because some payment brands set their own requirements for these devices.

P2PE in place or not

A PCI-listed point-to-point encryption solution that covers the full path from card read to decryption outside the merchant environment can significantly reduce the number of requirements that apply to a store. Validation cost falls because the POS network carries encrypted card data rather than clear text. Confirm the solution is on the PCI-listed inventory, that the terms of your deployment match the listing, and that you have not added components the listing does not cover, such as a PC that touches decrypted data.

Third-party remote access

Remote support from a POS vendor, integrator or managed network provider is one of the most common reasons a small store ends up in a larger scope. Each remote session that can reach payment devices or the store LAN must be authenticated, time-limited, logged and only enabled when needed. Ask who holds remote access credentials, how sessions are recorded, and whether the vendor is itself responsible for protecting the connection under its own assessment.

Which SAQ or validation route fits a card-present environment

SAQ B suits merchants whose card acceptance is limited to imprint machines or standalone dial-out terminals, with no electronic storage of account data. Eligibility depends on the payment flow: the merchant processes cards only through the terminal and does not keep card data on any system. The questionnaire assumes the terminal does not connect to other merchant systems and that the connection to the processor is a dedicated line rather than a shared network.

Terminal type: Imprint machines or standalone dial-out terminals, with no IP connection to the processor.
No electronic storage: Card data is not stored in any electronic form, including paper-to-digital copies.
Isolation: The terminal does not share a network with other merchant systems.
Attestation: The merchant completes the SAQ and an Attestation of Compliance on official PCI SSC templates.

Confirm with your acquirer that SAQ B is the correct questionnaire for your devices and that your terminal model and connection still fit the eligibility text after any change in hardware or line type.

How to protect card-present devices from tampering and substitution

Requirement 9.5.1 asks you to keep a device list, inspect card-present payment devices on a defined schedule, and train staff to spot tampering or substitution. Any device that captures card data through physical interaction, whether swiped, tapped or dipped, falls under it. For a store or restaurant, that usually means every countertop terminal, mobile handheld and unattended kiosk. The device list is the anchor for the rest of the work. It should record each device's make, model, serial number, location, assigned owner and status, so an assessor can match what is on the list to what sits on the counter. Ask your acquirer and terminal provider which serial and model fields they already hold, and reconcile those records against your own before the first assessment.

The inspection frequency and method are not fixed by the standard. You set them through a targeted risk analysis under Requirement 12.3.1, and Requirement 9.5.1.2.1 made that analysis mandatory on 31 March 2025. The analysis should consider how many devices you run, how many staff and customers touch them, whether devices sit in unsupervised or high-traffic areas, and how often your payment vendor has reported tampering in similar estates. Document the chosen interval, the inspection method (for example, checking seals, housings, cable runs and displayed serial numbers against the list) and the person responsible. An assessor will test whether the interval you wrote down is the one you actually follow. Also confirm with your team whether a documented exception process exists for devices that are offline, in storage or replaced mid-cycle.

Devices do not need to be bolted down or tethered to meet Requirement 9.5, according to PCI SSC FAQ 1281, so your choice of mounting is a business and operational decision. Mobile handhelds used at tables or curbside are compliant if the list, inspections and training are in place. What assessors look for is evidence. A dated inspection record should show the device serial number, the person who inspected it, what was checked, the result and any follow-up. A device inventory should show the same serial numbers the terminal provider reports. Staff training records should show who was trained, when and on what signs of tampering. Confirm with your assessor, before you rely on this approach, which records they will accept as the primary evidence in your environment.

How a retail POS assessment runs from scoping to attestation

This sequence takes a store or restaurant group from confirming its validation obligations to an Attestation of Compliance accepted by its acquirer, with each phase producing a documented output that the next phase depends on.

Confirm validation level and acquirer requirements
Start by asking your acquirer which validation level applies to your business and what they require you to submit and by when. Payment brands, not the PCI SSC, set these obligations and run any enforcement, so the acquirer's written answer is the authority for your deadline. Ask whether they accept a self-assessment or require a Qualified Security Assessor (QSA) report, and whether they have a position on expired PTS devices. The output is a short written record of your validation level, required document type, submission route and contact, which sets the scope of every later step.
Map terminals, networks and cardholder data flow
Inventory every payment terminal, point-of-sale computer, router, switch, Wi-Fi network and connected back-office system at each location, and record which ones touch card data or connect to the payment path. Draw the cardholder data flow from the card swipe, tap or dip through the terminal, any POS software, the network and the processor connection. Identify where clear-text output leaves the store and whether terminals or POS systems store sensitive authentication data. The output is a current network diagram, a data-flow diagram and a device list that a technical reviewer has checked against the actual store configuration.
Select the SAQ or ROC for your environment
Choose the self-assessment questionnaire that matches your architecture, such as SAQ B, B-IP, C or P2PE, or a Report on Compliance if your validation level or acquirer requires one. Eligibility depends on facts from the previous step: whether terminals are standalone, whether a POS system shares a LAN with the internet connection, and whether any account data is stored electronically. If your architecture does not fit any questionnaire, the ROC route is the likely choice. The output is a documented selection rationale, signed off by the person accountable for payments, that explains why the chosen document fits your environment.
Close gaps in devices, isolation and encryption
Work through the gaps the mapping exposed. Confirm each payment device is on a PTS listing and not past its approval expiry, and resolve any device your acquirer has flagged. Set up a tamper and substitution process covering device lists, risk-based inspection frequency defined in a targeted risk analysis, and staff training. Isolate the POS network from guest Wi-Fi, back-office systems and other locations, and encrypt any clear-text output before it crosses the internet. Where a P2PE solution is in use, confirm it is PCI-listed and that your deployment matches the listing. The output is a remediation log that records each gap, the fix applied, the owner and the date it was verified.
Collect and retain evidence for each requirement
Gather the records that show each applicable requirement is met as it operates, not only as designed. Typical items include the device inventory, completed inspection logs, tamper-awareness training records, firewall and network configuration exports, vendor and processor responsibility documents, and the risk analysis that sets inspection frequency. Confirm each item is dated, owned and stored where the assessor can retrieve it. The output is an evidence folder indexed to the questionnaire or ROC requirements, so that every answer can be traced to a document.
Complete the SAQ or have the QSA assess
If you use a self-assessment questionnaire, the merchant completes each answer against the evidence and must be able to explain every answer that relies on a compensating control or a customized approach. If you use a ROC, a Qualified Security Assessor tests the environment, interviews staff, examines configurations and samples evidence before writing the report. In either case, an internal reviewer should challenge the answers before submission. The output is a completed SAQ or ROC, with the assessor's independent conclusion where a QSA is involved.
Submit the AOC to the acquirer
Complete the Attestation of Compliance that matches your questionnaire or report, confirm its details match the scope described in your data-flow diagram, and submit it through the route your acquirer specified in the first step. Keep the signed attestation, the questionnaire or ROC, and the supporting evidence on file, and check whether your acquirer expects a certificate or other document, since PCI SSC guidance says certificates are not recognized as validation. The output is an accepted submission on record and a calendar entry for the next validation cycle, along with a plan for re-validating when stores, terminals or networks change.

What must be in place before the assessor arrives

An assessor will test the card-present environment from the outside in: which devices touch card data, how they are protected, and whether the network keeps them apart from everything else. The six items below are the evidence that answers those questions, and each one can be checked internally before anyone from outside the business looks at it.

Current network and data-flow diagram

The assessor starts with a diagram showing where card data enters, moves and leaves the store, from each terminal through the POS server, the processor link and any back-office system. Check that the diagram matches the live network, not the one drawn at installation. Confirm that every device on the diagram is also on the device inventory, and that any new register, kiosk or Wi-Fi access point added since the last review has been drawn in.

Device inventory with PTS status

Maintain a list of every payment terminal with its make, model, serial number, location, connection type and PTS approval status. Compare each approval against the PCI SSC listing, because some payment brands restrict devices whose approval has expired, and your acquirer can tell you whether a specific device is affected. Record the device owner, so that replacements and retirements are traced rather than discovered during the assessment.

Documented inspection plan

Requirement 9.5.1.2.1 expects the frequency and type of terminal inspections to come from a targeted risk analysis, so the plan must show how the interval was chosen. Write down who inspects, what they check (seals, cable routes, unexpected attachments, serial numbers against the inventory), and how findings are logged and escalated. Ask whether your risk analysis records the reasoning behind each decision, because an interval with no documented basis is a common assessor finding.

Staff training records

Requirement 9.5.1 expects store staff to be trained to recognize tampering and device substitution, so the assessor will ask for the training content and proof that each relevant employee completed it. Records should show names, dates, the version of the material used, and what happens when a new hire or seasonal worker joins the team. Check that the training covers the specific signs of substitution at your sites, such as a stranger claiming to be a technician or an unannounced device swap.

Segmentation evidence between POS and guest Wi-Fi

Where POS systems share a LAN or Wi-Fi network with guest access, corporate laptops or smart devices, the assessor will test whether those networks are separated from the cardholder data environment. Collect firewall or switch rule sets, VLAN configuration and a segmentation test result that shows traffic from the guest network cannot reach POS hosts. If your SAQ selection depends on the POS network being isolated, confirm that isolation with your QSA or acquirer before you assume it.

Proof that terminals do not store sensitive data

Assessors check that terminals and POS software are not configured to store sensitive authentication data after authorization, and that any clear-text output leaving the store is encrypted before it crosses the Internet. Gather configuration exports or vendor attestations for each device model, plus a sample of the terminal and POS logs or storage locations you checked yourself. Note any device that writes receipts or journals to local storage, since those files need the same scrutiny.

Who owns controls, who prepares evidence, and who attests

The retailer remains accountable for PCI DSS compliance in every store and restaurant. Its own staff make the decisions that assessors test: which terminals are in use, who may touch them, how they are inspected, and whether the business keeps any stored account data. Because PCI DSS does not enforce itself, the acquirer and payment brands set the validation expectations that the retailer must meet, so the retailer also owns the relationship with its acquirer.

Controls ownership: Store operations, IT and finance approve the policies, the device inventory and the risk analysis that drives device inspection frequency under Requirement 9.5.1.2.1.
Device handling: Store staff perform and record POI device inspections, follow the device list and report suspected tampering or substitution.
Training: Cashiers, managers and technicians receive recurring training on tamper signs and on not sharing or replacing terminals without authorization.
Vendor and acquirer contact: The retailer checks PTS listings when deploying devices and asks its acquirer about any expired devices.
Evidence it keeps: Inspection logs, training records, the device inventory and the signed Attestation of Compliance.

Check that each store has a named owner for these tasks and that the inspection records exist for the past period, not only in the policy.

What usually delays retail POS validation

Most delays in card-present validation trace back to a small set of gaps: an incomplete device inventory, hardware that falls out of PTS approval, and networks that were never separated. Each card names one of these pitfalls and the check that prevents it before the assessor or acquirer finds it.

Unknown terminal inventory across stores

Payment terminals are part of the cardholder data environment, so every device in every store must appear in your records. Teams often track headquarters hardware but not terminals swapped in after a repair, added for a pop-up, or left at a closed location. Build a device list per store with serial number, model, location, PTS listing and owner, and reconcile it against the processor's terminal records each quarter. An inventory that cannot be matched to a physical device is the most common reason inspection evidence is rejected.

Expired PTS devices found late

PCI DSS does not require PTS-approved devices, but some payment brands do, and devices whose PTS approval has expired can trigger acquirer action. Teams usually discover this during validation, when replacing hardware on short notice is costly. Check the PTS listing of each model when you deploy it, record the expiry date in the device list, and ask your acquirer in writing how it treats expired devices before you plan a refresh cycle.

POS and guest Wi-Fi on one network

When the POS system and guest Wi-Fi share a LAN, the entire store network can fall into scope, and SAQ C eligibility disappears because the payment system is connected to other merchant systems. Place payment devices on a dedicated segment with firewall rules that block traffic from guest networks, back-office systems and the internet except for the processor connection. Test the segmentation before the assessment, because an assessor will check it against the network diagram.

Clear-text output sent over the Internet

Merchants must encrypt any clear-text output from a payment system before sending it over the Internet. Store systems often send receipts, reporting exports or diagnostic logs to a central office, and those files can contain card data that was never meant to leave the store. Inventory every outbound data flow from the POS network, confirm which carry card data, and enforce strong encryption on each one. Ask your POS vendor to document what its software transmits.

Inspection records not kept

Requirement 9.5.1 expects POI devices to be protected from tampering and substitution through a device list, periodic inspections and staff training. Assessors ask for dated records showing who inspected each device, what they checked and what they found. Many stores perform inspections but keep no log, so the work cannot be shown. Define the inspection frequency in your targeted risk analysis, use a standard checklist per device, and retain the signed records centrally.

P2PE assumed to remove all requirements

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. Merchants still own device inspection, network controls for the remaining systems, policies and the annual validation. Confirm with your acquirer which validation type applies to a P2PE deployment, and map which requirements remain your responsibility before you sign off on the solution.

Questions retail and restaurant teams ask about PCI DSS at the register

Does a standalone card terminal need a Report on Compliance?

Usually not, but the answer depends on your validation level and the rules of your acquirer and payment brands, not on the terminal alone. A standalone terminal that connects to the processor over IP often fits the SAQ B-IP path. That path covers merchants using only standalone PCI-listed PTS devices with an IP connection to the processor, excluding secure card readers, and the devices must not connect to other merchant systems or rely on a computer or phone to reach the processor. A Report on Compliance is completed by a Qualified Security Assessor, while an SAQ is completed by the merchant. Either way, the result is documented with an Attestation of Compliance, and a certificate alone is not accepted as validation. If a terminal depends on a POS computer, a phone, or a store network, the answer may change. Confirm your level and required validation type with your acquirer before you choose a path.

Does point-to-point encryption remove PCI DSS from my store?

No. 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. You still own the parts of the environment the encryption does not cover. These usually include the device inspection and training duties in Requirement 9.5, the network the devices sit on, the policies and staff records, and the validation your acquirer requires. Ask the solution provider for the P2PE listing and its scope documentation, then map what remains in your own environment. The reduction in work is real only for the requirements the listed solution actually covers, so confirm that boundary in writing before you plan the remaining controls and evidence.

What can an acquirer require for payment devices with expired PTS approval?

PCI DSS itself does not require PTS-approved devices, but some payment brands do, and their rules can cover devices whose PTS approval has expired. Check the PTS listing when you deploy each device and keep a record of its approval status. Then ask your acquirer, in writing, whether any device in your estate is expired, what replacement or remediation they expect, and by what date. The PCI SSC does not enforce compliance itself. The individual payment brands decide which entities must comply and run any enforcement programs, so the acquirer's instructions set the consequences for your business. Do not assume that a device that still works is compliant. Its approval status is what the brand rules check.

How often must card terminals be inspected for tampering?

Requirement 9.5.1.2.1 leaves the frequency and type of inspections to your own targeted risk analysis under Requirement 12.3.1, and that requirement became mandatory on 31 March 2025. The analysis should consider where devices sit, whether they are left unattended, how many staff handle them, how often devices move between sites, and any past tampering or substitution attempts. Document the chosen frequency, who performs the inspections, what they check, and the results of each inspection. Requirement 9.5.1 also expects a maintained device list and personnel training on recognizing tampering. Your assessor will test whether the frequency you chose matches the risk you documented, so a schedule without a risk analysis behind it is weak evidence.

Can our own staff handle PCI DSS for a few stores?

Often yes for a simple setup, because the merchant completes the applicable SAQ and signs the Attestation of Compliance. Ownership stays with you in every case. Your team controls the device list, inspection records, staff training, policies, network design and the answers given in the questionnaire. The work that tends to take the most time is the targeted risk analysis for device inspections, separating the POS network from other systems, and collecting consistent evidence across each store. An implementation partner can prepare systems, configuration records and evidence, but it does not issue reports or certificates. Only an independent assessor does that. Confirm with your acquirer which validation type applies before you decide whether you need outside assessment.

What should we ask a QSA before engaging for store validation?

Start by confirming the assessor is a Qualified Security Assessor listed by the PCI SSC and that they have assessed card-present environments before. Then ask the questions that decide whether their work will hold up:

How they will test the device list, inspection frequency and training under Requirement 9.5, including the targeted risk analysis under Requirement 12.3.1.
How they will assess POS networks and whether they expect segmentation evidence for each store and any central systems.
Whether any consulting you buy from them, or from a related party, creates a conflict with the assessment, and how they keep the two separate.
Which evidence they accept, and whether they will treat a vendor certificate as validation (it is not).
What deliverables, scope boundaries and timeline they will document in writing before work begins.

Does a POS terminal have to be fixed in place or tethered?

No. PCI SSC FAQ 1281 states that Requirement 9.5 does not require POI devices to be fixed in place or tethered. Mobility is still a risk factor, so your targeted risk analysis should cover whether devices can be removed, taken home or swapped between lanes. Common controls include a maintained device list with serial numbers, tamper-evident checks at each inspection, and staff training on what a substituted device looks like. A complex POS system also needs more controls than a locked-down terminal or one that uses a dial-out line. Assessors check that terminals are not configured to store sensitive authentication data, and that any clear-text output is encrypted before it crosses the Internet.

How DeployOpen prepares retail POS environments for assessment

DeployOpen plans, builds and documents the systems behind card-present payments inside your own infrastructure, so the cardholder data environment is defined, segregated and evidenced before an assessor arrives. The organization owns its controls and its validation, while an independent QSA or the applicable validation route issues the report or attestation.

How we scope

Map every POS terminal, payment application, store LAN and connection that touches card data or could affect it.
Confirm which SAQ path fits the environment, such as B, B-IP, C or a P2PE-based route, before any build work starts.
Agree the written scope, deliverables and timelines in advance, with ongoing support available as a retainer.

How we build

Segment the POS network so payment devices and systems stay isolated from guest Wi-Fi, back office and other merchant systems.
Configure hardened terminal and payment application settings, including checks that no sensitive authentication data is stored.
Set up device inventory, tamper-check procedures and the risk-based inspection frequency the organization defines for its stores.

How we hand over

Deliver network and data-flow diagrams, device inventories and the PTS listing checks that support the scope statement.
Document policies, store procedures and staff training records for the requirements the organization must evidence.
Walk the organization's internal team through the evidence pack so it can answer the assessor's questions directly.

How we support

Support store rollouts and device replacements so new hardware is checked against the PTS listing and scope before it goes live.
Keep configurations, inventories and segmentation rules current as stores, terminals and acquirer requirements change.
Confirm with your acquirer and assessor which evidence they expect, since the payment brands set validation requirements.