PCI-DSS Compliance Guide for SaaS and E-Commerce Companies
PCI-DSS applies to any business that processes, stores, or transmits cardholder data. This guide covers the 12 requirements, SAQ types, scoping, network segmentation, and how to minimize your compliance burden.
PCI-DSS (Payment Card Industry Data Security Standard) applies to every organization that processes, stores, or transmits payment card data. That includes SaaS companies that handle card payments directly, as well as e-commerce platforms and payment processors.
PCI-DSS v4.0, published in 2022 with a compliance deadline of March 2025, introduces significant changes including continuous monitoring requirements and additional controls for online payment pages.
Scope: What Falls Under PCI-DSS
Your PCI scope is defined as the Cardholder Data Environment (CDE): all systems that process, store, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus any systems that can directly or indirectly affect the security of the CDE.
What Counts as Cardholder Data
| Data Element | Storage Permitted | Must Protect |
|---|---|---|
| Primary Account Number (PAN) — the 16-digit card number | Yes, if protected | Yes |
| Cardholder Name | Yes | Yes (if stored with PAN) |
| Service Code | Yes | Yes (if stored with PAN) |
| Expiration Date | Yes | Yes (if stored with PAN) |
Sensitive Authentication Data (SAD) — Never Store After Authorization
| Data Element | Notes |
|---|---|
| Full track data (magnetic stripe) | Never store |
| CAV2/CVC2/CVV2/CID (3–4 digit code) | Never store |
| PINs / PIN blocks | Never store |
Even if encrypted, storing CVV/CVC after authorization is a PCI violation.
The Single Most Important PCI Decision: Reduce Scope
The best PCI-DSS compliance strategy is to ensure card data never touches your servers. This means:
Use a PCI-compliant payment processor with client-side tokenization:
- Stripe.js / Stripe Elements: Card data collected in an iframe served by Stripe; your servers never see card numbers
- Braintree Drop-in UI: Same approach
- PayPal/Square hosted fields: Similar pattern
If cardholder data never enters your environment, your PCI scope shrinks dramatically. You may qualify for the shortest SAQ (Self-Assessment Questionnaire) type.
SAQ Types: Which One Applies to You?
| SAQ | Who It's For | Questions |
|---|---|---|
| SAQ A | Card-not-present merchants using fully outsourced payment page (Stripe, PayPal redirect) | 22 |
| SAQ A-EP | E-commerce merchants with JavaScript payment form that calls a third-party processor | ~191 |
| SAQ B | Merchants using standalone payment terminals (no e-commerce) | 41 |
| SAQ B-IP | IP-connected payment terminals | 83 |
| SAQ C | Merchants with payment apps connected to internet | 161 |
| SAQ C-VT | Virtual terminal only | 73 |
| SAQ D | All other merchants; all service providers | 329 |
| SAQ P2PE | Hardware payment terminals on a P2PE solution | 35 |
Most SaaS companies using Stripe Elements qualify for SAQ A (22 questions). If you host any JavaScript that interacts with the payment flow, you're likely SAQ A-EP (~191 questions).
The 12 PCI-DSS Requirements
Requirement 1: Install and Maintain Network Security Controls
□ Firewall rules documented and reviewed every 6 months
□ Default deny inbound/outbound (allowlist, not blocklist)
□ Network diagram showing all CDE connections
□ No direct internet connectivity to CDE (DMZ required)
□ Stateful inspection on all connections
Requirement 2: Apply Secure Configurations
□ No vendor-supplied default passwords (change before deployment)
□ Remove all unnecessary services and functionality
□ Encrypt non-console administrative access (SSH, not Telnet)
□ System configuration standards documented for each system type
Requirement 3: Protect Stored Account Data
□ PAN masked when displayed (show only last 4 digits: XXXX-XXXX-XXXX-1234)
□ PAN encrypted using strong cryptography (AES-256)
□ Cryptographic keys protected and rotated annually
□ SAD never stored after authorization
□ Data retention policy limits PAN storage to what's needed
□ Quarterly process to identify and delete unnecessary CHD
Requirement 4: Protect Cardholder Data in Transit
□ Strong cryptography (TLS 1.2+) for all CHD transmission over open networks
□ TLS 1.0 and 1.1 disabled
□ Trusted keys and certificates only
□ No unprotected PANs in messages or emails
Requirement 5: Protect All Systems Against Malware
□ Anti-malware on all systems (or documented risk assessment for systems not at risk)
□ Anti-malware updated regularly
□ Periodic scans and real-time protection enabled
□ Anti-malware logs retained for 12 months
□ Phishing protection deployed
Requirement 6: Develop and Maintain Secure Systems and Software
□ Security patches applied: critical within 1 month, others within 3 months
□ Secure development lifecycle (SDLC) documented
□ Code review process for CHD-related code
□ OWASP Top 10 addressed in development practices
□ Web-facing applications protected by WAF or security code review
□ Change management process for production changes
□ Public-facing web apps: WAF or penetration test before production
New in PCI-DSS v4.0: Payment page scripts (JavaScript loaded on your checkout page) must be managed with an inventory, integrity checking (SRI or CSP with hashes), and authorization.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need
□ Access to CDE based on documented need-to-know
□ Default deny — access denied unless explicitly granted
□ Access control list (ACL) for each system component
□ All access reviewed every 6 months
Requirement 8: Identify Users and Authenticate Access
□ Unique IDs for all users (no shared accounts, no group logins)
□ MFA required for all access to CDE
□ MFA required for all remote access
□ Strong password policy (minimum 12 characters as of v4.0)
□ Password changed every 3 months for accounts not using MFA
□ Inactive accounts disabled after 90 days
□ Session timeout after 15 minutes of inactivity
Requirement 9: Restrict Physical Access to Cardholder Data
□ Physical access controls to CDE systems (badge access, locks)
□ Visitor logs maintained
□ Media containing CHD protected and tracked
□ Devices that capture PANs (POS terminals) inspected periodically for tampering
Requirement 10: Log and Monitor All Access
□ Audit logs for all CDE access
□ Logs protected from tampering
□ Log retention: 12 months, 3 months immediately accessible
□ Review logs daily (automated alerting for anomalies)
□ Failure of critical security controls triggers alert
□ Time synchronization (NTP) across all systems
Requirement 11: Test Security of Systems and Networks Regularly
□ External vulnerability scans by an ASV (Approved Scanning Vendor) quarterly
□ Internal vulnerability scans quarterly and after significant changes
□ External penetration test annually and after significant changes
□ Internal penetration test annually
□ Segmentation testing annually (verify CDE segmentation)
□ File integrity monitoring (FIM) on CDE
□ Intrusion detection/prevention system (IDS/IPS) at CDE perimeter
□ Wireless network scans quarterly
Requirement 12: Support Information Security with Organizational Policies
□ Information security policy approved by management, reviewed annually
□ Security risk assessment annually
□ Security awareness training program for all personnel
□ Incident response plan tested annually
□ Agreements with service providers documenting their PCI responsibilities
□ Inventory of third-party service providers (TPSPs) updated annually
Network Segmentation
The single most important PCI implementation decision after reducing scope is network segmentation. If your CDE systems are isolated from your non-CDE systems, a compromise outside the CDE doesn't affect your PCI scope.
Without segmentation: your entire network is in scope (hundreds of systems).
With proper segmentation: only the explicitly defined CDE is in scope.
Segmentation methods:
- Dedicated VPC/subnet for CDE workloads
- Separate AWS account for payment systems
- Firewall rules with default deny between CDE and non-CDE networks
- Application-layer controls (separate database, no shared credentials)