Understanding SAQ B-IP: Which merchants fit this PCI DSS form?

SAQ B-IP explained: who it targets and why it matters

If you’re navigating PCI DSS territory, you’ll hear about different SAQs that fit different payment setups. One of the more focused ones is SAQ B-IP. It isn’t a blanket fit for every merchant, but for a very specific payment flow, it’s a clean, sensible path to compliance. So, what exactly does SAQ B-IP target? In short: merchants who process payments via standalone PTS-approved devices with an IP connection.

Let me explain what that means in practical terms and why it matters for your security strategy.

What SAQ B-IP is in simple terms

Think of SAQ B-IP as a security checklist tailored to a narrow way of taking payments. The essence is this: you’re not piping cardholder data through your own computers or servers. Instead, you rely on dedicated PIN entry devices (the PTS-approved, stand-alone endpoints) that handle the card data directly and communicate with the payment processor over an IP network. Because the merchant’s network doesn’t touch cardholder data, the scope of PCI DSS rests mostly on how those devices are secured and how the network around them is configured.

That’s a mouthful, so here’s a mental model you can hold onto: the device acts as a secure bridge, encrypting data at the point of entry, and the merchant’s systems stay out of the data path. The result is a smaller, more focused set of controls for compliance.

Who SAQ B-IP is meant for

The core audience for SAQ B-IP is pretty specific:

• Merchants who process payments using standalone PTS-approved devices that have an IP connection.

• Merchants who do not store, process, or transmit cardholder data on their own systems. In practice, any CHD (cardholder data) stays off the merchant’s servers and workstations because the device handles the sensitive data.

• Merchants who rely on the device to capture and encrypt card data before it travels across the network to the payment processor or acquirer.

If your payment setup looks like that—an IP-connected device that sits apart from your general IT environment—SAQ B-IP is the most appropriate self-assessment path. It’s not about how big your business is; it’s about where data touches your systems. The device does the heavy lifting for data security; your IT footprint remains, in a sense, a step removed from the card data.

What counts as a standalone PTS-approved device?

This is where the conversations tend to get technical, but the idea is simple: the device is built to meet PCI SSC’s PIN Transaction Security standards. A standalone PTS-approved device:

• Is a dedicated payment device, not a general-purpose PC or tablet, and it operates independently of your back-end servers when it comes to handling card data.

• Encrypts card data at the point of entry (for example, when a card is dipped, swiped, or tapped) and keeps the raw PAN (primary account number) away from your systems.

• Transmits data to the processor or acquirer over an IP connection, without exposing CHD to your internal network.

You’ll sometimes hear references to PEDs (PIN entry devices) and contactless readers that are part of these secure, dedicated devices. The key point is that the device itself is the only component in your environment that touches the sensitive data, and it’s designed to meet a standardized security baseline. Vendors like Ingenico, Verifone, and similar providers often offer these PTS-approved devices, and the PCI SSC maintains the certification framework to ensure consistency across devices.

Why the IP connection matters

The “IP” in SAQ B-IP isn’t just a networking detail; it shapes how the data travels and how security controls are scoped. An IP-connected device can send payment authorization requests directly to the processor over the network. Because the merchant’s servers aren’t in the data path, you’ll see a narrower PCI DSS footprint.

That said, the IP connection introduces its own security considerations:

• Network segmentation: even though data doesn’t touch your internal databases, you still want to limit which devices can reach the payment network. A straightforward firewall rule set often suffices, but it’s important to define and test the path to the processor.

• Device hardening: keep the device firmware up to date, configure strong access controls for any maintenance interfaces, and monitor for unusual activity at the device level.

• Monitoring and logging: you don’t need the same depth of CHD logging as a full payment system, but you do want visibility into device reboots, firmware updates, and connection interruptions.

• Vendor management: you’re relying on a third party (the device vendor and processor) for the security of card data in the device’s path. Documented vendor security practices and timely firmware updates become part of your control set.

A practical, human-friendly comparison

If SAQ B-IP were a vehicle, imagine a small, efficient delivery van. The van (the standalone PTS-approved device) is purpose-built to carry precious cargo (cardholder data) safely from the customer to the distribution network (the payment processor). You don’t pile shipments on a full-size warehouse truck (your servers or workstations). That keeps the risk concentrated where it should be: inside the secure, purpose-built hardware and the network path it uses.

Other realities to keep in mind

• Mobile wallets and other payment streams: You’ll hear about different SAQs for other setups, like mobile or e-commerce channels. Those paths often involve separate controls and are not covered by SAQ B-IP. If your business accepts card data in other ways, you’ll likely need to assess additional SAQ types to cover those channels.

• Physical retail vs. online channels: SAQ B-IP is agnostic to the size of the business, but the setup is nicely suited to environments where a dedicated device handles the payment entry. A store with multiple integrated systems may drift into a broader PCI DSS scope, and you’d consider whether another SAQ type better fits that environment.

• Compliance is ongoing, not a one-off act: the device and the network are living parts of your security posture. Regular firmware updates, vulnerability management, and change control keep the PCI scope sane over time.

Common misconceptions, cleared up

• “If I use a standalone device, I’m automatically compliant.” Not true. SAQ B-IP is a guide for the specific setup, but you still must meet the described controls. It’s about the right fit for your data flow, not a shortcut to security.

• “Mobile wallets are the same as standalone devices.” They aren’t always. Mobile wallets introduce other risk vectors and often require different SAQ pathways, such as SAQ P2PE or SAQ A variants, depending on how the payment data is processed.

• “The device does all the work, so I don’t need to worry about my network.” The opposite is true. Securing the network path and ensuring the device remains in a trusted state are essential parts of the equation.

Takeaways you can apply

• Confirm the setup: If your payments flow goes through a standalone PTS-approved device with an IP connection and you don’t store CHD on your systems, SAQ B-IP is the right lens to view your PCI DSS obligations.

• Check the device health: Keep firmware current, verify the device’s PTS certification status, and ensure only authorized personnel can access maintenance features.

• Secure the network path: Implement basic protections like a properly configured firewall, network segmentation, and monitored connections to the payment processor.

• Document your controls: Even though the scope is narrower, you still need clear documentation of how data flows, what is in scope, and how you verify ongoing compliance.

• Prepare for audits with clarity: The goal isn’t to perform some ritual dance for the assessor, but to demonstrate that your payment path remains isolated from CHD on your systems and that the device path is protected end-to-end.

A quick, real-world example

Imagine a small café that uses a countertop PIN pad connected via Ethernet to a router that heads straight to the payment processor. The cafe staff never touches card data on the café’s computers. The POS just handles orders and receipts; the secure device handles the card data and encryption before it leaves the device. The café’s IT team keeps the firmware current on the device, ensures the router is protected by a basic firewall, and maintains a simple change log for any configuration adjustments. This kind of setup is a textbook fit for SAQ B-IP, where security focuses on the device’s integrity and the network path that carries the encrypted data.

Bringing it all together

SAQ B-IP serves a focused niche: merchants who process payments through standalone PTS-approved devices over an IP network, with no CHD stored on their own systems. The beauty of this approach is clarity—data flow is tightly scoped, and the security controls concentrate on the device and the network that connects it to the processor. If your payment world looks like that, you’re aligning with a practical, enforceable security posture that keeps card data out of sight where it doesn’t belong.

If you’re building expertise around PCI DSS for real-world applications, keep the mindset simple: identify where data touches your environment, lock down that path, and treat the device as the secure gatekeeper. The math is straightforward, the payoff is real, and the safeguards become second nature with steady attention.