⚠️ What this page is (and isn't)
This is a conceptual overview to help you ask better questions of your vendors. It is not compliance advice, it doesn't cover assessment types or detailed rules, and PCI requirements change. For the actual requirements that apply to you, check current official requirements here: PCI Security Standards Council — the official source.
The core principle
One sentence that explains 90% of PCI scope decisions.
If card data passes through a system, that system is in scope. If card data never touches it, it generally isn't. That's the whole game: every cable, Wi-Fi hop, and software integration that carries (or could carry) card numbers drags the systems on both ends into your compliance obligations. Design your setup so card data travels the shortest possible path — ideally, it never leaves the payment terminal at all.
Think of it like plumbing: you don't waterproof the whole house, you keep the water in the pipes. The terminal is the pipe. Everything else should stay dry.
The three architectures
Every card-present setup is some version of one of these.
1. Standalone terminal
The terminal sits on the counter, connected directly to the processor. The cashier keys in (or the customer sees) the amount, the card is tapped or inserted, and the receipt prints from the terminal. Card data never touches your POS, your PC, or your network beyond carrying the terminal's own encrypted traffic.
Because nothing else in your business ever sees card data, your POS, back-office computers, and other systems are largely out of scope. This is the simplest architecture to secure and to assess — which is why it's the right choice for many small businesses that don't need deep POS integration.
2. Semi-integrated / P2PE terminal
Here the terminal connects to your POS so the sale amount flows automatically (no re-keying), but card data still never touches the POS. The terminal encrypts the card data the instant it's read and sends it straight to the processor; the POS only ever sees non-sensitive references like approval codes and totals.
"P2PE-validated" at a high level: P2PE stands for point-to-point encryption. A P2PE-validated solution is one where an independent assessor has verified that card data is encrypted inside the terminal and stays encrypted until it reaches the processor — with validated controls around the devices and decryption environment. In plain terms: it's a setup someone qualified has checked actually keeps card data out of your systems, rather than a vendor merely claiming it does.
Done properly, the POS stays largely out of scope — you get the convenience of integration without dragging your whole network into scope. Done improperly (card data readable anywhere along the path), it quietly becomes architecture #3.
3. Card data passing through the POS
In this architecture, card data flows through the POS software or the PC it runs on — for example, a card reader plugged into the POS computer that sends unencrypted card data through the POS application to the processor.
The POS is now in scope — and so is everything connected to it: the PC, the network it sits on, and potentially the back-office systems it talks to. Your compliance obligations grow substantially, and so does your breach risk: card data sitting in more places means more places it can be stolen from.
If your setup works this way and you didn't deliberately choose it, that's worth a conversation with your vendors about moving to architecture #1 or #2.
The takeaway
Card data through the POS → the POS is in scope. Standalone terminal, or an appropriately semi-integrated / P2PE-validated device → the POS is largely out of scope. When a vendor proposes a setup, ask one question: "Show me exactly where the card data travels." Then check the current official requirements at the PCI Security Standards Council.
Seven common scope-creep mistakes
Ways businesses accidentally pull more systems into scope than they needed to.
Keying card numbers into the POS "just this once"
Typing a card number into the POS for a phone order or a failed terminal puts card data into a system that wasn't designed to hold it. Use your processor's virtual terminal or a proper card-not-present flow instead — and never as a routine workaround.
Storing card numbers in notes, spreadsheets, or booking fields
A card number in a booking note, a spreadsheet of "regulars," or an email thread is card data sitting in systems with none of the right protections. Tokenize (store a token, not the number) or don't store it at all.
Putting the terminal on the same network as everything else
A flat network where the terminal, the POS, the back-office PC, and guest Wi-Fi all mingle means card-data traffic shares space with everything. Segment the payment traffic away from the rest.
Letting guest Wi-Fi touch business systems
Guest devices on the same network as terminals or the POS is a scope and security problem at once. Guest Wi-Fi must be isolated — no path to payment, POS, or PMS systems.
Assuming "the cloud handles it"
Cloud POS doesn't automatically mean small scope. What matters is still the card-data path: if card data passes through the local POS app or browser before reaching the cloud, the local environment is in the picture.
Forgetting about paper
Printed receipts with full card numbers, old terminal settlement reports in a drawer, carbon copies — paper with card data counts. Truncate, secure, and shred on a schedule.
Never re-checking after changes
Scope isn't set once. A new integration, a POS update, a "temporary" workaround during a busy season — any of these can quietly reroute card data through systems that were previously clean. Re-verify the card-data path after every change.
The audit and business angle
Why scope matters beyond compliance paperwork.
A smaller scope isn't just less paperwork — it's less risk and less cost. Every system in scope needs securing, patching, monitoring, and periodic assessment. Every system holding card data is a system a breach can start from. Businesses with tight, well-designed card-data paths spend less on compliance, face less breach exposure, and have simpler conversations with their processors and insurers.
There's a money angle too: the architecture you choose affects your processing setup, and your processing setup affects what you pay. When we audit statements, we sometimes find businesses paying for complexity they didn't choose on purpose — a setup that drifted into a higher-scope, higher-cost shape over years of small changes. The free audit looks at what you're paying; this guide helps you look at why your setup looks the way it does.
Check the current official requirements
PCI standards evolve, and only the official source is authoritative for what applies to you: PCI Security Standards Council — pcisecuritystandards.org. If a vendor's claim about scope or compliance doesn't match what you find there, believe the Council and ask the vendor harder questions.
Want a second pair of eyes on what you're paying?
The audit is free and takes about a week. If there's nothing to find, you get a clean bill of health and owe us nothing.
Start your free audit