What is PCI DSS?
If you're building a fintech product or any software that touches payment card data, you've likely encountered PCI DSS. This guide explains what PCI DSS actually is, when compliance is required, and how to approach it strategically for your business.
PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements designed to protect cardholder data. Created by the major card brands (Visa, Mastercard, American Express, Discover, and JCB), it applies to any organization that stores, processes, or transmits credit card information.
Key Takeaways
| Point | Summary |
|---|---|
| What it is | A security standard (not a law) mandated by card brands to protect cardholder data |
| Who needs it | Any organization that stores, processes, or transmits credit card data |
| Current version | PCI DSS v4.0.1 (released June 2024), with v3.2.1 sunset in March 2024 |
| Compliance levels | Four levels based on annual transaction volume (Level 1 being highest) |
| Validation | Self-Assessment Questionnaire (SAQ) or on-site audit by a QSA depending on level |
Quick Answer: PCI DSS is a security standard that protects credit card data. If you handle card numbers in any way, you need some level of PCI DSS compliance. The scope and complexity depend on how you process payments and your transaction volume.
Why PCI DSS Exists
Before PCI DSS, each card brand had its own security requirements:
- Visa had CISP (Cardholder Information Security Program)
- Mastercard had SDP (Site Data Protection)
- American Express had DSOP (Data Security Operating Policy)
This created confusion for merchants who accepted multiple card types. In 2004, the card brands unified their requirements into PCI DSS, managed by the PCI Security Standards Council (PCI SSC).
The goal: establish a baseline of security controls that protect cardholder data across the entire payment ecosystem.
Who Needs PCI DSS Compliance?
PCI DSS applies to any entity involved in payment card processing:
| Entity Type | Examples | Typical Requirements |
|---|---|---|
| Merchants | E-commerce sites, retail stores, SaaS with payments | SAQ or on-site audit based on volume |
| Service Providers | Payment gateways, hosting providers, processors | Typically Level 1 (most stringent) |
| Acquirers | Banks that process merchant transactions | Level 1 with additional requirements |
| Issuers | Banks that issue credit cards | Level 1 with additional requirements |
Important distinction: Even if you outsource payment processing to Stripe, Adyen, or another provider, you still have PCI DSS obligations. The scope is just significantly reduced.
The Cardholder Data Environment (CDE)
PCI DSS compliance centers on protecting the Cardholder Data Environment (CDE), which includes:
Cardholder Data (CHD)
- Primary Account Number (PAN) - the 16-digit card number
- Cardholder name (when stored with PAN)
- Expiration date (when stored with PAN)
- Service code (when stored with PAN)
Sensitive Authentication Data (SAD)
- Full magnetic stripe data
- CVV/CVC/CAV2
- PIN/PIN block
Critical rule: Sensitive Authentication Data must NEVER be stored after authorization, even if encrypted. This is a fundamental PCI DSS requirement with no exceptions.
PCI DSS Compliance Levels
The card brands define four compliance levels based on annual transaction volume:
| Level | Annual Transactions | Validation Requirements |
|---|---|---|
| Level 1 | 6+ million (Visa/MC) or 2.5M+ (Amex) | Annual on-site audit by QSA, quarterly network scans |
| Level 2 | 1-6 million | Annual SAQ, quarterly network scans |
| Level 3 | 20,000-1 million e-commerce | Annual SAQ, quarterly network scans |
| Level 4 | Under 20,000 e-commerce or under 1M other | Annual SAQ, quarterly network scans recommended |
Note: If you've ever had a data breach, you may be escalated to Level 1 regardless of transaction volume.
For service providers, the thresholds are different (Visa thresholds shown; other card brands may vary):
- Level 1: 300,000+ transactions annually
- Level 2: Under 300,000 transactions annually
The 12 PCI DSS Requirements
PCI DSS v4.0 organizes requirements into six control objectives:
Build and Maintain a Secure Network and Systems
- Install and maintain network security controls (firewalls, etc.)
- Apply secure configurations to all system components
Protect Account Data
- Protect stored account data (encryption, masking, etc.)
- Protect cardholder data during transmission (TLS, etc.)
Maintain a Vulnerability Management Program
- Protect all systems against malware
- Develop and maintain secure systems and software
Implement Strong Access Control Measures
- Restrict access to system components by business need
- Identify users and authenticate access
- Restrict physical access to cardholder data
Regularly Monitor and Test Networks
- Log and monitor all access to network resources and cardholder data
- Test security of systems and networks regularly
Maintain an Information Security Policy
- Support information security with organizational policies and programs
Each requirement contains detailed sub-requirements. PCI DSS v4.0 has approximately 280 specific requirements when fully expanded, with over 330 testing procedures.
PCI DSS v4.0: What Changed
PCI DSS v4.0 introduced significant changes from v3.2.1:
| Area | Key Changes |
|---|---|
| Customized approach | Organizations can now meet objectives with alternative controls |
| Authentication | Multi-factor authentication (MFA) expanded to all CDE access |
| Encryption | Stricter encryption requirements, including for internal networks |
| Security awareness | Enhanced training requirements for personnel |
| Risk assessment | More frequent targeted risk analyses required |
| Technology | New requirements for phishing protection, web application firewalls |
Timeline:
- March 2024: PCI DSS v3.2.1 officially retired
- March 2025: All "future-dated" v4.0 requirements become mandatory
Common Misconceptions
"We use Stripe, so we don't need PCI compliance"
Reality: Using a payment processor significantly reduces your scope, but you still have obligations. Even with Stripe Elements or Checkout, you must complete an SAQ (typically SAQ A or SAQ A-EP) to attest that you're handling the integration correctly.
"PCI DSS is only for large companies"
Reality: PCI DSS applies to organizations of all sizes. A small e-commerce site with 1,000 transactions per year still needs to complete an SAQ. The validation requirements scale with volume, but compliance is universal.
"We only need to comply once"
Reality: PCI DSS is an ongoing program. You must maintain compliance continuously, with annual validation and quarterly network scans. Controls must be operating effectively at all times, not just during assessments.
"PCI DSS certification exists"
Reality: There's no such thing as "PCI DSS certified." You can be PCI DSS compliant, and a QSA can issue an Attestation of Compliance (AOC) or Report on Compliance (ROC), but there's no certification body or certificate.
PCI DSS vs Other Frameworks
| Aspect | PCI DSS | SOC 2 | ISO 27001 |
|---|---|---|---|
| Focus | Payment card data | Trust services criteria | Information security management |
| Mandated by | Card brands | Customers (voluntary) | Customers (voluntary) |
| Validation | SAQ, QSA audit | CPA firm attestation | Certification body audit |
| Scope | Cardholder data environment | Defined by organization | ISMS scope |
| Non-compliance penalty | Fines, loss of card processing | Lost deals | Lost deals |
Many organizations need multiple frameworks. SOC 2 and ISO 27001 don't replace PCI DSS if you handle card data, but there's significant control overlap that can streamline compliance programs.
Getting Started with PCI DSS
Step 1: Understand Your Payment Flow
Map out exactly how payment data flows through your systems:
- Where does card data enter your environment?
- What systems process or transmit card data?
- Is card data stored anywhere (even temporarily)?
- Which third parties have access to card data?
Step 2: Minimize Scope
The less card data you touch, the simpler compliance becomes. Consider:
- Using tokenization to avoid storing PANs
- Implementing payment iframes (Stripe Elements, Adyen Web Components)
- Outsourcing to PCI-compliant service providers
- Network segmentation to isolate the CDE
Step 3: Determine Your SAQ Type
Based on your payment integration, identify which SAQ applies:
- SAQ A: Card-not-present, fully outsourced (iframes, redirects)
- SAQ A-EP: E-commerce with partial outsourcing
- SAQ B: Imprint machines or dial-out terminals only
- SAQ C: Payment application systems connected to the internet
- SAQ D: Everything else, or service providers
Step 4: Implement Required Controls
Work through the requirements applicable to your SAQ. For most SaaS companies using Stripe/Adyen, SAQ A covers:
- Maintaining a list of service providers
- Ensuring secure integration implementation
- Confirming your site doesn't receive card data
Step 5: Complete Validation
- Fill out the applicable SAQ
- Arrange quarterly network scans (if required)
- Submit AOC to your acquiring bank or payment processor
The Business Case for Compliance
PCI DSS compliance isn't optional if you want to process payments. Non-compliance risks include:
| Risk | Impact |
|---|---|
| Fines | $5,000-$100,000+ per month from card brands |
| Increased fees | Higher transaction fees during non-compliance |
| Lost processing | Acquiring banks can terminate your merchant account |
| Breach liability | Full liability for fraudulent transactions during non-compliance |
| Reputation | Customer trust damage from security incidents |
The good news: with proper scoping and modern payment integrations, achieving compliance is straightforward for most SaaS companies.
How Bastion Helps
Bastion helps technology companies navigate PCI DSS compliance efficiently:
- Scope assessment: We help you understand exactly what's in scope and how to minimize it
- Gap analysis: Identify what controls you need to implement
- SAQ preparation: Guidance on completing the right SAQ correctly
- Integration review: Ensure your payment integration is configured securely
- Combined programs: Align PCI DSS with SOC 2 and ISO 27001 for efficiency
Ready to discuss your PCI DSS needs? Talk to our team
Sources
- PCI Security Standards Council - Official PCI DSS documentation and guidance
- PCI DSS v4.0.1 - Current standard documentation
- PCI DSS Quick Reference Guide - Summarized requirements