PCI DSS Compliance
- Most small merchants qualify for SAQ A (~22 controls) by using hosted payment pages or iframes. If you use Stripe Checkout, Square, or Shopify Payments, you're probably already close.
- If you never see raw card numbers, your PCI burden is minimal. Tokenization is the single best thing you can do.
- Non-compliance fines: $5,000-$100,000/month, plus you're liable for all breach costs.
- Current standard: PCI DSS 4.0.1. All future-dated requirements are now mandatory.
What Should I Do?
Most merchants searching "PCI compliance" need one of these three things:
"I just need to know if I'm compliant"
- Check your merchant level (based on annual transaction volume)
- Use the SAQ flowchart to find your questionnaire type
- Most Level 4 merchants using hosted checkout = SAQ A = 22 controls. You're probably fine.
"I want to reduce my PCI burden"
- Tokenization removes stored card data from your systems
- Hosted payment pages keep raw card numbers off your servers entirely
- P2PE terminals reduce in-store scope to ~33 controls
"I got a letter from my processor about PCI"
- Don't panic. Your processor or acquirer may require an annual SAQ submission and AOC
- Determine your SAQ type, complete it, and submit
- If you need quarterly scans, engage an Approved Scanning Vendor
"I need PCI tools or a scanning vendor"
- Check what your processor already provides - you may not need anything extra
- Need quarterly scans? See Approved Scanning Vendors
- Need help completing your SAQ? See PCI compliance platforms
- Need payment page monitoring (Req 6.4.3/11.6.1)? See payment page security tools
If you use a hosted payment page (Stripe Checkout, Square, PayPal) and never store card numbers yourself, your main job is: (1) complete SAQ A annually, (2) don't do anything dumb with whatever card data you do see (last 4 digits, etc.), and (3) keep your website secure. That covers most small merchants.
- Using Stripe/Square/Shopify? See your processor's PCI tools below - you may already be compliant
- Got a PCI letter from your processor? See Processor Management for how to respond
- Worried about data breaches? See Breach Response Playbook for the step-by-step plan
- Need to understand network security rules? See Network Rules for Visa/Mastercard requirements
Full page contents
- What Should I Do?
- What Is PCI DSS?
- Which SAQ Do You Need?
- Who Must Comply
- The 12 PCI DSS Requirements
- Merchant Compliance Levels
- Service Provider Compliance Levels
- Self-Assessment Questionnaires (SAQs)
- Scope Reduction Strategies
- Network-Specific Requirements
- Cardholder Data Defined
- Compliance Validation and Assessment
- PCI Compliance Tools and Vendors
- Consequences of Non-Compliance
- Common Compliance Pitfalls
- PCI DSS 4.0 Key Changes
- Getting Started with Compliance
- Next Steps
- See Also
Key Fact: Most Level 4 merchants using hosted checkout (Stripe Checkout, Square, Shopify Payments) qualify for SAQ A - just 22 controls, not the full 300+ of SAQ D. If you never see raw card numbers, your PCI burden is minimal.
What Is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for anyone who processes, stores, or transmits credit card information. It was created by the PCI Security Standards Council (PCI SSC), founded by Visa, Mastercard, American Express, Discover, and JCB. The council develops and maintains the standard; the card brands enforce compliance.
PCI DSS 3.2.1 was retired on March 31, 2024. The current standard is PCI DSS 4.0.1. Future-dated requirements in 4.0 became mandatory on March 31, 2025.
The rest of this page covers the full standard in detail. If you need background first:
- How payments work (data flows and infrastructure)
- Processor management (your processor relationship)
- Payment methods (what you accept and how)
Which SAQ Do You Need?
Goal: Get to SAQ A or SAQ P2PE. These have the fewest requirements and lowest audit burden.
SAQ Eligibility Checklists
Use these checklists to confirm which SAQ applies to you. Every item must be true for that SAQ.
SAQ A Checklist (easiest - ~22 controls)
You qualify for SAQ A if ALL of these are true:
- Card-not-present only (e-commerce, mail order, telephone order)
- All payment processing is fully outsourced to a PCI DSS validated third-party processor
- Your payment page is either:
- A full redirect to the processor (customer leaves your site to pay), OR
- A processor-hosted iframe embedded in your page
- Your systems never store, process, or transmit cardholder data in any form
- You do not have any electronic cardholder data on your systems or premises
- You have confirmed your payment integration method with your processor and they agree you qualify for SAQ A
- Your processor is PCI DSS compliant and you have their current AOC on file
Common platforms that typically qualify you for SAQ A:
| Platform | Integration Type | SAQ A? | Notes |
|---|---|---|---|
| Stripe Checkout | Full redirect | Yes | Customer goes to Stripe-hosted page |
| Stripe Elements (iframe) | Processor iframe | Yes | Card fields are Stripe iframes; you never see PAN |
| Square Online | Fully hosted | Yes | Square handles everything |
| Shopify Payments | Fully hosted | Yes | Shopify is PCI Level 1; merchants inherit |
| PayPal Standard | Full redirect | Yes | Customer goes to PayPal to pay |
| Adyen Drop-in | Processor iframe | Yes | Adyen-hosted payment fields |
| Braintree Drop-in UI | Processor iframe | Yes | PayPal/Braintree hosted fields |
| WooCommerce + Stripe | Depends on plugin | Check | Must use Stripe Elements, not direct API |
| Custom Stripe API (server-side) | Direct API | No | If your server touches raw card data, you're SAQ A-EP or D |
For iframe integrations, SAQ A now requires you to confirm either:
- You comply with Req 6.4.3 (script inventory on payment pages) and 11.6.1 (payment page change detection), OR
- Your processor confirms they handle these for you
Full redirect integrations (where customers leave your site entirely) are the simplest path. If you're choosing between iframe and redirect, redirect is easier for PCI compliance.
SAQ A-EP Checklist (~140 controls)
You qualify for SAQ A-EP if ALL of these are true:
- Card-not-present e-commerce only
- All payment processing is outsourced to a PCI DSS validated processor
- Your website delivers the payment page to the customer's browser, but you don't receive cardholder data
- Your web server could impact the security of the payment transaction (e.g., your JavaScript runs on the payment page)
- You do not store, process, or transmit cardholder data electronically on your systems
- Quarterly ASV scans are passing for all internet-facing systems
When you're SAQ A-EP instead of SAQ A:
- Your JavaScript library makes a direct-post API call to the processor (the card number goes from the customer's browser to the processor, but your scripts are involved)
- You serve the payment page from your servers (not a redirect)
- Your JavaScript or other code on the checkout page could theoretically intercept card data even though it doesn't
Common example: A custom React/Next.js checkout that uses Stripe.js with confirmCardPayment() where your front-end code orchestrates the payment flow, even though card data goes directly to Stripe.
SAQ B / B-IP Checklist (card-present, ~41-82 controls)
SAQ B (dial-out terminals, ~41 controls):
- Card-present only using imprint machines or standalone dial-out terminals
- Terminals are not connected to the internet
- No electronic cardholder data storage
SAQ B-IP (IP-connected terminals, ~82 controls):
- Card-present only using standalone PTS-approved terminals
- Terminals connect via IP but are isolated from other systems on your network
- No electronic cardholder data storage on any system
- Terminal vendor has confirmed PTS device validation
SAQ C-VT Checklist (virtual terminal, ~79 controls)
- You process cards only via a virtual terminal on a browser (web-based, processor-provided)
- One transaction at a time, manually entered
- Virtual terminal is provided by your PCI DSS validated processor
- No electronic cardholder data storage
- Computer used for virtual terminal is isolated and not used for other internet browsing
Common use case: Phone orders where a call center agent types card details into a processor's web portal.
SAQ P2PE Checklist (P2PE terminals, ~33 controls)
- Card-present only using a PCI SSC-validated P2PE solution (check the PCI SSC P2PE list)
- All payment terminals are managed per the P2PE Instruction Manual (PIM) from the solution provider
- No electronic cardholder data storage in unencrypted form
- Your P2PE solution provider is listed on the PCI SSC website
If your terminal vendor says "encrypted" but isn't on the PCI SSC validated P2PE list, it's E2EE, not P2PE. E2EE doesn't automatically reduce your SAQ scope. See E2EE vs P2PE for the full comparison.
SAQ D (everything else, 300+ controls)
You're SAQ D if any of these are true:
- You store cardholder data electronically (even encrypted)
- You use a custom payment integration where your servers handle raw card data
- You don't fit any other SAQ category
- Your acquirer designates you as SAQ D
SAQ D is the "catch-all." If you're here, your first priority should be figuring out how to move to SAQ A through tokenization and outsourcing.
Quick Reference: SAQ Comparison
| SAQ | Controls | ASV Scan? | Pen Test? | Best For |
|---|---|---|---|---|
| A | ~22 | No | No | E-commerce with hosted/redirect checkout |
| A-EP | ~140 | Yes | No | E-commerce with direct-post integration |
| B | ~41 | No | No | Dial-out terminals (no internet) |
| B-IP | ~82 | Yes | No | IP-connected standalone terminals |
| C-VT | ~79 | Yes | No | Web-based virtual terminal only |
| C | ~160 | Yes | No | Payment apps connected to internet |
| P2PE | ~33 | No | No | PCI-validated P2PE terminals |
| D | 300+ | Yes | Yes (L1/L2) | Everything else; try to leave this category |
Who Must Comply
PCI DSS applies to any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD):
- Merchants accepting payment cards
- Service providers processing, storing, or transmitting CHD on behalf of merchants
- Issuers and Acquirers
- Any entity that could impact the security of CHD (even if they don't directly handle it)
Even if you outsource all payment processing, some PCI DSS requirements still apply. You must verify your service provider's compliance and manage that relationship appropriately.
The 12 PCI DSS Requirements
PCI DSS is organized under six goals, each containing specific requirements:
Build and Maintain a Secure Network and Systems
Requirement 1: Install and Maintain Network Security Controls
- Implement firewalls and network security controls
- Maintain configuration standards for all system components
- Restrict traffic to and from the cardholder data environment (CDE)
- Review firewall rules at least every six months
Requirement 2: Apply Secure Configurations to All System Components
- Change all vendor-supplied default passwords and settings
- Remove or disable unnecessary accounts and services
- Implement only one primary function per server
- Document security configuration standards
Protect Account Data
Requirement 3: Protect Stored Account Data
- Minimize data storage. Only store what's necessary.
- Never store sensitive authentication data (SAD) after authorization
- Mask PAN when displayed (show first 6 and/or last 4 only)
- Render PAN unreadable wherever stored (encryption, hashing, tokenization, truncation)
Requirement 4: Protect Cardholder Data in Transit
- Use strong cryptography when transmitting CHD over open networks
- TLS 1.2 or higher required
- Never send PAN via email, SMS, or chat
Maintain a Vulnerability Management Program
Requirement 5: Protect All Systems and Networks from Malicious Software
- Deploy anti-malware on all systems commonly affected
- Keep anti-malware mechanisms current
- Ensure anti-malware is actively running and cannot be disabled
Requirement 6: Develop and Maintain Secure Systems and Software
- Identify and address vulnerabilities through a risk-based process
- Apply risk-based patching (e.g., critical patches within one month)
- Follow secure software development lifecycle (SDLC)
- PCI DSS 4.0 adds Req 6.4.3: Manage all payment page scripts (JavaScript, etc.)
Implement Strong Access Control Measures
Requirement 7: Restrict Access to System Components and CHD by Business Need-to-Know
- Implement minimum privileges
- Default deny: access only granted when explicitly needed
- Document access control policies
Requirement 8: Identify Users and Authenticate Access
- Assign unique IDs to all users
- MFA required for all access into the CDE (expanded in 4.0)
- 12-character passwords (or 8 characters if the system cannot support 12)
- Lock accounts after 10 failed attempts
Requirement 9: Restrict Physical Access to Cardholder Data
- Implement entry controls to sensitive areas
- Protect media containing CHD
- Control physical access to systems in the CDE
Regularly Monitor and Test Networks
Requirement 10: Log and Monitor All Access to System Components and CHD
- Implement audit trails for all access
- Synchronize clocks across systems
- Review logs daily
- Retain audit logs for at least 12 months, with 3 months immediately available
Requirement 11: Test Security of Systems and Networks Regularly
- Conduct quarterly wireless testing
- Perform quarterly vulnerability scans by an Approved Scanning Vendor (ASV)
- Conduct annual penetration testing
- Deploy intrusion detection/prevention systems (IDS/IPS)
- PCI DSS 4.0 adds Req 11.6.1: Detect unauthorized payment page changes
Maintain an Information Security Policy
Requirement 12: Support Information Security with Organizational Policies and Programs
- Conduct annual risk assessments
- Maintain acceptable use policies
- Implement security awareness training
- Screen personnel before hiring
- Maintain an incident response plan
Merchant Compliance Levels
Card networks assign merchants to compliance levels based on annual transaction volume. Each level has different validation requirements.
Level 1
Criteria:
- More than 6 million transactions annually (Visa/Mastercard)
- OR any merchant that has experienced a data breach
- OR designated by a card network
Validation Requirements:
- Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA)
- Quarterly network scans by an ASV
- Annual penetration test
- Attestation of Compliance (AOC)
Level 2
Criteria:
- 1–6 million transactions annually
Validation Requirements:
- Annual Self-Assessment Questionnaire (SAQ)
- May need QSA assessment for SAQ A, A-EP, or D (Mastercard requirement)
- Quarterly ASV scans
- AOC
Level 3
Criteria:
- 20,000–1 million e-commerce transactions annually
Validation Requirements:
- Annual SAQ
- Quarterly ASV scans (if applicable)
- AOC
Level 4
Criteria:
- Fewer than 20,000 e-commerce transactions annually
- OR up to 1 million total transactions annually
Validation Requirements:
- SAQ recommended (not always enforced)
- Quarterly ASV scans (if applicable)
- Direct Mastercard validation may not be required
Mastercard's Site Data Protection (SDP) program and Visa's Account Information Security (AIS) program have specific requirements. Your acquiring bank may impose additional requirements regardless of your level. Always verify with your acquirer.
Service Provider Compliance Levels
Level 1
Criteria:
- More than 300,000 transactions annually
- OR designated by a card network
Validation Requirements:
- Annual ROC by QSA
- Quarterly ASV scans
- Annual penetration test
- AOC
Level 2
Criteria:
- Fewer than 300,000 transactions annually
Validation Requirements:
- Annual SAQ D (Service Provider version)
- Quarterly ASV scans
- AOC
Designated Entities Supplemental Validation (DESV)
Large or high-risk service providers may be required to complete DESV, additional controls beyond standard PCI DSS requirements. This includes:
- More frequent penetration testing
- Enhanced logging and monitoring
- Additional governance requirements
Self-Assessment Questionnaires (SAQs)
SAQs are validation tools for merchants and service providers to assess their own compliance. The appropriate SAQ depends on how you handle cardholder data.
| SAQ | Description | Approx. Controls | Typical Use Case |
|---|---|---|---|
| A | Card-not-present, all CHD outsourced | ~22 | Hosted payment pages, MOTO outsourced |
| A-EP | E-commerce affecting payment page | ~140 | Iframes, JS affecting checkout |
| B | Imprint-only or dial-out terminals | ~41 | Small retail dial-out |
| B-IP | Standalone IP-connected PTS | ~82 | IP terminals, no CHD storage |
| C-VT | Virtual terminal only | ~79 | Call centers, browser-based |
| C | Payment apps connected to internet | ~160 | Small merchant POS |
| D | All other / complex environments | 300+ | CHD storage, doesn't fit above |
| P2PE | Validated P2PE terminals | ~33 | PCI-validated P2PE solution |
Note: Exact question counts change by version; these are ballpark figures.
Choosing Your SAQ
Use this decision tree:
- Do you store cardholder data? → SAQ D
- Is all processing outsourced? → SAQ A or A-EP
- Do you use validated P2PE? → SAQ P2PE
- Do you have IP-connected terminals? → SAQ B-IP or C
Goal: Use redirect/hosted payment pages + tokenization to qualify for SAQ A instead of SAQ D. This dramatically reduces your compliance burden.
Under PCI DSS 4.0, SAQ A eligibility for iframe integrations requires either:
- Compliance with Req 6.4.3 and 11.6.1 for payment page script management, OR
- Confirmation from your processor that they manage these requirements
Redirect integrations (where the customer leaves your site entirely) provide an easier compliance path.
Scope Reduction Strategies
The most effective approach to PCI DSS compliance is reducing your scope: minimizing the systems and processes subject to requirements.
1. Tokenization
What it does: Replaces cardholder data with a non-sensitive token that has no exploitable value.
Benefits:
- Tokens are not cardholder data (out of scope)
- Removes stored PAN from your environment
- Enables card-on-file without storing actual cards
- Can move from SAQ D to SAQ A
Implementation:
- Use your processor's tokenization service
- Ensure tokens are non-reversible
- The token vault is your provider's responsibility
Deep Dive: How Tokenization Works
Tokenization is your most powerful scope reduction tool. Understanding it helps you implement correctly.
Token Types
| Token Type | Description | Use Case |
|---|---|---|
| Payment token | Replaces PAN for processing | Card-on-file, subscriptions |
| Network token | Issued by card networks | Enhanced auth rates, lifecycle updates |
| Merchant token | Processor-specific | Single processor environments |
| Multi-use token | Same token across transactions | Repeat customers |
| Single-use token | One transaction only | One-time payments, checkout |
Network Tokenization Benefits
Network tokens (Visa Token Service, Mastercard Digital Enablement Service) provide additional benefits beyond PCI scope reduction:
| Benefit | Why It Matters |
|---|---|
| Card lifecycle updates | Automatic reissue when card expires |
| Higher auth rates | Issuers trust tokenized transactions |
| Domain-specific | Token only works for your merchant |
| Reduced false declines | Better fraud signal for issuers |
Tokenization Implementation Checklist
| Step | What to Do |
|---|---|
| 1. Select token provider | Processor's native tokenization or third-party |
| 2. Determine token type | Network tokens preferred if supported |
| 3. Implement token creation | At card capture point (checkout, add card) |
| 4. Store tokens, not PANs | Update database schema |
| 5. Display handling | Show last 4 for customer reference |
| 6. Migration plan | Convert existing stored cards to tokens |
Token Security Considerations
| Do | Don't |
|---|---|
| Store tokens in your database | Store PANs alongside tokens "just in case" |
| Use processor's token vault | Build your own reversible tokenization |
| Implement token rotation for high-value accounts | Use tokens that are mathematically reversible to PANs |
| Log token usage | Log actual card numbers |
Token Format Examples
Original PAN: 4111 1111 1111 1111
Processor token: tok_1234567890abcdef
Network token: 4000 0012 3456 7899 (looks like a card but isn't)
Display format: •••• •••• •••• 1111
Note: Network tokens intentionally look like card numbers to work with existing payment infrastructure. They're domain-restricted and useless outside your integration.
2. Point-to-Point Encryption (P2PE)
What it does: Encrypts cardholder data from the point of interaction (terminal) to the decryption environment.
Benefits:
- Qualifies for SAQ P2PE (~33 controls)
- Encrypted data is out of scope
- Dramatically reduces CDE
P2PE vs E2EE:
- P2PE: PCI SSC-validated solution with immediate scope reduction
- E2EE: Encryption at rest and in transit, but requires acquirer approval for scope reduction
3. Network Segmentation
What it does: Isolates the cardholder data environment from other network segments.
Benefits:
- Fewer in-scope systems
- Limits attack surface
- Faster assessments
- Reduced compliance costs
Implementation:
- Use firewalls, VLANs, or physical separation
- Implement role-based access control
- Conduct segmentation testing (Req 11.4.5)
- Document CDE boundaries clearly
4. Outsourcing Payment Functions
Approaches:
- Hosted payment pages (redirect to processor)
- Secure iframes (processor-controlled)
- Gateway API with tokenization (never touch raw card data)
- Managed payment services
Important: Even when outsourcing:
- Verify provider's AOC
- Include provider in your service provider management program
- Understand your residual responsibilities
Network-Specific Requirements
Visa Requirements
- Account Information Security (AIS): Primary compliance program
- Compromise Investigation: Must engage a PCI Forensic Investigator (PFI) after suspected breach
- Fraud Monitoring: Report fraud through required channels
- Terminated Merchant File (TMF): Also known as MATCH, the list of terminated merchants
Mastercard Requirements
- Site Data Protection (SDP): Primary compliance program
- Level 1/2 service providers may require DESV
- Validation documents submitted to acquiring bank
- Information Security Program: Required under Mastercard Rules Section 2.2.7
- Third Party Processor (TPP) registration requirements
Cardholder Data Defined
Understanding what constitutes cardholder data is essential for scoping.
Cardholder Data (CHD)
| Element | Description | Notes |
|---|---|---|
| PAN | Primary Account Number (15-19 digits) | The defining element: if PAN is present, it's CHD |
| Cardholder Name | Name on card | Only CHD when stored with PAN |
| Expiration Date | Card validity period | Only CHD when stored with PAN |
| Service Code | 3-digit code on magnetic stripe | Only CHD when stored with PAN |
Note on truncation: Truncated PAN (first 6 + last 4 digits) is still considered CHD, but permanently deleting the middle digits means you're not storing the full PAN.
Sensitive Authentication Data (SAD)
NEVER store SAD after authorization, even encrypted:
| Element | Description |
|---|---|
| Full track data | Track 1 and Track 2 from magnetic stripe |
| CVV/CVC/CVV2/CID | Card verification codes |
| PIN/PIN block | Personal identification numbers |
Data Rendering Methods
When you must store PAN, render it unreadable using:
| Method | Description |
|---|---|
| Truncation | Permanently remove middle digits (keep first 6 and/or last 4) |
| Tokenization | Replace with non-reversible token |
| Strong hashing | One-way cryptographic hash with salt |
| Encryption | Strong encryption with proper key management (AES-256) |
Compliance Validation and Assessment
Quarterly ASV Scans
- External vulnerability scans performed by an Approved Scanning Vendor
- Required for any internet-facing systems
- Must pass (no high or critical vulnerabilities)
- Submit passing scan reports with your SAQ or ROC
Annual Penetration Testing
- Required for Level 1 and Level 2 merchants
- Test both internal and external networks
- Validate network segmentation effectiveness
- PCI DSS 4.0 requires a defined methodology
Attestation of Compliance (AOC)
- Formal attestation of PCI DSS compliance status
- Signed by QSA (for ROC) or merchant officer (for SAQ)
- Required to be submitted to acquirer
- Often requested by business partners
PCI Compliance Tools and Vendors
You don't need to figure out PCI compliance alone. Here are the categories of tools and vendors that help, organized by what you actually need.
Approved Scanning Vendors (ASVs)
ASVs perform the quarterly external vulnerability scans required for SAQ A-EP, B-IP, C-VT, C, and D. They scan your internet-facing systems and certify whether you pass.
Check the SAQ comparison table. If your SAQ type shows "ASV Scan: Yes," you need one. SAQ A and SAQ P2PE do not require ASV scans.
| ASV | Best For | Approx. Cost | Notes |
|---|---|---|---|
| SecurityMetrics | SMBs, easy setup | $100-300/year | Popular with small merchants; includes SAQ wizard |
| Qualys | Mid-market to enterprise | $500-2,000+/year | Comprehensive vulnerability management platform |
| Trustwave (Viking Cloud) | Mid-market | $300-1,000/year | Also offers managed security services |
| Rapid7 InsightVM | Enterprise, DevOps teams | $1,000+/year | Integrates with CI/CD pipelines |
| Tenable Nessus | Enterprise, large networks | $1,000+/year | Deep vulnerability scanning beyond PCI |
| Intrust IT / ControlScan | SMBs | $200-500/year | White-labeled by many processors |
How it works:
- Sign up with an ASV
- Provide your external IP addresses and domains
- ASV runs automated scans quarterly
- Fix any high/critical vulnerabilities found
- Get a passing scan report to submit with your SAQ
Many processors (Stripe, Square, Adyen) include basic PCI compliance tools in their merchant portal. Check there first before buying separately. Some acquirers also bundle ASV scanning into their merchant services.
Qualified Security Assessors (QSAs)
QSAs are individuals certified by the PCI SSC to perform on-site PCI DSS assessments. You need a QSA if:
- You're a Level 1 merchant (6M+ transactions/year) - required for your annual ROC
- You're a Level 1 service provider (300K+ transactions/year)
- Your acquirer requires a QSA assessment regardless of level
- You want an expert review of your compliance posture (optional for smaller merchants)
| QSA Firm | Focus | Notes |
|---|---|---|
| Coalfire | Enterprise, cloud-heavy environments | Strong in AWS/Azure PCI assessments |
| Trustwave | Full-service, mid-market to enterprise | ASV + QSA + managed security under one roof |
| SecurityMetrics | SMB to mid-market | Also offers ASV scans and compliance platforms |
| A-LIGN | Mid-market, SOC 2 + PCI combos | Good if you need multiple compliance frameworks |
| Schellman | Enterprise, complex environments | Known for thoroughness |
| Foregenix | E-commerce and payments focused | PCI forensic investigator (PFI) as well |
Typical QSA engagement costs:
- Level 1 ROC assessment: $30,000-$100,000+ depending on scope
- Level 2 SAQ validation: $5,000-$20,000
- Gap analysis (any level): $5,000-$15,000
The PCI SSC QSA directory lists all qualified firms.
PCI Compliance Platforms
These platforms guide you through completing your SAQ, track your compliance status, and often bundle ASV scanning.
| Platform | Best For | What It Does | Approx. Cost |
|---|---|---|---|
| SecurityMetrics | SMBs | SAQ wizard + ASV scans + training | $100-500/year |
| Viking Cloud (Trustwave) | SMBs to mid-market | Guided SAQ + ASV + policy templates | $200-800/year |
| Sprinto | Startups, multi-framework | PCI + SOC 2 + ISO 27001 automation | $5,000+/year |
| Vanta | Startups, multi-framework | Continuous compliance monitoring, PCI + SOC 2 | $5,000+/year |
| Drata | Mid-market, multi-framework | Automated evidence collection, PCI + SOC 2 | $5,000+/year |
| PCI Pal | Call centers | Descopes phone payments from PCI (DTMF masking) | Custom pricing |
For most SMBs: SecurityMetrics or Viking Cloud is sufficient. They walk you through the SAQ step by step, run your quarterly scans if needed, and give you the documentation your acquirer wants.
For startups needing multiple certifications: Sprinto, Vanta, or Drata let you manage PCI alongside SOC 2 and ISO 27001 in one platform. Only worth it if you need more than PCI.
Payment Page Security Tools (Req 6.4.3 / 11.6.1)
PCI DSS 4.0 requires you to manage and monitor all scripts on your payment pages (Req 6.4.3) and detect unauthorized changes to payment page content (Req 11.6.1). These requirements target Magecart-style attacks where attackers inject malicious JavaScript to skim card data.
Who needs this: Anyone with an e-commerce payment page, especially SAQ A-EP. SAQ A merchants using iframes must confirm either they or their processor handles these requirements.
| Tool | What It Does | Best For | Notes |
|---|---|---|---|
| Jscramble | Client-side JavaScript protection, script inventory, tamper detection | Mid-market to enterprise | Purpose-built for PCI 4.0 6.4.3/11.6.1 |
| Source Defense | Real-time payment page monitoring, script sandboxing | E-commerce merchants | Monitors third-party scripts on checkout pages |
| Cloudflare Page Shield | Script monitoring, Magecart detection | Cloudflare customers | Included in Business/Enterprise plans; easy if you're already on Cloudflare |
| Akamai Page Integrity Manager | Client-side detection and mitigation | Enterprise, Akamai customers | Part of Akamai's security suite |
| Imperva Client-Side Protection | Script visibility, behavior analysis | Enterprise | Part of Imperva's WAF platform |
| Human Security | Bot and client-side protection | Enterprise | Broader than just PCI; covers bot defense too |
If you use a full redirect (Stripe Checkout, PayPal Standard), Req 6.4.3/11.6.1 is largely your processor's problem - the payment page is on their domain.
If you use an iframe (Stripe Elements, Adyen Drop-in), ask your processor for a written confirmation that they handle 6.4.3/11.6.1 for their iframe. Most major processors provide this. If they don't, you'll need one of the tools above or a Content Security Policy (CSP) that restricts scripts on your checkout page.
What Your Processor Already Gives You
Before buying any PCI tools, check what your processor includes for free:
| Processor | Built-in PCI Help | Details |
|---|---|---|
| Stripe | SAQ A auto-qualification, hosted checkout, PCI compliance dashboard | Stripe handles PCI for you if you use Checkout or Elements. They provide a pre-filled SAQ A in your dashboard. |
| Square | Fully PCI compliant, no SAQ needed for most merchants | Square handles all PCI compliance for merchants using their hardware and software. |
| Shopify Payments | PCI Level 1 certified, merchants covered | Shopify stores are PCI compliant by default. No separate SAQ needed. |
| Adyen | PCI Level 1, Drop-in components | Provides compliance documentation and handles SAQ A eligibility through Drop-in/Components. |
| PayPal | PCI Level 1, hosted checkout | Standard Checkout redirects mean SAQ A eligibility. PayPal provides compliance documentation. |
| Braintree | PCI compliance included with hosted fields | Part of PayPal. Hosted Fields keep you at SAQ A. Provides compliance resources. |
| Worldpay (FIS) | PCI portal, often bundles ASV scanning | Check your merchant portal - many Worldpay merchants get basic PCI tools included. |
If you use Stripe, Square, or Shopify and don't handle card data yourself, you likely don't need to buy a separate ASV, compliance platform, or QSA. Check your processor's PCI documentation first. Many merchants pay for PCI tools they don't need.
Key Fact: PCI DSS non-compliance fines range from $5,000 to $100,000 per month, and the merchant bears full liability for all breach costs. A data breach for an SMB averages $120,000-$1.24M in total costs (forensics, notification, fines, legal). The cheapest path is SAQ A via hosted checkout - not buying tools.
Consequences of Non-Compliance
| Consequence | Details |
|---|---|
| Monthly fines | $5,000–$100,000/month depending on severity and duration |
| Increased transaction fees | Higher interchange and assessment fees |
| Liability shift | Merchant bears full liability for breach costs |
| MATCH listing | Added to Mastercard terminated merchant file |
| Loss of card acceptance | Processing privileges revoked |
| Brand damage | Breach notification requirements, reputational harm |
Common Compliance Pitfalls
Underestimating Scope
- Payment applications often store data in unexpected places (logs, temp files, databases)
- Systems connected to the CDE are in scope
- Third-party integrations may pull CHD into scope
- Cloud environments have shared responsibility models
Scope Creep Over Time
- New sales channels added without security review
- New devices connected to payment network
- Test environments using production data
- Acquired companies with different security postures
Documentation Gaps
- Outdated network diagrams
- Missing or incomplete policies
- Incomplete service provider inventory
- No business justification for enabled protocols/ports
Key Management Weaknesses
- Using weak or default encryption keys
- No key rotation schedule
- Storing keys with encrypted data
- No split knowledge or dual control for key operations
Misunderstanding Compensating Controls
- Compensating controls are only used when the original requirement cannot be met
- Insufficient documentation of why original requirement isn't achievable
- Not demonstrating equivalent protection
- Failing to re-evaluate annually
PCI DSS 4.0 Key Changes
Customized Approach
- Design your own controls to meet requirement objectives
- Document and test effectiveness
- Requires QSA validation
- More flexibility but more documentation burden
Targeted Risk Analysis
- For certain requirements, determine frequency via targeted risk analysis (TRA) instead of fixed schedules
- Can apply to some log reviews, vulnerability scanning, and other periodic activities where 4.0 explicitly allows
- Must document methodology and defend conclusions
Enhanced Authentication
- MFA required for all CDE access (not just remote access)
- 12-character passwords (8 characters only if the system cannot support 12)
- Service account password/key protection requirements
Payment Page Security (Future-Dated to March 2025)
Requirement 6.4.3: Authorize, document, and monitor all scripts (JavaScript, etc.) on payment pages
Requirement 11.6.1: Implement mechanisms to detect unauthorized changes to payment page content
These requirements address Magecart-style attacks where attackers inject malicious scripts into payment pages to steal card data.
Getting Started with Compliance
- Understand your data flows – Map where CHD enters, moves through, and exits your environment
- Determine your merchant level – Based on annual transaction volume
- Identify scope reduction opportunities – Tokenization, P2PE, outsourcing
- Select appropriate SAQ – After implementing scope reduction
- Implement required controls – Gap analysis against applicable requirements
- Engage qualified assessors – QSA for Level 1, or self-assessment
- Establish ongoing processes – Quarterly scans, annual assessments, continuous monitoring
Next Steps
Just learning about PCI?
- Map your cardholder data environment → Where does card data flow?
- Determine your merchant level → Based on annual transaction volume
- Identify scope reduction opportunities → Tokenization eliminates most PCI burden
Ready to reduce scope?
- Evaluate tokenization providers → Let them handle card data, not you
- Consider hosted payment pages → Remove your systems from scope entirely
- Ask your processor about P2PE terminals → Reduce in-store PCI requirements
Preparing for assessment?
- Gap analysis against your SAQ type → Know what's required
- Engage a QSA early (Level 1) → Don't wait until assessment time
- Establish quarterly ASV scanning → See the vendor comparison above
- Check what your processor includes → Don't buy tools you already have
See Also
- Payment Tokenization - Reducing PCI scope with tokens
- Fraud Detection Fundamentals - Detection approaches
- AVS and CVV - Verification signals
- 3D Secure - Authentication for payments
- Chargeback Prevention - Reducing disputes
- Authorization Decisioning - How issuers decide
- Payments Overview - How money moves
- Processor Management - Working with processors
- Network Programs - Compliance thresholds
- AML Basics - Anti-money laundering
- Consumer Protection - Reg E and Reg Z
- Buying Payments - Processor selection
- Device Fingerprinting - Session security