Summary

Consequences include fines from card brands (typically $5,000–$100,000 per month), mandatory forensic investigations at your expense, increased transaction fees, and potentially losing the ability to process card payments altogether. Enterprise clients may also terminate contracts.

PCI DSS Requirements List for B2B SaaS: A Practical Compliance Guide

If your B2B SaaS platform touches payment card data in any way — even indirectly — you need to understand PCI DSS requirements. The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that stores, processes, or transmits cardholder data, and the consequences of non-compliance range from steep fines to losing the ability to accept card payments entirely.

This guide breaks down the full PCI DSS requirements list in plain language, with specific context for B2B SaaS companies navigating compliance for the first time or preparing for an audit.

What Is PCI DSS and Why Does It Matter for B2B SaaS?

PCI DSS is a global security standard maintained by the PCI Security Standards Council (PCI SSC). Version 4.0, released in 2022 and now fully enforceable, represents the most significant update in over a decade.

For B2B SaaS companies, PCI DSS matters because:

You may process subscription payments or invoices using credit cards
Your platform may integrate with payment processors on behalf of clients
You could be storing cardholder data in logs, databases, or support tickets without realizing it
Enterprise clients increasingly require proof of PCI compliance before signing contracts

Even if you outsource payment processing to Stripe, Braintree, or another gateway, you still have compliance obligations depending on your integration method.

Understanding Your Scope: The First Step for SaaS Companies

Before diving into the requirements list, you must define your Cardholder Data Environment (CDE) — the systems, people, and processes that store, process, or transmit cardholder data. Scope reduction is one of the most powerful strategies available to SaaS companies.

Common Scope Reduction Strategies

Use hosted payment pages (iframes or redirects) so card data never touches your servers
Implement tokenization to replace card numbers with non-sensitive tokens
Leverage point-to-point encryption (P2PE) for any physical payment terminals connected to your platform
Segment your network to isolate payment-related systems from the rest of your infrastructure

Your applicable SAQ (Self-Assessment Questionnaire) type depends on your integration method. Most SaaS companies using redirect-based payments qualify for SAQ A, which has significantly fewer requirements than SAQ D.

The 12 PCI DSS Requirements: Full List with SaaS Context

PCI DSS v4.0 organizes its controls into 12 core requirements grouped under six goals.

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

Configure firewalls to restrict inbound and outbound traffic to only what is necessary
Document all network connections to and from the CDE
Review firewall and router rule sets at least every six months
For SaaS: This applies to your cloud infrastructure (AWS security groups, GCP firewall rules, Azure NSGs)

Requirement 2: Apply Secure Configurations to All System Components

Change all vendor-supplied default passwords before deployment
Develop configuration standards for all system components
Enable only necessary services, protocols, and ports
For SaaS: Harden your EC2 instances, containers, and database configurations using CIS Benchmarks

Goal 2: Protect Account Data

Requirement 3: Protect Stored Account Data

Identify all locations where cardholder data is stored
Limit data retention to what is legally or operationally necessary
Mask PANs (Primary Account Numbers) when displayed — show only the first six and last four digits
Use strong cryptography to protect stored cardholder data
For SaaS: Audit your logs, databases, and support tools — card data often ends up in unexpected places

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Use TLS 1.2 or higher for all transmissions of cardholder data over open networks
Never send unprotected PANs via email, chat, or messaging platforms
Maintain an inventory of all trusted keys and certificates

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

Deploy anti-malware solutions on all applicable system components
Perform periodic scans and generate audit logs
Protect against phishing attacks targeting your team
For SaaS: Implement endpoint detection on developer machines and CI/CD pipeline security scanning

Requirement 6: Develop and Maintain Secure Systems and Software

Follow a secure software development lifecycle (SDLC)
Address vulnerabilities based on a risk-ranking system
Conduct code reviews and application security testing before production releases
Use a web application firewall (WAF) to protect public-facing applications
For SaaS: This requirement directly impacts your engineering team — document your SDLC and penetration testing cadence

Goal 4: Implement Strong Access Control Measures

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

Implement role-based access control (RBAC)
Default all access to “deny all” unless explicitly granted
Document access control policies and review them regularly

Requirement 8: Identify Users and Authenticate Access to System Components

Assign unique IDs to every user — no shared credentials
Enforce multi-factor authentication (MFA) for all access to the CDE
Set strong password policies (minimum 12 characters under v4.0)
Lock accounts after a maximum of 10 failed login attempts
For SaaS: MFA is now required for all non-console CDE access — enforce this across your team and customer-facing admin panels

Requirement 9: Restrict Physical Access to Cardholder Data

Control physical access to systems in your CDE
Maintain visitor logs and badge access records
For SaaS: If you’re cloud-hosted, your data center provider (AWS, Azure, GCP) handles most of this — document this in your shared responsibility model

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Implement audit logs for all access to CDE systems
Protect logs from modification or deletion
Review logs daily using automated tools or SIEM solutions
Retain logs for at least 12 months, with three months immediately available
For SaaS: Set up centralized logging with tools like Splunk, Datadog, or AWS CloudWatch

Requirement 11: Test Security of Systems and Networks Regularly

Run internal and external vulnerability scans quarterly (using an Approved Scanning Vendor for external scans)
Conduct penetration testing at least annually and after significant infrastructure changes
Use intrusion detection systems (IDS/IPS) to monitor network traffic
Implement file integrity monitoring (FIM) on critical systems

Goal 6: Maintain an Information Security Policy

Requirement 12: Support Information Security with Organizational Policies and Programs

Maintain a comprehensive information security policy reviewed annually
Conduct security awareness training for all personnel at hire and annually
Maintain an incident response plan and test it at least once per year
Manage third-party service providers with a formal vendor risk management program
For SaaS: Your vendor risk program must include documented assessments of all payment processors and subprocessors

New PCI DSS v4.0 Requirements SaaS Teams Should Know

Version 4.0 introduced several notable changes relevant to SaaS companies:

Customized approach: Organizations can now implement alternative controls that meet the intent of a requirement, offering more flexibility for cloud-native architectures
Targeted risk analysis: Many requirements now allow you to set your own frequency based on a documented risk assessment
MFA everywhere: MFA is now required for all access into the CDE, not just remote access
Password length: Minimum password length increased from 8 to 12 characters
Script integrity: New controls for managing scripts on payment pages to prevent skimming attacks (critical for SaaS with embedded payment forms)

FAQ: PCI DSS for B2B SaaS

Does PCI DSS apply to my SaaS company if we use Stripe?

Yes, to some degree. Using Stripe reduces your scope significantly, but you still have obligations around how you integrate, what data you log, and how you protect your systems. Most Stripe-integrated SaaS companies qualify for SAQ A or SAQ A-EP.

What is the difference between SAQ A and SAQ D for SaaS?

SAQ A applies to merchants using fully outsourced payment pages where no card data touches their systems. SAQ D applies to all other merchants and service providers and covers all 12 requirements in full. SaaS platforms acting as payment facilitators or storing any card data typically fall under SAQ D.

How often do we need to conduct penetration testing?

At minimum, annually and after any significant changes to your infrastructure or application. Many enterprise clients and QSAs recommend twice per year for SaaS platforms with active development cycles.

What happens if our SaaS platform is breached and we’re not PCI compliant?

Do we need a Qualified Security Assessor (QSA) to become PCI compliant?

Not always. Smaller merchants and service providers can self-assess using the appropriate SAQ. However, Level 1 service providers (processing over 300,000 transactions annually) must have an annual Report on Compliance (ROC) conducted by a QSA.

Start Your PCI DSS Compliance Journey with Ready-to-Use Templates

Building PCI DSS documentation from scratch is time-consuming and easy to get wrong. Missing a single policy or procedure can delay your audit, cost you a client deal, or leave you exposed during an assessment.

Our professionally written PCI DSS compliance template bundles include everything B2B SaaS teams need to get audit-ready fast:

Information Security Policy
Incident Response Plan
Access Control and Password Policy
Vendor Risk Management Policy
Network Security and Firewall Policy
Security Awareness Training Program outline
PCI DSS Scope and Risk Assessment templates

Each template is written by compliance experts, aligned with PCI DSS v4.0, and formatted for immediate use with your team or QSA.

Browse PCI DSS Compliance Templates → and stop starting from a blank page.