PCI DSS 4.0 Basics for SaaS Teams
What PCI DSS 4.0 actually requires, why most SaaS companies have less scope than they fear, and what the new rules in version 4.0 mean in practice.
Most founders I talk to assume PCI DSS is a problem for banks and payment processors, not for a B2B SaaS team that uses Stripe. That assumption is usually correct — but "usually" does a lot of work in that sentence. If your product touches payment card data at any point, you're in scope. And with PCI DSS 4.0 now the only active version of the standard, this is worth getting right before your first enterprise security questionnaire asks about it.
What PCI DSS is and who runs it
PCI DSS stands for Payment Card Industry Data Security Standard. It's maintained by the PCI Security Standards Council, a body founded by the major card brands — Visa, Mastercard, American Express, Discover, and JCB. The council writes and publishes the standard. The card brands themselves enforce it through the acquirers and processors they've signed.
Version 4.0 was published in March 2022. The previous version, 3.2.1, was retired on March 31, 2024. Version 4.0.1 — a minor revision with clarifications — was released in 2024 and is the current document. A batch of requirements initially labeled "best practices" in 4.0 became fully mandatory on March 31, 2025.
The scope question that determines everything
Before you read a single requirement, ask yourself: does your product store, process, or transmit cardholder data?
Cardholder data is the primary account number (the sixteen-digit card number) combined with any of: the cardholder name, expiry date, or service code. Sensitive authentication data — the CVV, PIN, and full magnetic stripe contents — carries even stricter rules and must not be stored at all after authorization.
The cardholder data environment (CDE) is every system, application, person, and process that stores, processes, or transmits that data, plus anything that could affect the security of those systems. The CDE is what the audit actually covers. Scope creep here is expensive — each additional system in scope adds evidence requirements, and scope decisions made early tend to stick.
The practical shortcut most SaaS companies take: push payments through a processor like Stripe using their hosted payment fields or redirect flow, so raw card numbers never touch your servers. When implemented correctly, your CDE shrinks to almost nothing. You're still technically in scope as a merchant, but the scope is narrow enough to qualify for a short self-assessment questionnaire instead of a full external audit.
SAQ types and merchant levels
The PCI SSC defines four merchant levels based on annual transaction volume with the card brands. Level 1 merchants — those processing more than six million transactions per year with Visa or Mastercard — must undergo an annual Report on Compliance (RoC) conducted by a Qualified Security Assessor, a QSA certified by the PCI SSC. Levels 2 through 4 cover lower volumes and can self-attest using a Self-Assessment Questionnaire.
For most SaaS companies, the correct SAQ depends on how payments are implemented:
- SAQ A applies when card processing is fully outsourced — the cardholder data is captured and stored entirely by your payment provider, and your integration uses their redirect page or embedded iframe with no server-side access to card data. This is the lightest path.
- SAQ A-EP applies when you run your own checkout page scripts that interact with payment fields before data goes to the processor. It's more demanding than SAQ A and carries the new 4.0 script security requirements.
- SAQ B covers merchants using standalone physical terminals with no electronic card data storage.
- SAQ D is the catch-all for merchants that don't qualify for shorter forms. It carries the full requirement set and is a substantial compliance exercise.
Picking the right integration pattern is a security and compliance decision, not just a UX one. I've seen startups accidentally move out of SAQ A territory by customizing their checkout flow in a way that made their servers briefly touch card data in transit — often without realizing it.
The twelve requirements, briefly
PCI DSS organizes its controls into twelve numbered requirements grouped under six goals. The structure hasn't changed in 4.0, but many requirements have been expanded or made more explicit:
- Install and maintain network security controls
- Apply secure configurations to all system components
- Protect stored account data
- Protect cardholder data with strong cryptography during transmission — the encryption in transit controls are specific here
- Protect all systems against malware and keep anti-malware software current
- Develop and maintain secure systems and software
- Restrict access to system components and cardholder data by business need to know
- Identify users and authenticate access to system components
- Restrict physical access to cardholder data
- Log and monitor all access to network resources and cardholder data
- Test security of systems and networks regularly
- Support information security with organizational policies and programs
For a SaaS team that's new to PCI, requirements 3, 4, 7, 8, and 10 are usually where the gaps live. Requirement 9 — physical access — only matters if you run physical infrastructure; most cloud-native companies rely on their cloud provider's attestations for that layer.
What actually changed in version 4.0
PCI DSS 4.0 introduced dozens of new or expanded requirements. Most of the heavier additions affect organizations with broader scope. For a typical SaaS company, the changes that land in practice are:
MFA for all CDE access. Version 3.2.1 required multi-factor authentication for remote access into the CDE. Version 4.0 extends the requirement to all access — including access over an internal network. Every account that can reach the systems touching payment data now needs MFA, not just people connecting from outside. The MFA explainer covers what auditors specifically look for.
Password minimums raised. The minimum password length moved from seven to twelve characters under Requirement 8.3.6. This is a low-effort change, but failing to update your policy documentation is a quick finding.
Script controls for e-commerce checkout pages. Requirements 6.4.3 and 11.6.1 are new in 4.0 and specifically address eSkimming attacks of the kind that have hit checkout pages for years. Every JavaScript on a payment page must be inventoried, authorized by management, and verified for integrity. Changes to scripts or HTTP security headers must trigger alerts within seven days. If you're operating under SAQ A-EP, this is meaningful ongoing operational work — not a one-time checkbox.
Customized approach. Version 4.0 formally introduced a "customized approach" that lets organizations meet the intent of a requirement through controls they design themselves, rather than the prescriptive "defined approach." In practice, this is aimed at large, mature security programs with established governance. Each customized control requires a Targeted Risk Analysis documented and signed off by qualified personnel. It's not a loophole for smaller teams; the documentation burden alone tends to outweigh the prescriptive path for anyone below enterprise scale.
Additional service provider requirements. If your product is used by other organizations that process payments through it, eleven additional requirements apply to you as a service provider. These include quarterly compliance status reviews and notification requirements during security incidents.
What "PCI compliant" actually means
There is no PCI seal issued by a neutral authority. What compliance actually produces is one of two documents:
A Self-Assessment Questionnaire with Attestation of Compliance (AOC) — a signed form you complete yourself, filed with your acquirer. Levels 2 through 4 merchants use this path.
A Report on Compliance (RoC) — a formal report produced by a QSA, required for Level 1 merchants and sometimes demanded by specific acquirers at lower volumes.
Your acquirer is the party technically enforcing compliance. They can require you to provide documentation, mandate a QSA assessment, or terminate your ability to accept card payments for persistent non-compliance. The card brands set the rules; the acquirer enforces them on their merchants.
This is worth understanding when a customer asks about your PCI posture. The honest, complete answer is: "We complete an annual SAQ at Level X and file the AOC with our acquirer." If they want the document, point them to your AOC. A vague "we're PCI compliant" statement invites follow-up questions — and rightly so.
For context on how PCI fits alongside SOC 2, ISO 27001, and the rest, the frameworks overview has the comparison. The short version: most B2B SaaS teams run SOC 2 first since that's what buyers ask for, and PCI becomes relevant when payments enter the picture. The underlying controls — access management, encryption, logging, incident response — overlap heavily, so there's little redundant work if you've already built a real security program.
Where SaaS teams usually get tripped up
Most SAQ A companies have a cleaner compliance path than they expect. The failure modes I see most often:
Teams implement Stripe's hosted fields correctly but then log form submission events through a third-party analytics script — one that inadvertently captures card fields. That log entry means the server touched cardholder data. SAQ A no longer applies.
Teams assume their cloud provider's PCI compliance covers them. AWS holds its own PCI attestation, which means the physical data center infrastructure is covered. But the shared responsibility model applies: your application code, your configuration, your access controls are still your problem. Using PCI-compliant infrastructure doesn't make your deployment compliant — same principle as the AWS SOC 2 shared responsibility question.
The practical starting point: confirm with your payment processor which SAQ actually applies to your integration method. Complete it honestly. Keep the AOC on file with your acquirer. If anything runs on your checkout pages — analytics, A/B testing scripts, chat widgets — review what the 4.0 script requirements mean for your inventory and monitoring obligations. That work tends to surface the gaps that matter.