Summary

This guide breaks down exactly what PCI DSS requires for B2B SaaS companies, how to determine your compliance level, and the practical steps you need to take to protect cardholder data. - Level 1: More than 300,000 Visa or Mastercard transactions annually — requires an annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) - Level 2: Fewer than 300,000 transactions annually — requires an annual Self-Assessment Questionnaire (SAQ) and quarterly network scans

PCI DSS Requirements for B2B SaaS: What You Need to Know to Stay Compliant

If your B2B SaaS platform touches payment card data in any way — even indirectly — PCI DSS compliance isn’t optional. The Payment Card Industry Data Security Standard applies broadly, and misunderstanding your scope can expose your business to fines, breaches, and lost enterprise contracts.

This guide breaks down exactly what PCI DSS requires for B2B SaaS companies, how to determine your compliance level, and the practical steps you need to take to protect cardholder data.

What Is PCI DSS and Why Does It Apply to B2B SaaS?

PCI DSS is a global security standard created by the PCI Security Standards Council (PCI SSC) that governs how organizations store, process, and transmit payment card data. It applies to any organization that accepts, processes, stores, or transmits cardholder data — including SaaS vendors that serve business customers.

For B2B SaaS companies, the compliance obligation often surprises founders and engineering teams. You may think, “We don’t handle payments directly,” but if your platform:

Integrates with payment processors on behalf of clients
Stores any cardholder data (even temporarily)
Transmits payment data through your infrastructure
Provides APIs that interact with card transaction systems

…then PCI DSS applies to you.

Enterprise buyers increasingly require PCI DSS compliance as a vendor qualification criterion. Failing to demonstrate compliance can cost you deals, damage your reputation, and create legal liability.

Understanding Your PCI DSS Scope as a SaaS Provider

Before diving into specific requirements, you must determine your compliance scope — the systems, people, and processes that store, process, or transmit cardholder data (CHD) or that could affect the security of that data.

The Cardholder Data Environment (CDE)

Your CDE includes all system components that:

Store, process, or transmit CHD or sensitive authentication data (SAD)
Connect to or provide security services for those components
Could impact the security of the CDE even indirectly

Scope reduction is critical. The smaller your CDE, the fewer requirements apply and the lower your compliance burden. Many B2B SaaS companies reduce scope by using tokenization or outsourcing payment processing entirely to a PCI-compliant third party like Stripe or Braintree.

Merchant Levels vs. Service Provider Levels

B2B SaaS companies typically qualify as service providers rather than merchants. Service provider levels are determined by transaction volume:

Level 1: More than 300,000 Visa or Mastercard transactions annually — requires an annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)
Level 2: Fewer than 300,000 transactions annually — requires an annual Self-Assessment Questionnaire (SAQ) and quarterly network scans

Knowing your level determines what documentation, assessments, and controls you must maintain.

The 12 PCI DSS Requirements: A B2B SaaS Breakdown

PCI DSS v4.0 (the current version as of 2024) organizes its requirements into 12 domains. Here’s how each applies to a typical B2B SaaS environment.

1. Install and Maintain Network Security Controls

Your cloud infrastructure must use firewalls, network segmentation, and access control lists to isolate your CDE from other environments. For SaaS platforms on AWS, GCP, or Azure, this means properly configured VPCs, security groups, and network ACLs.

2. Apply Secure Configurations to All System Components

Default passwords and vendor-supplied settings must be changed before deployment. Maintain a hardened configuration baseline for all servers, containers, and cloud services in scope.

3. Protect Stored Account Data

This is where many SaaS companies get into trouble. Never store:

Full magnetic stripe data
CVV/CVC codes
PINs or PIN blocks

If you must store Primary Account Numbers (PANs), they must be rendered unreadable using strong cryptography (AES-256 or similar).

4. Protect Cardholder Data with Strong Cryptography During Transmission

All CHD transmitted over public networks must be encrypted using TLS 1.2 or higher. Disable older protocols (SSL, TLS 1.0, TLS 1.1) across your entire platform.

5. Protect All Systems Against Malware

Deploy and maintain anti-malware solutions across all system components. In containerized SaaS environments, this includes runtime security scanning and image vulnerability management.

6. Develop and Maintain Secure Systems and Software

This requirement is especially relevant for SaaS engineering teams:

Follow a secure software development lifecycle (SSDLC)
Conduct code reviews for security vulnerabilities
Apply patches within defined timeframes (critical patches within one month)
Use a web application firewall (WAF) to protect customer-facing applications

7. Restrict Access to System Components and Cardholder Data by Business Need to Know

Implement role-based access control (RBAC). Only personnel who genuinely need access to CHD should have it, and access should be granted at the minimum privilege level necessary.

8. Identify Users and Authenticate Access to System Components

Enforce multi-factor authentication (MFA) for all access to the CDE
Use unique user IDs — no shared accounts
Enforce strong password policies
Disable inactive accounts after 90 days

9. Restrict Physical Access to Cardholder Data

If you use third-party data centers or colocation facilities, ensure they maintain appropriate physical security controls. Most cloud-native SaaS companies satisfy this through their cloud provider’s compliance certifications.

10. Log and Monitor All Access to System Components and Cardholder Data

Implement centralized logging for all CDE access. Logs must:

Be tamper-evident
Retain for at least 12 months (3 months immediately available)
Be reviewed daily using automated tools or SIEM solutions

11. Test Security of Systems and Networks Regularly

Conduct quarterly vulnerability scans using an Approved Scanning Vendor (ASV)
Perform annual penetration testing (and after significant changes)
Run internal vulnerability scans after any significant infrastructure changes

12. Support Information Security with Organizational Policies and Programs

Document and maintain a comprehensive information security policy. This includes:

Risk assessment processes
Incident response plans
Security awareness training for all personnel
Third-party/vendor management policies

Choosing the Right SAQ for Your B2B SaaS Model

Not all SaaS companies complete the same Self-Assessment Questionnaire. The right SAQ depends on how your platform interacts with payment data:

SAQ Type	Applicable Scenario
SAQ A	CHD fully outsourced; no electronic storage of CHD
SAQ A-EP	E-commerce that partially outsources payment processing
SAQ D (Service Provider)	Service providers that store, process, or transmit CHD

Most B2B SaaS companies that handle any cardholder data on their own infrastructure will complete SAQ D for Service Providers, which covers all 12 requirement domains.

Practical Steps to Achieve PCI DSS Compliance for Your SaaS

Here’s a realistic roadmap for a B2B SaaS company pursuing compliance:

Define your scope — Map all data flows involving cardholder data
Reduce your CDE — Implement tokenization or redirect payment flows to a compliant processor
Gap assessment — Compare current controls against all applicable PCI DSS requirements
Remediation — Address gaps in network security, access controls, encryption, and logging
Documentation — Create required policies, procedures, and evidence artifacts
Vulnerability scanning — Engage an ASV for quarterly external scans
Penetration testing — Commission an annual pentest from a qualified firm
Complete your SAQ or ROC — Submit with your acquiring bank or card brands
Ongoing monitoring — Maintain continuous compliance through log review, patch management, and training

FAQ: PCI DSS for B2B SaaS

Does PCI DSS apply if we use Stripe or another third-party payment processor?

Yes, but your scope is significantly reduced. Using a processor like Stripe with their hosted payment fields (Stripe.js/Elements) means cardholder data never touches your servers. You’ll likely qualify for SAQ A, which has far fewer requirements. However, you still need to document your integration and maintain basic security controls.

How long does PCI DSS compliance take to achieve?

For most B2B SaaS companies starting from scratch, expect 3–6 months to achieve initial compliance. Companies with existing security programs and mature infrastructure can often complete the process in 6–10 weeks with the right documentation and tooling in place.

What happens if we’re not PCI DSS compliant and we experience a breach?

Non-compliant organizations face significant consequences: fines from card brands ranging from $5,000 to $100,000 per month, liability for fraudulent transactions, mandatory forensic investigations at your expense, and potential termination of your ability to process card payments. Enterprise customers may also pursue breach of contract claims.

Do we need a QSA, or can we self-assess?

Level 2 service providers can self-assess using the SAQ. Level 1 service providers must engage a Qualified Security Assessor (QSA) for an annual Report on Compliance. Even if self-assessment is permitted, many B2B SaaS companies voluntarily engage a QSA to strengthen their compliance posture and provide assurance to enterprise customers.

How does PCI DSS v4.0 differ from v3.2.1?

PCI DSS v4.0 introduces more flexibility in how requirements are met (customized approach), strengthens authentication requirements (MFA now required for all CDE access), and adds new targeted risk analysis requirements. Full enforcement of v4.0 future-dated requirements began in March 2025.

Get Compliant Faster with Ready-to-Use PCI DSS Templates

Building PCI DSS documentation from scratch is time-consuming, error-prone, and expensive. Our professionally crafted PCI DSS compliance template bundle for B2B SaaS includes everything you need to accelerate your compliance program:

✅ Information Security Policy (PCI DSS aligned)
✅ Incident Response Plan template
✅ Risk Assessment framework
✅ Vendor Management Policy
✅ Access Control and User Management procedures
✅ Patch Management Policy
✅ SAQ D completion guide with annotated evidence requirements
✅ Security Awareness Training outline

Stop reinventing the wheel. Our templates are written by compliance professionals, reviewed against PCI DSS v4.0, and designed specifically for cloud-native SaaS environments.

[Browse PCI DSS Templates for B2B SaaS →]

Get audit-ready in weeks, not months — and give your enterprise prospects the compliance evidence they need to say yes.