PCI DSS — the Payment Card Industry Data Security Standard — is one of those requirements that most small business merchants know they're supposed to comply with but aren't entirely sure what compliance actually means in practice. The acronym is intimidating, the full standard runs to hundreds of pages, and the compliance industry has done an excellent job of making the process sound more complex and expensive than it actually is for most merchants.

Here's the reality: for the vast majority of small businesses, PCI compliance is an annual self-assessment questionnaire, a passing network vulnerability scan, and a $5–$15/month compliance fee charged by your processor. It's not a security audit, it doesn't require a consultant, and it's not particularly burdensome once you understand which requirements actually apply to your specific processing environment.

This guide covers what PCI DSS actually requires of small merchants, which Self-Assessment Questionnaire (SAQ) type applies to your business, and how to get certified without paying anyone to do it for you.

What PCI DSS Actually Is

PCI DSS is a security standard created and maintained by the Payment Card Industry Security Standards Council — a body founded by Visa, Mastercard, American Express, Discover, and JCB — that sets the minimum security requirements for any business that stores, processes, or transmits credit card data. It's not a law, but card network rules require processors to ensure their merchants comply, and non-compliance creates real consequences: fines assessed to your processor (which get passed to you), increased liability in the event of a data breach, and in serious cases, loss of the ability to accept cards.

PCI DSS 4.0 is the current version, having replaced PCI DSS 3.2.1 in 2024. The full standard has 12 requirement domains covering network security, cardholder data protection, vulnerability management, access control, monitoring, and information security policy. The full set of requirements applies to large merchants and service providers who handle significant cardholder data environments. Small merchants — those processing under 1 million Visa or Mastercard transactions annually — qualify for simplified compliance paths through Self-Assessment Questionnaires.

The SAQ Types: Which One Is Yours

The SAQ you need to complete depends entirely on how your business accepts payments — specifically, whether cardholder data ever touches your systems and how. This is the question that most merchants get confused about, and getting it right matters because the wrong SAQ means either over-complying (wasting time on requirements that don't apply) or under-complying (missing requirements that do).

SAQ A — The simplest. For fully outsourced card-not-present merchants.

If you accept payments online exclusively through a fully hosted payment page — where the customer enters their card details on a page hosted by your payment processor, not on your own website — and you never touch cardholder data in any form, SAQ A is your questionnaire. It has 22 requirements and takes most merchants about 20 minutes to complete. The key criterion: your checkout redirects customers to a processor-hosted payment page, or you use an iframe or embedded form where the card data goes directly to the processor without ever passing through your server.

Most merchants using CyoGate's Collect.js tokenization or a hosted payment page qualify for SAQ A. If you're not sure whether your integration qualifies, the question to ask your developer is: "Does card data ever touch our server?" If the answer is no, SAQ A likely applies.

SAQ A-EP — For ecommerce merchants with partially outsourced payment pages.

If your checkout page is hosted on your own server but payment processing is handled by a third-party processor — a common setup with direct API integrations — SAQ A-EP applies. It's more extensive than SAQ A (approximately 191 requirements) because your server is in the payment flow even if you're not storing card data. This applies to merchants who have their own checkout forms that submit card data to a payment API, rather than redirecting to a hosted page.

SAQ B — For retail merchants using standalone terminals.

If you accept payments only through a standalone dial-up or IP-connected card terminal with no electronic cardholder data storage, SAQ B applies. This is the common situation for simple retail merchants with a physical terminal that dials directly to the processor. The questionnaire covers physical security of the terminal and basic network considerations.

SAQ B-IP — For retail merchants using IP-connected terminals.

A variant of SAQ B for merchants using IP-connected POS terminals that meet specific PCI-approved device requirements. More requirements than SAQ B but still manageable for small retailers.

SAQ C-VT — For merchants using web-based virtual terminals.

If you process payments by manually entering card details into a web-based virtual terminal — like CyoGate's — from a dedicated computer that's not used for other internet browsing or email, SAQ C-VT applies. It covers the security of that workstation and access controls around the virtual terminal.

SAQ C — For merchants with payment applications connected to the internet.

If your payment application (POS system, shopping cart) connects to the internet for processing but doesn't store cardholder data electronically, SAQ C covers the network security requirements for that setup.

SAQ D — The most extensive. For merchants who store cardholder data.

If your business stores any cardholder data — even encrypted — in any form, SAQ D applies. This is the most comprehensive questionnaire and the one that typically requires real security investment. The strong recommendation: don't store cardholder data. Use tokenization instead. CyoGate's Customer Vault stores payment credentials on PCI-compliant infrastructure so your systems never hold the raw card data — which means you never qualify for SAQ D when you could qualify for SAQ A instead.

The Annual Compliance Process Step by Step

For most small merchants using a fully hosted or properly tokenized integration, PCI compliance looks like this:

Step 1: Determine your SAQ type. Use the framework above, or ask your processor which SAQ type they have you registered under. If you're not sure, the description of your checkout process — how customers enter card details and where that data goes — is the determining factor.

Step 2: Complete the SAQ. The SAQ is a yes/no questionnaire about your security practices. For SAQ A, the questions cover things like: Do you use strong passwords on your systems? Is your payment page accessed over HTTPS? Do you have a security policy? Most small merchants can answer truthfully "yes" to all SAQ A questions without making any changes to their existing practices.

Step 3: Pass an Approved Scanning Vendor (ASV) scan. Most SAQ types require a quarterly external vulnerability scan of your publicly accessible IP addresses and web infrastructure. This is automated — you provide your IP address(es) and website URL to an ASV, they run the scan, and you receive a passing or failing report. SAQ A merchants with no publicly accessible systems sometimes have a reduced or waived scanning requirement.

Step 4: Submit to your processor. Your processor maintains your compliance status. CyoGate's PCI compliance certification tool walks you through the SAQ completion and scan submission process within a single interface — no separate accounts or third-party portals required. Annual certification takes most merchants under an hour.

Step 5: Repeat annually. PCI compliance is an annual requirement. Your processor will typically notify you when your certification is expiring. Staying on top of it proactively — rather than responding to a non-compliance notice — avoids the non-compliance fees that processors charge when certification lapses.

What Non-Compliance Actually Costs

The consequences of PCI non-compliance have two components that merchants often conflate:

Non-compliance fees. Most processors charge a monthly non-compliance fee — typically $20–$50/month — when a merchant's PCI certification has lapsed. These fees accumulate quietly and are easy to miss on a statement. They're also entirely avoidable: completing the annual SAQ stops the fees immediately.

Breach liability. The more serious consequence is the liability exposure in the event of a data breach. A PCI-compliant merchant who experiences a breach has significantly reduced liability compared to a non-compliant merchant. Card network rules allow acquiring banks to pass breach investigation costs, card replacement costs, and fraud losses back to non-compliant merchants. For a small business, a significant breach while non-compliant is potentially business-ending. Compliance isn't just a fee-avoidance exercise — it's a genuine risk management practice.

PCI DSS 4.0: What Changed for Small Merchants

PCI DSS 4.0 introduced several requirements that affect small ecommerce merchants specifically, with some provisions becoming mandatory in 2025:

Script security on payment pages. Requirement 6.4.3 requires merchants to maintain an inventory of all scripts on their payment pages and implement controls to ensure they haven't been tampered with. This addresses Magecart-style attacks where malicious JavaScript is injected into checkout pages to skim card data. For merchants using hosted payment pages or proper tokenization, this risk is largely mitigated at the processor level — but merchants with custom checkout implementations need to audit their script inventory.

Stronger authentication requirements. Multi-factor authentication is now required for all access to the cardholder data environment, not just remote access. For most small merchants using hosted solutions, this is already handled by their processor's infrastructure.

Enhanced testing requirements. More explicit requirements around penetration testing and security control effectiveness. Again, merchants using fully outsourced payment pages have limited direct exposure — the processor's environment bears the testing obligation, not the merchant's.

The consistent theme in PCI DSS 4.0, as with prior versions, is that merchants who keep card data out of their own systems through proper hosted payment pages and tokenization have the least compliance burden. The new requirements are most significant for merchants who have kept payment processing infrastructure in-house.

Getting Certified

CyoGate's PCI compliance certification tool is designed specifically to make the annual process straightforward for merchants — guided SAQ completion, integrated ASV scanning, and direct submission to your merchant account record. No separate compliance portal, no third-party account to manage, and no consultant fee required for the routine annual certification that the vast majority of merchants need.

If you have questions about which SAQ type applies to your specific integration, or if your checkout setup involves custom development that makes the SAQ type less obvious, contact us — we can walk through your integration and point you to the right path.