If your business accepts card payments, PCI DSS applies to you in some form. That surprises a lot of owners, particularly those who use a payment processor and reasonably assume the processor handles all of it.
The good news is that for most small businesses the obligations are far lighter than the standard’s size suggests — provided the business has actually arranged things so card data never touches its own systems.
Educational guidance, not a compliance determination
This article explains PCI DSS in general terms. It is not legal advice and it is not an official compliance determination. Your specific obligations depend on how you accept payments and on your agreements with your payment processor and acquiring bank. Confirm what applies to you with your processor, your acquiring bank, or a Qualified Security Assessor.
What PCI DSS is
The Payment Card Industry Data Security Standard is a set of security requirements for organizations that handle payment card data. It is maintained by the PCI Security Standards Council, an industry body founded by the major card brands.
An important distinction: PCI DSS is not government regulation. It is enforced contractually. Your merchant agreement with your payment processor or acquiring bank obliges you to comply, and the consequences of not doing so — fees, increased liability if an incident occurs, or in serious cases losing the ability to accept cards — flow from that contract rather than from a statute.
The current version is PCI DSS v4.0.1, a limited revision published in June 2024 that clarified wording without adding or removing requirements. Earlier versions have been retired: v3.2.1 in March 2024 and v4.0 at the end of December 2024. The set of “future-dated” requirements introduced with v4.x became mandatory on 31 March 2025. Because versions and timelines move, confirm the current state in the Council’s document library rather than relying on any article, including this one.
Does it apply to you?
The standard applies to any entity that accepts, processes, stores, or transmits payment card data. There is no minimum transaction volume below which it stops applying — volume affects how you validate compliance, not whether the requirements apply.
Two roles are worth understanding at a high level:
- Merchants accept cards as payment for their own goods or services. Nearly every small business in this conversation is a merchant.
- Service providers handle card data on behalf of other businesses. If you build or host systems that process payments for other companies, you may fall into this category, which carries heavier obligations.
Merchants are grouped into levels based on annual transaction volume, which determines how compliance is validated — from a self-assessment questionnaire for smaller merchants through to a formal assessment by a Qualified Security Assessor for the largest. Your acquiring bank tells you which applies to you; it is not something you determine unilaterally.
What counts as card data
“Card data” is more specific than it sounds, and the distinctions drive everything else.
Cardholder data includes the primary account number — the long number on the card — along with the cardholder name, expiration date, and service code. The account number is the element that matters most; wherever it goes, obligations follow.
Sensitive authentication data includes the full data from the magnetic stripe or chip, the security code on the back (CVV2/CVC2), and PINs. This category is stricter: it must never be stored after authorization, under any circumstances, even encrypted.
A common and serious mistake
Writing a card number and security code on a paper form, or accepting them by email so a staff member can key them in later, puts that data squarely in scope — and storing the security code at all is prohibited. Paper and email are not exempt because they are not software.
Scope, and why it matters most
If you take one concept away, make it this one. Your cardholder data environment is everything that stores, processes, or transmits card data — plus any system connected to it that could affect its security.
The size of that environment determines how much of the standard you have to satisfy. A business where card data never touches its own systems has a very small environment and a correspondingly light obligation. A business that keys card numbers into a computer on the office network has just pulled that computer, and potentially the whole network, into scope.
This is why reducing scope is the single most effective thing a small business can do. Every system removed from scope is a system you no longer have to secure, document, scan, and attest to. It is almost always cheaper to redesign how you accept payments than to bring a broad environment up to the full standard.
How outsourcing changes things
Using a payment processor genuinely helps — it is the right answer for nearly every small business. But “we use a processor” does not by itself end your responsibility, and the details of how you integrate matter enormously.
| How you take payment online | Where card data goes | Typical effect on your scope |
|---|---|---|
| Redirect to the processor's hosted page | Entirely to the processor; your site never sees it | Smallest scope. Usually the simplest validation path. |
| Payment link sent to the customer | Entirely to the processor | Small scope, similar to a hosted page. |
| Processor-hosted fields embedded in your page (iframe) | To the processor, though your page frames the form | Still limited, but your website's integrity now matters — a compromised page could redirect or overlay the form. |
| Custom checkout that touches card data before sending it on | Through your own systems | Substantially larger scope and a much heavier validation burden. |
| Staff keying card numbers into a computer | Through that computer and its network | Pulls that device — and potentially the surrounding network — into scope. |
Even in the lightest arrangements, responsibilities remain: you must still confirm which requirements apply, complete the appropriate validation, keep your website secure and current, manage who has access to payment systems, and — importantly — confirm that your service providers are themselves compliant, keeping a record of that.
Self-assessment questionnaires
Most small merchants validate compliance through a Self-Assessment Questionnaire. There are several types, and the one that applies depends on how you accept payments — for example, whether you are entirely outsourced to a hosted page, whether you use embedded fields, or whether you handle card data directly. Each type contains a different subset of the requirements.
Two practical points. First, choosing the right questionnaire matters: completing an easier one that does not reflect how you actually take payments is worse than useless, because your attestation would be inaccurate. Second, your acquiring bank or processor generally tells you which one they expect and when — start there rather than guessing. The current questionnaires are published in the Council’s document library.
Common small-business mistakes
- Assuming the processor handles everything. They handle their part. Your website, your devices, your staff practices, and your validation remain yours.
- Storing card numbers “temporarily.” In a spreadsheet, a booking note, an email folder, or a paper file. This is the most common way a small business unintentionally expands its scope.
- Keeping security codes. Prohibited after authorization, without exception.
- Accepting card details by email or text. Those messages persist in multiple mailboxes and backups indefinitely.
- Treating it as a one-time exercise. Compliance is a continuous state, not an annual form. Changing how you take payments changes your obligations.
- Forgetting the point-of-sale hardware. Card terminals need updates and physical protection against tampering.
- Not documenting service providers. You are expected to know who handles card data for you and to confirm their compliance status.
The controls behind it
The requirements themselves are largely security fundamentals that a well-run business benefits from regardless. In broad terms they cover: securing networks and configurations, protecting stored data, encrypting transmission, managing vulnerabilities and keeping systems patched, restricting access to those with a business need, giving each person a unique ID with strong authentication, restricting physical access, logging and monitoring access to systems and data, testing security regularly, and maintaining written policies.
If you have already worked through protecting customer information and have visibility into your devices, you have covered a fair portion of the underlying ground. The specific obligations, evidence, and attestation are separate work.
Practical first steps
Practical first steps
- Write down every way your business accepts card payments — in person, online, by phone, and by invoice.
- For each, trace exactly where the card number goes and which of your systems, people, or paper it touches.
- Eliminate any storage of card numbers you control, and confirm security codes are never retained.
- Stop accepting card details by email, text, or handwritten form; replace them with a payment link or hosted page.
- Check how payments are integrated on your website — hosted page, embedded fields, or custom checkout.
- Contact your payment processor or acquiring bank and ask which self-assessment questionnaire applies to you and when it is due.
- List every service provider that touches card data and obtain confirmation of their compliance status.
- Confirm point-of-sale terminals are updated and physically protected against tampering.
- Apply the underlying controls: unique accounts, multi-factor authentication, patching, and access logging.
- Write down how you handle payments, and review it whenever that changes.
- If your scope extends beyond a fully outsourced setup, get advice from a Qualified Security Assessor.
Where we fit
We can help with the practical security work underneath these requirements — reducing what your systems touch, patching, access control, and monitoring — and help you prepare for a self-assessment. To be clear about the boundary: we are not a Qualified Security Assessor, and we do not certify PCI compliance or issue compliance determinations. That validation runs through your acquiring bank, your processor, or a QSA.
Sources and further reading
- PCI Data Security Standard (PCI DSS)(opens in a new tab) — PCI Security Standards Council
- PCI SSC Document Library(opens in a new tab) — PCI Security Standards Council
- PCI DSS v4.x Resource Hub(opens in a new tab) — PCI Security Standards Council
- Protecting Personal Information: A Guide for Business(opens in a new tab) — Federal Trade Commission