How to Prove SAQ B-IP Eligibility: The 5-Check Terminal Zone Test
SAQ B-IP eligibility means your merchant environment accepts card data only through standalone, PTS-approved terminals that sit in their own network zone, separate from every other system you operate. Under PCI DSS v4, a terminal is not standalone if other device types share its network zone, and the boundary must be tested, not asserted.
A merchant's compliance file looks perfect on its face. SAQ B-IP, signed. Terminals listed. Acquirer satisfied. Then the assessor, or the breach investigator, asks one question: what sits in the same network zone as those terminals?
The answer is usually not "just the terminals." It is the back office Wi-Fi, the manager's laptop, the printer server. In our PCI compliance assessments, the SAQ B-IP is the form we most often see signed on paper and contradicted by the network diagram, and the contradiction is rarely the terminals themselves. It is the assumption behind the word "standalone."
The cost of that assumption is not an extra fee. IBM's Cost of a Data Breach 2026 report puts the global average breach cost at $4.99 million, a 12% increase and a record high, and 56% of breaches involved AI-driven attacks [2]. The average does not split by SAQ type. The questionnaire you filed changes the questions you were expected to answer, and a wrong filing does not reduce the breach, it just leaves the right requirements unaddressed.
Clone Systems' position: a merchant's SAQ choice is a documented claim about their own network, and most B-IP claims fail the PCI Security Standards Council's "same network zone" reading before the first requirement is even answered.
What Does the PCI SSC Actually Mean by "Standalone" in Version 4?
SAQ B-IP is for merchants whose only card data channel is payment terminals that connect to the processor over IP. The eligibility conditions, as summarized in the v4.0 SAQ B-IP guidance, are: only standalone, PTS-approved terminals; no other system (workstation, server, or otherwise) transmits or processes payment data; the terminals' IP network is segmented from all other systems in the merchant environment, typically by a firewall or other network security control; and no electronic storage of cardholder data, which forces SAQ D if present [3].
The change most merchants miss is not in the requirements list. It is in the v4.0 SAQ Instructions and Guidelines: the PCI SSC clarified that SAQ B-IP is intended only for standalone, PCI-approved point-of-interaction devices that are not connected to other types of devices in the same network zone [1].
Read that sentence slowly. A terminal that runs no payment application can still share a network zone with your office Wi-Fi, your VoIP phones, and your file server. In v4, that is not a B-IP environment. The terminals being dedicated hardware is necessary. It is not sufficient. The zone has to be the story.
The Four Ways the Claim Falls Apart in Practice
In our compliance work, the B-IP claim fails in four recurring places, and none of them requires a sophisticated attacker to exploit:
- "Standalone" means "no payment software," not "isolated." The merchant checked the application box and never the network box. The terminal gets its IP from the same DHCP pool as the coffee machine.
- The zone's firewall is invisible to the person who filed the SAQ. The IT contractor configured it years ago. Nobody can produce the current ruleset, and eligibility assumes a control the organization cannot describe.
- Electronic storage is sneaking back in. The back office keeps last night's sales totals in a spreadsheet, or a receipt with a PAN gets scanned into email. Paper is fine. Electronic is not, and it is the fastest way to lose B-IP eligibility [3].
- "Standalone" is confused with "segmented from the internet." Pointing at the edge firewall and saying "we are behind a firewall" does not address the internal boundary between the terminal zone and the rest of the LAN.
How Do You Test Whether You Actually Qualify for SAQ B-IP?
Five checks, in order. If any one fails, you do not qualify for B-IP, and the right move is to identify which SAQ you do qualify for before you sign anything.
The Clone Systems 5-Check Terminal Zone Test
| # | Check | What proves it | Fails B-IP when |
|---|---|---|---|
| 1 | Every terminal in use is PTS-approved and on the PCI SSC's list of approved devices [1][3] | Model and firmware version checked against the PCI SSC PTS POI list | Any terminal is unlisted or unapproved |
| 2 | No other system transmits or processes payment data [3] | Network inventory with the terminal zone isolated on the diagram | Any workstation, server, or app touches cardholder data |
| 3 | The terminals sit in their own network zone, separate from all other device types [1] | A current network diagram plus the firewall (or NSC) ruleset showing only terminal traffic crossing | Office Wi-Fi, VoIP, or servers share the zone |
| 4 | No electronic storage of cardholder data [3] | Storage check on the terminal, the zone, and any system that could write receipts or totals | Any PAN or sensitive authentication data persists after authorization |
| 5 | The segmentation actually holds when tested (Requirement 11.4.5) [3] | A penetration test of the segmentation controls, not a screenshot of the rules | Traffic crosses the boundary that should not |
The fifth check is the one that turns the SAQ from a form into a finding. Requirement 11.4.5 obliges you to test the network segmentation with a penetration test, and the v4 B-IP carries that obligation even though the rest of the questionnaire is short [3]. A ruleset screenshot is documentation. A test result is evidence, and the difference is the entire post.
The Zone Is Where the Compliance Lives
Here is what trips people up: B-IP is not a terminal-only questionnaire. The v4.0 B-IP pulls in requirements from areas 1, 2, 3, 6, 7, 8, 9, 11 and 12, and most of the technical weight lands on the firewall or network security control that isolates the zone [3]. That device needs documented, current, in-use security policies (the v4 additions in requirements 3.1.1, 8.1.1 and 9.1.1 apply to the zone, not the terminals), vendor default accounts removed, critical and high patches installed within one month of release, individual accounts with least privilege, and quarterly external vulnerability scans by an ASV [3].
If you have never had the zone's firewall reviewed, you have never done half of SAQ B-IP. The terminal provider handles the terminal. The zone is yours.
This is the point where the decision usually changes. If check 3 or 5 fails, the fix is not a longer firewall rule, it is a different SAQ, and the evidence you need (a tested segmentation boundary, a clean zone inventory) is exactly what a PCI ASV and segmentation test engagement produces. See PCI ASV scanning and external vulnerability scanning to put that evidence in place before you sign.
SAQ B-IP vs SAQ C vs SAQ D: Which One Do You Actually Owe?
The three short-form questionnaires for card-present merchants differ in one variable: what else is in scope around the payment flow.
| SAQ B-IP | SAQ C | SAQ D (Merchants) | |
|---|---|---|---|
| Payment channel | Standalone IP-connected PTS-approved terminals, in their own network zone [1][3] | Payment application systems connected to the internet, including integrated POS [4] | Any channel, or any environment with electronic storage of cardholder data [3][4] |
| Other systems in scope | None may transmit or process payment data [3] | The POS back end and supporting infrastructure are in scope [4] | Everything in scope, full applicable requirement set [4] |
| Electronic cardholder data storage | Not permitted [3] | Not stored (transit only) [4] | Permitted, with full Requirement 3 obligations [4] |
| Approximate question count (v4) | ~86 [4] | ~160 [4] | ~330+ [4] |
| Pick it when | Checks 1 through 5 above all pass | You run an integrated POS that connects to the internet | You store card data, or your channels do not fit a specific SAQ |
Two practical notes. First, SAQ C is the natural landing spot when check 2 or 3 fails: an integrated POS that talks to a back office is not B-IP, and pretending otherwise is how breaches turn into non-compliance findings [4]. Second, SAQ eligibility is assessed per payment channel, not per company. If you also take cards on a hosted e-commerce checkout, that channel has its own SAQ (often SAQ A or A-EP), and your acquirer decides whether you submit per-channel SAQs or roll everything into SAQ D [4].
What Happens When You File the Wrong SAQ?
A wrong SAQ does not fail quietly. It surfaces in one of three places: the assessor or QSA reading the scope description against your network diagram, the acquirer review that asks for evidence the questionnaire did not anticipate, or the breach investigation, which is the worst place to discover that "standalone" was never true [4].
In practice, the consequences cascade:
- The attestation is re-scoped. You answer the questions for the correct SAQ, which for most B-IP misfiles means moving to C or D, with the question count roughly doubling or quadrupling [4].
- The unaddressed requirements become findings. Segmentation testing, patching on the zone boundary, and policy obligations that B-IP's shorter scope skipped are now due, and they were never implemented [3].
- Your ASV coverage may have been wrong too. B-IP's quarterly external scans cover the terminal zone's exposure. If your real scope includes a POS back end or a stored-data system, the scan scope was smaller than your risk, and the Attestation of Scan Compliance you handed your acquirer does not describe your environment. Our PCI scan cost guide breaks down how scope size drives scan pricing, and what to check before you buy a PCI scan online covers keeping the attestation file defensible.
- The breach math does not change. The $4.99 million global average applies whether you filed B-IP or D [2]. What changes is whether the controls that reduce that number were actually in place, and whether your attestation proves it.
One more way the story goes sideways: contactless and mobile wallet flows. A merchant who adds tap-to-pay or a mobile wallet path has introduced a new acceptance channel, and "we already filed B-IP" does not cover a channel that was not in the original scope. We wrote about the NFC side of this in Tap to Pay, Tap to Hack?, and the scoping principle is the same: every channel gets its own eligibility analysis.
How Clone Systems Can Help
Clone Systems is a PCI Approved Scanning Vendor, and the 5-Check Terminal Zone Test is the same analysis we run before a client commits to a questionnaire.
- Segmentation and scope review. We map the terminal zone against the live network, not the diagram on the wall, and tell you B-IP, C, or D with the evidence to defend the answer. This is the same boundary work we cover in how to reduce PCI DSS scope, applied to your payment zone.
- Requirement 11.4.5 segmentation testing. A penetration test of the boundary between the terminal zone and the rest of your network, so check 5 is a result, not a hope.
- Quarterly ASV scanning. External scans with a defensible scope and an Attestation of Scan Compliance that matches the SAQ you actually owe. See PCI ASV scanning services.
Start at www.clone-systems.com or book a consultation.
Frequently Asked Questions
What does SAQ B-IP eligibility mean? SAQ B-IP eligibility means you accept card data only through standalone, PTS-approved terminals that sit in their own network zone, with no other system transmitting or processing payment data and no electronic storage of cardholder data. Under PCI DSS v4, sharing a network zone with other device types disqualifies you.
Can I use SAQ B-IP if my terminal connects to my business network? No, not if other device types share the terminal's network zone, which is the v4 reading of "standalone." If the terminal and your office share a flat network, you need SAQ C or SAQ D, depending on what else is in scope.
What happens if I file the wrong SAQ? You will have to complete the correct questionnaire, and the requirements it adds were never implemented, so the gap shows up as findings at assessor review, acquirer review, or breach investigation. The fix is to re-scope before you sign, not after.
Does one SAQ cover all of my payment channels? No, SAQ eligibility is assessed per payment channel, not per company. If you run terminals and a hosted checkout, each channel needs its own eligibility analysis, and your acquirer decides whether you file separate SAQs or roll into SAQ D.
Does SAQ B-IP require a penetration test? Yes, Requirement 11.4.5 requires you to test the network segmentation with a penetration test to prove the boundary holds. A firewall ruleset screenshot documents the intent; the test result is the evidence.
Conclusion
A SAQ is the shortest form in your compliance file, and it is also the one where a single wrong assumption costs the most: the whole attestation rests on a claim about your own network. The PCI SSC's v4 instructions drew the line clearly, a B-IP terminal must be the only kind of device in its network zone, and IBM's 2026 data puts the price of getting the surrounding story wrong at $4.99 million on average [1][2].
Run the 5 checks against your live network, not your diagram. If check 3 or 5 wavers, you already know which SAQ you actually owe, and the evidence to prove it is a tested boundary, a clean zone inventory, and a scan scope that matches. That is a conversation Clone Systems can have with you this quarter, starting at www.clone-systems.com.
References
[1] PCI Security Standards Council: "PCI DSS v4: What's New with Self-Assessment Questionnaires," PCI Perspectives blog, March 2024 (v4.0 SAQ Instructions and Guidelines clarify SAQ B-IP applies only to standalone PCI-approved POI devices not connected to other types of devices in the same network zone; new Requirements 3/9 policy obligations added to SAQ B-IP). https://blog.pcisecuritystandards.org/pci-dss-v4-whats-new-with-self-assessment-questionnaires
[2] IBM (with Ponemon Institute): Cost of a Data Breach Report 2026 (global average breach cost $4.99 million USD, up 12% year over year, a record high; 56% of breaches involved AI-driven attacks). https://www.ibm.com/reports/data-breach
[3] SecurityMetrics: "Performing an SAQ B-IP Version 4.0 Self-Assessment," December 2023 (B-IP eligibility: only standalone PTS-approved terminals, no other systems transmitting or processing payment data, IP network segmented from all other systems, no electronic storage of cardholder data; Requirement 11.4.5 segmentation penetration test; quarterly ASV scans; critical/high patches within one month; v4 additions 3.1.1, 8.1.1, 9.1.1). https://www.securitymetrics.com/blog/performing-an-saq-b-ip-version-40-self-assessment
[4] Episki: "PCI DSS SAQ Types Explained (A, A-EP, B, B-IP, C, C-VT, D, P2PE)" (eligibility summaries and approximate question counts: B-IP ~86, C ~160, D for Merchants ~330+; eligibility assessed per payment channel, not per company; multi-channel options are per-channel SAQs or a SAQ D rollup). https://episki.com/frameworks/pci/saq-types-explained
[5] Clone Systems: In our PCI compliance assessments, the SAQ B-IP is the form most often seen signed on paper and contradicted by the network diagram. The four recurring failure points are a flat zone shared with office devices, a zone boundary nobody can describe, electronic storage that crept back in, and "standalone" read as "no payment software" instead of "own network zone."
[6] Clone Systems: How to Reduce PCI DSS Scope: What Actually Takes a System Out of the CDE. www.clone-systems.com/blog/how-to-reduce-pci-dss-scope
[7] Clone Systems: PCI ASV Scanning and External Vulnerability Scanning service. www.clone-systems.com/pci-asv-scan-external-vulnerability-scanning
[8] Clone Systems: Buy a PCI Scan Online: 7 Things to Check Before You Pay. www.clone-systems.com/blog/buy-pci-scan-online
[9] Clone Systems: PCI Scan Cost 2026. www.clone-systems.com/blog/pci-scan-cost-2026
[10] Clone Systems: Tap to Pay, Tap to Hack? Understanding Security Risks in Contactless Payments. www.clone-systems.com/blog/tap-to-pay-tap-to-hack