PCI DSS Network Monitoring for Retail: What Your Firewall Data Needs to Show

Retail networks are rarely simple.

A single retail location may contain point-of-sale systems, payment terminals, staff devices, guest Wi-Fi, security systems, and other connected equipment. Some of these systems may also be maintained remotely by third-party vendors. 

Scale that across dozens of stores, service stations, or branches, and the cardholder data environment can become difficult to monitor, even when the network has been carefully segmented.

This complexity has practical security consequences. In Verizon’s 2025 Data Breach Investigations Report, system intrusion accounted for 53% of retail breaches, up from 36% the previous year. Third-party involvement across all industries also doubled from 15% to 30%.

Effective network monitoring helps retailers identify suspicious activity, unauthorized access, and security controls that are not working as expected. It also supports the logging and review processes required under PCI DSS.

Network segmentation can reduce PCI DSS scope by isolating cardholder data from the rest of the network. Retailers must also be able to verify that those boundaries remain effective as networks and firewall policies change.

By turning existing firewall data into readable reports, dashboards, and alerts, retailers gain a clearer view of network activity. This visibility can support security investigations and PCI DSS compliance efforts without replacing the firewall or introducing another resource-heavy monitoring platform where one is not otherwise required.

PCI DSS Network Monitoring Checklist for Retailers

Check whether your environment provides the visibility and evidence needed to monitor POS systems, vendor access, network segmentation, and unusual firewall activity.

What is PCI DSS?

The Payment Card Industry Data Security Standard, or PCI DSS, is a global security standard designed to protect payment account data. The current version is PCI DSS v4.0.1. It became the only active version supported by the PCI Security Standards Council on 31 December 2024, and its future-dated requirements became effective on 31 March 2025. It applies to organizations that store, process, or transmit cardholder data, as well as systems and service providers that may affect the security of the cardholder data environment

Its 12 requirements are organized around six broad goals:

• Building and maintaining secure networks and systems

• Protecting stored and transmitted cardholder data

• Maintaining a vulnerability management program

• Implementing strong access controls

• Monitoring and testing networks

• Maintaining an information security policy

For retailers, this often extends well beyond the payment terminal itself. Systems do not need to store card data directly to fall within scope. Systems that connect to the CDE, provide security services to it, or could affect its security may also be included. Point-of-sale systems, firewalls, remote access services, network devices, and vendor connections may all form part of the wider cardholder data environment (CDE).

Why PCI DSS compliance is important

For retailers, PCI DSS compliance is both a security requirement and a commercial obligation.

The controls required by PCI DSS help retailers:

• Protect cardholder data from theft and misuse

• Identify and address security weaknesses

• Reduce the likelihood and impact of data breaches

• Demonstrate that appropriate security controls are in place

• Meet obligations set by payment brands and acquiring banks

Failure to maintain PCI DSS compliance can expose retailers to additional costs and commercial consequences. Depending on the circumstances and the retailer’s agreements with its acquiring bank or payment processor, these may include non-compliance fees, higher processing costs, forensic and remediation expenses, reputational damage and, in serious or unresolved cases, restrictions on the ability to accept card payments.

PCI DSS compliance is not a one-off annual exercise. As networks, devices, vendors, and systems change, continuous network monitoring helps retailers confirm their security controls are still working as intended.

How network monitoring supports PCI DSS compliance

Network monitoring helps retailers understand what is happening across the systems and network segments that store, process, transmit, or could affect cardholder data.

Firewalls, VPN services and other network security controls generate large volumes of data about allowed connections, blocked traffic, remote access attempts, security events and traffic moving between network segments. The challenge is turning that raw data into information the IT team can review, investigate and use to support compliance assessments.

This is particularly relevant to PCI DSS Requirement 10, which requires access to system components and cardholder data to be logged and monitored. Under PCI DSS v4.0.1, logs from security systems and in-scope components must be reviewed at least daily. In contrast, logs from other in-scope components must be reviewed at a frequency determined by the organization’s targeted risk analysis. Automated mechanisms are also required to support audit-log reviews.

For retailers, effective network monitoring strengthens their security posture and supports compliance with PCI DSS by helping teams:

• Review access to cardholder data and payment-related systems

• Monitor network traffic between the cardholder data environment and other parts of the network

• Check whether PCI DSS network segmentation is working as intended

• Identify activity that may indicate potential security threats

• Investigate remote access, VPN activity and third-party vendor connections

• Confirm that firewall rules are helping restrict access to sensitive data

• Review security events from firewalls and other network security controls

• Retain evidence that required log reviews and investigations are taking place

Network monitoring does not replace strong access control measures, intrusion detection systems, file integrity monitoring tools, vulnerability scanning, or other necessary security controls.

It does help retailers maintain a clearer view of their security posture by showing whether network activity aligns with the expected design. During an assessment, reports and documented investigations can help show that relevant network activity is being actively reviewed rather than simply retained.

What effective PCI DSS log monitoring needs to show

Collecting logs is only the first step. Retailers also need a repeatable way to identify activity that warrants investigation and record what happened next.

For retailers, that means being able to see more than whether systems are connected and traffic is flowing.

Effective monitoring should help answer these questions:

• Are POS systems communicating only with expected services?

• Is traffic crossing between network segments that should remain isolated?

• Are third-party vendors using only approved remote access paths?

• Are there unusual VPN connections or repeated failed login attempts?

• Has a device suddenly transferred an abnormal amount of data?

• Are systems connecting to unexpected countries and cloud services?

• Are critical firewall, logging, or segmentation controls failing or no longer sending data?

• Can the team show when an alert was reviewed, what was found, and what action was taken?

What retailers should monitor in and around the cardholder data environment?

Point-of-sale and payment systems

POS systems should generate a relatively consistent set of connections based on their role. A terminal may regularly communicate with payment processors, update services, inventory platforms, approved vendor infrastructure, DNS services that resolve domain names, and NTP services that keep its clock accurate.

Activity outside that baseline should be investigated.

Examples include:

• A POS device initiating a connection to a new external IP address

• Traffic to a country or cloud service not previously associated with the system

• Use of an unexpected remote access application such as TeamViewer or RDP

• A sudden increase in outbound traffic or session volume

• Communication with staff, guest or unrelated operational network segments

• Connections occurring outside normal transaction or maintenance periods

A baseline should not be treated as self-authorizing. Expected activity should still be checked against the retailer’s documented data flows, approved services and firewall policies.

The activity may be legitimate, such as a software update or vendor support session. It may also indicate a firewall rule that is too broad, an incorrectly configured application, compromised credentials, or malware attempting to establish command-and-control traffic.

For the sysadmin, the question is not simply whether the firewall allowed the connection. It is whether the connection makes sense for that device.

Remote and third-party access

Retailers often rely on external providers to maintain payment terminals, POS software, fuel pumps and other connected equipment.

That access should be restricted to the systems, services and time periods required for the job. PCI DSS also requires multi-factor authentication for remote access that could lead into the CDE, including access by vendors and third parties.

Retail IT teams need visibility over:

• When a vendor connects

• The source IP address, country, and remote access method

• Which internal IP addresses and network segments are reached

• Which ports and applications are used

• How long the session remains active

• Whether access occurs outside approved maintenance windows

• Whether the same account or tool appears elsewhere on the network

• Whether repeated failed attempts precede a successful connection

A vendor may need access to a single POS controller at a single location. That does not mean the same connection should be able to reach every store, server, or device in the cardholder data environment.

Remote access should be treated as a controlled exception, not a permanent trusted path.

Traffic between network segments

Where the cardholder data environment is segmented, retailers should monitor traffic crossing the firewall-enforced boundaries around it.

Monitoring can identify unexpected traffic across those boundaries, but it does not replace the penetration testing required to validate segmentation. Under PCI DSS v4.0.1, segmentation controls must generally be tested at least annually and after changes. Service providers have additional six-monthly testing requirements.

Useful checks include:

• Guest Wi-Fi attempting to reach POS or payment systems

• Staff devices communicating directly with the payment infrastructure

• Vendor networks accessing systems outside their approved scope

• Operational devices, such as kiosks or fuel pumps, contacting unrelated corporate systems

• New connections between VLANs or security zones

• Traffic using ports or protocols not included in the documented design

An allowed connection is not automatically an expected connection.

If traffic repeatedly crosses a boundary that should be tightly controlled, the IT team may need to review the firewall policy, routing, device configuration, or original segmentation design.

Unusual outbound traffic

Unexpected outbound traffic can be an early sign that a device or account requires investigation.

Examples include:

• Connections to newly observed domains

• Traffic to known hosting or anonymization services

• A device communicating with a new country

• Persistent beacon-like traffic at regular intervals

• A payment-related device generating traffic outside its normal role

Not every anomaly will lead back to a security breach.

A large transfer may be a legitimate software update. Regular outbound connections may be an approved service checking in. The same patterns may indicate malware, insider threats, compromised credentials or an unauthorized remote access tool.

The immediate task is to establish whether the activity has an approved business purpose, matches the device’s documented role and falls within the expected destination, timing and traffic profile. If it does not, the team has a clear reason to investigate.

PCI DSS network monitoring in a real retail environment

One of our US customers, a multi-site fuel and convenience retailer, uses Fastvue Reporter's firewall reporting software to monitor store networks, POS systems, VPN connections and equipment maintained remotely by third-party vendors.

As a Level 1 merchant, the retailer relies on ongoing network visibility to support its wider PCI DSS compliance program. This means network monitoring is not simply a preference of the security team - it is an integral player in the company's wider compliance processes.

The IT team uses firewall reporting to:

• Review unusually large data transfers

• Monitor POS systems by IP address

• Check for unexpected remote access tools

• Investigate connections to unfamiliar countries

• Review vendor traffic to specific devices

• Create alerts for blocked threats and suspicious activity

• Share readable reports with external IT consultants when further investigation was needed

In one case, the IT team spotted payment-related equipment talking to infrastructure in another country, not long after a vendor upgrade.

Obviously this did not automatically mean a breach had occurred. But it is exactly the kind of data security teams need. A fuel pump, POS system or payment device might legitimately need to contact vendor infrastructure for updates, remote diagnostics or configuration changes. Firewall reporting allows teams to confirm whether that traffic matches an approved vendor, expected destination, known service, and normal maintenance pattern. Think of it like a sanity check for your firewall.

In another case, the retailer blocked TeamViewer as a general rule but allowed it for one approved equipment provider. Fastvue Reporter for IT allowed the IT team to confirm that the remote access tool was not appearing elsewhere on the network.

From approved exception to verified activity

Firewall reporting can support a practical control loop for managing vendor and remote-access exceptions:

1. Approve the exception scope. Confirm the business reason for the access, the vendor involved, the system they need to reach, the approved access method, and when access should be available. For example, a fuel equipment provider may need remote access to maintain one controller at one site. That does not mean the same access path should reach every store, server or device in the cardholder data environment.

2. Create a narrow firewall policy Configure a dedicated firewall policy for the exception rather than reusing a broad rule. Limit the source, destination, port, protocol, user group and schedule wherever possible. If the vendor only needs access from a known IP range to a specific POS controller, the firewall rule should reflect that.

3. Enable logging and send relevant firewall data to Fastvue Configure the firewall to log the allowed and blocked activity needed to review the exception. Fastvue can only report on the data it receives from the firewall, so the exception needs to be logged properly, and the firewall must be configured as a Fastvue source.

4. Monitor the exception in Fastvue Use Fastvue dashboards, reports, and alerts to review how the exception is being used. This may include allowed sessions through the rule, source IPs hitting the policy, activity timelines, unusual bandwidth, or activity outside the expected pattern.

5. Investigate and tighten the control If the activity matches the approved pattern, retain the scheduled report and any review or investigation record required by the organization’s compliance process. If it does not, investigate the source IP, user, device, timing and data volume, then update the firewall control if required. This may mean narrowing the rule, changing the schedule, blocking an unexpected source or removing access that is no longer needed.

Download the PCI DSS Network Monitoring Checklist for Retailers

Your firewall is almost certainly generating logs. The more useful question is whether your team can turn them into a repeatable review and investigation process. 

Use this PCI DSS Network Monitoring Checklist for Retailers to assess whether your environment gives you enough visibility to:

• Identify the systems, network segments and firewall policies affecting the CDE

• Review POS, VPN, vendor and cross-segment activity

• Investigate unexpected destinations, traffic volumes and blocked threats

• Record who reviewed significant events and what action was taken

• Confirm that required evidence can be retained and produced for an assessment

How Fastvue supports PCI DSS network monitoring

Fastvue Reporter turns firewall logs into readable reports, dashboards and alerts that help retail IT teams review activity in and around the cardholder data environment.

Instead of searching individual firewall logs, IT teams can review activity by user, device, source IP, destination IP, application, country, firewall rule and traffic volume. This makes it easier to investigate unusual activity involving POS systems, payment-related devices, vendor access and traffic crossing firewall-enforced network segments.

For PCI DSS network monitoring, Fastvue can help retailers:

• Identify the firewall policies allowing or blocking activity

• Drill into source and destination IP addresses

• Investigate unusual traffic volumes and destinations

• Create alerts for supported security events, bandwidth thresholds and other defined traffic conditions

• Generate scheduled reports

• Export or share reports

The firewall remains the control point. It allows, blocks, and enforces the access policy.

Fastvue provides the reporting layer that shows what happened, when it happened, which rule or policy was involved, and whether the activity needs further investigation.

How Fastvue fits into broader PCI DSS requirements

Fastvue does not replace the security controls required for PCI DSS compliance.

Retailers will still need the other controls applicable to their environment, including access controls, intrusion detection, file integrity monitoring, vulnerability management, penetration testing, authentication, encryption and secure configuration.

Fastvue helps retailers review and evidence the network activity already recorded by their firewall. This is particularly useful where firewall policies restrict access to the CDE, enforce segmentation or control remote access to POS systems, payment devices and vendor-managed equipment.

Fastvue does not configure firewall rules, enforce access controls or determine whether every unusual connection is malicious. It provides the visibility IT teams need to investigate firewall activity and document their findings as part of a broader PCI DSS compliance program.