SAQ C vs SAQ D: When to Use Each

Bottom Line

SAQ C is for merchants with payment applications connected to the internet (but no card storage), while SAQ D is for everyone else — including merchants who store cardholder data electronically or have complex payment environments. If you’re processing payments through a virtual terminal or web-based point-of-sale system without storing card data, you’ll likely use SAQ C. If you’re storing card data, have custom payment integrations, or don’t fit neatly into other SAQ categories, you’re heading for SAQ D.

What’s Being Compared and Why It Matters

Choosing between SAQ C vs SAQ D determines the scope and complexity of your PCI compliance journey. SAQ C covers merchants using payment application systems connected to the internet, while SAQ D serves as the catch-all for merchants with more complex environments or those who store cardholder data electronically.

This comparison helps you identify which self-assessment questionnaire matches your payment environment and compliance obligations. The wrong choice means either over-engineering your compliance program (choosing D when C would suffice) or under-scoping your requirements (choosing C when you need D).

When this comparison becomes relevant:

Your payment application connects to the internet for processing
You’re unsure if your virtual terminal qualifies for SAQ C
Your acquirer questions your SAQ selection
You’re transitioning from outsourced to in-house payment processing

Comparison Table

Aspect	SAQ C	SAQ D
Scope	Payment application systems with internet connectivity	All merchants not eligible for other SAQ types
Requirements	~80 questions across 9 sections	~320+ questions across all 12 requirements
Complexity	Moderate	High
Typical Timeline	2-4 weeks	3-6 months
Annual Cost Range	$3,000-$10,000	$15,000-$100,000+
Common Use Cases	Virtual terminals, web-based POS	Stored cardholder data, complex environments
Network Segmentation	Usually not required	Often critical for scope reduction
Quarterly Scans	Required	Required

Detailed Breakdown

SAQ C: Payment Applications Without Storage

SAQ C applies when your payment application systems connect to the internet but you don’t store cardholder data electronically. Think virtual terminals, web-based point-of-sale systems, or payment applications that immediately transmit card data to your processor.

Who it’s for:

Merchants using internet-connected payment terminals
Businesses with virtual terminal applications
Retailers using web-based POS systems
Companies processing through payment application software

Strengths:

Significantly fewer requirements than SAQ D
No data retention requirements to manage
Simpler network security controls
Lower compliance maintenance burden

Limitations:

No electronic storage allowed — not even temporary batch files
Payment applications must be validated (PA-DSS or listed on PCI SSC website)
All system components must be on the same network segment
Internet connectivity requirement excludes dial-out terminals

The moment you store cardholder data electronically — even encrypted — you’ve moved beyond SAQ C territory. This includes temporary storage for batch processing, recurring billing databases, or archived transaction logs.

SAQ D: The Comprehensive Assessment

SAQ D serves as the catch-all for merchant environments that don’t fit other SAQ types. If you store cardholder data, have custom payment applications, or maintain complex network architectures, this is your assessment path.

Who it’s for:

Merchants storing cardholder data electronically
Businesses with custom payment applications
Companies not eligible for other SAQ types
Organizations with complex, multi-segment networks

Strengths:

Covers all PCI DSS requirements
Accommodates any payment architecture
Allows for compensating controls
Supports complex business models

Limitations:

Extensive documentation requirements
Higher implementation costs
Longer completion timelines
May require specialized expertise

SAQ D requires you to address all 12 PCI DSS requirements, including network security, access controls, vulnerability management, and security policies. Your quarterly ASV scans cover your entire CDE, and you’ll need documented processes for everything from change management to incident response.

The Technical Differences That Matter

The jump from SAQ C to SAQ D isn’t just about question count. SAQ D introduces requirements for:

Network segmentation validation (Requirement 11.3.4)
Cryptographic key management (Requirements 3.5 and 3.6)
File integrity monitoring (Requirement 11.5)
Penetration testing (Requirement 11.3)
Security awareness training (Requirement 12.6)
Incident response planning (Requirement 12.10)

These aren’t just checkbox exercises. Implementing proper network segmentation alone can take months and require significant infrastructure changes. Key management procedures need documentation, testing, and annual reviews. Your FIM solution must monitor all system components within the CDE.

Decision Framework

Choose SAQ C if:

You use internet-connected payment applications exclusively
Zero electronic storage of cardholder data
Payment applications are PA-DSS validated or PCI-listed
All payment systems share the same network segment
No custom payment software or modifications

Choose SAQ D if:

You store any cardholder data electronically
Custom payment applications process transactions
Payment systems span multiple network segments
You don’t clearly fit other SAQ categories
Your acquirer specifically requires SAQ D

Questions to Confirm Your Category

Before committing to SAQ C, verify:
1. Do any systems retain card numbers after authorization?
2. Are all payment applications on the PCI SSC’s acceptable list?
3. Do payment systems share the same subnet and security policies?
4. Have you modified any payment application code?

For SAQ D consideration, check:
1. Do you need cardholder data for recurring billing?
2. Have you developed custom payment interfaces?
3. Do different locations have different network configurations?
4. Does your business model prevent qualifying for other SAQs?

Common Misidentification Scenarios

Virtual terminal confusion: Not all virtual terminals qualify for SAQ C. If your virtual terminal stores transaction history with full card numbers, you need SAQ D. Check whether your terminal truly transmits and forgets.

“We don’t store cards” misconception: Temporary files, log entries, and database backups count as storage. That CSV export of today’s transactions sitting in your downloads folder just pushed you to SAQ D.

Network complexity overlooked: SAQ C requires payment systems on the same network segment. If your virtual terminal runs on the corporate network while your e-commerce platform sits in the DMZ, you’re looking at SAQ D.

What Happens If You Choose Wrong

Completing the Wrong SAQ

Submitting SAQ C when you need SAQ D creates immediate compliance gaps. Your acquirer may accept it initially, but any breach investigation will reveal the mismatch. Potential consequences include:

Immediate non-compliance status
Fines from your acquirer
Increased transaction fees
Mandatory forensic investigation costs
Personal liability for executives who signed the AOC

Over-Scoping Your Environment

Choosing SAQ D when SAQ C suffices wastes resources but maintains compliance. You’ll implement unnecessary controls and spend more on assessments, but you won’t face penalties. The main risks:

Excessive compliance costs
Delayed implementation timelines
Staff burnout from unnecessary requirements
Opportunity cost of misdirected resources

How to Course-Correct

Discovered you’re using the wrong SAQ? Take these steps:

1. Stop current assessment — Don’t submit an incorrect AOC
2. Document your actual environment — Map all payment flows and data storage
3. Consult your acquirer — Explain the situation and get written guidance
4. Complete the correct SAQ — Start fresh with the right questionnaire
5. Implement missing controls — Address any gaps from your previous approach

When to Get a QSA’s Opinion

Bring in a QSA when:

Your payment environment spans multiple locations or segments
You’re unsure about data storage in your applications
Your acquirer questions your SAQ selection
You’ve had significant changes to your payment environment
The cost difference between SAQ C and D justifies professional guidance

FAQ

Q: Can I use SAQ C if my payment application temporarily caches card data in memory?

A: Yes, temporary memory storage during processing doesn’t disqualify you from SAQ C. However, any persistent storage — including swap files, hibernation files, or memory dumps — would require SAQ D. Ensure your systems don’t inadvertently write cardholder data to disk.

Q: What if I use multiple payment applications — some storing data, others not?

A: You must complete SAQ D. PCI compliance covers your entire payment environment, and the presence of any system storing cardholder data electronically determines your overall SAQ type. You can’t segment your compliance by application.

Q: Does SAQ C require network segmentation?

A: SAQ C doesn’t require network segmentation, but it does require all payment application systems to be on the same network segment. If your payment applications span multiple segments, you’ll need to consolidate them or move to SAQ D.

Q: If I only store truncated card numbers and expiration dates, can I use SAQ C?

A: No, expiration dates combined with truncated PANs are considered cardholder data under PCI DSS. Electronic storage of this combination requires SAQ D compliance. Only storing truncated numbers alone (without other data elements) avoids this requirement.

Q: How do I prove I don’t store cardholder data for SAQ C?

A: Document your data flow diagrams, application configurations, and retention policies. Run card data discovery tools across your environment. Have your payment application vendor provide written confirmation about their data handling. Keep evidence of these validation efforts for your compliance records.

Conclusion

The choice between SAQ C vs SAQ D shapes your entire compliance program. SAQ C offers a streamlined path for merchants using internet-connected payment applications without data storage, while SAQ D provides comprehensive coverage for complex environments or those storing cardholder data.

Most merchants initially assume they need SAQ D, but many qualify for the simpler SAQ C by confirming they don’t store cardholder data electronically and use only approved payment applications. The key is accurately assessing your environment before committing to either path.

Remember that PCI compliance isn’t just about picking the easiest questionnaire — it’s about accurately representing your payment environment and implementing appropriate security controls. Whether you’re completing SAQ C or tackling the comprehensive SAQ D, your goal remains the same: protecting cardholder data and maintaining the trust of your customers.

PCICompliance.com gives you everything you need to achieve and maintain PCI compliance — our free SAQ Wizard identifies exactly which questionnaire you need, our ASV scanning service handles your quarterly vulnerability scans, and our compliance dashboard tracks your progress year-round. Start with the free SAQ Wizard to confirm whether SAQ C or SAQ D fits your environment, or talk to our compliance team about your specific payment setup.