PCI Compliance Requirements: 5 Steps for Small Merchants

The PCI compliance requirements are usually presented as a list of twelve. That list is accurate and almost useless if you run a ten-person operation, because it’s written for an organization with a security team. “Install and maintain network security controls” is a reasonable instruction to a network engineer. To a caterer with a router from the cable company, it’s a shrug.

The twelve requirements translate cleanly into five pieces of work. The order matters, because the first step decides how much of the rest applies to you at all.

That first step is also the one small merchants skip, which is why so many end up answering the longest questionnaire for a business that didn’t need to.

The Bottom Line

• PCI DSS has 12 requirement areas, and they only apply to systems that touch cardholder data.
• Shrinking what touches card data is the highest-value move available, and it’s step one for a reason.
• The 51 future-dated requirements from PCI DSS v4.0 became mandatory on March 31, 2025 (PCI Security Standards Council).
• Phone orders and card readers carried on delivery runs pull more systems into scope than most owners realize.
• Documentation isn’t bureaucracy here. It’s the thing that determines your position after a breach.

How the 12 PCI DSS requirements map to five steps

Here’s the whole standard, grouped by the work it actually represents.

Requirement areas per PCI Security Standards Council.

If you’re not yet sure whether any of this applies to your business, start with what PCI compliance means for a small business, which covers merchant levels and the consequences of skipping the whole thing.

Step 1: Map the cardholder data environment

Every requirement below applies only to your cardholder data environment: the systems, people, and processes that store, process, or transmit card data. Everything outside it is out of scope. So the cheapest compliance work you will ever do is making that environment smaller.

Start by writing down every route money takes into your business. For a business that delivers its own orders, the list is usually longer than expected:

• The website checkout.
• The POS terminal at the counter.
• The card reader that goes out in a vehicle.
• Phone orders, and the workstation the number gets typed into.
• Invoices with pay links for wholesale accounts.
• Third-party ordering platforms that settle to you.
• Cards kept on file for standing weekly orders.

Then, for each one, ask a single question: does a card number ever exist inside my business, even for a second? On a screen, on a phone call, on a slip of paper, in a saved file, in a call recording. If yes, that system is in scope and everything below applies to it. If the number goes straight from the customer to the processor without passing through anything of yours, that route mostly drops out.

Two changes do most of the shrinking. Replace phone-dictated card numbers with a payment link the customer fills in themselves, which takes your phone system, your staff, and your recordings out of scope (Shuttle). And let your processor tokenize cards for repeat customers instead of keeping numbers on file, which is what otherwise pushes a small merchant into the longest questionnaire. Our guide to choosing the right SAQ and proving compliance shows exactly how much paperwork this decision is worth.

Step 2: Protect the card data you can’t avoid handling

This covers requirements 3, 4, and 9: stored data, data in transit, and physical access.

Don’t store what you don’t need. Requirement 3 is mostly about not keeping card data in the first place. Full card numbers, and never the security code on the back or full magnetic stripe data after authorization. For most small merchants, the honest answer is that they shouldn’t be storing card numbers at all, and the places they accidentally do are email inboxes, spreadsheets, and order-management notes fields.

Encrypt anything crossing a public network. Requirement 4 means current TLS on your checkout, and it means not emailing card numbers, not texting them, and not accepting them through a web form that isn’t a payment form. A customer who emails you their card number has created a compliance problem in your inbox. Delete it and tell them how to pay properly.

Lock up the physical stuff. Requirement 9 is the one delivery operations underestimate. Card readers that travel need to be accounted for: know which device is where, don’t leave terminals in unattended vehicles, and check them periodically for tampering or swapped hardware. Any paper that carries a card number goes in a locked drawer and then through a shredder, not a recycling bin.

Step 3: Secure the systems around the data

Requirements 1, 2, 5, and 6 cover the infrastructure. At small-business scale this is less intimidating than it sounds.

• Requirement 1: network security controls. A properly configured firewall between the internet and anything handling card data. If your POS shares a flat network with the guest Wi-Fi and the tablet in the back office, that’s the gap. Putting customer Wi-Fi on a separate network from payment systems is the single most effective network change most small merchants can make.
• Requirement 2: secure configurations. Change vendor defaults. Every default admin password on the router, the POS, the card terminal, the CMS. Default credentials remain one of the easiest ways into a small business.
• Requirement 5: anti-malware. Maintained and updated on the systems that need it, with scans actually running rather than a licence that lapsed two years ago.
• Requirement 6: secure systems and software. Patching, in practice. Your ecommerce platform, plugins, POS software, and operating systems. Unpatched plugins are the most common finding on external scans, and v4.0 added tighter expectations around the scripts running on payment pages.

Step 4: Control who can reach it

Requirements 7, 8, and 10 cover access, and this is where v4.0 asked more of small merchants than v3.2.1 did.

Requirement 7 is need-to-know: not everyone needs access to payment systems. The person who packs orders doesn’t need the POS admin account.

Requirement 8 is identification and authentication, and it’s where the 2025 changes bite. Shared logins are out. Each person gets their own account, so logs mean something. Multi-factor authentication expanded significantly under v4.0, and the practical effect for a small merchant is that MFA is now expected on administrative access and on remote access into any environment handling card data (Linford & Company). Password expectations also lengthened.

Requirement 10 is logging. You need a record of who accessed what, and it needs to be retained. Most small merchants satisfy this through their POS and platform logs rather than a separate tool. The work is confirming the logs exist, are turned on, and are kept long enough.

For a delivery operation, the practical question under this step is usually about devices. If drivers use a shared tablet or a personal phone for anything connected to payments, that’s shared access to a payment system, and it needs individual accounts and a screen lock at minimum.

Step 5: Test it, then write it down

Requirements 11 and 12 are testing and policy.

Requirement 11 means regular security testing. If you have internet-facing systems in scope, that’s quarterly external scans by an Approved Scanning Vendor, plus internal vulnerability scanning, and v4.0 added an expectation that internal scans be authenticated rather than surface-level. Automated web application scanning tools can cover the internal side between formal scans, though the quarterly external scan itself has to come from an approved vendor to count toward validation.

Requirement 12 is the information security policy, and it’s the one most likely to be dismissed as paperwork. It isn’t. It’s a written document covering acceptable use, how staff handle card data, who’s responsible for what, and what happens during an incident, and every employee is meant to have seen it.

If you already maintain policies for food safety, labeling, or vendor requirements, this belongs alongside them rather than in a separate binder. The habits that make a retail compliance program work (one owner per area, a review date, and a checklist staff can actually follow) are the same habits that keep a PCI policy from going stale the week after it’s written.

Two parts of it earn their keep on an ordinary Tuesday:

• The incident response plan. Who gets called, in what order, when something looks wrong. A business that has to invent this during an actual breach loses days it doesn’t have. The general approach to handling a compliance issue applies here too: contain first, document as you go, and notify the parties contractually owed a notification, which here means telling your acquiring bank early.
• Staff training. A new hire who takes a card number over the phone because nobody told them not to has undone step 1. Training is how the map you drew stays accurate.

Requirement 12 also covers third parties. Any service provider that handles card data on your behalf, whether processor, gateway or hosted checkout, needs to be on a list, and you’re expected to confirm their compliance status is current rather than assume it. Which providers earn their fee is covered in our breakdown of PCI compliance services and what they actually do.

What changed in PCI DSS v4.0 that small merchants notice

Three of the 51 future-dated requirements that became mandatory in March 2025 are the ones small merchants actually feel (PCI Security Standards Council):

1. Broader multi-factor authentication. MFA expectations widened beyond remote admin access, which for most small businesses means turning it on across POS back offices and platform admin accounts.
2. Payment page script management. Requirements 6.4.3 and 11.6.1 cover knowing which scripts run on your payment page and detecting unauthorized changes to it. It’s a direct response to attackers skimming cards by injecting JavaScript into checkout pages.
3. Authenticated internal vulnerability scanning. Internal scans now need credentials so they see what an attacker with a foothold would see, not just what’s visible from outside.

None of these require an enterprise budget. They require someone to sit down with the admin settings of systems you already pay for.

Frequently asked questions

What are the 12 requirements of PCI DSS?

They cover network security controls, secure configurations, protecting stored account data, encrypting data in transit, anti-malware, secure systems and software, need-to-know access restrictions, user identification and authentication, physical access restrictions, logging and monitoring, regular security testing, and an organizational information security policy (PCI Security Standards Council). Each breaks into sub-requirements, and only those touching your cardholder data environment apply to you.

Do all 12 requirements apply to a small business?

Every requirement applies to the systems in your cardholder data environment, but many will be marked not applicable if you don’t have the systems they describe. A merchant using a hosted checkout and never storing card numbers legitimately answers “N/A” to large sections. That’s the payoff for shrinking scope: same standard, far fewer applicable controls.

How do PCI requirements apply to card payments taken at a customer’s door?

The terminal, the person carrying it, and any network it connects to are all in scope. Modern readers encrypt at the point of tap, which keeps the exposure narrow, but physical control of the device, individual user accounts, and never writing a card number down still apply. A declined card that someone jots down “to retry later” is a requirement 3 and requirement 9 failure in one move.

Which PCI requirement do small businesses fail most often?

Requirement 6 in practice, through unpatched software. Outdated plugins and CMS versions are the most frequent external-scan findings, and they’re the most common way a small merchant’s site gets compromised. Requirement 12 is the most commonly skipped outright, because a written policy feels optional until something goes wrong.

Does using a payment processor mean the requirements don’t apply to me?

No. A compliant processor absorbs a large share of the technical controls and can reduce your applicable requirements substantially, but you’re still responsible for your own systems, your staff, your physical premises, and any card data that reaches you outside that processor’s flow. The obligation to validate annually stays with you either way.

Start where the data is

The twelve requirements look like twelve projects. They’re one project with five stages, and the first stage decides how big the other four are.

Map every payment route this week. Kill the ones that put card numbers inside your business: the phone dictation, the paper slips, the cards on file. What’s left is a much shorter list of systems to secure, a much shorter questionnaire to answer, and a much smaller problem if something ever does go wrong. Compliance work that starts anywhere else ends up securing things you should have stopped doing instead.