- PCI DSS v4.0 is now fully mandatory—all 64 requirements apply to assessments in 2026, and compliance is now a procurement gate for enterprise deals, not just a security checkbox.
- You must encrypt cardholder data with AES-256 at rest and TLS 1.2+ in transit, never store Sensitive Authentication Data (CVV, magnetic stripe, PIN), implement MFA for all admin access, and run quarterly external vulnerability scans.
- Tokenization, hosted payment pages, and PCI-compliant gateways reduce your compliance scope and are the fastest path to launch without building your own payment processing infrastructure.
What PCI DSS Is and Why It Matters for Your SaaS
PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements mandatory if your SaaS platform processes, stores, or transmits credit card data. If you take card payments directly—even if you never see the raw card number—you're in scope. Compliance isn't optional; it's a legal requirement and increasingly a procurement requirement in enterprise sales, not just a security formality. Enterprises won't sign with you without proof of compliance.
As of now, all 64 new or updated requirements introduced in v4.0 are mandatory—the transition period is over, and assessments in 2026 are assessed against v4.0.1. If you launch a payment-processing SaaS without these controls in place, you're not just exposed to fines and processing suspension; you're also disqualifying yourself from enterprise deals from day one.
The 12 Core Requirements You Must Build
PCI DSS has 12 primary requirements. Most are infrastructure and operational—not fancy, but non-negotiable.
1. Install and Maintain a Firewall Configuration
Your cardholder data must live behind a firewall. This isn't about marketing—it's about network segmentation. Restrict traffic to only what's needed. If you're on AWS or cloud infrastructure, use security groups and NACLs to enforce this. If you're on a VPS, use iptables or a cloud firewall. No exceptions.
2. Do Not Use Vendor-Supplied Defaults for Passwords
Change all default passwords on networking equipment, servers, and applications before production. Document each change. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, 1Password) to rotate credentials. This is table stakes.
3. Protect Stored Cardholder Data
This is the encryption pillar. Data at rest must be encrypted with AES-256 or equivalent, while data in transit should use TLS 1.2 or higher. If you're storing card data (which most SaaS shouldn't), encrypt it with AES-256. If you're transmitting it, always use TLS 1.2 or higher and implement HSTS to prevent downgrade attacks.
4. Protect Cardholder Data Transmitted Across Public Networks
Never send raw card data over HTTP, email, or unencrypted channels. Use TLS 1.2+. Period.
5. Protect Systems Against Malware
Deploy antivirus and anti-malware on all systems that access cardholder data. Keep definitions updated. Most cloud providers handle this for bare-metal instances, but you're responsible for application-level security.
6. Develop and Maintain Secure Systems and Applications
This is the biggest one. You must:
- Maintain a Software Bill of Materials (SBOM) for all custom and third-party software. PCI DSS v4.0 Requirement 6.3.2 mandates that every instance of bespoke and custom software maintain an inventory of software components, which is fully required as of March 31, 2025.
- Track and patch all dependencies and frameworks monthly, or immediately if a critical vulnerability is disclosed.
- Perform static code analysis or use automated tooling (SonarQube, Checkmarx) to catch vulnerabilities before they reach production.
- Do code reviews. Peer review every change before merge.
- Use secure development practices: input validation, parameterized queries to prevent SQL injection, output encoding to prevent XSS.
7. Restrict Access to Cardholder Data by Business Need
Only the people and systems that need cardholder data can access it. This is role-based access control (RBAC). If a team member changes roles, revoke access immediately. Document who has access to what and why.
8. Identify Users and Authenticate Access
MFA is required for administrative access and should be enforced across VPNs, dashboards, cloud consoles, and even CI/CD pipelines. No password-only access to production systems. Use a hardware key, authenticator app, or TOTP—anything stronger than SMS if possible. Require MFA for anyone touching cardholder data or your infrastructure.
9. Restrict Physical Access
If you run on-premises, restrict physical access to servers and storage containing cardholder data. For cloud, this is mostly handled by the cloud provider, but you're responsible for access logs and monitoring.
10. Track and Monitor Network Access
Log all access to cardholder data. Retain logs for at least a year (some rules say 90 days minimum, but keep a year to be safe). Monitor for suspicious activity: failed login attempts, unusual data exports, changes to firewall rules. Use a SIEM (Splunk, ELK, Datadog) or at minimum, centralized logging.
11. Regularly Test Security Systems and Processes
Quarterly external vulnerability scans by a PCI SSC-approved Approved Scanning Vendor (ASV) are mandatory under Requirement 11.3. You'll also need penetration testing at least annually. Budget for this. ASV scans typically cost $500–$2,000 per quarter.
12. Maintain a Policy That Addresses Information Security
Document your security policies: data handling, incident response, password management, vendor management, employee training. Review and update them annually. Provide security training to all staff at least once a year.
The Non-Negotiables: What You Cannot Skip
Sensitive Authentication Data (SAD) includes full magnetic stripe data, card verification codes (CVV/CVC), and PINs—SAD must never be stored after authorization, regardless of encryption status. This is absolute. If you capture a CVV during a transaction, you must discard it immediately after authorization succeeds or fails. You cannot store it encrypted or unencrypted. Your payment processor handles this, but if you're building custom payment logic, this is where people fail.
Encryption is non-negotiable. AES-256 at rest, TLS 1.2+ in transit, HSTS headers on your domain, and no fallback to HTTP. If a penetration tester finds even one endpoint accepting unencrypted traffic, you fail the assessment.
MFA on all administrative access is non-negotiable. No exceptions for "internal use only" or "we're a startup." Password-only authentication to production systems will disqualify you from assessment.
Scope Reduction: The Fastest Path to Compliance
The easiest way to launch compliant is to reduce your scope. You can reduce scope by using tokenization, hosted payment pages, or PCI-compliant gateways to limit your exposure.
| Approach | Scope | Timeline to Launch | Cost |
|---|---|---|---|
| Build custom payment processing | Full PCI DSS (Level 1 or 2) | 3–6 months minimum | $50K–$200K+ (dev + audits) |
| Use Stripe, Adyen, or Square via API | Reduced (you don't store card data) | 2–4 weeks | $0 upfront (2.2%–3% per transaction) |
| Hosted payment page (Stripe Hosted) | Minimal (card data never touches your servers) | 1–2 weeks | $0 upfront (2.2%–3% per transaction) |
| Tokenization + your infrastructure | Reduced (no card data stored, only tokens) | 4–8 weeks | $20K–$80K + $500–$2K quarterly ASV scans |
Most SaaS startups should use a PCI-compliant gateway like Stripe or Adyen. You handle the token, the gateway handles the raw card. Your compliance burden drops dramatically. If you want direct control over payment processing, tokenization is the middle ground: you accept the card, the gateway tokenizes it, you store the token and use it for recurring charges or refunds.
For custom software development involving payments, we recommend starting with a third-party gateway and only building custom payment logic if you have a specific reason (e.g., you're building a payment platform itself, not just processing payments for your SaaS product).
Assessment Levels and What You're Responsible For
| Level | Annual Card Transactions | Assessment Type | Frequency |
|---|---|---|---|
| 1 | Over 6 million | External audit by Qualified Security Assessor (QSA) | Annual |
| 2 | 1–6 million | QSA audit or self-assessment (AOC) | Annual |
| 3 | 20,000–1 million | Self-assessment questionnaire (SAQ) | Annual |
| 4 | Under 20,000 | SAQ | Annual |
As a startup, you'll likely be Level 4 initially. You'll fill out a self-assessment questionnaire and submit attestation of compliance to your acquirer or payment processor. Don't skip this. Your processor will ask for proof before processing goes live.
Timeline and Budget Before Launch
If you're using a third-party payment gateway (Stripe, Adyen, Square), you need:
- 2–3 weeks: Integrate the payment API, test end-to-end, verify TLS and HSTS are enforced.
- 1 week: Prepare self-assessment questionnaire, document your architecture, confirm you're not storing card data.
- Budget: $0 for compliance tooling; $2.2–3% per transaction to the processor.
If you're using tokenization or a hosted payment page, add 1–2 weeks for testing and documentation.
If you're building custom payment logic, add 3–6 months and budget $50K–$200K for development, then $500–$2K quarterly for ASV scans indefinitely.
What Happens If You're Not Compliant
Non-compliance exposes acquiring banks, merchants, and service providers to fines, suspension of card processing privileges, and mandatory forensic audits following a breach. Fines can reach $5,000–$100,000 per month. Processing suspension kills your business overnight. A breach triggers a forensic audit, which costs $10K–$50K and can reveal secondary violations.
Beyond fines: if you're enterprise-facing, compliance is now a procurement requirement. You'll lose deals. Your liability insurance may not cover a breach if you weren't PCI-compliant. Customers will sue.
Checklist Before Launch
- [ ] Choose a payment processing method (gateway, tokenization, or custom). Document the architecture.
- [ ] Verify all cardholder data is encrypted with AES-256 at rest (if you store it).
- [ ] Verify all cardholder data is transmitted over TLS 1.2+ with HSTS enforced.
- [ ] Confirm you never store CVV, magnetic stripe, or PIN data.
- [ ] Enable MFA for all administrative access to production systems and cloud consoles.
- [ ] Deploy firewall rules: restrict network access to only what's needed.
- [ ] Implement centralized logging for all access to sensitive systems.
- [ ] Run a vulnerability scan (internal or with an ASV) and fix all critical/high issues.
- [ ] Document your security policies and software inventory (SBOM).
- [ ] Complete the PCI DSS self-assessment questionnaire (SAQ).
- [ ] Submit attestation of compliance to your payment processor.
- [ ] Schedule quarterly ASV scans if you're handling card data directly.
FAQ
Do I need PCI DSS compliance if I'm just accepting payments through Stripe?
No. If you're using Stripe's API and never storing or transmitting raw card data, your scope is minimal. You handle the token; Stripe handles the card. You still need to ensure you're using HTTPS and have basic security controls, but you don't need a full PCI audit. Your processor will still ask for a self-assessment questionnaire, but it's simpler.
Can I store encrypted card data to speed up checkout?
No. You cannot store Sensitive Authentication Data (CVV, magnetic stripe, PIN) regardless of encryption. You can store a tokenized card (a reference to the card on your processor's servers), but not the raw card number or security codes. Tokenization is the compliant way to enable fast re-billing or saved payment methods.
What if we process under 20,000 transactions per year?
You're a Level 4 merchant. You'll complete a self-assessment questionnaire instead of a full external audit. It's simpler, but still mandatory. The requirements don't change—encryption, MFA, logging, and vulnerability scanning are still required. You just skip the expensive third-party audit.
How often do we need to do penetration testing and vulnerability scans?
Vulnerability scans are quarterly. Penetration testing is at least annual. If you're using a third-party payment gateway, you can shift some of this responsibility to them—confirm what they cover in their compliance documentation. If you're handling card data directly, these are your costs and your responsibility.
