Skip to main content
Compliance Requirements

From Firewalls to "Network Security Controls": What PCI DSS v4 Changed

PCI DSS v4 stopped talking about firewalls and started talking about network security controls. Here is what the rename actually means, and which of Requirement 1's rules a small UK merchant genuinely has to satisfy.

Fraud Defence First
28 July 2026
7 min read

For most of PCI DSS's life, Requirement 1 was about firewalls. In version 4 it is about 'network security controls' — a change of vocabulary that sounds like standards-committee tidying but genuinely reflects how businesses now run their networks. This guide explains what the rename means, which parts of Requirement 1 a typical UK merchant actually has to satisfy, and which parts your payment provider is already handling. For the full list of what version 4 changed, see our summary of PCI DSS v4.0.1.

Why did the wording change?

Because 'firewall' had stopped describing the thing. When the requirement was written, the boundary between your network and the internet was a physical box in a cupboard. Today that boundary might be a cloud provider's security group, a virtual appliance, a software-defined rule set, a hosting platform's built-in controls, or a feature of the business router your internet provider supplied — often several of these at once. The standard now uses 'network security control', or NSC, to mean any technology that enforces rules about what traffic is allowed between networks, regardless of what it is called or where it runs.

The practical consequence is that you can no longer answer the question by pointing at a box. The requirement asks whether the controls exist and are configured deliberately, not whether you bought a product with the right label. For a business whose payment environment sits largely in a provider's cloud, that is a fairer question than the old one.

Does Requirement 1 apply to you at all?

This is the first thing to establish, because for a meaningful number of small merchants the honest answer is 'barely'. If you qualify for the shortest questionnaire — fully outsourced e-commerce, where card data never touches your systems — Requirement 1 is largely handled by your provider and does not appear in your assessment in any depth. If you use an internet-connected terminal, a till system, or take payments through your own network, it applies to you directly. Our guide to the card-present SAQ types sets out which questionnaire matches your setup, and therefore how much of this you own.

The scoping question underneath it is more important than the requirement itself: which of your systems are in the cardholder data environment, and what else can reach them? A flat network — where the till, the office laptops, the guest Wi-Fi and the CCTV all sit together — pulls everything into scope, and then all of Requirement 1 applies to all of it. Separating the payment systems is not mandatory, but it is almost always cheaper than the alternative.

What does Requirement 1 actually ask for?

Stripped of the formal language, the rules that matter to a small merchant are these:

  • Know what your network looks like. The standard expects a current network diagram showing how the payment environment connects to everything else, and a data-flow diagram showing where account data actually goes. Most small businesses have neither, and drawing them usually reveals a surprise.
  • Allow only traffic you can justify. Inbound traffic to the payment environment is restricted to what is necessary, and everything else is denied. Outbound traffic is restricted too — this is the one businesses forget, and it is what stops a compromised till from talking to an attacker's server.
  • Keep a list of the services, protocols and ports you permit, with a business reason for each. Anything insecure that you genuinely need must have compensating protections documented.
  • Put a control between any wireless network and the payment environment, whether or not the wireless is 'yours'.
  • Do not let systems holding card data be reachable directly from the internet, and do not leak internal addressing to the outside world.
  • Secure the configuration files themselves, so the live rules and the stored rules cannot silently drift apart.
  • Manage changes. Network changes go through an approval step rather than being made on the fly and remembered later.

How often do the rules have to be reviewed?

At least once every six months. That review is not a glance at the dashboard — it means going through the rule set and asking, for each rule, whether the business reason for it still exists. Rule sets accumulate: a temporary opening for a supplier's engineer in March is still there in December, still pointing at a service nobody uses, still reachable from the internet. Six-monthly review exists because that specific pattern causes real breaches.

Write down what you reviewed and when. An undocumented review is indistinguishable from no review during an assessment, and this is one of the easiest pieces of evidence to produce if you simply keep a dated note each time.

What about Wi-Fi?

Wireless is where small businesses most often undo their own segmentation. The pattern is familiar: a guest network is set up for customers, then someone connects a tablet, a printer or a stock scanner to it because it was the network with the password everyone knew. From that point the guest network has a route to the business, and every customer in the building is on the same side of the boundary as your payment systems.

The fix is straightforward and usually free with equipment you already own: guest wireless entirely separated with no route to internal systems, business wireless on strong modern encryption with a key that is not written on a chalkboard, default administrative passwords on access points changed, and a periodic look for access points nobody authorised — including the helpful one somebody plugged in to improve coverage in the stockroom.

What about laptops, phones and home working?

Version 4 is explicit about a gap that used to be argued over: a device that can reach both the internet and your payment environment — a laptop used at home and in the office, for instance — has to have security controls of its own. In practice that means the device is managed, patched, protected against malware, and not simply trusted because it belongs to a director.

Remote administration deserves particular care here, because it is the most common route into a small business's payment systems — enable it for the job, require multi-factor authentication on it, and switch it off again afterwards. Our PCI DSS compliance checklist covers this alongside the other controls worth working through.

Is the router from your internet provider good enough?

Sometimes, and it depends less on the hardware than on what you do with it. A consumer router with its default administrative password unchanged, remote management enabled and no separation between guest and business traffic is a liability whoever supplied it. The same box, with the administrative password changed, remote management off, firmware kept current, guest wireless isolated and unused services switched off, may be perfectly adequate for a small merchant using a standalone terminal.

If you want a simple, externally-defined baseline for this, the government-backed Cyber Essentials scheme covers much the same ground in plainer language, and the two align well. Our comparison of Cyber Essentials and PCI DSS explains where they overlap and where they do not.

Key takeaways

  • 'Network security control' replaced 'firewall' because the boundary is now often virtual, cloud-based or built into someone else's platform.
  • How much of Requirement 1 you own depends entirely on your scope — fully outsourced e-commerce owns very little, an internet-connected till owns most of it.
  • Restrict outbound traffic as well as inbound; the outbound rule is what limits the damage when something does get in.
  • Review your rule set at least every six months and keep a dated record that you did.
  • Separate guest wireless completely, and treat any device that touches both the internet and your payment systems as needing controls of its own.

Working out which of these apply to your business — and which your provider already covers — is exactly the scoping work that makes compliance simple or painful. Fraud Defence First's fully managed PCI compliance service maps your payment environment, establishes what is genuinely in scope, completes the right questionnaire with you and files it with your acquirer, for a flat £100 + VAT a year.

Need Expert PCI Compliance Help?

Our PCI compliance specialists are here to guide your business through the certification process. Get personalised advice and ensure your business stays compliant.

28/07/2026
8 min

SAQ B, B-IP, C-VT and P2PE: the Card-Present SAQ Types Explained

Most PCI guidance is written for online shops. If you take payments over a counter, your questionnaire is one of five card-present types — and the difference between them is the difference between 22 questions and 249.

Read Article
14/07/2026
6 min

'My Provider Handles PCI for Me' — What Your Acquirer Actually Does (and Doesn't)

Your payment provider secures its systems — but PCI validation, your premises and your staff stay your responsibility. Here is where the line really sits, and how to stop paying for the misunderstanding.

Read Article
14/07/2026
6 min

Why Your Card Machine Provider Charges a PCI Fee — and How to Stop It

That PCI charge on your card machine statement is usually two different fees in disguise — and the larger one can normally be removed. Here is why providers charge it and how to stop paying.

Read Article