PCI DSS

What PCI DSS is

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security rules for organizations that handle payment card data. The PCI Security Standards Council, which maintains it, describes it as “a baseline of technical and operational requirements designed to protect payment account data.”¹

It is written for any organization that stores, processes or transmits card data, or that could affect the security of the systems that do. The council names merchants, processors, acquirers, card issuers and service providers.¹ An acquirer, or acquiring bank, is the bank that handles card payments for a merchant, and Mastercard says it is the acquirer that oversees each merchant’s compliance.²

PCI DSS is not a law. It is an industry standard, and the council says it neither enforces compliance nor monitors how its standards are put into practice.³ Whether a business must comply, and how it proves it, is decided by the organizations that run compliance programs, such as a payment brand or an acquirer.¹

The standard uses a handful of defined terms:

• Account data. Cardholder data, sensitive authentication data, or both.⁴
• Cardholder data. At a minimum, the full primary account number (PAN), the unique number of a credit, debit or prepaid card.⁴
• Sensitive authentication data. Security information used to authenticate cardholders or authorize card transactions.⁴
• Card verification code. For PCI DSS purposes, the three- or four-digit value printed on the front or back of a card.⁴
• Cardholder data environment. The systems, people and processes that store, process or transmit cardholder data.⁴
• Payment page. A web page with one or more form fields meant to capture account data from a customer.⁴

Origins: from card-brand programs to one council

Before PCI DSS, the card brands ran separate security programs. In February 2005, SC Magazine reported that Visa and MasterCard had combined Visa’s Cardholder Information Security Program (CISP) and MasterCard’s Site Data Protection (SDP) program into one Payment Card Industry Data Security Standard, which had been sent to the companies’ members the previous December.⁵ John Verdeschi, a MasterCard vice president, told the magazine the two programs had “different documentation, definitions and standards.”⁵

On September 7, 2006, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International announced the PCI Security Standards Council, LLC, an independent body to manage the standard. Its first act was to release PCI DSS version 1.1.⁶ The announcement said the council would act in an advisory role while each payment brand kept responsibility for its own compliance program.⁶

The five founding members still share equally in the council’s ownership and governance.³ Strategic membership is open to multinational payment acceptance brands, and UnionPay joined as a strategic member in November 2020.³⁷

The council has added other standards over the years. Its own timeline lists the Payment Application Data Security Standard (PA-DSS) in October 2008, and standards for PIN security and point-to-point encryption in September 2011.⁷ PA-DSS is now marked as retired.³

The six goals and 12 requirements

PCI DSS is organized as 12 principal requirements grouped under six goals. The headings below are those of PCI DSS v4.0.1, as printed in the council’s self-assessment questionnaire of October 2024.⁸

Each heading holds many detailed sub-requirements. Stripe, a payment company, says a business that takes raw card numbers on its own payment page may have to meet more than 300 security controls.⁹ A few of them bear directly on websites:

• No storing sensitive authentication data. Requirement 3.3.1 says such data is “not stored after authorization, even if encrypted.”⁸
• Encryption in transit. Requirement 4.2.1 calls for strong cryptography to protect card numbers sent over open, public networks, accepting only trusted keys and certificates and never falling back to insecure protocol versions.⁸ On the web this means HTTPS and TLS.
• Quarterly scans. Requirement 11.3.2 calls for external vulnerability scans at least once every three months by an Approved Scanning Vendor (ASV), a company the council approves for this work.¹⁰⁴
• Multi-factor authentication. Version 4.0 expanded Requirement 8 to require multi-factor authentication for all access into the cardholder data environment.¹¹

Versions, from 1.1 to 4.0.1

The council revises the standard every few years. The table lists the versions whose dates could be confirmed in the council’s own pages or in reports from the time.

The council’s own pages disagree on version 3.1. A 2015 council blog post says SSL was removed in version 3.1 in April 2015, while the council’s 20-year timeline lists version 3.1 under June 2015.¹³⁷

Leaving SSL and early TLS

SSL is the older encryption protocol that TLS replaced. In December 2015 the council extended the deadline for moving off SSL and early TLS to June 30, 2018, and told organizations to move to TLS 1.1 at a minimum, and preferably TLS 1.2.¹³ It pointed to the POODLE and Heartbleed exploits as evidence of the risk.¹³

Version 4.0 and its transition

Version 4.0 was published on March 31, 2022, after more than 200 organizations sent over 6,000 items of feedback across three years. Among other changes it replaced the word “firewall” with “network security controls.” Version 3.2.1 stayed in force alongside it until March 31, 2024.¹¹

In an August 2024 interview on the council’s blog, Michael Aminzade of the security firm VikingCloud called version 4.0 “the first major update to the Standard in over a decade.” Of its 64 new requirements, 51 were future-dated, meaning they became mandatory only on March 31, 2025.¹⁰

Version 4.0.1 followed on June 11, 2024. The council said the limited revision added and deleted no requirements. It restored the earlier rule that only critical vulnerabilities must be patched within 30 days, and exempted accounts that use phishing-resistant authentication from one multi-factor requirement. Version 4.0 was retired on December 31, 2024.¹⁴

The next version

As of October 2026, version 4.0.1 is the current standard. On June 3, 2026, the council opened a six-week request for comments on it, running to July 20, and said the feedback would help shape the future of the standard. It gave no release date for that next version.¹⁵

Payment pages, scripts and SAQ A

Card data breaches during online transactions are commonly called e-skimming. The council says scripts running in shoppers’ browsers have become a significant target for attackers trying to steal card data, and links the rise to more complex e-commerce platforms and heavier reliance on outside scripts.¹⁶ A script here is a piece of JavaScript code that a web page loads and the browser runs.

Two requirements in version 4 deal with this. Requirement 6.4.3 covers every payment page script that is loaded and run in the shopper’s browser: each must be authorized, its integrity assured and listed in an inventory with a reason for having it.⁸ Requirement 11.6.1 calls for watching payment pages for tampering, including unauthorized changes to the page or to security-related HTTP headers as the browser receives them.¹⁶ Both took effect on March 31, 2025, and the council published guidance on them that March.¹⁷¹⁶

Smaller merchants usually prove compliance each year with a self-assessment questionnaire (SAQ). Mastercard’s rules name several versions, among them SAQ A, SAQ A-EP and SAQ D.² SAQ A is for merchants who have completely outsourced their account data functions to PCI DSS validated and compliant third parties.¹⁷ On January 30, 2025, the council removed Requirements 6.4.3 and 11.6.1 from SAQ A. In their place it added an eligibility rule: the merchant must confirm its site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The change took effect on March 31, 2025, and the council stressed that it does not remove the underlying requirements from PCI DSS.¹⁷

A council FAQ from February 2025 explains how the rule works:¹⁸

• Redirects. If the checkout sends the shopper to the payment provider’s own page, for example with an HTTP 30x redirect, a meta refresh or JavaScript, the script rule does not apply. The same goes for a payment link sent by email.¹⁸
• Embedded forms. If the provider’s payment form is embedded in the merchant’s page, for example in an iframe (an HTML element that shows one page inside another), the rule applies. The merchant can protect the page with techniques like those in 6.4.3 and 11.6.1, or get confirmation from a PCI DSS compliant provider that its product protects the page when set up as instructed.¹⁸

Who checks compliance

The council trains and lists the people who assess compliance. Qualified Security Assessors (QSAs) are independent firms it has qualified to check an organization against PCI DSS, and Approved Scanning Vendors run the external scans.¹⁴

Card brands sort merchants into levels by yearly transaction counts. Mastercard’s four levels, as of October 2026, are:²

• Level 1. More than six million Mastercard and Maestro transactions a year. Validation is an annual assessment ending in a Report on Compliance (ROC).
• Level 2. More than one million and up to six million transactions a year. Validation is an annual SAQ.
• Level 3. More than 20,000 e-commerce transactions a year, up to one million. Annual SAQ.
• Level 4. All other merchants. Annual SAQ.

Mastercard says it does not require Level 3 and Level 4 merchants to validate their compliance to it. Instead, the acquirer must show Mastercard it has a risk management program for those merchants. Level 4 merchants must still comply with PCI DSS, and a law or regulation may require them to validate.²

Mastercard says merchants send their validation documents to their acquiring bank.² The only evidence the council recognizes is its own forms: the ROC, the Attestation of Compliance (AOC), the SAQ and the ASV’s attestation of scan compliance. In September 2025 it warned that it “does not provide compliance certificates or compliance logos.”¹⁹

Payment companies and hosted platforms count as service providers, businesses other than a card brand that are directly involved in processing, storing or transmitting card data, and they are assessed themselves.⁴ Stripe says an independent QSA certifies it every year as a PCI Level 1 service provider, and that the businesses using it must still attest to their own compliance each year.⁹ Shopify says it reissues its Attestation of Compliance after each annual assessment and shows it to merchants who log in.²⁰

PCI DSS and the law

Although PCI DSS is a private standard enforced through compliance programs, some US states refer to it in their laws. Two examples:

• Nevada. Under NRS 603A.215, a data collector doing business in Nevada that accepts payment cards must comply with the current version of PCI DSS. A collector that complies is not liable for damages from a breach, unless the breach was caused by its gross negligence or intentional misconduct. The section was added in 2009 and amended in 2011 and 2025.²¹
• Washington. Under RCW 19.255.020, for breaches from July 1, 2010, a processor or business that fails to take reasonable care with account information can owe banks the cost of reissuing cards. It is not liable if the data was encrypted, or if it was certified compliant with PCI DSS by an annual assessment made no more than a year before the breach.²²

Regulators have also brought their own cases over card data security. On March 27, 2008, the Federal Trade Commission announced a settlement with the retailer TJX, after an intruder obtained data from tens of millions of payment cards. The FTC said TJX had stored personal information in clear text, had not required strong passwords and had not used firewalls to limit access. The order required a security program with outside audits every other year for 20 years.²³

Privacy laws are separate from PCI DSS and set their own rules for personal information. They are covered in the entries on the GDPR and the CCPA and CPRA.

Timeline

1. June 3, 2026The council opens a request for comments on PCI DSS v4.0.1 ahead of the next version¹⁵
2. March 31, 2025The 51 future-dated v4 requirements and the revised SAQ A take effect¹⁷
3. January 30, 2025The council removes Requirements 6.4.3 and 11.6.1 from SAQ A and adds a script eligibility rule¹⁷
4. December 31, 2024PCI DSS v4.0 is retired¹⁴
5. June 11, 2024PCI DSS v4.0.1, a limited revision, is published¹⁴
6. March 31, 2024PCI DSS v3.2.1 is retired¹¹
7. March 31, 2022PCI DSS v4.0 is published¹¹
8. November 2020UnionPay joins the council as a strategic member⁷
9. June 30, 2018Deadline for moving payment systems off SSL and early TLS¹³
10. April 2015PCI DSS v3.1 removes SSL as an example of strong cryptography¹³
11. November 2013PCI DSS v3.0 is published⁷
12. October 2010PCI DSS v2.0 is published⁷
13. March 27, 2008The FTC announces its data security settlement with TJX²³
14. September 7, 2006Five card brands found the PCI Security Standards Council and release PCI DSS 1.1⁶
15. December 2004Visa and MasterCard send members a combined Payment Card Industry Data Security Standard⁵

What it means for your website

See also

• HTTPS and TLS
• GDPR
• CCPA and CPRA
• Website builder
• Payment gateway
• WooCommerce review
• Website legal requirements for US small businesses (2026)

References

1. PCI Data Security Standard (PCI DSS). PCI Security Standards Council. accessed October 22, 2026.
2. Site Data Protection (SDP) Program and PCI. Mastercard. accessed October 22, 2026.
3. About Us. PCI Security Standards Council. accessed October 22, 2026.
4. Glossary. PCI Security Standards Council. accessed October 22, 2026.
5. Visa and MasterCard act to align data protection. Marcia Savage, SC Magazine (SC Media). 2005-02-22. accessed October 22, 2026.
6. Five leading payment brands unite to strengthen global data security (press release). PCI Security Standards Council. 2006-09-07. accessed October 22, 2026.
7. Celebrating 20 Years. PCI Security Standards Council. accessed October 22, 2026.
8. Self-Assessment Questionnaire D for Merchants and Attestation of Compliance, for use with PCI DSS v4.0.1. PCI Security Standards Council (copy published by the Nebraska State Treasurer). 2024-10. accessed October 22, 2026.
9. Integration security guide. Stripe Documentation. accessed October 22, 2026.
10. Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x. Alicia Malone, PCI Perspectives blog, PCI Security Standards Council. 2024-08-20. accessed October 22, 2026.
11. Securing the Future of Payments: PCI SSC Publishes PCI Data Security Standard v4.0 (press release). PCI Security Standards Council. 2022-03-31. accessed October 22, 2026.
12. Due Out in October, PCI Update Will Consist of Tweaks, Council Says. Digital Transactions. 2008-05-14. accessed October 22, 2026.
13. Migrating from SSL and Early TLS. Laura K. Gray, PCI Perspectives blog, PCI Security Standards Council. 2015-12-18. accessed October 22, 2026.
14. Just Published: PCI DSS v4.0.1. PCI Perspectives blog, PCI Security Standards Council. 2024-06-11. accessed October 22, 2026.
15. Request for Comments: PCI Data Security Standard (PCI DSS) v4.0.1. Alicia Malone, PCI Perspectives blog, PCI Security Standards Council. 2026-06-03. accessed October 22, 2026.
16. New Information Supplement: Payment Page Security and Preventing E-Skimming. Alicia Malone, PCI Perspectives blog, PCI Security Standards Council. 2025-03-10. accessed October 22, 2026.
17. Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A. Alicia Malone, PCI Perspectives blog, PCI Security Standards Council. 2025-01-30. accessed October 22, 2026.
18. FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?. PCI Security Standards Council. 2025-02. accessed October 22, 2026.
19. Beware of PCI DSS Compliance Certificates. Alicia Malone, PCI Perspectives blog, PCI Security Standards Council. 2025-09-02. accessed October 22, 2026.
20. Viewing Shopify's compliance reports. Shopify Help Center. accessed October 22, 2026.
21. NRS 603A.215: Security measures for data collector that accepts payment card. Nevada Revised Statutes, Chapter 603A, Nevada Legislature. accessed October 22, 2026.
22. RCW 19.255.020: Liability of processors, businesses, and vendors. Revised Code of Washington, Washington State Legislature. accessed October 22, 2026.
23. Agency Announces Settlement of Separate Actions Against Retailer TJX, and Data Brokers Reed Elsevier and Seisint for Failing to Provide Adequate Security for Consumers' Data. Federal Trade Commission. 2008-03-27. accessed October 22, 2026.
24. PCI-DSS compliance and WooCommerce. WooCommerce Documentation. 2025-06-06. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].