PCI DSS: The Payment Industry's Armour

The payments industry never stops evolving, and every upgrade plays an important role in building trust with users by protecting their sensitive data. Any business that touches card payments needs to meet a baseline set of security standards that act as its armour.

One such globally recognized standard is PCI DSS.

The PCI Security Standards Council (PCI SSC) created the Payment Card Industry Data Security Standard (PCI DSS) framework to protect credit and debit card transactions and cardholder data from breaches. It is a mandate for every merchant and service provider that stores, processes, or transmits cardholder data to comply with this standard.

How Was PCI DSS Created?

It all began during the internet boom of the late 1990s, when the early stages of e-commerce brought in both excitement and a wave of fraudsters. As retailers, merchants, card networks, and consumers widely adopted web-driven transactions, credit card fraud and scams rose steadily. That's when card networks like American Express, Mastercard, and Visa began digging into the problem to create standards for payment processing systems.

Visa took the lead in 2001 with its "Cardholder Information Security Program" (CISP), followed by other card networks rolling out their own, company-specific standards. But this created a real problem for merchants and POS providers — anyone accepting multiple card networks had to comply with several overlapping, inconsistent standards at once. To fix this, American Express, Discover, JCB, Mastercard, and Visa came together and published PCI DSS version 1.0 in December 2004.

In 2006, these five networks formally established the PCI Security Standards Council (PCI SSC) to manage the ongoing development of PCI DSS and align policy across the industry. The Council's job has stayed the same since: make sure every entity that touches card data is genuinely committed to protecting it.

Where PCI DSS Stands Today: The Move to Version 4.0

For years, PCI DSS 3.2.1 (released May 2018) was the standard every merchant and service provider worked against. That changed with the release of PCI DSS 4.0 in March 2022 — the first major overhaul of the standard in nearly a decade, built to reflect how payments technology, and the threats against it, have evolved since 3.2.1 was written.

The rollout of 4.0 was deliberately staggered to give the industry time to adapt:

• PCI DSS 3.2.1 was retired on March 31, 2024 — from that date, PCI DSS 4.0 became the only active version of the standard.

• A set of "future-dated" requirements — new controls introduced in 4.0 that organizations were given extra time to implement — became mandatory from March 31, 2025.

• The PCI SSC has since published PCI DSS v4.0.1, a minor revision that clarifies and corrects parts of the original 4.0 release without changing its underlying security requirements.

In other words: PCI DSS 4.0 is no longer "the upcoming version" — it is the standard, in full effect, and every merchant, acquirer, and MMS (Merchant Management System) provider handling card data is expected to be assessed against it.

PCI DSS 4.0 was designed around three goals:

1. Continue to meet the security needs of the payments industry, as e-skimming, API-based attacks, and cloud-native infrastructure have reshaped the threat landscape since 3.2.1.

2. Promote security as a continuous process, not a once-a-year audit exercise.

3. Add flexibility for organizations to meet security objectives in ways suited to their own architecture, through a new "customized approach" alongside the traditional "defined approach."

Why Businesses Need to Comply with PCI DSS

With the sheer volume of card transactions taking place every day, a safe payment environment isn't optional — it's the baseline expectation of every customer and partner a business works with. A PCI DSS-compliant business earns customer trust with sensitive card data, which directly supports sales and customer confidence. Because every business relies on partners, acquirers, and other players in the payments chain, being PCI DSS compliant also strengthens a business's reputation and its standing with the partners it depends on.

Data breaches and payment card theft can be significantly reduced when card data is stored securely and monitored continuously. PCI DSS compliance also has a practical side benefit: the discipline it requires — inventorying systems, tracking access, testing regularly — tends to improve overall IT infrastructure efficiency along the way.

PCI DSS Compliance Levels

PCI DSS compliance levels are still defined by the number of annual card transactions a business handles, and this structure hasn't changed with the move to 4.0:

• Level 1: Over 6 million transactions annually

• Level 2: 1 to 6 million transactions annually

• Level 3: 20,000 to 1 million transactions annually

• Level 4: Fewer than 20,000 transactions annually

What has changed is how validation is documented at each level, given 4.0's added emphasis on continuous, evidence-based compliance rather than point-in-time checklists — particularly for Level 1 entities, which require a full Report on Compliance (RoC) from a Qualified Security Assessor (QSA).

Requirements for PCI DSS Compliance

Every system, entity, and component connected to the Cardholder Data Environment (CDE) must comply with PCI DSS. This spans security management, policies, procedures, network architecture, software design, and other protective measures across the business.

PCI DSS 4.0 keeps the same 12 core requirements that have anchored the standard since its earliest versions — but several of them have been meaningfully strengthened to address how card data environments actually look today:

1. Firewall and Network Security Controls

Firewalls (and, more broadly, network security controls) are configured to protect cardholder data from unauthorized access and malware, helping prevention systems keep intruders out of private data.

2. Secure Configurations — No More Default Passwords

Businesses can't use vendor-supplied defaults for system passwords and other security parameters on routers, modems, POS systems, and other third-party products. Basic precautions — changing default credentials, hardening default configurations — remain essential, since generic vendor settings are widely known and easily exploited.

3 & 4. Protection of Stored and Transmitted Cardholder Data

Stored cardholder data must be encrypted with strong, current cryptography, and primary account numbers (PANs) must be regularly scanned and monitored so unencrypted data doesn't slip through. Data must also be encrypted whenever it's transmitted across open, public networks — between payment processors, branch locations, and head offices, for instance — and account numbers should never be shared to locations outside documented, approved flows.

5. Anti-Malware Protection

Every system that interacts with, shares, or stores PAN data must be protected against malware, with anti-malware mechanisms actively maintained and kept current — not installed once and forgotten.

6. Secure Systems and Applications — Now With Payment Page Script Integrity

Organizations must develop and maintain secure systems and applications, patched and updated on a defined schedule. PCI DSS 4.0 adds real teeth here for e-commerce: Requirement 6.4.3 now requires every script that loads and executes on a payment page in the customer's browser to be inventoried, justified by business need, and monitored for unauthorized changes — a direct response to the rise of e-skimming attacks, where malicious JavaScript is injected into checkout pages to steal card data at the point of entry.

7. Restriction of Access by Business Need-to-Know

Access to cardholder data is restricted to what each role genuinely needs, with access rights accurately documented and reviewed on a regular basis.

8. Strong, Unique Authentication — MFA Is Now Everywhere in the CDE

Every person with computer access to cardholder data gets a unique ID and credentials — shared logins are no longer acceptable. PCI DSS 4.0 raises the bar significantly here: multi-factor authentication (Requirement 8.4.2) is now required for all access into the CDE, not just remote or administrative access as under 3.2.1. Minimum password length has also increased from seven to twelve characters, with both numeric and alphabetic characters required.

9. Restriction of Physical Access

Cardholder data — whether written, typed, or stored digitally on physical media — must be kept in a secured location with restricted physical access, and any access must be logged.

10. Logging and Monitoring — With Faster Detection

All access to network resources and cardholder data must be tracked and monitored through access logs, maintained with accuracy since this record directly supports breach investigation and accountability. PCI DSS 4.0 also introduces Requirement 11.6.1, requiring a change- and tamper-detection mechanism for payment pages that alerts on unauthorized modifications to HTTP headers and page content at least weekly — closing a gap that traditional log review alone didn't catch quickly enough.

11. Regular Testing of Security Systems and Processes

Security systems and processes — spanning digital infrastructure, software, and physical locations — must be tested and scanned regularly to catch vulnerabilities before they're exploited.

12. Documented Information Security Policies

Information security policies covering every stage, from data storage to transmission and use, must be documented and maintained for all personnel. PCI DSS 4.0 adds more structure here too, through targeted risk analyses (Requirement 12.3.1): instead of following fixed, prescribed frequencies for certain security activities, organizations can define their own cadence — provided they can justify it with a documented, defensible risk analysis that a QSA can actually test.

What Else Is New in PCI DSS 4.0

A few changes don't map neatly onto a single numbered requirement but are worth understanding on their own:

• The "customized approach." For the first time, PCI DSS allows organizations to design their own control to meet a requirement's underlying security objective, instead of following the prescribed control exactly as written — provided they can demonstrate, through rigorous documentation and testing, that it's just as effective. This offers real flexibility for organizations with sophisticated security engineering, though it comes with a much higher documentation and validation bar than the traditional "defined approach."

• Cloud and modern infrastructure scoping. PCI DSS 4.0 was written with containerized, microservices, and cloud-native environments in mind — infrastructure that barely existed in a meaningful way when 3.2.1 was published — with clearer guidance on scoping dynamic, elastic environments.

• A push toward phishing-resistant authentication. While not universally mandated, PCI DSS 4.0 signals a clear direction: SMS-based one-time passwords are vulnerable to SIM-swapping and interception in ways that authenticator apps and hardware security keys are not, and higher-risk access points are increasingly expected to move toward the latter.

Why This Matters More Than Ever

With PCI DSS 4.0 now fully in effect, "PCI DSS compliant" isn't a static label — it's a continuous, evidence-based commitment that has to hold up under real testing, not just an annual questionnaire. For merchants, acquirers, and MMS providers alike, the standard's objectives remain the same as they've always been: protect cardholder data, reduce fraud, and keep the trust that makes card payments work at scale. What's changed is how rigorously — and how continuously — that trust now needs to be earned.

Subscribe to our newsletter and get the latest fintech news, views, and insights, directly to your inbox.

Follow us on LinkedIn and Twitter for insightful fintech tales curated for curious minds like you.