PCI DSS is the security standard that applies the moment your business touches payment card data, enforced by the card brands and your acquiring bank rather than by any law.
The short answer
PCI DSS is the Payment Card Industry Data Security Standard: twelve requirements covering how cardholder data is stored, transmitted and protected. How you validate depends on transaction volume, from a self-assessment questionnaire at the low end to an on-site assessment by a qualified assessor at the high end. Version 4.0.1 is the only active version, and every requirement in it has been mandatory since 31 March 2025.
The single most useful thing to understand early is that PCI DSS scope drives cost. What determines your effort is not the twelve requirements themselves but how much of your infrastructure sits inside the cardholder data environment.
On this page
The twelve PCI DSS requirements
The twelve PCI DSS requirements group into six goals. The grouping matters more than the numbering, because it shows where the work concentrates.
| Goal | Requirements |
|---|---|
| Build and maintain a secure network | 1. Network security controls · 2. Secure configurations, no vendor defaults |
| Protect account data | 3. Protect stored data · 4. Encrypt transmission across open networks |
| Maintain a vulnerability management programme | 5. Protect against malicious software · 6. Develop and maintain secure systems |
| Implement strong access control | 7. Restrict access by business need · 8. Identify users and authenticate access · 9. Restrict physical access |
| Monitor and test networks | 10. Log and monitor all access · 11. Test security regularly |
| Maintain an information security policy | 12. Support the programme with organisational policies |
Requirement 8 is where identity and access management lands, requirement 10 is logging and monitoring, and requirement 11 pulls in scanning and penetration testing. Requirement 12 is the governance layer, including a tested incident response plan.
What changed in PCI DSS version 4.x
PCI DSS version 4.0 introduced 64 new or updated requirements. Thirteen applied immediately. The remaining 51 were designated future-dated best practices and became mandatory on 31 March 2025, which means any assessment from that date scores all of them as fully in scope with no grace period.
| Change | What it means in practice |
|---|---|
| MFA for all CDE access | Requirement 8.4.2 extends multi-factor authentication beyond administrators and remote users to every account entering the cardholder data environment |
| Payment page script inventory | Requirement 6.4.3 asks for an authorised inventory of every script running on a payment page, which fails on governance gaps more often than on technology |
| Payment page tamper detection | Requirement 11.6.1 requires detection of unauthorised changes to payment pages, aimed squarely at skimming attacks |
| Authenticated internal scanning | Internal vulnerability scans must now run with credentials rather than unauthenticated |
| Targeted risk analysis | Several requirements let you set your own frequency, provided a documented risk analysis justifies it |
| Customised approach | You may meet a requirement’s objective with a different control, if you can evidence that it achieves the same outcome |
Check which version your last assessment used
PCI DSS 3.2.1 retired on 31 March 2024 and 4.0 retired on 31 December 2024, leaving 4.0.1 as the only active version. An organisation that validated in 2024 and treated the future-dated items as optional will fail its next assessment unless those controls are now in place. A successor version is in development, with no release date announced.
Which PCI DSS level applies
PCI DSS levels are set by annual transaction volume per card brand, and the thresholds vary slightly between brands. The pattern below is the common shape.
| Level | Rough volume | How you validate |
|---|---|---|
| Level 1 | Over 6 million transactions a year | Annual Report on Compliance by a qualified security assessor, plus quarterly external scans by an approved vendor |
| Level 2 | 1 to 6 million | Self-assessment questionnaire, sometimes an assessor depending on the brand and acquirer |
| Level 3 | 20,000 to 1 million e-commerce | Self-assessment questionnaire plus quarterly external scans |
| Level 4 | Below the level 3 thresholds | Self-assessment questionnaire, with requirements set by the acquirer |
Which questionnaire you complete depends on how payments are handled. A merchant that fully outsources card entry to a hosted page answers far fewer questions than one that touches card data directly. Your acquirer confirms both the level and the questionnaire type, so ask them before assuming.
PCI DSS scope is most of the work
The PCI DSS cardholder data environment covers every system that stores, processes or transmits card data, plus anything connected to it that could affect its security. Shrinking that boundary is the highest-leverage decision available.
| Technique | Effect on scope |
|---|---|
| Hosted payment page or redirect | Card data never reaches your servers, which cuts scope more than any control you could deploy |
| Tokenisation | A token replaces the card number in your systems, so downstream databases fall out of scope |
| Point-to-point encryption | Card data is encrypted at the terminal, so intermediate systems cannot read it |
| Network segmentation | Isolates the environment so the rest of the estate is not dragged in |
| Storing card numbers | Expands scope sharply and is rarely necessary once tokenisation is in place |
Note that outsourcing card capture reduces your scope without removing it. Payment page script controls still apply, because the page your customer sees is served by you even when the card field is not.
How Osto maps PCI DSS controls
PCI DSS overlaps heavily with what you already need for SOC 2 and ISO 27001. Access control, logging, vulnerability management, secure configuration and incident response appear in all three, worded differently. Osto runs those controls once and maps the evidence across 200 or more frameworks, so the second and third standard cost a fraction of the first.
On the technical side, web and API protection covers requirement 6.6, VAPT and scheduled scanning cover requirement 11, correlated logging covers requirement 10, and MFA enforced at the access gate covers the expanded requirement 8.4.2. Osto is not a qualified security assessor and does not issue a Report on Compliance. What it does is remove the gap between having a control and being able to prove it ran.
Platform walkthrough
One control set, every framework
Access, logging, scanning and web protection run in one platform and map across 200 or more frameworks. Prove the same control to a card brand, an auditor and an enterprise buyer.
Book a demo200+ frameworks mapped · Evidence from your own stack · One platform, everything
Frequently asked questions
What is PCI DSS?
The Payment Card Industry Data Security Standard: twelve requirements governing how organisations that store, process or transmit payment card data must protect it. It is maintained by the PCI Security Standards Council and enforced contractually by the card brands and acquiring banks.
Is PCI DSS a legal requirement?
Not in most jurisdictions. It is a contractual obligation that arrives through your merchant agreement or payment processor. The practical consequences of non-compliance are fines passed down by the acquirer, higher transaction costs, and liability after a breach.
Which version of PCI DSS is current?
Version 4.0.1. Version 3.2.1 retired on 31 March 2024 and version 4.0 retired on 31 December 2024. Every requirement in 4.0.1, including the 51 that were originally future-dated, has been mandatory since 31 March 2025.
What is the cardholder data environment?
Every system that stores, processes or transmits cardholder data, along with any connected system that could affect its security. Defining and shrinking this boundary is the main lever on cost, because everything inside it must meet all applicable requirements.
Does using a payment provider make us compliant?
It reduces your PCI DSS obligations substantially but does not remove them. You still complete a self-assessment questionnaire, and the payment page script and tamper detection requirements can still apply, because the page is served by you even when the card field belongs to the provider.
How does PCI DSS relate to SOC 2 and ISO 27001?
They overlap heavily. PCI DSS, SOC 2 and ISO 27001 all cover access control, logging, vulnerability management and incident response, worded differently in each. Teams that map one control set across frameworks rather than running three separate programmes save most of the duplicated effort.