Payment Security Is Non-Negotiable
The Payment Card Industry Data Security Standard (PCI DSS) exists to protect cardholder data wherever it’s stored, processed, or transmitted. If your SaaS product accepts payments, processes transactions, or touches card data in any way, PCI DSS applies.
Unlike SOC 2 or ISO 27001, PCI DSS isn’t about demonstrating general security maturity. It’s a prescriptive standard with specific technical requirements dictated by the payment card brands (Visa, Mastercard, Amex, Discover) through the PCI Security Standards Council. Non-compliance can result in fines from your acquiring bank, increased transaction fees, or losing the ability to process card payments entirely.
PCI DSS 4.0: What Changed
PCI DSS 4.0, which became mandatory in March 2025, represents the most significant update to the standard in over a decade. Key changes include:
Customized approach. Organizations can now meet requirements using the traditional defined approach or a new customized approach that allows flexibility in how you achieve each security objective. This is particularly valuable for SaaS companies with modern architectures that don’t fit neatly into traditional control prescriptions.
Expanded multi-factor authentication. MFA is now required for all access to the cardholder data environment, not just remote access.
Enhanced encryption requirements. Stronger requirements for cryptographic key management and the deprecation of older protocols.
Targeted risk analysis. Many requirements now specify that the frequency of certain activities should be determined by a targeted risk analysis rather than rigid timelines.
Client-side security. New requirements for managing payment page scripts and protecting against client-side attacks like e-skimming.
Determining Your Scope
Scope is the single biggest factor in PCI DSS compliance complexity. The cardholder data environment (CDE) includes every system that stores, processes, or transmits cardholder data, plus every system connected to those systems.
For SaaS companies, the most important question is: does cardholder data actually touch your systems?
Scenario 1: You Use a Third-Party Payment Processor
If you use Stripe, Braintree, or a similar processor and card data never touches your servers (the customer’s browser communicates directly with the processor via iframe or redirect), your PCI scope is minimal. You’ll likely qualify for SAQ A, the simplest self-assessment questionnaire.
Scenario 2: You Handle Card Data Through Your Application
If cardholder data flows through your application servers, even briefly, your scope expands significantly. You’ll need to implement the full range of PCI DSS controls for those systems and any connected systems.
Scenario 3: You Store Card Data
If you store cardholder data (card numbers, expiration dates), you’re in the deepest end of PCI compliance. You need strong encryption, key management, access controls, and regular testing. Unless you have a specific business reason to store card data, don’t.
Compliance Levels
Your compliance validation requirements depend on your transaction volume:
Level 1: Over 6 million transactions annually. Requires an annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) and quarterly network scans.
Level 2: 1-6 million transactions. Requires an annual Self-Assessment Questionnaire (SAQ) and quarterly network scans.
Level 3: 20,000 to 1 million e-commerce transactions. Same as Level 2.
Level 4: Fewer than 20,000 e-commerce transactions or up to 1 million total transactions. SAQ and quarterly network scans.
Most SaaS companies fall into Level 3 or 4 and can self-assess using the appropriate SAQ. But your acquiring bank or payment processor may impose additional requirements.
The 12 Requirements
PCI DSS is organized around 12 high-level requirements:
- 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
- Protect all systems and networks from malicious software
- 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 system components and cardholder data
- Test security of systems and networks regularly
- Support information security with organizational policies and programs
Each requirement breaks down into detailed sub-requirements with specific implementation expectations.
Scope Reduction Strategies
The best PCI DSS strategy for most SaaS companies is minimizing scope:
Use tokenization. Replace actual card numbers with tokens throughout your application. If your systems only ever see tokens, they’re out of PCI scope.
Use hosted payment pages. Redirect customers to your payment processor’s hosted page or use their embedded iframe. If card data never enters your domain, your scope shrinks dramatically.
Segment your network. If you must handle card data, isolate the CDE from the rest of your environment. Proper network segmentation limits which systems fall into PCI scope.
Leverage your cloud provider. AWS, Azure, and GCP all maintain their own PCI DSS compliance. Using their PCI-validated services means you inherit their physical and infrastructure-level controls.
Common Mistakes
Underestimating scope. That logging server that receives data from your payment system? In scope. The developer laptop that accessed the production payment database? In scope. Any system connected to your CDE is in scope unless properly segmented.
Ignoring SAQ requirements. Just because you qualify for a simpler SAQ doesn’t mean you can ignore its requirements. SAQ A still has specific controls you must implement around payment page security, especially under PCI DSS 4.0.
Assuming your payment processor handles everything. Using Stripe doesn’t make you PCI compliant. It reduces your scope, but you still have responsibilities: securing your application, protecting your authentication credentials, managing your payment page scripts, and completing the appropriate SAQ.
Treating PCI as separate from your security program. PCI DSS requirements overlap with SOC 2 and ISO 27001 controls. Access controls, logging, encryption, vulnerability management, and incident response are all shared territory. Build once, map across frameworks.
PCI DSS and Your Other Frameworks
If you’re already SOC 2 or ISO 27001 certified, you have a head start. Many PCI DSS requirements around access control, logging, encryption, change management, and incident response are satisfied by controls you’ve already implemented.
The unique PCI DSS requirements typically center on cardholder-data-specific controls: tokenization, payment page security, PAN masking, key management for card data encryption, and the specific quarterly scanning and annual penetration testing requirements.
At Concerto, we help SaaS companies determine their PCI scope, implement the right controls, and integrate PCI compliance into their existing security program. Schedule a consultation to discuss your payment security requirements.
