PCI DSS applies to every system that stores, processes or transmits card data, and to anything connected to those systems without controls in between. On the network side, that means firewalls and rules that only allow what is needed, secure configurations, protected wireless, secure remote access, regular testing and an accurate diagram. The single most useful design choice for a small merchant is to put card terminals on their own network segment, so the rest of the business stays out of scope. Your card processor tells you which assessment applies to you.
This is general information, not legal or compliance advice. PCI DSS is updated over time, and your acquiring bank, your processor and, where you use one, a qualified security assessor decide what applies to your business.
We cover PCI in passing in our guide to internet for restaurants and retail. This article goes further into the network requirements: what scope means, how segmentation reduces it, and what a small merchant's network typically needs to show.
Who sets the rules, and how you prove compliance
The Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council, which the major card brands founded. The brands and the acquiring banks enforce it. The current version is 4.0.1.
Most small merchants show compliance each year with a self-assessment questionnaire, or SAQ, and the right one depends on how you take cards. In broad terms:
| How you take cards | Typical SAQ family | Network reach |
|---|---|---|
| Online only, through a fully hosted payment page | SAQ A | Small; your network never sees card data |
| Standalone terminals connected over IP, not linked to other systems | SAQ B-IP | The terminals and the network they sit on |
| A validated point-to-point encryption (P2PE) solution | SAQ P2PE | Much reduced, because cards are encrypted at the reader |
| A POS application on a computer or server connected to the internet | SAQ C | The POS systems and everything connected to them |
| Anything more complex, or storing card data | SAQ D | The full standard |
This is a simplification, and the eligibility rules for each SAQ are specific. Your processor or acquirer tells you which one to use. Larger merchants and service providers may need an on-site assessment instead.
Scope: the idea that drives everything
The cardholder data environment, or CDE, is the set of systems that handle card data. Anything that can connect to it without a control in between is generally treated as in scope too. On a flat network, where the card terminals, the office PCs, the cameras and the guest Wi-Fi all share one segment, that can mean almost everything in the building.
Segmentation is not strictly required by the standard, but it is the practical way to keep scope small. If the card terminals sit on an isolated segment that can reach only the payment processor, then the office PCs, the cameras and the guests are, with proper controls and testing, outside the CDE. Fewer systems in scope means fewer to secure, document and test.
Card terminals on their own network
For most small merchants, the design looks like this:
- A dedicated VLAN or physically separate network for card terminals and any POS devices that handle card data. Our guide to VLANs and network segmentation covers how this works on shared hardware.
- Firewall rules that allow only what the terminals need, typically outbound connections to the processor's addresses, and deny everything else, including traffic from other internal segments.
- No route from guest Wi-Fi, staff Wi-Fi, cameras or smart devices into that segment. See guest Wi-Fi security.
- No casual devices on it. Nobody plugs a laptop, a music player or a spare switch into a payment port.
Some terminals connect over cellular instead of your network. That takes them off your LAN entirely, which can simplify things, though it brings its own coverage and data plan questions. If your POS provider supplies its own router, ask exactly what it separates. Some set up a proper isolated network; some put everything on one flat segment.
What the network part of the standard asks for
PCI DSS has twelve high-level requirements. Several bear directly on the network. In summary, and not as a substitute for the standard itself:
Network security controls
Firewalls or equivalent controls between the CDE and everything else, with rules that are documented, justified, reviewed on a schedule and limited to traffic that is actually needed. The standard expects an accurate network diagram and a diagram showing how card data flows through your systems. Our small business firewall guide covers choosing and maintaining the firewall.
Secure configurations
Change vendor default passwords and settings on every device in scope, including routers, switches, access points and terminals. Disable services you do not use. Keep an inventory of what is in scope.
Encrypting card data in transit
Card data crossing the internet or other open networks must be strongly encrypted. Modern terminals and processors handle this, but older equipment and some integrations may not; ask your processor.
Wireless
If wireless is part of the CDE, it needs strong encryption and changed defaults. Separately, the standard includes checks for unauthorized wireless access points, because a rogue access point plugged into a payment segment is an easy way in.
Access and remote access
Unique logins for each person, no shared admin accounts, and multi-factor authentication for access into the card environment, including remote access. This matters for POS vendors who support you remotely: their access should be individual, protected with MFA, and not left permanently open.
Testing
Depending on your SAQ, this can include vulnerability scans, with external scans run quarterly by an Approved Scanning Vendor, and penetration testing. If you rely on segmentation to reduce scope, the standard expects that segmentation to be tested to confirm it actually isolates the CDE, at least annually for merchants and after significant changes.
Logging and monitoring
Logs of access to systems in scope, reviewed and kept for a set period. A managed firewall with log retention helps here; our cybersecurity page describes managed firewalls and a 24/7 SOC designed around PCI needs.
Ways to shrink the problem further
- Validated P2PE terminals encrypt the card at the reader, so your network only ever carries encrypted data. Ask your processor whether your terminals are part of a listed P2PE solution, since "encrypted" in a brochure is not the same thing.
- Tokenization replaces stored card numbers with tokens, so card-on-file payments do not leave real numbers on your systems.
- Hosted payment pages for online sales keep card entry off your website entirely.
- Do not store card data you do not need. No card numbers in spreadsheets, emails or notes, and none in call recordings.
Keeping payments running
Compliance and uptime pull in the same direction. A payment segment with a backup internet path keeps cards working when the main line drops; see do you need backup internet. If your terminals have an offline mode, understand what it stores and for how long, and what risk it shifts to you, before relying on it.
A worked example
Hypothetical: the business and its setup are invented to show the method. Your processor decides which SAQ and requirements apply.
A café takes cards on three countertop terminals connected over its internet. It also has a back-office PC for ordering and payroll, a tablet for online orders, four cameras, a music player and guest Wi-Fi. Today all of it shares one network and one Wi-Fi password, so in principle the PC, the cameras and every guest phone sit next to the terminals.
The redesign:
- The three terminals move to their own VLAN, with firewall rules allowing only outbound connections to the processor.
- Guests get a separate SSID and VLAN, internet only, with client isolation.
- The back-office PC, the order tablet and the music player go on a staff VLAN. The cameras get their own.
- Default passwords on the router, access points and cameras are changed, and the POS vendor's remote access is set to individual accounts with MFA.
- The owner keeps a one-page diagram and a list of firewall rules with a reason for each, and asks the processor which SAQ applies to standalone IP terminals on an isolated segment.
Nothing here required new card terminals. It required a managed switch, access points that support VLANs, a firewall that can filter between segments, and an afternoon of careful configuration and testing.
Questions to ask your processor and your provider
- Which SAQ applies to how we take cards, and what does it require of our network?
- Are our terminals part of a validated P2PE solution?
- What addresses and ports do the terminals need to reach?
- Does the router or Wi-Fi our POS provider supplied isolate the terminals, and can we see the configuration?
- How is remote vendor access controlled, and is MFA enforced?
- Who keeps the network diagram and firewall rule list current?
Getting the network built for it
Our managed network service builds separate segments for payment terminals, staff, guests and cameras, with policies that enforce them and monitoring on top, and we price the internet and backup circuits across several Tier 1 carriers with no markup, because the carrier pays us. We do not replace your processor or assessor, but we can make sure the network they look at is built the way they expect. The consultation is free with no obligation, you usually hear back the same day, and Phil Morales is your one point of contact. Tell us how you take cards, call 478-758-8091 or text (347) 870-0965.
