PCI DSS v4.0.1 Self-Assessment Questionnaire (SAQ B-IP)

Why does it matter?

The IP connection is what separates SAQ B-IP from SAQ B. A terminal that reaches the processor over a network is a system component on that network, so the questionnaire asks the merchant to show network security controls, encrypted transmission, patching, authentication and quarterly external scans, even though the device itself has been validated under the PTS POI program. The trade-off is still favorable: ten requirements with a narrow set of sub-requirements, and a scope that stops at the terminals and the network segment that isolates them, provided every eligibility criterion holds.

Key benefits include:

• Ten requirements, scoped to the terminal network

Requirements 1, 2, 3, 4, 6, 7, 8, 9, 11 and 12 appear, with far fewer sub-requirements than the full standard; for example Requirement 8 asks for 8.1.1, 8.2.2, 8.2.7 and 8.4.3 only.

• PTS validation carries weight

The devices must be validated under the PTS POI program and appear on the PCI SSC list; footnote 1 tells merchants with expired approvals to check with their acquirer or payment brand whether this SAQ is still acceptable.

• Segmentation is allowed, and then tested

The criteria allow the terminals to be isolated from other systems by network segmentation, and Requirement 11.4.5 then requires a penetration test of the segmentation controls at least every 12 months and after changes.

• Future-dated items are handled in the form

Under Guidance for Responding to Future Dated Requirements, a bullet not yet implemented before 31 March 2025 could be marked Not Applicable and explained in Appendix C.

• Attestation built in

Section 1 and Section 3 are the four parts of the Attestation of Compliance, so the questionnaire, the eligibility certification and the signed status travel as one document.

How does it work?

Completion follows the five PCI DSS Self-Assessment Completion Steps: check the eligibility criteria and the Council's Self-Assessment Questionnaire Instructions and Guidelines to confirm that B-IP is the right form; make sure the environment is correctly scoped; assess it against the requirements; fill in Section 1 (AOC Parts 1 and 2), Section 2 (the questionnaire) and Section 3 (AOC Parts 3 and 4); then send the SAQ, the AOC and any supporting material requested, such as ASV scan reports, to the organization that manages the compliance program, typically a payment brand or acquirer.

For each requirement the merchant selects exactly one response. The Requirement Responses table defines In Place, In Place with CCW (a Compensating Controls Worksheet completed in Appendix B), Not Applicable (explained in Appendix C) and Not in Place; Not Tested is not offered, since every requirement in B-IP must be tested, and Appendix D exists only to hold explanations for that unavailable response. Not in Place answers may trigger Part 4 of the AOC if the recipient asks for it, and a requirement that a local or regional law prevents is marked Not in Place and declared as a legal exception in Part 3.

The Expected Testing column names the evidence for each item: Examine (documents, configurations, logs, scan reports, keys and certificates), Observe (people, systems and physical controls in operation) and Interview. Two worked examples sit in the front matter: the media controls in 9.4.1 to 9.4.6 apply only when paper media with cardholder data is stored, and may otherwise be Not Applicable; and the customized approach cannot be documented in an SAQ, so its objectives are left out and a merchant wanting to use it must ask its acquirer about completing a Report on Compliance instead.

Key Elements

• Merchant Eligibility Criteria

Only standalone, PCI-listed approved PTS POI devices (not SCRs or SCRPs) connected via IP to the processor; devices validated to the PTS POI program; devices not connected to any other system in the merchant environment, which segmentation may achieve; the only transmission of account data is from the device to the processor; the device does not rely on a computer, phone or tablet to connect; no electronic storage; whatever account data is kept exists only on paper and never arrives electronically.

• Requirement 1: Network Security Controls

1.2.3 an accurate network diagram of connections between the cardholder data environment (CDE) and other networks; 1.2.5 identified and approved services, protocols and ports; 1.2.6 security features for any insecure ones in use; 1.3.1 and 1.3.2 inbound and outbound traffic restricted to what is necessary; 1.3.3 controls between wireless networks and the CDE; 1.4.3 anti-spoofing measures.

• Requirement 2: Secure Configurations

2.2.2 vendor default accounts changed or removed; 2.2.7 all non-console administrative access encrypted with strong cryptography; 2.3.1 and 2.3.2 wireless defaults changed and wireless encryption keys rotated when personnel leave or keys are suspected of compromise.

• Requirements 3 and 4: Account Data at Rest and in Transit

3.1.1 policies for stored account data; 3.3.1 sensitive authentication data not stored after authorization, with 3.3.1.1 to 3.3.1.3 covering track data, card verification code and PIN; 3.4.1 PAN masked when displayed; 4.2.1 strong cryptography and trusted keys and certificates for PAN sent over open, public networks, with the certificate-validity bullet a best practice until 31 March 2025.

• Requirements 6, 7 and 8: Vulnerabilities, Access and Authentication

6.3.1 security vulnerabilities identified and risk-ranked; 6.3.3 critical patches applied within one month; 7.2.2 access assigned by job function and least privilege; 8.1.1 authentication policies; 8.2.2 no group, shared or generic IDs; 8.2.7 third-party accounts enabled only when needed and monitored; 8.4.3 multi-factor authentication for all remote network access from outside the network.

• Requirement 9: Physical Access

9.1.1 physical security policies; 9.2.2 controls on publicly accessible network jacks; 9.4.1 to 9.4.6 physical security, classification, approved transport and destruction of media, with 9.4.1.1 on offline backups; 9.5.1 protection of POI devices against tampering and substitution, with 9.5.1.1 a device list, 9.5.1.2 periodic inspection and 9.5.1.3 training.

• Requirements 11 and 12: Testing and Policy

11.3.2 external vulnerability scans at least every three months by a PCI SSC Approved Scanning Vendor, with rescans until a passing result; 11.4.5 penetration tests of segmentation controls at least every 12 months; 12.1.1 to 12.1.3 the information security policy; 12.6.1 security awareness; 12.8.1 to 12.8.5 third-party service provider management; 12.10.1 an incident response plan.

• Attestation of Compliance

Part 1 contact and assessor details; Part 2a to 2f channels, role, environment, facilities, validated products and service providers; Part 2g a summary of responses for the ten requirements; Part 2h the eligibility certification; Part 3 the status (Compliant when every requirement is In Place, In Place with CCW or Not Applicable; Non-Compliant with a target date; or Compliant but with Legal exception), signatures in 3a to 3d; Part 4 the action plan, completed only on request.

What does it cover?

SAQ B-IP covers merchants, card-present or mail and telephone order, whose account data is handled only by standalone IP-connected PTS POI devices that send it straight to the processor and that store no account data on any computer system. Its requirements reach the devices, the network segment and wireless environment around them, the people who administer and handle them, the paper records that may result and the third-party service providers involved. It does not cover e-commerce channels, service providers, or merchants whose terminals depend on a separate computer, phone or tablet to reach the processor, and merchants with SCR or SCRP devices must use a different SAQ.

What are its objectives?

The questionnaire is designed to let an eligible merchant demonstrate the following:

That the seven eligibility criteria hold for the payment channel being assessed, as certified in Part 2h and described in Parts 2a to 2f.

That the network around the terminals is controlled: a current diagram, restricted inbound and outbound traffic, protected wireless, encrypted administrative access and tested segmentation (Requirements 1, 2 and 11.4.5).

That account data is not stored after authorization and is encrypted in transit with trusted certificates (Requirements 3 and 4).

That access is limited, individual and, for remote access, protected by multi-factor authentication, and that patches and quarterly ASV scans keep the devices and network current (Requirements 6, 7, 8 and 11.3.2).

That policies, awareness, service provider oversight and incident response exist (Requirement 12), and that the result is signed in an Attestation of Compliance that an acquirer can accept.

Framework in Context

SAQ B-IP sits between SAQ B, for dial-out terminals that never touch a network, and SAQ C, for merchant-run payment application systems connected to the Internet, which carries all twelve requirements. The device requirements behind it come from the Council's PIN Transaction Security POI program and its published approval lists, and the scanning requirement relies on the ASV Program Guide. Every SAQ validates against PCI DSS v4.0.1 (June 2024); the Council's SAQ Instructions and Guidelines document, republished with the v4.0.1 SAQs, explains how to choose among them.

Common Framework Mappings

SAQ B-IP inherits the mappings of the parent standard for the ten requirements it contains; the network, configuration, access and testing controls it tests correspond to control families in the frameworks listed below.

Mapped frameworks include:

ISO 27001:2022

ISO 27002:2022

NIST CSF 2.0

NIST 800-53 Rev.5

PCI DSS 4.0.1

SOC 2