PCI DSS Requirement 4 – Explained
PCI DSS stands for Payment Card Industry Data Security Standard. It’s a set of globally recognised security requirements designed to ensure that businesses protect payment card data. This article focuses on Requirement 4 of PCI DSS v4.0.1 – what it means, how it’s evolved from version 3.2.1, and what your organisation needs to do to stay compliant.
For more on PCI DSS, see our Ultimate Guide.
What is PCI DSS Requirement 4?
Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks
Requirement 4 ensures that any time cardholder data is transmitted over public or untrusted networks – such as the internet or wireless networks – it is protected using strong encryption. Attackers often target data as it moves between systems. Encrypting it in transit makes that data unreadable, even if intercepted.
Why is Requirement 4 Important?
Without proper encryption, sensitive data such as the Primary Account Number (PAN) can be intercepted and used for fraud. Transmission over open networks – such as public Wi-Fi, partner integrations, or cloud-based systems – increases this risk.
Requirement 4 helps prevent this by ensuring:
- Cardholder data is encrypted before it leaves the sender’s environment
- Only trusted recipients with appropriate decryption capabilities can access the information
- Strong protocols and certificates are used to protect against modern threats (such as man-in-the-middle attacks)
What’s changed in PCI DSS v4.0.1?
The main principles of Requirement 4 remain consistent in v4.0.1 – but there are important updates:
- More emphasis on the use of strong cryptography – aligned with current industry standards (e.g. TLS 1.2 or higher)
- New controls for segregating transmission environments to ensure only trusted connections are used
- Enhanced guidance around wireless networks and the encryption of cardholder data when transmitted over them
- Support for the customised approach, allowing organisations with mature risk management to tailor how they meet the requirement
A breakdown of Requirement 4
4.1 – Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and understood.
Organisations must define, document, and communicate clear policies and procedures for protecting PAN in transit. These procedures must include expectations for secure protocols, approved encryption methods, certificate management, and oversight of cryptographic controls. All relevant personnel must be aware of and trained in these processes.
Requirement 4.1 also expects roles and responsibilities for protecting PAN in transmission to be explicitly documented and understood. This means assigning ownership of tasks such as configuring secure channels, managing encryption keys or certificates, and monitoring network traffic. A clear understanding of who is responsible helps ensure accountability and consistent application of security measures.
4.2 – PAN is protected with strong cryptography during transmission.
Strong cryptography and security protocols must be implemented to safeguard PAN as it traverses open or untrusted networks. This includes ensuring that only trusted certificates and keys are accepted, that expired or revoked certificates are rejected, and that only secure versions of encryption protocols are used. Insecure versions, weak key lengths, and outdated algorithms must not be permitted.
Encryption strength must be appropriate for the method in use, and system configurations should enforce these controls reliably. While Requirement 4.2 does not mandate encryption at both the data and session level, it is strongly recommended. Encrypting PAN before transmission adds another layer of protection even if the communication channel is already encrypted (e.g. TLS).
To verify compliance, entities should inspect configurations, transmission logs, and encryption certificates. They must confirm that PAN cannot be read in cleartext and that any non-compliant protocols or weak settings are explicitly blocked. This reduces the risk of interception, even in cases where attackers gain access to the transmission medium.
Common challenges with Requirement 4
Many organisations struggle with:
- Using outdated or weak encryption protocols (e.g. TLS 1.0 or self-signed certificates)
- Overlooking transmissions between internal systems routed through public networks
- Sending PAN via insecure channels (e.g. email)
- Not encrypting data before transmission
- Misconfigured wireless networks or forgotten remote access channels
How Securious Can Help
Securious has been a PCI QSAC since 2016, with a team of qualified, highly experienced PCI DSS QSA and 3DS assessors ready to assist you in achieving and maintaining compliance with the latest PCI DSS standards.
Based in Exeter, Devon, we undertake PCI QSA work both nationally and internationally. We are the only PCI DSS QSA company in our region, so organisations in Devon, Cornwall, or Somerset can benefit from cost efficiencies with on-site assessments.
Our mission is to build cyber security confidence. When it comes to PCI DSS compliance, we collaborate with you to make the process as efficient as possible, helping you understand what needs to be done and why.
We offer three options to assist our clients with PCI DSS compliance:
- PCI DSS QSA Gap Analysis & Assessment (one-off fee)
Read more about our PCI DSS QSA Gap Analysis & Assessment by clicking here.
- Managed PCI DSS Compliance Service (fixed monthly fee)
Read more about our Managed PCI DSS Compliance Service by clicking here.
- Assisted PCI DSS SAQ Compliance Service (one-off fee)
Read more about our Assisted PCI DSS SAQ Compliance Service by clicking here.
Get in Touch to Get Started
To learn more, visit our PCI services page, call us on 01392 247 110, email info@securious.co.uk, or send us a message using the form below.
Find out whether you’re ready for PCI DSS v4.0.1 in minutes.