PCI DSS Basics

By Midcove Editorial Team, Payments & Risk · Last updated: August 7, 2026

PCI DSS stands for Payment Card Industry Data Security Standard. It’s the set of security requirements the major card networks created to protect cardholder data wherever it’s stored, processed, or transmitted — and if your business accepts card payments in any form, PCI DSS compliance applies to you. It isn’t a law passed by a government; it’s an industry standard that processors, gateways, and merchants agree to follow as a condition of being able to accept card payments at all.

For most merchants, the standard feels intimidating from a distance: twelve requirements, multiple merchant levels, a stack of acronyms like SAQ, QSA, and ASV. Up close, the logic is simpler than it looks. The card networks want card data encrypted, access to it limited and logged, the systems around it kept secure and tested, and a written record that someone is actually responsible for all of it.

This guide walks through the PCI DSS basics in plain language: what the standard is and who enforces it, who it applies to, how merchant levels and SAQs work, what the six goals and twelve requirements actually ask for, and — most usefully — how the software choices you make can shrink the amount of compliance work that lands on your desk.

In this guide:

• What PCI DSS is and who enforces it
• Who PCI DSS applies to
• Merchant PCI levels and SAQs, in plain language
• The 6 goals and 12 requirements, summarized honestly
• How software choices reduce your PCI DSS compliance scope
• What to look for in a payment platform
• The takeaway
• Frequently Asked Questions

What PCI DSS Is and Who Enforces It

The standard is maintained by the PCI Security Standards Council, an independent body founded in 2006 by the major card brands — Visa, Mastercard, American Express, Discover, and JCB. The Council writes and updates the standard, publishes the official documents, and certifies the assessors and scanning vendors who validate compliance.

Here’s the part that surprises people: the Council doesn’t enforce anything. Enforcement flows through your payment ecosystem. The card brands set compliance programs, your acquiring bank (the bank behind your merchant account) is responsible for making sure the merchants it sponsors comply, and your processor or gateway passes those obligations down to you through your merchant agreement. If you fall short, consequences come from your acquirer — not from a regulator.

At a high level, PCI DSS is organized around a few core ideas: keep cardholder data secure with encryption, limit who and what can access that data, secure the networks that carry it, monitor and test systems on an ongoing basis, and maintain clear policies for how all of this is managed. It’s less a single checklist and more a framework that touches nearly every part of how a business handles payments.

Who PCI DSS Applies To

PCI DSS applies to any business that stores, processes, or transmits cardholder data, regardless of size. That includes a small shop running a handful of card-not-present transactions a month and a large enterprise processing thousands of transactions a day. The specific validation steps scale with transaction volume, but the underlying obligation to protect card data applies broadly across the industry.

It also applies to the vendors and platforms merchants rely on. A payment gateway, a CRM that displays transaction data, and a virtual terminal that keys in card-not-present orders are all touching cardholder data in some form, which means the standard’s principles apply to how those tools are built, not just to the merchant using them.

A useful mental model is “scope.” Your PCI scope is every system, person, and process that touches cardholder data or could affect the security of the systems that do. A laptop where staff key in phone orders is in scope. A spreadsheet with card numbers saved “just in case” is very much in scope — and a common audit failure. The less of your business that touches raw card data, the smaller your scope, and the lighter your compliance burden.

Merchant PCI Levels and SAQs, in Plain Language

Every merchant has the same obligation to protect card data, but not every merchant validates compliance the same way. That’s where merchant PCI levels and SAQs come in.

Merchant levels: how much proof you owe

Each card brand sorts merchants into levels, roughly by annual transaction volume. The exact thresholds vary by brand, so your acquirer or processor tells you which level applies to you — but the pattern is consistent:

• Level 1 covers the largest merchants (generally those processing millions of transactions a year, or any merchant that has suffered a data breach). Level 1 merchants typically need a formal annual assessment by a Qualified Security Assessor (QSA), resulting in a Report on Compliance.
• Levels 2–4 cover everyone else, in descending order of volume. These merchants generally validate through a Self-Assessment Questionnaire instead of a full on-site audit, sometimes with quarterly network scans by an Approved Scanning Vendor (ASV) depending on how they accept cards.

Most small and mid-sized businesses land in Level 3 or 4. The obligation to be compliant is identical at every level; what changes is how formally you have to prove it.

SAQs: which questionnaire matches your setup

The Self-Assessment Questionnaire (SAQ) is exactly what it sounds like: a structured set of yes/no questions about your security practices, which you complete and attest to annually. The Council publishes several SAQ types, and the one you fill out depends on how card data flows through your business. In broad strokes:

• SAQ A is the shortest, for merchants who fully outsource card handling — for example, an e-commerce site that redirects customers to a third party’s payment page and never touches card data itself.
• SAQ A-EP applies to e-commerce merchants whose own website affects how the payment page works, even if a third party processes the payment.
• SAQ B and B-IP cover merchants using standalone payment terminals with no electronic storage of card data.
• SAQ C and C-VT cover merchants using internet-connected payment applications or a web-based virtual terminal on a dedicated workstation.
• SAQ D is the longest, for merchants who store cardholder data electronically or don’t fit a simpler category.

The practical lesson: the SAQ you qualify for is a direct consequence of your architecture. Merchants who never store card numbers and outsource as much card handling as possible answer far fewer questions than merchants who keep card data in their own systems. When in doubt, confirm your SAQ type with your acquirer — they make the final call.

The 6 Goals and 12 Requirements, Summarized Honestly

The standard organizes its twelve requirements under six goals. You don’t need to memorize the control-by-control detail — that’s what the official documents on the Council’s site are for — but knowing the shape of the standard makes every compliance conversation easier:

Read as a whole, the twelve requirements describe basic security hygiene applied specifically to card data: encrypt it, limit access to it, keep the surrounding systems healthy, watch what happens, and write it all down. None of it is exotic — the challenge is doing it consistently, which is exactly why reducing how much of your business touches card data matters so much.

How Software Choices Reduce Your PCI DSS Compliance Scope

This is where PCI DSS compliance stops being an abstract obligation and becomes a series of practical decisions. Every requirement applies to your cardholder data environment — so the single most effective compliance move is shrinking that environment.

Tokenization: work with references, not card numbers

Tokenization replaces the primary account number (PAN) with a token — a reference value that’s useless to a thief but lets you run refunds, recurring billing, and reporting against the original transaction. When your platform stores tokens from your gateway instead of raw card numbers, a breach of that platform doesn’t expose usable card data, and the systems holding only tokens carry far less compliance weight than systems holding PANs.

Don’t store what you don’t need

The standard is blunt on this point: the best protection for stored card data is not storing it. Many businesses accumulate card numbers by accident — in email threads, support tickets, exported spreadsheets, call recordings. Each copy expands your scope and your risk. Card data security improves fastest when raw numbers simply never land in your systems, and good platform design makes that the default rather than a discipline your staff has to maintain.

Let the gateway and platform carry the heavy controls

When card entry, encryption, and storage happen inside your gateway and a well-built platform layered on top of it, many of the hardest requirements — encryption key management, secure storage, network segmentation around card data — become their problem to engineer and yours to verify. You still own your compliance, but your validation typically gets shorter and simpler. This is the same logic behind layering your defenses generally: dedicated payment fraud prevention software stops bad transactions before they become breaches or disputes, and a broader merchant risk management practice keeps your exposure visible over time. Weak card data security has downstream costs too — compromised cards turn into disputes, and our guide to how chargebacks work shows how expensive that cycle gets.

What to Look For in a Payment Platform

Merchants evaluating a payment gateway CRM or any tool that touches card data don’t need to become PCI experts, but a few practical questions go a long way:

• Is data encrypted both in transit and at rest, not just at the point of entry?
• Does the platform use tokenization, working with a token from your processor instead of storing raw card numbers, so a breach of the platform doesn’t expose usable card data?
• Are there role-based access controls and audit logs, so you can see who viewed, refunded, or changed a transaction and when?
• Does the vendor describe its practices in specific terms, rather than vague claims of being “secure,” and are those practices designed to align with PCI DSS requirements?
• Does it reduce your scope in practice — keeping card entry inside the gateway’s secure flow and keeping raw PANs out of your reports, exports, and screens?

Midcove is built with these principles in mind: encryption in transit and at rest, tokenized card data instead of stored raw numbers, and role-based access controls with audit logging. Because Midcove connects to the merchant account you already have with NMI, Authorize.Net, Stripe, or PayPal, security is layered across both the platform and the gateway you’ve chosen — and there’s no new underwriting to slow you down. You can read exactly how this works on our PCI DSS compliance and security page.

The Takeaway

PCI DSS exists to keep card payments trustworthy for everyone involved: merchants, processors, and cardholders. It’s enforced through your acquirer rather than a regulator, it scales its validation demands to your size and setup, and its twelve requirements boil down to disciplined security hygiene around card data.

You don’t need to memorize every requirement to make good decisions. Focus on shrinking your scope: choose platforms that encrypt data properly, tokenize instead of storing raw card numbers, and show you exactly who has access to sensitive information. The smaller the part of your business that touches card data, the shorter your questionnaire, the lower your risk, and the more time you spend running the business instead of documenting it.

Frequently Asked Questions