[ARCHIVED → Ch 24] Chapter 20 — 24 Questions or 328: Why Your Integration Choice Is a Compliance Decision

The Four Compliance Levels: Who Needs What

So you know that PCI-DSS applies to anyone who stores, processes, or transmits cardholder data. But here's a reasonable question: should a corner café processing 200 card transactions a month really face the same security requirements as Amazon?

The answer, sensibly, is no. PCI-DSS uses a tiered system of four compliance levels that scale requirements based on transaction volume. Think of it as proportional security — the more cards you process, the higher your risk profile, and the more scrutiny you face.

The logic is straightforward: a merchant processing 6 million transactions a year represents a vastly larger target than one processing 15,000. A breach at the larger merchant exposes exponentially more cardholders. So the standard demands proportionally more rigorous validation.

Let's walk through each level using WhiteBottle Coffee's growth story — because the beauty of this system is how it evolves alongside a real business.

Level 4: Where Most Businesses Start

WhiteBottle begins life as a single café in a quiet neighborhood. They process a few hundred card transactions a day at the counter, and their new website handles maybe 500 online orders a month. Total e-commerce volume: well under 20,000 transactions per year.

That puts WhiteBottle squarely at Level 4 — the lowest compliance tier. They need to complete the appropriate Self-Assessment Questionnaire (we'll get to which one shortly) and run an annual vulnerability scan. No external audit. No QSA visit. For a small merchant with the right architecture, this is manageable — potentially even a one-afternoon exercise.

The vast majority of merchants in the world — your local restaurants, boutiques, and independent online shops — sit at Level 4. It's the default starting position.

Level 3: Growth Brings Attention

WhiteBottle's online store takes off. A viral TikTok video about their oat milk latte drives a surge of subscription orders, and suddenly they're processing 50,000 e-commerce transactions a year.

They've crossed the 20,000 threshold into Level 3. The requirements are similar to Level 4 — still SAQ-based, still no mandatory external audit — but quarterly network scans by an Approved Scanning Vendor (ASV) now become mandatory. These scans probe WhiteBottle's internet-facing systems for vulnerabilities: unpatched software, misconfigured firewalls, exposed services.

For many growing businesses, Level 3 is where PCI compliance shifts from "something we fill out once a year" to "something that requires ongoing attention." Those quarterly scans aren't just a checkbox — they can surface real issues that need fixing within a defined remediation window.

Level 2: The Mid-Market Squeeze

Fast forward a few years. WhiteBottle is now a national chain with 200 locations. Between their physical stores and their thriving online business, they're processing 2 million card transactions annually.

Welcome to Level 2. The requirements look similar to Level 3 on paper — SAQ plus quarterly scanning — but the stakes are materially higher. At this volume, WhiteBottle is handling enough transactions that a security incident could affect hundreds of thousands of cardholders. Their acquiring bank is paying closer attention. The SAQ questionnaire needs to be completed with more rigor and documentation.

Some acquiring banks start recommending (or requiring) that Level 2 merchants engage a QSA for guidance, even if a full on-site audit isn't technically mandatory. The line between Level 2 and Level 1 can feel uncomfortably thin.

Level 1: The Big Leagues

Now imagine WhiteBottle has become a global franchise — a hypothetical, but useful for understanding the top tier. They're processing over 6 million card transactions a year across 2,000 locations worldwide.

At Level 1, everything changes. WhiteBottle must undergo an annual on-site assessment by a Qualified Security Assessor — a thorough, multi-week audit that examines every aspect of their cardholder data environment. Network architecture, encryption practices, access controls, physical security, employee training, incident response plans — all of it gets scrutinized. Quarterly ASV scans continue as well.

Level 1 assessments are expensive (often $50,000 to $500,000+ depending on complexity), time-consuming, and demanding. They require dedicated security staff, documented policies and procedures, and a mature security program. This is why the jump from Level 2 to Level 1 is the most significant threshold in the PCI world.

The Escalation Clause: When a Breach Overrides Everything

Here's a nuance that surprises many merchants: a single data breach can bump you to Level 1 regardless of your transaction volume.

If WhiteBottle suffers a breach at any level — even as a tiny Level 4 café processing 200 transactions a month — the card networks can immediately reclassify them as Level 1. This means a full on-site QSA audit, remediation of all identified issues, and ongoing monitoring. The costs can be devastating for a small business.

This isn't just theoretical. It's the stick behind the carrot. The PCI framework essentially says: comply proportionally now, or comply maximally after something goes wrong. For small merchants, the threat of Level 1 reclassification after a breach is a powerful motivator to take even basic security measures seriously.

Table 2: PCI Compliance Levels at a Glance. Transaction volume determines your tier, but a breach can override everything.

Notice something about the table above? Levels 2 through 4 all use the same basic validation approach: complete an SAQ and run periodic scans. The real cliff is between Level 2 and Level 1, where the requirement jumps from self-assessment to a mandatory external audit. That single distinction — self-reported vs. independently verified — represents an order-of-magnitude difference in cost, effort, and organizational readiness.

SAQ Types: Picking Your Path to Compliance

If compliance levels answer the question "how much compliance do I need?" then SAQ types answer the question "how do I prove it?"

Think of it this way. Compliance levels are like how often you go to the doctor — a healthy 25-year-old goes once a year for a basic checkup, while someone with a chronic condition might go quarterly for specialist appointments. The frequency and intensity of your visits depend on your risk profile.

SAQ types, on the other hand, are like which tests the doctor orders based on your specific symptoms. Two patients might both need annual checkups (same level), but one gets a simple blood pressure reading while the other gets a full cardiac workup. The tests depend on what's actually going on with your body — or in PCI terms, how your payment systems are actually architected.

The Self-Assessment Questionnaire comes in several flavors, each designed for a specific type of payment environment. Picking the right SAQ is one of the most consequential decisions a merchant makes, because it determines exactly how many controls you need to implement and how many questions you need to answer.

Let's walk through each one.

SAQ A: The Lightest Path (~24 Questions)

SAQ A is the compliance dream for online merchants. It applies when you've fully outsourced your payment page to a PCI-compliant third party. The customer leaves your website entirely and enters their card details on the payment provider's hosted page — think Stripe Checkout's redirect mode or PayPal's hosted payment flow.

With SAQ A, card data never touches your systems, never transits your servers, and your website doesn't even participate in the payment process. You're essentially telling the PCI framework: "I hand the customer off to someone else for payment, and I only get a confirmation back."

The questionnaire is just 24 questions, most of which confirm that you don't store, process, or transmit cardholder data. For WhiteBottle, this would apply if they used a pure redirect flow — clicking "Pay" sends the customer to a Stripe-hosted page, and WhiteBottle's website only receives a success or failure callback.

Turnaround: one to three days for most merchants.

SAQ A-EP: The Iframe Trap (~191 Questions)

Here's where things get interesting — and where many merchants get caught off guard.

SAQ A-EP applies when your website participates in the payment flow without directly handling card data. The most common scenario: you embed a payment provider's iframe or JavaScript-based form on your own checkout page. The card details go directly from the customer's browser to the payment provider, but your website hosts the page that contains the payment form.

Why does this matter? Because a compromised merchant website could:

• Inject malicious JavaScript that intercepts card data before it reaches the iframe
• Replace the legitimate payment iframe with a phishing lookalike
• Modify page scripts to redirect card data to an attacker's server

Your site doesn't handle card data, but it could if it were compromised. That potential is enough to bring your website into PCI scope.

The result? SAQ A-EP has approximately 191 questions — nearly eight times more than SAQ A. It covers vulnerability management, web application security, script integrity monitoring, Content Security Policy headers, and regular penetration testing.

For WhiteBottle, this is the SAQ they'd face if they use Stripe Elements (the iframe-based approach) rather than Stripe Checkout (the redirect approach). Same payment provider. Dramatically different compliance burden.

The One-Question Test: SAQ A vs. A-EP

Does your website participate in the payment process — even if you don't store card data?

If your site simply redirects to a hosted payment page, you're SAQ A (24 questions).

If your site loads JavaScript, iframes, or embedded forms from a payment provider, you're SAQ A-EP (191 questions).

The difference? 24 questions vs. 191. One to three days vs. one to three weeks. Choose your integration wisely.

This distinction is the single most practical takeaway for online merchants. Many startups choose an embedded checkout (iframe) for the better user experience — customers stay on your site, the form looks native, conversion rates are higher. That's a legitimate business decision. But it comes with a compliance cost that you need to factor in.

SAQ B: Standalone Terminals (~41 Questions)

SAQ B is for merchants using standalone, dial-out POS terminals — the kind that connect directly to the payment processor over a phone line, with no internet connection involved. Think of the classic countertop card reader at a neighborhood diner.

WhiteBottle's original countertop terminal would qualify for SAQ B. No internet-connected card processing, no electronic cardholder data storage. The terminal dials out, processes the transaction, and that's it.

At 41 questions focused on physical device security and basic procedures, SAQ B is straightforward. But it's becoming less common as more terminals move to IP-based connections.

SAQ B-IP: IP-Connected Terminals (~68 Questions)

When WhiteBottle upgrades their countertop terminal to a newer model that connects over the internet (IP) rather than a phone line, they shift from SAQ B to SAQ B-IP. The terminal still doesn't store card data after authorization, but now there's a network connection to secure.

SAQ B-IP adds 27 questions on top of SAQ B, mostly focused on network security: firewalls, network segmentation, and ensuring the terminal's IP connection is properly isolated from the rest of WhiteBottle's network.

SAQ C: Payment Apps on the Internet (~160 Questions)

SAQ C applies to merchants with payment applications connected to the internet — but who don't store cardholder data electronically after authorization. This covers scenarios like a custom POS application running on a merchant's computer that processes cards in real time.

At 160 questions, SAQ C is comprehensive. It covers firewall configuration, network segmentation, secure application development, and more. Most small online merchants won't fall into this category — they'll typically land in SAQ A or A-EP instead.

SAQ C-VT: Virtual Terminals (~80–85 Questions)

If WhiteBottle starts taking phone orders and manually keying card numbers into a web-based virtual terminal (essentially a payment form provided by their processor, accessed through a browser), they'd face SAQ C-VT. The focus is on securing the device used to access the virtual terminal and ensuring the environment around that device is protected.

SAQ P2PE-HW: Hardware Encryption (~33 Questions)

SAQ P2PE-HW applies when a merchant uses a PCI-listed Point-to-Point Encryption hardware device. These devices encrypt card data at the moment of interaction — the card swipe, dip, or tap — and the encrypted data can only be decrypted inside the payment processor's secure environment. The merchant's systems never see unencrypted card data.

At just 33 questions, P2PE-HW is one of the lightest SAQ paths. The tradeoff is that you need to use specific, PCI-validated hardware, which can be more expensive upfront.

SAQ D: The Full Monty (~328+ Questions)

SAQ D is the catch-all. If you don't fit into any of the categories above — or if you store cardholder data on your own systems, or if you have a complex custom environment — you're SAQ D.

For merchants, SAQ D has approximately 328 questions covering the full set of PCI-DSS controls. For service providers (payment gateways, hosting companies, PSPs), it's 328 to 359 questions with additional service-provider-specific obligations.

SAQ D is where compliance gets serious. It covers everything: network architecture, encryption, access controls, logging, monitoring, physical security, employee training, incident response, and more. Completing it can take four or more weeks, and larger organizations may need several months.

For WhiteBottle, SAQ D would only apply if they made a fateful decision: building their own custom billing platform that stores tokens capable of initiating transactions. As we discussed in the tokenization chapter, tokens that can trigger payments (like merchant-initiated transaction tokens) may be in PCI scope. If WhiteBottle stores those locally in a custom system, they've just inherited the full PCI control set.

Table 3: SAQ Types — Complete Reference. Your payment architecture determines which questionnaire you face. The range from 24 to 328+ questions shows just how much your integration choice matters.

Levels vs. SAQs: Putting It Together

Let's make sure the distinction between levels and SAQ types is crystal clear, because confusing them is one of the most common mistakes merchants make.

Levels determine how rigorously your compliance is validated — specifically, whether you self-assess or face an external audit. They're based on transaction volume.

SAQ types determine what you're assessed on — which controls apply to your environment based on how you handle card data. They're based on your payment architecture.

A merchant can be at any combination. A Level 4 merchant using an iframe checkout faces SAQ A-EP (191 questions, self-assessed). A Level 1 merchant using a pure redirect might have a simpler technical scope but still requires a full QSA audit because of their volume.

Here's a practical example: WhiteBottle at their current Level 4 status with a Stripe Elements iframe would complete SAQ A-EP on their own. If a breach pushed them to Level 1 overnight, they'd face the same 191 questions — but now a QSA would need to verify every answer on-site. Same scope, dramatically different process.

This is why smart merchants think about both dimensions when planning their payment architecture. You can't control your transaction volume (growth is the goal, after all), but you can control your payment integration. Choosing a redirect over an iframe. Using P2PE hardware at the point of sale. Keeping tokens with your payment provider rather than storing them locally. Each of these decisions shifts you toward a lighter SAQ — and when you eventually grow into a higher compliance level, you'll be grateful for every question you don't have to answer.

In the next sections, we'll look at the Attestation of Compliance — the document that proves you've done the work — and then dive into the specific architectural strategies that shrink your PCI scope. Because as we've just seen, the how of your payment integration matters just as much as the how much.