Quick answer: A branch kiosk is in PCI DSS scope whenever it stores, processes or transmits cardholder data or sensitive authentication data — that puts it inside the cardholder data environment. Components that are merely connected to that environment, or that can affect its security, can also be drawn in. Encryption alone and the fact that the terminal is unattended are not automatic exits.
Short answer: does a branch self-service kiosk fall inside PCI DSS scope?
A branch kiosk is in PCI DSS scope whenever it stores, processes or transmits cardholder data or sensitive authentication data — that puts it inside the cardholder data environment. Components that are merely connected to that environment, or that can affect its security, can also be drawn in. Encryption alone and the fact that the terminal is unattended are not automatic exits.
Most guidance stops there and repeats the twelve requirements. That is not the problem a branch compliance owner actually has. The problem is that scope boundaries get decided implicitly during procurement — by what the reader does, by how the cash module is wired, by which VLAN the unit lands on, and by what the vendor puts in writing — and then get discovered during the next assessment, when the device is already bolted to the floor. The nine items below turn those boundaries into a sign-off list you can attach to the RFP and to the vendor’s acceptance criteria, with a named owner for each answer.
The 9-point branch kiosk scope checklist
| # | Boundary to confirm before signing | Who owns the answer |
|---|---|---|
| 1 | Card-data path: does the reader read, transmit or store PAN, and is sensitive authentication data ever written after authorisation? | Vendor (design intent) + merchant compliance |
| 2 | P2PE status: which PCI-listed solution, if any, is used, and what does it actually remove from your validation effort? | Vendor + acquirer / QSA |
| 3 | Cash module path: can card data ever traverse the cash-acceptance or recycling board? | Vendor (integration documentation) |
| 4 | Connected-to components: which sub-systems can influence the security of the payment path (OS, remote-management agent, update service)? | Vendor + merchant security |
| 5 | Network path: how the kiosk is segmented from the branch LAN and WAN, and who monitors it. | Branch network team |
| 6 | Service access: how field and remote engineers reach the device, and how that access is logged. | Vendor service model + merchant IAM |
| 7 | Physical tamper protection: how the reader and cash module resist substitution and skimming. | Vendor + branch physical security |
| 8 | Evidence format: what the vendor hands over versus what you must generate yourself. | Vendor + merchant compliance |
| 9 | End of life: what happens to stored credentials, keys and logs when a unit is replaced, returned or redeployed. | Vendor + merchant asset management |
Two of these items decide most of the downstream work. Item 1 is binary: either the reader is a PIN entry device that handles sensitive authentication data, or it is a component that only transports an already-encrypted payload — and the two are documented differently. Item 5 is the largest lever you control, because it determines how many other branch systems must meet the full control set. Items 4, 6 and 9 are the ones buyers most often leave blank, and they are the ones a QSA will ask about first.
On item 2, be precise about what you are buying. PCI-listed point-to-point encryption reduces the applicable validation effort substantially, but it does not remove PCI DSS from the merchant environment — that clarification comes from the PCI SSC itself, not from a vendor datasheet, and it is widely restated in the unattended-payments literature. Treat “P2PE certified” as a scope-reduction input, never as a scope exit.
Cash acceptance is not a side issue for scope
Cash is not cardholder data, so it is tempting to treat a cash recycler as outside the conversation. In a branch kiosk it is not, for two reasons. First, the cash module adds a physical and electronic module inside the same chassis as the reader, and any shared controller, shared power path or shared service interface becomes a connected-to question. Second, cash-handling is where an attacker with physical access has the longest dwell time, which is why substitution and skimming controls sit in the same assessment as the payment path.
The vendor question to put in writing is simple: is the cash module on a separate data channel from the card reader, and how is that separation shown in the integration documentation? A wiring diagram and a data-flow statement are the evidence. If the answer is verbal, treat the boundary as unresolved and price the risk. Our freestanding cash-handling self-service kiosk is an example of the configuration where this question has to be answered before, not after, the acceptance test.
SAQ or ROC? Why the answer is about your channel, not the device
No kiosk spec sheet determines whether you validate with a Self-Assessment Questionnaire or a full Report on Compliance. That determination rests with the merchant and its acquirer, and depends on your card-present and unattended channel profile, transaction volume, and how your acquirer classifies the deployment. The device contributes evidence; it does not make the call.
Close this item before the purchase order, not after. Ask the acquirer and your QSA to confirm the validation route in writing, and refuse acceptance criteria that assume a vendor’s scope statement substitutes for the merchant’s own determination. If a quote implies that buying a particular terminal changes your validation category, that is a question for the acquirer.
Network segmentation: the lever that shrinks your audit
Isolating the cardholder data environment from the rest of the branch network means fewer systems need the full control set — segmentation reduces audit scope rather than merely tidying it, which is why it is analysed as the classic blind spot in branch environments. Three questions for your own network team before the kiosk lands:
- Which VLAN or segment will host the kiosk, and what is the documented rule set between it and teller, back-office and shared services?
- What east-west access is permitted between the kiosk and branch systems, and who approved each rule?
- Who owns monitoring and alerting for that segment, and where do the logs land?
A flat branch network turns one kiosk into a re-assessment across the site — the cost of that mistake shows up long after installation, which is why it belongs in the procurement decision rather than the deployment plan.
EU branches: what the DORA overlay changes
For EU financial entities, an ATM or self-service terminal is an ICT asset inside the operational-resilience regime, not only a payment device. Regulation (EU) 2022/2554 (DORA) sets ICT risk-management duties that include assessing such assets, and imposes threat-led penetration testing on significant financial entities. The practical procurement consequence is that resilience and testing evidence expectations belong in the vendor contract from the start; they cannot be bolted on during the next supervisory cycle.
Multi-jurisdiction groups should assume controls stack rather than substitute. US PCI DSS work, EU resilience obligations and, where relevant, SWIFT CSP segmentation expectations each add their own evidence trail. Design the branch network and the vendor evidence pack once, so each framework is satisfied by the same artefacts.
What to demand from the vendor before you sign (evidence pack)
- A signed statement of what the device stores, processes and transmits — and an explicit list of what it does not.
- Component and firmware update policy: who can push updates, over what channel, and how integrity is verified.
- Remote-access and service-model description, mapped to your own access controls and logging.
- Reader and cash-module tamper-response description, including how the module behaves after a detected event.
- Explicit acknowledgement of what the vendor cannot warrant — anything dependent on your network, your acquirer or your operational controls.
- End-of-life handling for keys, credentials and logs.
Mirror this list into your RFP scoring so compliance answers are comparable across bidders rather than buried in annexes — the self-service kiosk RFP procurement checklist shows how to weight these lines against hardware and service criteria. Be clear internally about roles here: we are a hardware OEM/ODM and supply the device and its evidence; we do not certify your compliance, and scope determination and SAQ or ROC selection rest with the merchant and its acquirer.
Where these decisions change your total cost
Three scope choices have a price that only appears after go-live if they are left open: segmentation engineering and ongoing rule maintenance; service-access controls and logging for field and remote support; and re-validation effort when a boundary turns out to have been undocumented. Put those lines next to the unit price in the business case — the bank self-service kiosk TCO comparison sets procurement, integration and service-model costs side by side so finance sees the whole picture rather than the invoice.
How to verify any “out of scope” or “P2PE certified” claim
- Ask for the exact listing or reference and check that it is current, not a historical certificate for a superseded configuration.
- Re-read the vendor’s own limitation language — the paragraph after the headline claim usually states what is excluded.
- Confirm the claim is made about the model and firmware you are buying, not a reference platform.
- If the evidence is absent or verbal, treat the scope question as open and price that risk into the decision.
Questions buyers ask during scope review
Are self-service kiosks in PCI DSS scope if they only accept cards for a few seconds?
Duration is irrelevant. If the device stores, processes or transmits cardholder data or sensitive authentication data, it is in the cardholder data environment, and connected-to or security-impacting components can be drawn in as well.
Does encrypting card data remove the kiosk from PCI DSS scope?
No. Encryption reduces exposure and supports a reduced validation path, but PCI SSC guidance does not treat encryption alone as removing PCI DSS applicability.
Does a PCI-listed P2PE solution remove the need for a SAQ?
No. It can substantially reduce the applicable validation effort, but the merchant still validates, and the route is confirmed with the acquirer and QSA — not by the device.
What evidence should a kiosk vendor provide for branch compliance approval?
The evidence pack above: a signed data-handling statement, component and update policy, remote-access model, tamper-response description, stated limitations and end-of-life handling. Anything the vendor cannot warrant should be named, not implied.
Next step
Attach this checklist to your RFP and ask every bidder to answer it line by line, with the owner of each answer named. Request the branch kiosk PCI DSS scope-determination checklist + compliance evidence pack — or a datasheet for the card-accepting and cash-accepting terminal configuration you are evaluating — from the cash-handling kiosk platform page , and we will return the hardware documentation and evidence items you can hand to your QSA. The handover is straightforward: hardware and its accompanying evidence come from us; scope determination, network design and SAQ or ROC selection stay with your merchant, network and acquirer teams.
