When it comes to PCI-DSS, two things determine whether everything else is manageable or a landslide: network segmentation and a risk analysis. Get those right before you do anything else, and the 12 requirements become a structured program you can work through. Skip them, and everything else falls apart.
Most small merchants skip both. Not out of negligence but because nobody told them they needed to think about this when they signed up to accept credit cards. The payment vendor handed them a terminal, the acquiring bank sent a SAQ link once a year, and they assumed that was it. It is not.
Rosario’s Kitchen is a fictional small restaurant used throughout this series. It processes payments through Toast POS terminals, a Square reader for catering, and a Stripe-integrated website for gift cards. What it looks like under a PCI-DSS assessment is what most small merchants look like: a business that has been accepting cards for years without a formal security program and without any of the foundational controls PCI-DSS requires.
Segmentation Is Not Optional
PCI-DSS does not require network segmentation. It also does not let you ignore scope. If your POS terminals, your back-office PC, your staff phones, and your customer guest WiFi all share the same network with no controls between them, every one of those devices is in scope for PCI-DSS compliance. You have not simplified your environment. You have expanded what you are responsible for.
Rosario’s Kitchen runs a flat network. One Comcast consumer-grade router and modem serves everything: Toast terminals, the kitchen display system, the Windows PC the owner uses for reporting, staff personal devices, and the guest WiFi the customers connect to. There is no VLAN, no firewall ruleset, no traffic isolation of any kind. In a PCI-DSS assessment, that is not a minor gap. It is the gap that makes everything else harder to fix.
A consumer ISP-provided router is not a security appliance. It has no VLAN capability, no stateful firewall rules, no logging, and no management interface that meets any reasonable security standard. It is designed to provide internet access to a household. Using one as the network boundary for a cardholder data environment is the equivalent of using a padlock on a screen door.
The fix does not have to be expensive. A used enterprise-grade appliance from Cisco, Fortinet, or SonicWall can be sourced for a few hundred dollars. For a technically inclined owner, an older desktop PC running pfSense or OPNsense is a capable open-source alternative. Either option gives you VLAN support, firewall rules, logging, and a management interface you actually control. The Comcast router stays for the ISP connection. It stops being the security perimeter.
Segmentation Is Also a Scope Reduction Tool
The reason segmentation matters beyond security is that it controls how much of your environment PCI-DSS applies to. A properly segmented CDE means your POS terminals, the systems that directly process or transmit card data, are isolated from everything else. The guest WiFi is not in scope. Staff personal devices are not in scope. The PC you use for ordering supplies is not in scope. You have a defined, bounded environment and PCI-DSS applies to that environment.
Without segmentation, scope expands until it covers your entire network. That is a compliance nightmare.
The Risk Analysis Nobody Does
PCI-DSS Requirement 12.3 requires a formal risk assessment. Most small merchants have never done one. Rosario’s Kitchen has not. The chargeback spike that triggered their assessment was the first time anyone had formally looked at risk in the organization’s history.
A risk analysis for a small merchant does not need to be an elaborate document. It needs to identify where card data exists, what could go wrong with it, and what the organization is doing about each identified risk. That analysis is what justifies every other control decision you make. It is also what First Data, Visa, or Mastercard will ask for if a confirmed breach triggers a forensic investigation.
PCI-DSS requires that you implement controls appropriate to your environment. Appropriate means proportional to the risk you have identified. If you have never identified the risk, you have no basis for the controls you chose and no documentation showing you made an informed decision. In the event of a breach, that gap becomes a liability.
What Rosario’s Kitchen Actually Looks Like
The assessment found what a flat-network, no-security-program small merchant typically looks like:
Passwords written down. The Toast back-office portal password is on a sticky note on the office monitor. The Windows PC login is a first name with a number at the end. MFA has never been enabled on any account, despite being available on every platform in use.
Shared PINs at the POS. All floor staff use the same PIN to access the Toast terminals. There is no individual user identification, no way to attribute a transaction to a specific employee, and no audit trail that means anything from a compliance standpoint.
Guest WiFi on the same network as the POS. Customers connect to a network that has no barrier between them and the payment terminals. This is not a theoretical risk. It is an open path.
No logging anywhere. Toast keeps transaction logs, but those are not the same as system and network audit logs. The back-office PC has no logging configured. The router has no logging capability. If something happened, there is no record to investigate.
No terminal inspections. The Toast terminals have never been physically inspected for skimming devices. Given the chargeback spike, this is the first thing that needs to happen before any technical remediation.
Wrong SAQ filed. Rosario’s Kitchen has been submitting SAQ-A to First Data since 2022. The Square catering reader disqualifies SAQ-A eligibility. The correct form is SAQ-B-IP, which is a more demanding self-assessment that covers the gaps above. Filing the wrong SAQ does not reduce compliance obligations. It adds a misrepresentation problem on top of them.
The Conversation That Should Have Happened Earlier
None of this is the owner’s fault. She opened a restaurant. She signed up for Toast, got a Square reader, and built a website with a gift card option. Nobody at any of those onboarding processes told her that combining those three payment channels would require SAQ-B-IP, that her network needed to be segmented, or that she needed a written security policy before her first transaction processed.
This is the argument for a pre-PCI consultation before a business accepts its first card payment. A single conversation covering network design, SAQ eligibility, and the controls PCI-DSS requires would have cost a fraction of what remediation costs now. It also would have avoided filing two years of incorrect SAQs during an active fraud inquiry.
Before any other assessment work, verify SAQ eligibility and network topology. Ask the merchant to describe every payment channel they use and draw the network. Those two inputs tell you the scope, the correct SAQ, and most of the significant gaps before you have reviewed a single policy or interviewed a single employee.
For small merchants specifically: the network diagram is almost always the most revealing document. If there is no network diagram, draw one during the assessment. What you discover in that process usually surfaces the highest-risk findings.
Next in this series: Requirements 1 and 2, covering network controls and secure configurations. What they require, what Rosario’s Kitchen needs to do, and what a properly segmented small merchant network actually looks like.
