PCI DSS Compliance: A Practical Guide for SaaS That Touches Card Data
PCI DSS compliance is required for any company that stores, processes, or transmits payment card data, and that quietly includes most SaaS platforms that charge their customers by card. The good news is that the amount of work involved is not fixed. It scales directly with how close card data gets to your own systems, and for most SaaS companies that number can be driven almost to zero.
This guide covers what PCI DSS compliance actually requires, who needs it, which self-assessment questionnaire applies to you, and how a tokenizing payment processor shrinks your scope. For the full engagement, see the PCI DSS service page.
What PCI DSS compliance means
PCI DSS stands for the Payment Card Industry Data Security Standard. It is a security framework created by the major card brands (Visa, Mastercard, American Express, Discover, and JCB) and maintained by the PCI Security Standards Council. The current version is PCI DSS v4.0, and its future-dated requirements became mandatory in early 2025.
The standard exists to protect cardholder data: the primary account number, cardholder name, expiration date, and the sensitive authentication data used to approve a transaction. Any business that handles this data has to meet the standard. Unlike SOC 2 or ISO 27001, PCI DSS is not a certification you pursue for marketing. It is a contractual obligation imposed by the card brands and enforced through your acquiring bank or payment processor.
The PCI DSS compliance meaning that trips people up is the assumption that it only applies to merchants. It applies to service providers too: any company that could affect the security of a card transaction, including SaaS platforms, hosting providers, and payment gateways.
Who needs PCI DSS certification
If your platform accepts card payments, PCI DSS applies to you. There is no revenue floor and no small-business exemption. What changes with size is how you validate compliance, not whether you have to.
Validation is tiered into four merchant levels based on annual transaction volume:
- Level 1: over 6 million card transactions per year. Requires an annual audit by a Qualified Security Assessor (QSA) resulting in a Report on Compliance.
- Level 2: 1 million to 6 million transactions per year. Usually a self-assessment questionnaire plus, in some cases, a QSA-assisted review.
- Level 3: 20,000 to 1 million e-commerce transactions per year. Self-assessment questionnaire and quarterly network scans.
- Level 4: fewer than 20,000 e-commerce transactions, or up to 1 million total. Self-assessment questionnaire and scans, validated through your acquirer.
Most Series A to C SaaS companies sit at Level 3 or Level 4 and validate through a self-assessment questionnaire. The card brands set the level thresholds, and each brand runs its own compliance program, so your acquiring bank is the authority on which level applies to you.
The 12 requirements, grouped into 6 principles
PCI DSS is organized as 12 requirements under six control objectives. These six objectives are what the People Also Ask box means by the "6 major principles."
Build and maintain a secure network and systems
- Install and maintain network security controls, such as firewalls between untrusted networks and your cardholder data environment.
- Apply secure configurations to all system components, and remove vendor default passwords and settings.
Protect account data
- Protect stored account data through encryption, truncation, or tokenization. Never store sensitive authentication data after authorization.
- Encrypt cardholder data in transit across open, public networks using strong cryptography such as TLS 1.2 or higher.
Maintain a vulnerability management program
- Protect all systems against malware and keep anti-malware current.
- Develop and maintain secure systems and software, including timely patching and secure development practices.
Implement strong access control measures
- Restrict access to cardholder data by business need to know.
- Identify users and authenticate access, including multi-factor authentication for access into the cardholder data environment.
- Restrict physical access to cardholder data and the systems that store it.
Regularly monitor and test networks
- Log and monitor all access to system components and cardholder data.
- Test the security of systems and networks regularly, including vulnerability scans and penetration testing.
Maintain an information security policy
- Support information security with organizational policies and a formal program, including risk assessment and personnel training.
If those requirements look familiar, they should. Roughly two-thirds of them overlap with SOC 2 and ISO 27001 controls, which is why companies pursuing multiple frameworks build once and map across. We cover that pattern in compliance controls overlap.
Which self-assessment questionnaire applies to you
For most SaaS companies not at Level 1, PCI DSS compliance is validated through a Self-Assessment Questionnaire (SAQ). The SAQ you complete depends entirely on how card data flows through your environment. Choosing the right one is the most important scoping decision you will make.
- SAQ A: you have fully outsourced all card data handling to a PCI-compliant third party, and card data never touches your systems. This is the shortest questionnaire, and it is where you want to be.
- SAQ A-EP: you use a payment page that you partly control, such as a JavaScript integration that could theoretically be tampered with, even though your servers do not store card data.
- SAQ D: card data is stored, processed, or transmitted through your own systems. This is the longest questionnaire and requires the full control set, scanning, and penetration testing.
The difference between SAQ A and SAQ D is enormous: roughly two dozen questions versus several hundred, and a light annual effort versus a program that consumes real budget. Everything about keeping PCI DSS compliance manageable comes down to landing in SAQ A.
How Stripe (and tokenization) shrinks your scope
The single most effective PCI DSS strategy for SaaS is to never touch card data at all. If you use a hosted checkout or a tokenizing integration, the payment processor handles the card number and returns a token, and your systems only ever see the token.
Concretely, integrations like Stripe Checkout, Stripe Elements, or a redirect to a hosted payment page keep the card number inside the processor's PCI-compliant environment. Your servers, databases, and logs never see it. That qualifies you for SAQ A, the minimal questionnaire, because there is no cardholder data in your scope to protect.
The anti-pattern is building your own payment form that posts the raw card number to your backend, even if you immediately forward it to a processor. The moment that data hits your server, you are in SAQ D territory and your entire application becomes part of the cardholder data environment. The engineering shortcut of "just collect the card ourselves" is the most expensive decision a SaaS team can make on this framework.
PCI DSS compliance checklist for SaaS
If you are starting from zero, work through this order:
- Confirm how card data flows today. Map every point where a card number could enter your systems.
- Move to a tokenizing integration so card data never reaches your servers. This is the highest-leverage step.
- Determine your merchant level with your acquiring bank.
- Identify the correct SAQ (aim for SAQ A).
- Complete quarterly network vulnerability scans through an Approved Scanning Vendor if your SAQ requires them.
- Fill out the SAQ and the Attestation of Compliance.
- Submit to your acquirer or processor, and re-validate annually.
PCI DSS is an annual obligation, not a one-time project. The controls have to stay in place and get re-attested every year, which is why building the program around a minimal scope pays back every year that follows.
For how PCI DSS fits alongside your other obligations, see which compliance framework your SaaS actually needs and the SaaS compliance stack. When you are ready to validate, the PCI DSS service page covers the full engagement, and if you also handle health or EU data, compliance controls overlap shows where the work double-counts.
Frequently Asked Questions
What is PCI DSS compliance? It means meeting the Payment Card Industry Data Security Standard, 12 security requirements that apply to any business that stores, processes, or transmits payment card data. It is enforced by the card brands through your acquiring bank, and validated by either a self-assessment questionnaire or an external assessor depending on your volume.
Who needs PCI DSS certification? Any organization that touches cardholder data, regardless of size, including SaaS platforms that accept card payments through a third party. The validation effort scales with volume, from the shortest self-assessment questionnaire up to a formal QSA audit at Level 1.
Can I do PCI compliance myself? For most SaaS companies, yes. If card data never touches your servers because you use a hosted or tokenizing integration, you qualify for SAQ A and can self-assess in-house. Setups where card data flows through your own systems require SAQ D and a much larger effort.
What are the 6 major principles of PCI DSS? Build and maintain a secure network and systems; protect account data; maintain a vulnerability management program; implement strong access control measures; regularly monitor and test networks; and maintain an information security policy. The 12 requirements sit under these six objectives.
How much does PCI DSS compliance cost? It depends on scope. A SaaS company using a tokenizing processor and completing SAQ A spends little beyond internal time, while an in-scope environment completing SAQ D can spend tens of thousands on scanning, testing, and remediation. Keeping card data out of your systems is the biggest cost lever.
Ready to Scope Your PCI DSS Compliance?
ShieldKey Solutions helps SaaS companies right-size their PCI DSS compliance, starting by re-architecting card data flows so you land in the smallest possible scope. We map your environment, identify the correct SAQ, and manage validation through to your Attestation of Compliance.