PCI DSS Compliance for Small Businesses: A Plain-English Guide

By J. Mesa

If your business accepts one credit card payment a year, PCI DSS applies to you. The standard covers the corner cafe and the national retailer alike. Small merchants carry a lighter paperwork load, but the duty to protect card data is the same, and criminals favor small merchants because their defenses tend to be thinner.

What is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security requirements for any organization that stores, processes, or transmits payment card data. Visa, Mastercard, American Express, Discover, and JCB founded the PCI Security Standards Council, which writes the standard. The current version is 4.0.1.

Is PCI DSS a law?

No. PCI DSS is a contractual obligation. Your merchant agreement with your payment processor or acquiring bank requires you to comply. The card brands enforce it through the banks, and the banks enforce it on you. A few states reference the standard in their laws, but your contract is what binds you.

Who has to comply?

Every merchant that accepts payment cards, at any volume, through any channel: in person, online, by phone, or by mail. Service providers that handle card data for merchants must comply as well.

Using a third-party processor such as Square, Stripe, or Clover reduces your work. It does not remove your responsibility.

What are the PCI merchant levels?

The card brands sort merchants by annual transaction volume. Visa’s levels are typical:

  • Level 1: more than 6 million transactions a year. Requires an on-site audit by a Qualified Security Assessor.
  • Level 2: 1 million to 6 million.
  • Level 3: 20,000 to 1 million e-commerce transactions.
  • Level 4: fewer than 20,000 e-commerce transactions, or up to 1 million total.

Most small businesses sit at Level 4. Level 4 merchants validate compliance with a Self-Assessment Questionnaire each year and, in some cases, quarterly network scans.

What are the 12 PCI DSS requirements?

  1. Install and maintain network security controls, such as firewalls.
  2. Apply secure configurations to all system components. Change vendor default passwords.
  3. Protect stored account data.
  4. Encrypt cardholder data sent across open, public networks.
  5. Protect all systems and networks from malicious software.
  6. Develop and maintain secure systems and software. Install security patches.
  7. Restrict access to cardholder data to people whose jobs require it.
  8. Identify users and authenticate their access. Use unique IDs and multi-factor authentication.
  9. Restrict physical access to cardholder data.
  10. Log and monitor all access to system components and cardholder data.
  11. Test the security of systems and networks on a regular schedule.
  12. Support information security with organizational policies and programs.

What is a Self-Assessment Questionnaire, and which one do I need?

A Self-Assessment Questionnaire, or SAQ, is a form on which you attest to meeting the requirements that apply to your way of taking cards. The right SAQ depends on how card data moves through your business.

  • SAQ A. You outsource all card handling. Customers pay on a page hosted by your payment provider, and no card data touches your systems.
  • SAQ A-EP. Your website does not receive card data, but it controls how customers reach the payment page.
  • SAQ B. You use standalone dial-out terminals or imprint machines, with no electronic storage.
  • SAQ B-IP. You use standalone, approved payment terminals connected over the internet.
  • SAQ C-VT. You key transactions by hand into a web-based virtual terminal on a dedicated computer.
  • SAQ C. Your payment application connects to the internet, with no electronic storage of card data.
  • SAQ P2PE. You use only a validated point-to-point encryption solution.
  • SAQ D. Everything else, including any merchant that stores card data electronically. SAQ D covers every requirement.

SAQ A asks a few dozen questions. SAQ D asks hundreds. Your processor or bank tells you which form it expects. If you take cards more than one way, you may need to cover each method.

What card data am I allowed to store?

The best answer for a small business: none.

You may store the card number, cardholder name, and expiration date if you have a business need and you protect them, with the card number rendered unreadable. You may never store sensitive authentication data after authorization. That includes:

  • The full contents of the magnetic stripe or chip
  • The three- or four-digit security code
  • The PIN or PIN block

Look for card data hiding in plain sight: paper order forms, call recordings, spreadsheets, old emails, notes in the customer database, and photos of cards on a phone. Shred the paper and delete the files.

How do I reduce my PCI scope?

Scope means the people, processes, and systems that touch card data or connect to systems that do. Smaller scope means fewer requirements and lower risk.

  • Outsource the payment page. Use a hosted checkout or an embedded payment form from your processor, so card data never reaches your website’s server.
  • Use validated P2PE terminals. They encrypt the card at the moment of the swipe, tap, or dip.
  • Stop storing card numbers. Use your processor’s tokenization and card-on-file features for repeat billing.
  • Segment the network. Put payment terminals on their own network, apart from office computers and guest Wi-Fi.
  • Stop taking card numbers by email or text. Send a payment link.

What changed in PCI DSS version 4?

Version 3.2.1 retired in March 2024. A group of new requirements in version 4 became mandatory on March 31, 2025. The ones small merchants notice most:

  • Multi-factor authentication for all access into the cardholder data environment, not just for administrators
  • Passwords of at least 12 characters, or 8 where a system cannot support 12
  • Protections against phishing, with training that covers phishing and social engineering
  • For e-commerce: an inventory of the scripts running on payment pages, with authorization for each one and detection of unauthorized changes
  • Authenticated internal vulnerability scans
  • Formal, documented risk analyses for certain decisions

In early 2025 the Council revised SAQ A. Merchants who use it must confirm that their site is not susceptible to attacks from scripts that could affect the e-commerce system. Ask your web developer and your payment provider how your site meets this.

Do I need vulnerability scans?

It depends on your SAQ. Merchants with internet-facing systems in scope need external scans each quarter from an Approved Scanning Vendor, plus scans after significant changes. Under version 4, this now includes e-commerce merchants on SAQ A. SAQ D merchants also need internal scans and penetration tests. Our post on vulnerability assessments and penetration tests explains the difference.

What happens if I do not comply?

  • Monthly non-compliance fees. Many processors charge $20 to $100 or more a month until you submit your SAQ.
  • Breach costs. After a card data breach, a non-compliant merchant can face a mandatory forensic investigation, card brand assessments, the cost of reissuing cards, and fraud losses passed down through the bank.
  • Higher rates or termination. The bank can raise your fees, require a Level 1 audit, or end your ability to accept cards.

How do I become PCI compliant?

  1. Map how you take cards: each terminal, website, phone order process, and vendor.
  2. Reduce your scope with the steps above.
  3. Ask your processor which SAQ applies.
  4. Complete the SAQ with honest answers, and fix each “no.”
  5. Run the required scans.
  6. Sign the Attestation of Compliance and submit it to your processor.
  7. Write the security policy that requirement 12 calls for, and train the staff who handle cards.
  8. Repeat each year, and maintain the controls in between.

What are the common mistakes?

  • Treating the SAQ as a form to click through
  • Writing card numbers on paper or keeping them in a spreadsheet
  • Running the point-of-sale system on the same network as guest Wi-Fi
  • Leaving default passwords on terminals and routers
  • Never inspecting terminals for skimmers or tampering
  • Assuming the processor makes you compliant
  • Forgetting the web developer and hosting company in the scope

Your next step

Log in to your processor’s compliance portal and check the date of your last SAQ. If it is overdue, or you do not know which one applies, start with a map of how cards move through your business. Cerberus Cybersecurity measures small businesses against PCI DSS as part of our risk and compliance assessments and writes the policies the standard requires. Contact us to begin.