PCI DSS compliance: v4.0.1 requirements, SAQs and training rules

PCI DSS (Payment Card Industry Data Security Standard) is the security standard for organizations that store, process or transmit payment card account data, or that can affect the security of the environment where that data lives. It is owned by the PCI Security Standards Council and enforced by the card brands and acquiring banks through contracts. The current version is PCI DSS v4.0.1, published in June 2024.

For software and IT companies, PCI DSS applies in two ways. You may be a merchant that takes card payments for your own subscriptions, or a service provider whose platform, hosting or support can affect the security of other companies' card data. This guide explains how scope works, what the 12 requirements contain, how compliance is validated and what version 4 changed. Requirement numbers refer to PCI DSS v4.0.1, linked in the sources.

What is PCI DSS and what does it protect?

PCI DSS protects account data, which has two parts:

• Cardholder data: the primary account number (PAN), and when stored with it, the cardholder name, expiration date and service code.
• Sensitive authentication data: full track data from the magnetic stripe or chip, card verification codes (such as CVV2 or CVC2), and PINs or PIN blocks. Sensitive authentication data must not be stored after authorization, even if encrypted (requirement 3.3.1).

The standard applies to the cardholder data environment (CDE): the people, processes and technologies that store, process or transmit account data, plus any system component that is connected to the CDE or could affect its security. Segmentation can reduce scope, but only if it is tested and proven to isolate the CDE.

The PCI Security Standards Council (PCI SSC) was founded by American Express, Discover, JCB, Mastercard and Visa, and UnionPay later joined as a strategic member. The Council writes the standard and trains assessors. It does not enforce compliance. Each card brand runs its own compliance program through the acquiring banks.

Is PCI DSS mandatory or voluntary?

PCI DSS is mandatory by contract, not by law. If you accept card payments, your merchant agreement with your acquirer (or payment processor) requires PCI DSS compliance. If you provide services to merchants or processors that can affect card data security, their contracts and the card brand rules require it from you.

A few jurisdictions refer to PCI DSS in law. Some US states, for example, reference it in data security or breach liability statutes. In most places, though, the obligation comes from the payment card contracts.

Who needs to comply with PCI DSS?

PCI DSS applies to every entity that stores, processes or transmits account data, and to entities that can affect its security. That includes:

• Merchants of every size that accept card payments online, in person or by phone.
• Payment service providers, gateways and processors.
• SaaS platforms that embed payments or store cards for their customers, such as e-commerce, booking, billing and marketplace platforms.
• Hosting, cloud and managed service providers whose infrastructure or administrators can reach a customer's CDE.
• Call centers and BPOs that take card details by phone.
• IT and software development firms that build, run or support payment systems for clients.

A SaaS company that sends all card entry to a PCI DSS compliant payment provider through a hosted page or iframe usually has a much smaller scope than one that handles card numbers on its own servers. It still has some scope, because its own web pages control how the customer reaches the payment form.

Why does PCI DSS matter for SaaS and IT service providers?

• You cannot take cards without it. Acquirers and payment processors require an annual validation of compliance.
• Merchants must manage you. Requirement 12.8 requires every entity to keep a list of third-party service providers, have written agreements, monitor their PCI DSS status at least once every 12 months and know which requirements each provider covers. Your customers will ask for your Attestation of Compliance.
• Service providers have extra duties. Requirement 12.9 requires service providers to acknowledge in writing their responsibility for the security of customer account data and to give customers information about which requirements they manage.
• Breach costs. A card data breach brings forensic investigation, card reissue costs, fraud liability and brand damage, with or without fines.

What are the 12 PCI DSS requirements?

PCI DSS v4.0.1 groups 12 principal requirements under six goals. Each principal requirement contains many sub-requirements, with testing procedures and guidance.

Defined and customized approaches

Version 4 introduced two ways to meet a requirement. The defined approach follows the requirement and its testing procedures as written, which is what most organizations do. The customized approach lets an entity meet the stated objective of a requirement with its own control, backed by a targeted risk analysis and a controls matrix, and tested by an assessor with procedures designed for that control. The customized approach is not available for entities that validate with an SAQ.

What does PCI DSS scope include?

Scoping is where most PCI DSS projects succeed or fail. Requirement 12.5.2 requires you to document and confirm PCI DSS scope at least once every 12 months and after significant changes. Service providers must do it at least once every six months (12.5.2.1).

A scope confirmation identifies:

• All data flows for each payment channel, and every location where account data is stored, processed or transmitted.
• All system components in the CDE, connected to it or able to affect it, including cloud services, identity providers, CI/CD pipelines and admin workstations.
• Segmentation controls and the results of segmentation testing (11.4.5, and every six months for service providers under 11.4.6).
• Connections to third parties with access to the CDE.

Ways software companies shrink scope include sending card entry to a validated payment provider through a redirect or iframe, tokenization so your systems never see full PANs, and point-to-point encryption for card-present payments.

What does PCI DSS mean for SaaS platforms and service providers?

Software companies usually meet PCI DSS in one of three patterns, and each one changes what you are responsible for.

The responsibility matrix

Requirement 12.8.5 requires every entity to keep information about which PCI DSS requirements each third-party service provider manages, which ones the entity manages, and which are shared. Requirement 12.9.2 requires service providers to support their customers' requests for that information and for their PCI DSS compliance status. In practice this is a document, often a spreadsheet, that lists every requirement and says "provider", "customer" or "shared". Cloud providers publish their own. If you are a service provider, writing yours early saves time in every sales cycle and assessment.

Written acknowledgment of responsibility

Requirement 12.9.1 requires service providers to acknowledge in writing to customers that they are responsible for the security of account data they possess or otherwise store, process or transmit on the customer's behalf, or to the extent they could affect the security of the customer's CDE. This usually sits in the master agreement or a security addendum.

Your own vendors

The same rules apply in the other direction. Under 12.8.1 to 12.8.4 you must list the service providers that can affect your account data, keep written agreements, do due diligence before engaging them and monitor their PCI DSS status at least once every 12 months. Collect their current AOCs each year and file them with your evidence.

How is PCI DSS compliance validated?

Compliance is validated once a year. How you validate depends on your role, your transaction volume and how you accept cards. The rules are set by each card brand and your acquirer, not by the PCI SSC.

Report on Compliance (ROC)

A ROC is a detailed assessment by a Qualified Security Assessor (QSA), or by an Internal Security Assessor (ISA) where the brands allow. It is required for the largest merchants and service providers. It comes with an Attestation of Compliance (AOC) signed by the entity and the assessor.

Self-Assessment Questionnaire (SAQ)

Smaller merchants and some service providers complete an SAQ and sign an AOC themselves. The SAQ type depends on how you take payments. The main types are:

In January 2025 the Council revised SAQ A. It removed requirements 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. In August 2026 it revised FAQ 1331 to clarify that merchants assessed with a ROC must consult their acquirer or payment brand, not only their QSA, before treating those requirements as not applicable.

Merchant and service provider levels

Each card brand defines merchant and service provider levels by annual transaction volume, and the highest-volume level generally requires a ROC by a QSA. Thresholds differ by brand and can change, and acquirers can require more than the brand minimum. Visa, for example, says merchant levels depend on meeting transaction thresholds in one country or with one acquirer per year, and that service providers must validate at least every 12 months. Ask your acquirer which level you are and what it needs from you.

Vulnerability scans

Most validation also requires quarterly external vulnerability scans by a PCI SSC Approved Scanning Vendor (ASV), with passing results (11.3.2), and quarterly internal scans (11.3.1).

What security awareness training does PCI DSS require?

PCI DSS is one of the few security standards with specific, testable training requirements. Requirement 12.6 covers everyone:

• 12.6.1 A formal security awareness program makes all personnel aware of the entity's information security policy and procedures and their role in protecting cardholder data.
• 12.6.2 The program is reviewed at least once every 12 months and updated as needed to address new threats and vulnerabilities.
• 12.6.3 Personnel receive security awareness training upon hire and at least once every 12 months. The program uses multiple methods of communicating awareness and educating personnel. Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures.
• 12.6.3.1 Training includes awareness of threats and vulnerabilities that could affect the security of cardholder data, including phishing and related attacks and social engineering.
• 12.6.3.2 Training includes awareness of the acceptable use of end-user technologies, in line with requirement 12.2.1.

Other roles have their own training requirements:

• 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months on software security relevant to their job and development languages, including secure software design and secure coding techniques, and how to use security testing tools.
• 9.5.1.3 Personnel in point-of-interaction environments are trained to spot tampering or replacement of payment devices.
• 12.10.4 Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained.

"Personnel" in PCI DSS includes full-time and part-time employees, temporary employees, contractors and consultants with security responsibilities for protecting account data or who can affect its security. An assessor will typically ask for the training content, a list of personnel, and completion and acknowledgment records showing hire dates and annual dates.

What changed in PCI DSS version 4?

PCI DSS v4.0 was published in March 2022, and v4.0.1, a limited revision with clarifications and corrections, in June 2024. Version 3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024, so all assessments now use v4.0.1. The requirements that v4.0 marked as "best practice until 31 March 2025" became mandatory on that date.

Changes that affect most software and IT companies:

• MFA for all access into the CDE (8.4.2), not only remote and administrative access.
• Longer passwords: at least 12 characters, or 8 if the system does not support 12 (8.3.6).
• Payment page script management (6.4.3) and change and tamper detection on payment pages (11.6.1), aimed at e-skimming.
• Targeted risk analyses (12.3.1) to justify the frequency of controls that the standard lets you set yourself.
• Automated log review (10.4.1.1).
• Authenticated internal vulnerability scans (11.3.1.2).
• Anti-phishing mechanisms (5.4.1) and phishing awareness training (12.6.3.1).
• Annual scope confirmation (12.5.2), and every six months for service providers.
• Roles and responsibilities documented for every requirement (x.1.2 in each section).
• Customized approach as an alternative to the defined approach.

How do you achieve PCI DSS compliance step by step?

1. Map payment channels and data flows. Every way card data enters, moves and leaves, including support tickets, call recordings and logs.
2. Reduce scope. Outsource card entry, tokenize, delete stored data you do not need, and segment what remains.
3. Confirm your level and validation type with your acquirer or the brands. Choose the SAQ type or engage a QSA.
4. Run a gap assessment against the applicable requirements.
5. Fix gaps. Common work items are MFA, logging, scans, script management on payment pages and documentation.
6. Train personnel under 12.6, and developers under 6.2.2, and collect policy acknowledgments.
7. Manage third parties under 12.8: list them, collect AOCs and document responsibilities.
8. Test. Quarterly ASV and internal scans, penetration tests and segmentation tests.
9. Validate. Complete the SAQ or ROC and the AOC, and submit to your acquirer or customers.
10. Keep it running. Many requirements have daily, quarterly or six-monthly tasks. Put them on a calendar with owners.

What are the most common PCI DSS failures?

• Scope drawn too narrowly, leaving out admin workstations, identity providers, CI/CD or logging systems that can affect the CDE.
• Card numbers found in places nobody expected: support tickets, chat transcripts, call recordings, debug logs or spreadsheets.
• Failed or missed quarterly ASV scans.
• MFA applied to remote access but not to every path into the CDE.
• No inventory or authorization of scripts on payment pages.
• Training given at hire but not repeated every 12 months, or missing the phishing and social engineering content.
• No annual acknowledgment of the security policy.
• Service provider AOCs not collected or out of date, and no record of who is responsible for which requirement.
• Targeted risk analyses missing for controls whose frequency the entity chose.

How does PCI DSS relate to other frameworks?

• ISO 27001 and SOC 2 cover many of the same controls. They do not replace PCI DSS, but one control set can support all three.
• PCI Secure Software Standard applies to vendors of payment software, alongside the Secure Software Lifecycle Standard.
• NIST CSF 2.0 can describe your broader security program.
• GLBA Safeguards Rule, NYDFS Part 500, DORA and RBI's IT directions apply to financial firms and often sit next to PCI DSS.

Key PCI DSS terms

CDECardholder data environment: the systems and people that handle account data, and anything that can affect them. PANPrimary account number, the card number. QSAQualified Security Assessor, a company and its employees approved by the PCI SSC to perform assessments. ASVApproved Scanning Vendor, approved to perform external vulnerability scans. SAQSelf-Assessment Questionnaire for eligible merchants and service providers. ROCReport on Compliance, the detailed assessment report. AOCAttestation of Compliance, the signed declaration of the validation result. TPSPThird-party service provider.

PCI DSS FAQs

Official sources and references

We checked these sources while writing and reviewing this guide. Where a rule is a proposal or a draft, the guide says so.

• PCI DSS v4.0.1, PCI Security Standards Council Standard, testing procedures and guidance
• PCI SSC blog: Just published, PCI DSS v4.0.1 June 2024 limited revision
• PCI SSC document library (SAQs, AOCs and ROC template) Current SAQ versions including the January 2025 SAQ A
• PCI SSC FAQ library FAQ 1331 (revised August 2026) and FAQ 1588 on SAQ A eligibility
• PCI SSC, Approved Scanning Vendors and Qualified Security Assessors lists Find an ASV or QSA
• Visa, security compliance for merchants and service providers How Visa sets validation levels

Next steps

1. Draw a data flow diagram for each payment channel and confirm your scope.
2. Ask your acquirer which level and SAQ or ROC you need.
3. Check MFA, scans and payment page script controls against the March 2025 requirements.
4. Assign security awareness training with a policy acknowledgment at hire and every 12 months. Book a demo to see how LMS Advisor tracks requirement 12.6.
5. Collect current AOCs from every service provider in scope.