You run a P2PE (Point-to-Point Encryption) certified checkout environment. Your POI (Point of Interaction) devices encrypt card data at the swipe, and your assessor has signed off on the solution. But here's the question your QSA (Qualified Security Assessor) will eventually ask: Is that POS (Point of Sale) system next to the POI in scope or out of scope?
The answer hinges on a critical distinction many teams overlook until they're deep into their assessment.
The Problem: Network Connections Overrule Physical Connections
Your POS connects to your POI via a serial or USB cable, which only passes transaction totals and approval codes. The P2PE certification process has already shown that the POI won't leak cardholder data through that cable. However, your POS also shares a network with the POI, and that network connection, not the cable, determines your scope.
Under PCI DSS, a system is "connected to" if it's on a different network but can access the Cardholder Data Environment (CDE) or impact its configuration or security. In a P2PE environment, your POI is your CDE. Any system that can reach it over the network is a connected-to system, even if it doesn't handle card data.
If your POS gets compromised, an attacker could pivot to your POI over the shared network. The risk may be low, but it's not zero, making your POS in scope.
What You Need Before Starting
Before scoping your POS infrastructure, gather these items:
Network documentation
- Current network diagrams showing all POS and POI connections
- VLAN configurations and routing tables
- Firewall rules between POS and POI subnets
P2PE certification materials
- Your P2PE solution's certification letter
- Documentation of approved connection methods
- List of certified POI models in your environment
Software inventory
- Payment utilities running on POS systems (e.g., WinEPS, OpenEPS)
- Version numbers and configuration files
- Any middleware or payment gateway clients
Current scope documentation
- Your most recent network segmentation testing results
- Existing PCI DSS scope boundary definitions
- Previous assessor notes on connected-to systems
Step-by-Step Implementation
1. Map Your Network Topology
Start with your physical connections. Document every POS-to-POI link: serial, USB, Ethernet. Note which connections carry transaction data versus network traffic.
Next, map your IP addressing. Identify which subnet each POS and POI occupies. Don't assume they're segmented just because they're in different VLANs. Check your routing tables to verify whether POS systems can initiate connections to POI devices.
Run a basic connectivity test from a POS terminal:
ping [POI_IP_address]
telnet [POI_IP_address] [common_ports]
If the POS can reach the POI over the network, you've confirmed a connected-to relationship.
2. Identify Your Payment Utility Architecture
Check which software utility your POS systems use to communicate with POIs. This distinction is crucial.
If you're running WinEPS or a similar utility that terminates encryption, your POS becomes the encryption endpoint. The transaction exists in clear text in the POS memory before re-encryption for transmission to the processor. This creates a man-in-the-middle attack vector, making your POS definitively in scope.
If you're running OpenEPS or equivalent pass-through utilities, the encrypted tunnel runs directly from the POI to the processor. The POS cannot decrypt the transaction stream. The utility only forwards encrypted data. This architecture keeps the POS out of scope for most requirements, though it remains a connected-to system due to the network relationship.
To verify which model you're using, check your utility's configuration files and review the P2PE solution documentation. The certification materials will specify whether the POS is an encryption endpoint.
3. Document Scope Boundaries
Create a scope matrix that lists every POS system and its relationship to the CDE:
| System ID | Network Segment | Payment Utility | Encryption Endpoint? | In Scope? |
|---|---|---|---|---|
| POS-01 | VLAN 10 | WinEPS 2.x | Yes | Yes |
| POS-02 | VLAN 10 | OpenEPS 3.x | No | Connected-to only |
For systems running utilities like WinEPS where clear-text card data exists in memory, apply full PCI DSS requirements. These systems handle cardholder data, even if only briefly.
For systems running pass-through utilities like OpenEPS, apply connected-to system requirements. Focus on Requirement 1 (network segmentation), Requirement 5 (anti-malware), Requirement 6 (secure configuration), and Requirement 10 (logging).
4. Implement Segmentation Controls
Even if your POS stays out of scope due to pass-through encryption, you need network segmentation between POS and POI systems.
Configure firewall rules that limit POS-to-POI communication to only required protocols and ports. Block all other traffic. A typical ruleset might allow:
Source: POS subnet
Destination: POI subnet
Protocol: TCP
Ports: [processor-specific ports only]
Action: Allow
Source: POS subnet
Destination: POI subnet
Protocol: Any
Ports: Any
Action: Deny
Document these rules in your network segmentation testing procedures. Your assessor will verify them during annual validation.
5. Address Legacy Assumptions
Review any historical scope decisions with fresh eyes. The Target breach in 2013 happened because teams assumed WinEPS operated like OpenEPS. It doesn't. If your organization made similar assumptions years ago, those decisions may still be embedded in your current scope documentation.
Pull your previous Reports on Compliance and Self-Assessment Questionnaires. Look for statements about POS systems being out of scope. Verify the technical basis for those statements still holds.
Validation: How to Verify It Works
Test your scope boundaries using these verification steps:
Network segmentation validation
- Attempt unauthorized connections from POS to POI
- Verify firewall logs show blocked traffic
- Confirm only approved protocols pass through
Payment utility verification
- Review memory dumps during test transactions (in a controlled environment)
- Confirm clear-text card data appears only where expected
- Validate encryption endpoints match your documentation
Scope documentation review
- Have a second team member independently map the same environment
- Compare results to identify gaps or inconsistencies
- Present findings to your QSA before the formal assessment
Run these tests quarterly, not just before your annual assessment. Network changes happen. A VLAN reconfiguration or new payment terminal can alter your scope overnight.
Maintenance and Ongoing Tasks
Monthly
- Review firewall logs for unexpected POS-to-POI traffic patterns
- Verify no new payment utilities have been installed
- Check for POS system configuration changes
Quarterly
- Re-run network segmentation tests
- Update scope documentation for any infrastructure changes
- Review P2PE certification status for all POI models
Annually
- Conduct full scope validation before your PCI assessment
- Review lessons from recent payment breaches for new threat patterns
- Evaluate whether your payment utility architecture still meets your risk tolerance
When you add new POS systems or change payment processors, repeat the scoping analysis from step one. Don't inherit assumptions from your existing documentation.
The connected-to determination isn't about whether your POS touches card data. It's about whether a compromised POS could threaten your POI. Answer that question honestly, and your scope boundaries will follow.
