PCI DSS Compliance

TL;DR

• Most small merchants qualify for SAQ A (~22 controls). A hosted payment page or an iframe gets you there. On Stripe Checkout, Square or Shopify Payments, you're probably already close.
• Never see raw card numbers? Your PCI burden is minimal. Tokenization is the single best thing you can do.
• The "$5,000-$100,000/month fine" isn't something you can verify. Nobody publishes a schedule. The networks assess your acquirer. Your acquirer passes it on per your merchant agreement. The real exposure is breach liability, not a monthly invoice.
• Current standard: PCI DSS 4.0.1. All future-dated requirements are now mandatory.

What Should I Do?

Most merchants searching "PCI compliance" want one of four things:

"I just need to know if I'm compliant"

1. Check your merchant level (based on annual transaction volume)
2. Use the SAQ flowchart to find your questionnaire type
3. Most Level 4 merchants using hosted checkout = SAQ A = 22 controls. You're probably fine.

"I want to reduce my PCI burden"

1. Tokenization removes stored card data from your systems
2. Hosted payment pages keep raw card numbers off your servers entirely
3. P2PE terminals reduce in-store scope to ~33 controls

"I got a letter from my processor about PCI"

1. Don't panic. Your processor or acquirer may require an annual SAQ submission and AOC
2. Determine your SAQ type, complete it, and submit
3. If you need quarterly scans, engage an Approved Scanning Vendor

"I need PCI tools or a scanning vendor"

1. Check what your processor already provides - you may not need anything extra
2. Need quarterly scans? See Approved Scanning Vendors
3. Need help completing your SAQ? See PCI compliance platforms
4. Need payment page monitoring (Req 6.4.3/11.6.1)? See payment page security tools

The 80/20 on PCI

Use a hosted payment page so you never store card numbers yourself, and Stripe Checkout, Square and PayPal all qualify. Then your job is three things. Complete SAQ A once a year, don't do anything dumb with the card data you do see (like the last 4 digits), and keep your website secure. That covers most small merchants.

Related Pages You'll Need

• 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 the Breach Response Playbook for the step-by-step plan.
• Need the network security rules? See Network Rules for Visa and Mastercard requirements.

PCI DSS is the card industry's security standard, and most small merchants qualify for its shortest version.

Key Fact: Most Level 4 merchants on hosted checkout qualify for SAQ A. That's 22 controls, not the 300+ of SAQ D. Stripe Checkout, Square and Shopify Payments all get you there. Never see raw card numbers? Your PCI burden is minimal.

What Is PCI DSS?

PCI DSS is a set of security requirements, and it applies to anyone who processes, stores or transmits card data. The PCI Security Standards Council (PCI SSC) wrote it, and Visa, Mastercard, American Express, Discover and JCB founded that council. The council maintains the standard, but the card brands enforce it. That split is the one thing worth remembering here, because no penalty ever arrives from the PCI SSC. It arrives through your acquirer.

Important Version Update

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.

Going Deeper?

The rest of this page covers the full standard in detail. Need background first?

• How payments work covers data flows and infrastructure.
• Processor management covers your processor relationship.
• Payment methods covers what you accept and how.

Which SAQ Do You Need?

Goal: get to SAQ A or SAQ P2PE. They've got the fewest requirements and the lowest audit burden.

SAQ Eligibility Checklists

These checklists confirm which SAQ you're on. Every item must be true for that SAQ.

SAQ A Checklist (easiest - ~22 controls)

You're 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
• No electronic cardholder data sits on your systems or premises
• You confirmed your integration method with your processor, and they agree you qualify for SAQ A
• Your processor is PCI DSS compliant and you hold their current AOC

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

SAQ A Under PCI DSS 4.0

An iframe adds a condition to SAQ A. You confirm one of two things.

• You comply with Req 6.4.3 (script inventory) and 11.6.1 (payment page change detection).
• Or your processor confirms they handle both for you.

Full redirect is the simplest path. The customer leaves your site entirely. Choosing between iframe and redirect? Redirect is easier.

SAQ A-EP Checklist (~140 controls)

You're 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 affect the security of the transaction (your JavaScript runs on the payment page, say)
• You never 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 makes a direct-post API call to the processor. The card number goes browser to processor, but your scripts are in the path.
• You serve the payment page from your servers, not a redirect.
• Your checkout-page code could intercept card data, even though it doesn't.

Common example: a custom React or Next.js checkout using Stripe.js. Your front-end code orchestrates the flow with confirmCardPayment() and the card data still goes straight to Stripe, but your scripts are in the path, so you're A-EP anyway. That's ~140 controls instead of ~22, plus quarterly ASV scans. Unless the custom checkout is earning that, go back to a hosted page.

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. An agent types card details into the 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

P2PE vs E2EE

Your terminal vendor says "encrypted." Check the PCI SSC validated P2PE list. Not on it? That'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 job is getting out. Tokenization and outsourcing are the routes to SAQ A.

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 anyone who stores, processes or transmits cardholder data (CHD). Same for sensitive authentication data (SAD):

• Merchants accepting payment cards.
• Service providers processing, storing or transmitting CHD for merchants.
• Issuers and acquirers.
• Anyone who could affect the security of CHD, even without handling it.

Outsourcing Doesn't Eliminate Responsibility

Outsource all your payment processing and some requirements still apply. You still verify your provider's compliance. You still manage the relationship.

The 12 PCI DSS Requirements

PCI DSS sits under six goals. Each one holds 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 runs actively and can't be turned off

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 (8 only if the system can't 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 you a level by annual transaction volume, and each level validates differently. Under 20,000 e-commerce transactions a year puts you in Level 4, which covers most small merchants. The other three blocks are context, not homework.

Level 1

Criteria:

• More than 6 million transactions annually (Visa/Mastercard)
• OR any merchant that's had 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, though it isn't always enforced
• Quarterly ASV scans (if applicable)
• Mastercard often doesn't require direct validation

Network-Specific Rules

Mastercard runs Site Data Protection (SDP) and Visa runs Account Information Security (AIS), and both carry their own requirements. Your acquiring bank can add more on top, whatever your level. 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 have to complete DESV. That's a set of controls beyond standard PCI DSS. It includes:

• More frequent penetration testing
• Enhanced logging and monitoring
• Additional governance requirements

Self-Assessment Questionnaires (SAQs)

An SAQ is how you validate your own compliance. Which one you use depends on how you're handling 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:

1. Do you store cardholder data? → SAQ D
2. Is all processing outsourced? → SAQ A or A-EP
3. Do you use validated P2PE? → SAQ P2PE
4. Do you have IP-connected terminals? → SAQ B-IP or C

Goal: get to SAQ A instead of SAQ D. Redirect or hosted payment pages plus tokenization is the route. It cuts your compliance burden hard.

SAQ A Eligibility (v4.0 Updates)

For SAQ A under 4.0, an iframe needs one of two things:

• You comply with Req 6.4.3 and 11.6.1 for payment page script management.
• Or your processor confirms they manage both.

Redirects are easier. The customer leaves your site entirely. The payment page isn't yours.

Scope Reduction Strategies

The best PCI move is shrinking your scope, because fewer systems and processes fall under the requirements. For an online SMB only two of these four matter: tokenization and a hosted payment page. P2PE counts only if you take cards in person. Segmentation is a project for companies that already store card data, which you shouldn't be.

1. Tokenization

What it does: swaps cardholder data for a token. The token has no exploitable value.

Benefits:

• Tokens aren't cardholder data, so they're out of scope.
• Stored PAN leaves your environment.
• Card-on-file works without storing actual cards.
• SAQ D can become SAQ A.

Implementation:

• Use your processor's tokenization service.
• Make sure tokens are non-reversible.
• The token vault is your provider's job.

---

Deep Dive: How Tokenization Works

Tokenization is your most powerful scope reduction tool. Understand it and you'll implement it right.

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 do more than reduce PCI scope. Visa Token Service and Mastercard Digital Enablement Service both issue them:

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 look like card numbers on purpose. That's how they work with existing payment infrastructure. They're domain-restricted and useless outside your integration.

---

2. Point-to-Point Encryption (P2PE)

What it does: encrypts card data at the terminal. It stays encrypted all the way to the decryption environment.

Benefits:

• Qualifies for SAQ P2PE (~33 controls).
• Encrypted data is out of scope.
• Your CDE shrinks a lot.

P2PE vs E2EE:

• P2PE: a PCI SSC-validated solution. Scope reduction is immediate.
• E2EE: encryption at rest and in transit. Scope reduction needs acquirer approval.

3. Network Segmentation

What it does: isolates the cardholder data environment from the rest of your network.

Benefits:

• Fewer in-scope systems.
• Smaller attack surface.
• Faster assessments.
• Lower compliance costs.

Implementation:

• Use firewalls, VLANs, or physical separation.
• Implement role-based access control.
• Run segmentation testing (Req 11.4.5).
• Document CDE boundaries clearly.

4. Outsourcing Payment Functions

Approaches:

• Hosted payment pages that redirect to the processor.
• Secure iframes the processor controls.
• Gateway API with tokenization, so you never touch raw card data.
• Managed payment services.

Important: outsourcing doesn't finish the job.

• Verify your provider's AOC.
• Include them in your service provider management program.
• Know your residual responsibilities.

Network-Specific Requirements

Visa Requirements

• Account Information Security (AIS): the primary compliance program.
• Compromise Investigation: you engage a PCI Forensic Investigator (PFI) after a suspected breach.
• Fraud Monitoring: report fraud through the required channels.
• Terminated Merchant File (TMF): your acquirer's own file of terminated merchants. Visa's shared screening database is VMSS. Mastercard's is MATCH. All three get called "TMF" in conversation.

Mastercard Requirements

• Site Data Protection (SDP): the primary compliance program.
• Level 1/2 service providers may need DESV.
• Validation documents go to your acquiring bank.
• Information Security Program: required under Mastercard Rules Section 2.2.7.
• Third Party Processor (TPP) registration requirements.

Cardholder Data Defined

Scoping starts with knowing what counts as cardholder data.

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: a truncated PAN (first 6 + last 4) is still CHD. But permanently delete the middle digits and the full PAN is gone.

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 can't avoid storing 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)

Of the four, only tokenization takes the data out of scope. The other three still leave cardholder data in your environment, and storing it electronically keeps you in SAQ D however well it's encrypted.

Compliance Validation and Assessment

Quarterly ASV Scans

• External vulnerability scans run by an Approved Scanning Vendor.
• Required for any internet-facing systems.
• They have to pass, with no high or critical vulnerabilities.
• Submit the 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 that network segmentation actually works.
• PCI DSS 4.0 requires a defined methodology.

Attestation of Compliance (AOC)

• A formal attestation of your PCI DSS compliance status.
• Signed by a QSA (for a ROC) or a merchant officer (for an SAQ).
• It goes to your acquirer.
• Business partners often ask for it too.

PCI Compliance Tools and Vendors

You don't need to figure out PCI compliance alone. These are the categories that help, sorted by what you need.

Approved Scanning Vendors (ASVs)

ASVs run the quarterly external vulnerability scans. SAQ A-EP, B-IP, C-VT, C and D all require them. They scan your internet-facing systems and certify whether you pass.

Do You Need an ASV?

Check the SAQ comparison table, and if it shows "ASV Scan: Yes" you need one. SAQ A and SAQ P2PE don't require ASV scans, so most small merchants can skip this line item entirely.

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:

1. Sign up with an ASV
2. Provide your external IP addresses and domains
3. ASV runs automated scans quarterly
4. Fix any high/critical vulnerabilities found
5. Get a passing scan report to submit with your SAQ

If you do need scans, SecurityMetrics ($100-300/year) and ControlScan ($200-500) are the two priced for small merchants. Everything else in that table is built for enterprise networks you don't have.

Your Processor May Provide This

Stripe, Square and Adyen include basic PCI tools in the merchant portal. Check there before you buy anything. Some acquirers bundle ASV scanning into merchant services too.

Qualified Security Assessors (QSAs)

The PCI SSC certifies QSAs to run on-site assessments. You need one if:

• You're a Level 1 merchant (6M+ transactions/year). It's required for your annual ROC.
• You're a Level 1 service provider (300K+ transactions/year).
• Your acquirer requires a QSA assessment whatever your level.
• You want an expert review of your 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 at any level: $5,000-$15,000.

The PCI SSC QSA directory lists all qualified firms.

If you're Level 4 on hosted checkout, skip this section. Below Level 1 a QSA is optional unless your acquirer asks for one. The cheapest engagement above starts at $5,000 to be told what the SAQ A checklist already told you for free.

PCI Compliance Platforms

These platforms walk you through the SAQ. They track your compliance status. Most 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 enough. They take the SAQ step by step, run your quarterly scans if you need them, and hand you the documentation your acquirer wants.

For startups needing multiple certifications: Sprinto, Vanta or Drata put PCI, SOC 2 and ISO 27001 on one platform. Only worth it if you need more than PCI.

Payment Page Security Tools (Req 6.4.3 / 11.6.1)

Req 6.4.3 makes you manage and monitor every payment page script, and Req 11.6.1 makes you detect unauthorized changes to payment page content. Both are in PCI DSS 4.0, and both target Magecart attacks, where an attacker injects JavaScript to skim card data.

Who needs this: anyone with an e-commerce payment page, SAQ A-EP especially. SAQ A merchants on an iframe have to confirm who handles it, them or their processor. On a full redirect, it's mostly not your purchase.

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

The Simplest Path for SAQ A Merchants

On a full redirect, 6.4.3 and 11.6.1 are mostly your processor's problem. The payment page sits on their domain. Stripe Checkout and PayPal Standard both work this way.

On an iframe, ask your processor for written confirmation that they handle 6.4.3/11.6.1 for it. Stripe Elements and Adyen Drop-in are iframes, and most major processors will confirm. If they won't, you're either buying one of the tools above or writing a Content Security Policy for your checkout page. At that point, take the redirect.

What Your Processor Already Gives You

Check what your processor already gives you first:

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.

Don't Double-Pay

If you're on Stripe, Square or Shopify and you never handle card data yourself, you probably don't need a separate ASV, compliance platform or QSA. Check your processor's PCI documentation before you buy anything, because plenty of merchants pay for tools they don't need.

Key Fact: the "$5,000 to $100,000 per month" PCI fine has no published source, and PCI SSC doesn't levy fines at all. What's real is breach liability, and you carry the full cost: an SMB breach runs $120,000-$1.24M all in once you count forensics, notification, legal and card replacement. Spend on scope, not on tools. The cheapest path is SAQ A via hosted checkout.

Consequences of Non-Compliance

Consequence	Details
Monthly assessments	Real, but not published by anyone. The network assesses your acquirer; your acquirer passes it through under your merchant agreement. Ask your acquirer what their pass-through actually is, because that number is in your contract and the internet's number isn't.
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

Most of these only bite merchants who store card data themselves. On a hosted page, scope is still the one to watch: a new sales channel or a third-party integration can pull you back in.

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 only apply when you can't meet the original requirement
• Thin documentation of why the 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 can't 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

Both address Magecart attacks. An attacker injects a script into your payment page and steals card data.

Getting Started with Compliance

1. Understand your data flows - Map where CHD enters, moves through, and exits your environment
2. Determine your merchant level - Based on annual transaction volume
3. Identify scope reduction opportunities - Tokenization, P2PE, outsourcing
4. Select appropriate SAQ - After implementing scope reduction
5. Implement required controls - Gap analysis against applicable requirements
6. Engage qualified assessors - QSA for Level 1, or self-assessment
7. Establish ongoing processes - Quarterly scans, annual assessments, continuous monitoring

Steps 1 through 4 are where the money is. Get them right and you land on SAQ A, where step 7 is one questionnaire a year and no quarterly scans.

Next Steps

Just learning about PCI?

1. Map your cardholder data environment → Where does card data flow?
2. Determine your merchant level → Based on annual transaction volume
3. Identify scope reduction opportunities → Tokenization eliminates most PCI burden

Ready to reduce scope?

1. Evaluate tokenization providers → Let them handle card data, not you
2. Consider hosted payment pages → Remove your systems from scope entirely
3. Ask your processor about P2PE terminals → Reduce in-store PCI requirements

Preparing for assessment?

1. Gap analysis against your SAQ type → Know what's required
2. Engage a QSA early (Level 1) → Don't wait until assessment time
3. Establish quarterly ASV scanning → See the vendor comparison above
4. 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