What are the PCI DSS requirements, in short?

PCI DSS is split into 12 requirement areas. They cover network security, secure configuration, protection of stored account data, encryption in transit, malicious software protection, secure software development, least-privilege access, user identification and authentication, physical access, logging and monitoring, regular security testing, and supporting policies. The list does not change. What changes per business is which areas you must evidence, and in which form: an SAQ, a report on Compliance, or a narrow subset.

Do PCI DSS requirements apply if we encrypt all cardholder data?

Encryption alone generally is not enough. The PCI Security Standards Council states that encryption alone is generally insufficient to render cardholder data out of scope for PCI DSS. Your environment stays in scope because cardholder data is present in it. Systems that encrypt, decrypt or manage keys for cardholder data stay in scope. A PCI-listed P2PE solution can reduce the number of requirements that apply to you, but it does not remove PCI DSS from the merchant environment.

How many PCI DSS requirements does a merchant have to evidence each year?

For Visa Level 1 to Level 3 merchants the recurring load is 6 compliance touchpoints per year. That is 1 annual validation document, a report on Compliance by a QSA at Level 1 or an SAQ at Levels 2 and 3, plus 1 Attestation of Compliance, plus 4 quarterly ASV network scans. Level 4 merchants have an annual SAQ recommended and a scan only when applicable, so the most you can face is 6 touchpoints per year.

If my payment processor hosts the payment page, am I still in scope?

PCI DSS is intended for all entities involved in payment processing, including merchants, whatever their size or transaction volume. FAQ 1588 draws the practical line for e-commerce. If a processor page or form is embedded on your site, you must confirm that your site is not susceptible to script attacks, either by implementing Requirements 6.4.3 and 11.6.1 or by holding your processor's confirmation. Redirected and fully outsourced arrangements fall outside that criterion, but your acquirer still decides your questionnaire.

PCI DSS Requirements in 2026 - What Applies to You

Q: Which PCI DSS requirements changed in v4.0.1?

The PCI Security Standards Council calls v4.0.1 a limited revision with no requirements added or deleted. The changes sit in Requirements 3, 6, 8 and 12, plus two appendices. Requirement 6 narrows the 30-day patching rule to critical vulnerabilities. Requirement 8 clarifies multi-factor authentication where accounts use phishing-resistant factors exclusively. Requirement 3 clarifies issuer applicability and keyed cryptographic hashes.

Q: What are PCI DSS requirements 6.4.3 and 11.6.1?

They are the two payment-page requirements covered by the council's information supplement Payment Page Security and Preventing E-Skimming, published on 10 March 2025. The supplement works through authorizing payment-page scripts, verifying their integrity, monitoring for tampering, and managing scripts and security-relevant HTTP headers. They became part of every assessment once the future-dated v4 requirements took effect on 31 March 2025.

Do you need PCI DSS at all? The three-question scope test

The council's merchant resources page settles the most common shortcut. Encrypting everything does not take card data out of scope.

Encryption alone is generally insufficient to render cardholder data out of scope. Your environment stays in scope because card data sits in it. Systems that encrypt, decrypt or manage card data keys stay in scope too.

A PCI-listed P2PE solution, meaning point-to-point encryption, can significantly reduce the requirements that apply to you. It does not remove PCI DSS from the merchant environment. You can turn this into three questions.

Do you store, process or transmit cardholder data or sensitive authentication data?

Do your systems encrypt, decrypt or manage keys for cardholder data?

Could your systems affect the security of the cardholder data environment?

A yes answer to any one of the three puts you in scope. Cardholder data means the card number and other data kept about a cardholder. Sensitive authentication data means the security codes and PINs tied to a card.

Your situation	In scope?	Why
You store card data	In scope	Card data is in your environment
You encrypt card data at rest and in transit	In scope	Encryption alone is insufficient
You use a PCI-listed P2PE solution	In scope, fewer requirements	P2PE does not remove applicability
You redirect to the processor page	In scope	FAQ 1588 criterion does not apply

You satisfy that clause in exactly two ways. Either you implement Requirements 6.4.3 and 11.6.1 yourself. Or you obtain confirmation from your TPSP, meaning third-party service provider. The confirmation must say its embedded solution gives those protections when you follow its instructions.

The clause applies only where a processor's payment page is embedded on your site. It does not apply to redirected or fully outsourced payments.

If you cannot meet SAQ A eligibility, ask your acquirer or payment brands which questionnaire applies. Which PCI DSS requirements you evidence is decided by that path.

Your checkout	SAQ A eligibility	What you must show
Redirected or fully outsourced payment	Criterion does not apply	Confirm the right SAQ with your acquirer
Processor page embedded on your site	Criterion applies to you	Implement 6.4.3 and 11.6.1, or hold your processor's confirmation
Embedded page with script evidence	Eligible for SAQ A if you meet its other criteria	Complete SAQ A, sign the attestation, file both
Embedded page without script evidence	Not eligible for SAQ A	Ask your acquirer which questionnaire applies

What does your merchant level demand of you each year?

Card brands set merchant levels on their own, so confirm yours with your acquirer. The Visa validation of compliance page lists the clearest thresholds.

Each level names an annual document, a scanning duty, and a signed form. A ROC, or Report on Compliance, is written by a QSA, a Qualified Security Assessor. An ASV, an Approved Scanning Vendor, runs the network scan.

Visa level	Annual volume threshold	Annual validation	Touchpoints per year, computed
Level 1	Over 6 million Visa transactions a year, all channels	Report on Compliance by a QSA	6
Level 2	1 million to 6 million Visa transactions a year, all channels	Self-Assessment Questionnaire	6
Level 3	20,000 to 1 million Visa e-commerce transactions a year	Self-Assessment Questionnaire	6
Level 4	Under 20,000 Visa e-commerce transactions a year, and other merchants up to 1 million a year	Annual SAQ recommended	Up to 6, set by the acquirer

The last column is arithmetic on Visa's stated cadence, not a figure Visa quotes. For Level 1 to Level 3, add 1 validation document, 1 Attestation of Compliance and 4 quarterly ASV scans. That gives 6 recurring compliance touchpoints each year. Level 4 depends on your acquirer, so the most you can face is 6.

For the money side, read PCI DSS compliance cost for e-commerce.

How do SAQ A and a full Report on Compliance differ?

SAQ A is a self-assessment form that you complete yourself. A Report on Compliance is written by a QSA. The PCI DSS requirements you evidence differ across the two paths.

Criterion	SAQ (such as SAQ A)	Report on Compliance
Who completes it	You	A QSA performs the assessment
Levels that use it	Visa Levels 2 and 3 file an SAQ, Level 4 is advised to	Visa Level 1
Payment-page work	Meet 6.4.3 and 11.6.1, or hold processor confirmation	The same two rules apply
Network scanning	Quarterly ASV scan at Levels 2 and 3	Quarterly ASV scan
Signed form	An Attestation of Compliance	An Attestation of Compliance

The row that changes your plan is the payment-page work. Under FAQ 1588 an embedded checkout must show that it is not susceptible to script attacks. That evidence sits with the merchant, so you implement the two payment-page rules or hold your processor's confirmation.

Which PCI DSS Requirements Changed in v4.0.1?

PCI DSS v4.0.1 is the active standard. Version 3.2.1 was retired on 31 March 2024, and v4.0 on 31 December 2024. The release did not change the 31 March 2025 effective date for the future-dated v4 requirements. The council describes it in its v4.0.1 announcement. For the timeline, read the PCI DSS 4.0 deadline prep guide.

The release is a limited revision. No requirement was added and none was deleted. The changes touch Requirements 3, 6, 8 and 12, plus two appendices.

Requirement 3 - Protect stored account data. Issuer rules and keyed cryptographic hashes are clearer. Such a hash stays unreadable without its key.
Requirement 6 - Secure systems and software. The 30-day patching rule now covers critical vulnerabilities only.
Requirement 8 - Identify users and authenticate access. MFA, meaning multi-factor authentication, does not apply to accounts that use phishing-resistant factors only.
Requirement 12 - Policies and programs. The rules on how you and your service providers relate are clearer.

The effect is on evidence, not on the list.

What do payment-page requirements 6.4.3 and 11.6.1 demand of a merchant?

On 10 March 2025 the council published a supplement on payment page security and preventing e-skimming. It covers authorizing payment-page scripts, verifying their integrity, and monitoring for tampering. It also covers the Hypertext Transfer Protocol headers, which a web server sends to browsers. Both requirements joined every assessment on 31 March 2025.

Requirement 6.4.3 sits in the secure systems and software area. Requirement 11.6.1 sits in the regular security testing area. Together they ask you to control payment-page scripts and watch the page for tampering.

A payment page loads scripts from other companies. If one script changes, the page can start sending card numbers somewhere else. That kind of theft is called e-skimming.

For a merchant with an embedded checkout, this is the work that satisfies the FAQ 1588 clause. Your processor may confirm that its solution does it when you follow its instructions.

What should you do next?

Write down how your checkout takes payment, then ask your acquirer which SAQ or report you file.
Confirm your merchant level, then put the validation and scan dates in a shared calendar.
If a processor page stays embedded on your site, collect the script-protection evidence now.

For other frameworks, the cybersecurity compliance frameworks guide shows where PCI DSS fits.

PCI DSS applies to every entity in payment processing. Encryption alone does not remove card data from scope. The 12 requirement areas did not change in v4.0.1, but the evidence did.

Photo: Maria_Domnina, Pixabay Content License, via Pixabay (https://pixabay.com/photos/banking-business-button-card-4896672/)

PCI DSS Requirements in 2026 - What Applies to You

Do you need PCI DSS at all? The three-question scope test

Related Articles

CMMC Level 1 Requirements - Do You Need Level 2

GDPR Compliance Requirements - What Changed in 2026

SOC 2 Type 1 vs Type 2 - Which Report Do You Need?

Nonprofit vs Not-For-Profit Differences Explained

Best ESG Certifications to Start in 2026

Try It in the Browser

Which validation path fits you: SAQ A, SAQ A-EP, or a full Report on Compliance?

What does your merchant level demand of you each year?

How do SAQ A and a full Report on Compliance differ?

Which PCI DSS Requirements Changed in v4.0.1?

What do payment-page requirements 6.4.3 and 11.6.1 demand of a merchant?

What should you do next?

Sprinto Pricing 2026: SOC 2 Compliance Cost