PCI DSS and Payment Security: The Contract Standard Behind Every Card Swipe

What PCI DSS is, and who stands behind it

The Payment Card Industry Data Security Standard (PCI DSS) is a technical standard for protecting payment card account data. It is written and maintained by the PCI Security Standards Council (PCI SSC), an industry body founded by the major card brands. The current version is v4.0.1, announced June 11, 2024 as a limited revision of v4.0. It corrected typographical and formatting errors and clarified some wording, and it added or deleted no requirements. Version 4.0 was retired on December 31, 2024, so v4.0.1 is the only active version the council supports.

The PCI SSC does not audit you, collect fines or decide who has to prove compliance. Its own standards page says PCI DSS is intended for any entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. It also says whether an entity must comply or validate compliance is decided by the organizations that manage compliance programs, such as a payment brand or acquirer. In practice the chain runs like this.

Who must comply

Everyone who accepts cards. A one-location bakery with a countertop terminal and a 4,000-employee retailer are both subject to PCI DSS, but their proof looks very different. Service providers that handle card data for others (a billing software vendor, a managed IT provider with access to your payment systems, a call center that takes card numbers by phone) are in scope as well. The standard speaks of merchants, processors, acquirers, issuers and service providers, and you can be more than one at once.

If you outsource everything, you are still responsible. Outsourcing shifts the work; it does not shift your obligation to confirm that your provider is compliant and to record which PCI requirements each of you handles. Your contract and your acquirer's rules decide the details, so read both.

Merchant levels

The card brands sort merchants into four levels, mostly by annual transaction volume. The council does not publish the levels; each brand does. Visa's public page confirms that a merchant's level depends on its total Visa transaction volume over 12 months and that acquirers must see that merchants validate at the right level, but it does not list the thresholds. Mastercard's public Site Data Protection page does list its levels (Level 1 over 6 million combined transactions; Level 2 over 1 million up to 6 million; Level 3 over 20,000 up to 1 million e-commerce transactions; Level 4 all others), and it counts the most recent 52 weeks of volume. The Visa figures below come from a secondary summary and match what acquirers commonly publish. Treat them as typical and confirm the exact level and the proof due with your own acquirer.

American Express uses different thresholds. Level 4 for most businesses means a questionnaire, not an auditor, which is why the SAQ table below matters to nearly every small and midsize company.

Visa also runs a Technology Innovation Program in the United States. Merchants that route at least 75 percent of transactions through EMV chip-enabled terminals, a validated point-to-point encryption solution, or an EMVCo-compliant tokenization solution, that do not store sensitive authentication data after authorization and that have not had a cardholder data breach may be excused from annual validation. Merchants outside the program still validate each year.

SAQ types: match the form to how you take payments

The Self-Assessment Questionnaire (SAQ) is a form in which a smaller merchant answers requirement-by-requirement and then signs an Attestation of Compliance. There are several types because a merchant that hands every card to a processor has far less to prove than one that runs its own payment page or stores numbers. The PCI SSC's FAQ index lists SAQ A, A-EP, B, B-IP, C, C-VT and P2PE (hardware). SAQ D is for merchants outside those fits and for service providers. The eligibility summary below is from the secondary source named above; each SAQ document lists the exact criteria, and a merchant must meet all of them to use that form.

A development worth a manager's attention involves SAQ A. For e-commerce merchants that embed a payment form (an iframe) from a processor, the SAQ A eligibility criteria now say the merchant has confirmed that its site is not susceptible to attacks from scripts. According to PCI SSC FAQ 1588 (February 2025), a merchant can meet that either by applying techniques like those in PCI DSS requirements 6.4.3 and 11.6.1 or by getting confirmation from a PCI DSS compliant provider that its embedded solution, implemented as instructed, protects the payment page from script attacks. Merchants that simply redirect to the provider's page are not subject to that criterion. If your web developer added a chat widget, a tag manager or an analytics script to a checkout page, ask them to list every script on that page.

The 12 requirements

PCI DSS v4.0.1 is organized in six goals and 12 principal requirements, each with many sub-requirements. These are the headings as they appear in v4.0 and v4.0.1.

The March 31, 2025 future-dated requirements

When v4.0 was released in March 2022, the council marked a large group of its new requirements as best practice only until March 31, 2025, when they would become mandatory. The PCI SSC's June 2024 blog confirmed the v4.0.1 revision "does not impact the effective date of these new requirements." As of October 2026 those requirements are mandatory in every assessment. Two of the future-dated requirements are tied to payment page scripts, and the PCI SSC's FAQ 1588 names both: 6.4.3 (manage and authorize each script on payment pages) and 11.6.1 (detect and alert on unauthorized changes to payment pages). Others widely cited in assessor guidance include multi-factor authentication for all access into the cardholder data environment (8.4.2), anti-phishing controls (5.4.1) and targeted risk analyses that justify how often certain controls run. Use the "Summary of Changes v4.0 to v4.0.1" document in the PCI SSC library as the authoritative list for your gap assessment.

For a manager, the useful translation is simple. Before 2025 a company could pass with older habits (one shared admin login, no MFA on internal admin access, no tracking of scripts on the checkout page). After March 31, 2025, an assessor will mark those down. If your last questionnaire was completed against the older expectations, treat it as stale.

Scoping: the cheapest security money you can spend

Scope is the set of people, processes and systems that must meet PCI DSS. Every system that stores, processes or transmits card data is in scope, and so is anything connected to it without strong separation. The principle is plain: the fewer systems that touch card data, the fewer requirements apply.

An easy discovery exercise: find every place card numbers might be. Staff email, spreadsheets, a paper order form that was scanned, a call recording, a support ticket where a customer typed a number, an old backup. If you find card numbers in places you did not plan, they are in scope until you remove them under a documented process.

How penalties and fees actually reach you

No government fines you under PCI DSS. The consequences flow through contracts.

• Non-compliance and validation fees. Many acquirers charge a monthly fee until you submit your questionnaire and scans. The amounts are set by your merchant agreement and differ by provider, so read the fee schedule. I have not verified any industry-wide figure and do not quote one.
• Brand assessments after a breach. If a breach exposes card numbers, the brands can assess charges against the acquirer, and the acquirer passes them to you under your agreement. These can cover fraud losses, card reissuance costs and investigation costs. The size depends on records exposed and on whether you were compliant at the time.
• Forensic investigation at your expense. The brands may require a PCI Forensic Investigator to examine the incident, billed to you.
• Chargebacks. A chargeback is a reversal of a sale initiated by the customer's bank. Fraud chargebacks climb after a card breach.
• Loss of card acceptance. In extreme or repeated cases the acquirer can terminate the merchant agreement, and the merchant can land on a list that makes it hard to find another acquirer.
• Higher level and cost. A breach can move you to a higher merchant level with an on-site assessment.

Because the brand programs are contract terms, a court tends to see PCI DSS as relevant evidence of reasonable security rather than as law. Washington's statute, below, is an example of a legislature turning it into a defense.

State laws that mention card data

Three states give card data special treatment. Each statute is short; read the official text for your situation.

A practical reading. Nevada makes PCI DSS compliance a statutory duty and a liability shield for Nevada data collectors that take cards. Washington makes PCI compliance, shown by a current annual assessment, a defense, with encryption as an alternative. Minnesota sets a bright-line data retention ban with a cost-shifting remedy to banks. A company with customers in all three states would be wise to adopt the PCI standard as the baseline and keep dated proof of its annual assessment. The general breach-notification statutes of every state are covered in lesson 07, and the laws that reach all businesses are in lesson 06.

Questions to ask your payment processor and IT provider

• What is our merchant level with each card brand, and what proof is due, to whom and by what date?
• Which SAQ type applies to each of our payment channels (store, web, phone, mobile, recurring)?
• Do you offer tokenization, hosted payment pages or validated P2PE, and where is your own PCI Attestation of Compliance?
• Which requirements does your service cover, and which are ours? Please give us the written responsibility matrix.
• What scripts load on our checkout page, who approved each one, and how would we know if one changed?
• Do we store any card numbers, verification codes or track data anywhere, including email, call recordings and backups?
• What fees do we pay if validation is late, and what happens to our merchant agreement if we have a suspected compromise?
• Whom do we call first if we suspect card data was stolen?

Questions and answers

If PCI DSS is not a law, why take it seriously?

Because you signed a contract that requires it, and because the costs after a breach are real: investigation, brand assessments, chargebacks and possible loss of card acceptance. In three states, statutes also point to it or to similar duties.

We use Square, Stripe or a similar all-in-one service. Are we done?

Not quite. Those services shrink your scope, often to SAQ A or P2PE-style forms, but your acquirer or the provider's agreement may still require an annual questionnaire. You also own your website scripts, your staff's handling of card data on the phone and your account security. Turn on multi-factor authentication for the provider dashboard.

Does PCI DSS apply to phone orders where staff write down the card?

Yes. Paper and verbal channels count. Writing numbers on paper puts the paper in scope. Better is a virtual terminal on an isolated computer (SAQ C-VT, if you meet its criteria) or a validated P2PE phone solution.

Can we store the three-digit security code if the customer allows it?

No. The standard forbids storing sensitive authentication data, including the card verification code, after authorization, even if encrypted. Minnesota's statute bans keeping it too.

What is the difference between PCI compliance and being secure?

PCI DSS is a baseline for protecting card data. A company can be validated and still be exposed through areas the standard does not govern. Use PCI as one backbone and pair it with the framework from lesson 04.

Who signs the Attestation of Compliance?

An officer of the company who can stand behind its truth. For a questionnaire, you are attesting that you met the requirements as you answered them. Do not delegate the signature without delegating the evidence review.

What should we do if we suspect card data was stolen?

Preserve evidence, stop further exposure, and notify your acquirer immediately under your merchant agreement. The brands' forensic and notice programs run through the acquirer. Lesson 11 sets out the notice clocks for other laws that may apply at the same time.

Do tokens count as card data?

A properly implemented token that cannot be reversed to a card number without access to the processor's vault generally falls outside the cardholder data you must protect. The question is whether your systems can reconstruct the number. Ask your processor for its documentation, not just a sales promise.

Hard questions

"Our acquirer never asked for proof. Can we skip it?"

Silence is not a waiver. Read your merchant agreement. If it requires compliance and a breach occurs, the absence of a request will not protect you from brand assessments, and in Washington or Nevada the absence of dated proof removes a statutory defense that you would otherwise have had.

"A breach happened at our processor. Why are we paying?"

You may not be. Responsibility depends on the contract and on where the data was compromised. Ask for the written responsibility matrix, and if you outsourced everything, make sure the contract says who pays for reissuance, forensics and notices. Washington's statute allocates fault among entities whose negligence proximately caused the damage.

"Isn't tokenization just moving the problem to the vendor?"

Partly, and that is the point. Moving card storage to a specialist that undergoes full assessments is cheaper and safer than doing it yourself. The risk that stays with you is the vendor's reliability, so use due diligence from lesson 09: ask for its Attestation of Compliance and SOC reports and check the date.

"SAQ A is so short. Is it a loophole?"

It is an accurate reflection of low exposure when card entry really happens on the provider's page. It stops being accurate when your own scripts, plugins or tag manager can alter the payment page, which is why the council added the script-confirmation criterion in 2025. If you claim SAQ A, be ready to show the script inventory.

"Why does the standard keep changing? Every update means more cost."

Attackers shifted to e-commerce skimming, stolen credentials and phishing, and the standard followed with script controls, MFA and anti-phishing requirements. The three-year cycle from v4.0 to the March 31, 2025 deadline gave merchants time. A customer-facing company that keeps a living inventory and dated evidence pays much less at each update than one that rebuilds proof once a year.