What PCI DSS is
The Payment Card Industry Data Security Standard is a set of security requirements written by the card brands, not by a government. It applies to every organization that stores, processes, or transmits card data. There is no size exemption: a single-terminal shop is in scope exactly as a national chain is, though the obligations differ enormously by how you accept payments.
Because it is a card-brand standard rather than a law, enforcement runs through your acquiring bank and processor rather than through a regulator.
Merchant levels
Levels are set by annual transaction volume and determine how compliance is validated rather than what the requirements are. The overwhelming majority of small businesses fall into the lowest level, which means self-assessment rather than an external audit. Practically speaking, if you are a small or mid-sized merchant you will complete a questionnaire and a scan rather than hire an assessor.
The questionnaire that applies to you
This is the part that confuses people, and it is the part that matters most. Different self-assessment questionnaires apply depending on how you accept cards, and they range from about twenty questions to several hundred.
Card-present only, standalone terminal
The simplest case by a wide margin. A dial-out or IP terminal with no card data touching any other system puts you in the shortest questionnaire available.
Ecommerce, fully outsourced checkout
If customers are redirected to a hosted payment page or an embedded iframe and card data never reaches your server, your scope shrinks dramatically.
Ecommerce, card data touches your site
If your own code handles card data at any point, you are in the longest and most demanding questionnaire. This is worth avoiding architecturally if you possibly can.
Mixed acceptance
Take cards in person and online and by phone, and you generally validate against the most demanding applicable questionnaire. Consolidating onto fewer card-data paths simplifies this.
What compliance actually requires
Stripped of jargon, the requirements come down to a short list: do not store card data you do not need, and never store the security code at all; keep the systems that touch card data patched and behind a firewall; use unique credentials with strong authentication for anyone who can reach cardholder data; encrypt card data in transit; restrict physical access to terminals and any paper records; and run periodic vulnerability scans if you take payments online.
For a merchant using a standalone terminal or a fully hosted checkout, most of these are satisfied by the setup itself rather than by anything you have to build.
Reducing your scope
This is the highest-leverage move available and almost nobody frames it this way. Every PCI requirement applies only to systems that touch card data. Reduce the number of systems that touch it and the requirements shrink with them.
Use hosted checkout or an iframe
If card data goes directly from the customer's browser to the processor, your server is out of scope for most requirements.
Tokenize stored customers
Store a token rather than a card number. A token is useless outside your account, so a breach of your systems does not expose card data.
Use point-to-point encryption at the terminal
Card data encrypted at the read head is never in the clear on your network.
Stop storing anything you do not need
Old order records with full card numbers are pure liability with no operational value.
Never store the security code
Storing CVV after authorization is prohibited outright, and it is a common finding in small-merchant assessments.
Non-compliance fees
Many processors charge a monthly fee to merchants who have not completed their questionnaire. It is worth checking your statement for this specifically, because it is one of the most common charges merchants pay without knowing why. Completing the paperwork usually removes it.
A practical starting point
Confirm with your processor which questionnaire applies to you, complete it honestly, run a scan if your acceptance method requires one, and then look at whether your architecture can be simplified to a smaller questionnaire next year. The goal is not to pass a test, it is to hold less card data, so that a breach has less to take.
CoreCommerce is PCI DSS Level 1 certified by A-LIGN, an independent third-party auditor. Level 1 is the highest validation tier the standard defines. Rather than the self-assessment questionnaire a merchant fills out, a Level 1 provider is examined on site every year by a Qualified Security Assessor, who tests the controls directly and issues a formal Report on Compliance. It means the infrastructure your payments run on was validated by an assessor, not a checklist. Your own requirements depend on how you accept payments, and it is worth asking any processor which questionnaire applies to your specific setup before you sign.
236.6B
US noncash payments in 2024, over three quarters by card
Source: Federal Reserve Payments Study
Common questions
Does PCI compliance apply to a small business?+
Yes. PCI DSS applies to every business that stores, processes, or transmits card data, with no size exemption. A single-terminal shop is in scope exactly as a national chain is, though what you actually have to do differs enormously by how you accept payments.
Which PCI SAQ applies to my business?+
It depends on how you handle cards. SAQ A, the shortest, is for merchants who fully outsource card handling to a hosted page. SAQ A-EP is much longer, for sites that touch the card. SAQ D, the longest by far, is for anyone storing card data on their own systems.
How do I reduce my PCI scope and compliance work?+
Keep card data off your own systems. Use a hosted payment page from a PCI DSS Level 1 certified gateway, so the card is captured in the gateway's environment rather than yours. That typically moves you from the full SAQ D down to the much shorter SAQ A.
How do small businesses accidentally expand their PCI scope?+
By letting card data touch systems it should not: writing card numbers on paper or in email, storing them in a CRM or spreadsheet, keying phone orders into a generic form, or letting staff photograph cards. Each pushes you toward full SAQ D scope.
What happens if I ignore PCI compliance?+
Enforcement runs through your acquiring bank and processor, not a regulator. You may see a monthly PCI non-compliance fee, and if a breach occurs while non-compliant, you face far higher liability, fines, and forensic costs. Most of the work is avoidable upfront.
Ask us which questionnaire applies to you.
Before you sign anything. It takes one phone call and it determines how much work compliance actually is for your setup.
More on merchant services and credit card processing, or read the payments glossary.