What is PCI DSS? Explained simply

The problem PCI DSS solves

Card data is only as safe as the weakest business that handles it. PCI DSS (the Payment Card Industry Data Security Standard) is the common security baseline for every organization that stores, processes or transmits card data, or that could affect the security of the systems that do.

That covers merchants, payment processors, acquirers (the banks that sign up merchants), card issuers and service providers.

The PCI Security Standards Council (PCI SSC) maintains the standard. American Express, Discover, JCB, Mastercard and Visa founded it in 2006, and each of them builds PCI DSS into its own compliance program. One standard means you do not have to meet five different security rulebooks.

The current version is PCI DSS v4.0.1, published June 11, 2024. It has been the only active version since v4.0 was retired on December 31, 2024. The requirements that v4.0 had marked as future-dated became mandatory on March 31, 2025, so every requirement in the standard now applies.

The standard protects two kinds of data. Cardholder data is the card number (the primary account number, or PAN), the cardholder name, the expiration date and the service code. Sensitive authentication data is the full magnetic stripe or chip data, the card verification code and the PIN.

Sensitive authentication data must never be kept after a transaction is authorized, even if you encrypt it.

What it actually asks of you

PCI DSS has 12 requirements, grouped under six goals. The table uses the PCI SSC's own requirement names with a plain reading beside each.

Version 4 also lets you set how often you do some tasks, such as certain log reviews, through a documented targeted risk analysis (12.3.1). That flexibility comes with paperwork: an assessor will ask to see the analysis.

What PCI DSS is not

It is not, in most places, a law. It binds you through contracts. Visa, for example, says its rules govern its client banks and, through them, merchants and service providers, and that acquirers are responsible for their merchants' compliance.

The PCI SSC separately reminds businesses to check local laws that may affect how the standards apply.

It is not a certificate. The PCI SSC says it is not a compliance organization: it does not receive your report, approve your controls or publish a list of compliant service providers. It also says that "compliance certificates" issued by anyone are not recognized.

The only valid evidence is the official forms: a Self-Assessment Questionnaire (SAQ), a Report on Compliance (ROC), an Attestation of Compliance (AOC) and the scan report from an Approved Scanning Vendor.

It is not the card brands' programs. The standard says what to do. Each brand decides who must prove compliance, how, how often, and what happens if they do not.

A clean quarterly scan is not compliance either; the PCI SSC says a scan report shows only that one requirement was checked.

It is not the other PCI standards. PIN security, point-to-point encryption (P2PE), payment terminal (PTS) and secure software standards are separate documents with their own programs.

How validation works, end to end

First, you work out your scope: every system, person and process that stores, processes or transmits card data (the cardholder data environment, or CDE) plus anything connected to it or able to affect its security. You must confirm that scope at least once a year.

Second, you ask your acquirer how to validate. The brands and acquirers, not the PCI SSC, decide whether you file a Self-Assessment Questionnaire or need a Report on Compliance from a Qualified Security Assessor (QSA). Each brand sorts merchants into levels, usually by annual transaction volume; Visa, for instance, counts your total Visa transactions over 12 months.

Your acquirer will tell you your level and what it requires.

Third, you meet each requirement. Most businesses use the defined approach: do what the requirement says, and use a documented compensating control only where a real technical or business constraint stops you. PCI DSS v4 added a customized approach for organizations that choose to meet a requirement's stated objective in a different way.

The PCI SSC describes it as meant for risk-mature organizations that can design, document, test and maintain their own controls.

Fourth, you document the result on the official template, sign the Attestation of Compliance, and send it to whoever asked for it, normally your acquirer. Nothing goes to the PCI SSC. Then you repeat the cycle on the schedule your acquirer or brand sets, with scans every quarter in between where your SAQ or assessment includes them.

Which SAQ fits the way you take cards

There are ten SAQ documents for v4.0.1. Each has eligibility criteria, and you must meet all of them to use it. Your acquirer has the final say on which one you file.

If you take cards in more than one way, you may be able to file one SAQ per channel, provided each channel meets its own criteria and is separated from the others on your network, or file a single SAQ covering everything. Either way, the Attestation of Compliance must describe every environment it covers.

A worked example

This is an illustrative small business, not a real one. A bakery sells at the counter through a standalone, PTS-approved card terminal on its own network segment. It also takes online orders, and its website shows its payment provider's card form in an embedded frame.

The owner calls the acquirer, who confirms the bakery can self-assess. The counter channel looks like SAQ B-IP; the website looks like SAQ A.

Because the card form sits inside the bakery's page, the owner must confirm the page is protected from malicious scripts, either with its own controls or with written confirmation from the payment provider that its form includes that protection when set up as instructed. The owner also books quarterly external scans with an Approved Scanning Vendor.

They cover the website and also the counter terminal's internet connection, because SAQ B-IP includes the same scan requirement.

Next come the service providers. The owner gets the payment provider's Attestation of Compliance, checks it covers the services the bakery uses, and records which requirements the provider handles and which the bakery keeps. Paper receipts with full card numbers go in a locked drawer and are destroyed on a schedule.

The owner completes each SAQ, signs the Attestation of Compliance that goes with each one, and sends them to the acquirer. The calendar now has four scan dates and one renewal date.

Who does what

Six kinds of organization are involved, and they are often confused.

You remain responsible for your own compliance even when a provider does the work. PCI DSS requires you to manage your service providers (12.8), and requires service providers to tell customers which requirements they cover (12.9).

How to read an Attestation of Compliance

An AOC is the short summary that says an assessment was done and what it found. The PCI SSC says AOCs are meant to be shared, so a vendor that handles your card data should give you one on request. Here is what each part tells a buyer.

"Compliant" applies only to that entity, those services and that scope, as of that date. It says nothing about the rest of the company or about services left out of Part 2a. Entities may redact sensitive details, but the PCI SSC says the contact, scope, provider, summary and validation sections should stay readable.

If you receive a certificate or badge instead, ask for the AOC on the official template.

How to check a QSA, ASV or service provider

The PCI SSC publishes searchable lists of Qualified Security Assessor companies and Approved Scanning Vendors on its website. Look the firm up by name. For a QSA, check the "Servicing Markets" field: a QSA company may only assess in the countries or regions listed there.

The PCI SSC site also has a lookup for individual qualified professionals. For scans, the scan must be run by a listed ASV using that vendor's own scan solution.

For your service providers, PCI DSS (12.8) means you do due diligence before engaging them, have written agreements, know which requirements each one covers, and check their compliance status at least once a year.

The PCI SSC says a provider with its own assessment should give customers its AOC on request, and PCI DSS (12.9) obliges providers to say which requirements are theirs and which stay with you. A responsibility matrix is the usual format. Visa also publishes a Global Registry of Service Providers that you can search.

A QSA or ASV that only assesses or scans for you is not a service provider for these requirements.

What it costs and how long it takes

We found no price for an assessment or a scan published by the PCI SSC or the card brand pages we could read. QSA companies and ASVs quote their own fees, so any figure you see is a firm's quote, not a standard rate.

What drives the quote is your scope: how many ways you take cards, how many locations and systems touch card data, whether you file an SAQ or need a full ROC, and how much you have outsourced to validated providers. Quarterly scans and penetration testing, where they apply, are recurring costs rather than one-off ones.

The PCI SSC also publishes no fine schedule. It says fines and penalties are defined by each card brand.

Visa, for example, says it may charge non-compliance assessments to the issuer or acquirer, which pays them and must not represent to the merchant that Visa imposed them, and that assessments may be waived where a forensic investigation shows no non-compliance before and at the time of a breach.

On timing, validation is a recurring cycle, not a project with an end. How long a result stays valid is set by the brands and acquirers; Visa requires service providers to demonstrate compliance at least every 12 months. For an SAQ, the PCI SSC expects the executive to sign within a reasonable time after the self-assessment is completed, for example two or three weeks.

What changed recently, and what comes next

The last two years moved everyone onto one version and settled most of the e-commerce questions.

There has been no new PCI DSS version in 2026. From June 3 to July 20, 2026, the PCI SSC ran a request for comments on v4.0.1 to help it decide whether, and how, to revise the standard. It has not published a date for a next version.

Its November 2026 Asia-Pacific Community Meeting agenda includes a session on the next era of PCI standards, and industry commentators have written about a future v5.0, but none of that is an announced requirement. Treat any "v5 deadline" you read as speculation until it appears on the PCI SSC's own site.

The PCI SSC's other recent work, such as its Key Management and Operations standard (v1.0, September 2026) and its guidance on AI systems, sits alongside PCI DSS rather than changing it.

What we could not verify

The PCI DSS v4.0.1 standard, the v4.0.1 SAQs and the SAQ Instructions and Guidelines sit behind a license agreement in the PCI SSC document library, which we did not accept for this page.

The requirement names come from the PCI SSC's public requirements page; the SAQ table comes from PCI SSC FAQs, its blog, and the public v4.0 SAQ documents for SAQs A-EP, B, C and D, whose eligibility criteria the October 2024 bulletin lists as clarified in v4.0.1 for SAQs A, A-EP and C-VT only; the A, A-EP and C-VT rows therefore rest on current PCI SSC FAQs and blog posts.

We did not print merchant level thresholds. Mastercard's page blocked our reads and Visa's current page does not show a threshold table, so we say only that each brand sets levels, usually by annual transaction volume. Ask your acquirer, or read the brand pages linked below.

We could not confirm which US state laws refer to PCI DSS, because the state statute sites we tried blocked automated reads. We also could not confirm any date for a next PCI DSS version.