PCI compliance for small business means meeting the Payment Card Industry Data Security Standard (PCI DSS), which applies to any entity that stores, processes, or transmits cardholder data. According to the PCI Security Standards Council, PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume. The standard is enforced by the card brands (Visa, Mastercard, American Express, Discover, JCB) and acquiring banks through their merchant agreements, not by government mandate. For most small merchants, compliance means completing a Self-Assessment Questionnaire (SAQ), not hiring an auditor.

What is PCI DSS and who does it apply to?

PCI DSS is a set of security requirements designed to protect cardholder data wherever it is stored, processed, or transmitted. According to the PCI SSC's merchant resources, the current version is PCI DSS v4.0.1, published in June 2024. The previous version, v4.0, retired on December 31, 2024; v3.2.1 retired on March 31, 2024. If you take card payments in any form, whether through a physical terminal, online checkout, phone order, or invoice payment, PCI DSS applies to your business.

The standard is the same in Canada and the United States. PCI DSS is a contractual obligation enforced through your merchant agreement, not a law. According to the PCI SSC's Guide to Safe Payments, your business may lose the ability to accept payment cards if you do not comply. The card brands define merchant levels and validation requirements, and your acquiring bank determines how you must demonstrate compliance.

What are merchant levels and how do they affect small businesses?

Visa assigns merchants to levels based on annual transaction volume, as stated in Visa's Supplemental Requirements (v10.0, June 2026). Effective 25 April 2024, Visa consolidated levels 3 and 4 into a unified Level 3. Level 1 covers over 6 million annual Visa transactions; Level 2 covers 1,000,001 to 6,000,000; Level 3 covers 1 to 1,000,000. According to Visa's AIS page, transaction volume determines the merchant level, and acquirers must ensure their merchants validate at the appropriate level.

Most small businesses fall into Level 3. Specific validation requirements are set by Visa, Mastercard, and your acquirer. As the PCI SSC states, "whether a small merchant is required to validate compliance is determined by the individual payment brands." If you are unsure of your level or requirements, ask your payment processor or acquiring bank directly.

Which Self-Assessment Questionnaire applies to a small merchant?

The SAQ you complete depends on how you handle card payments, not your transaction volume. According to the PCI SSC SAQ Instructions and Guidelines (v4.0.1, Revision 1, April 2025), each SAQ has specific eligibility criteria you must meet. Common options for small merchants include the following:

  • SAQ A: Card-not-present only (e-commerce, mail order, phone order). All card processing is outsourced to a PCI-compliant third-party service provider. You do not store, process, or transmit card data electronically. For e-commerce, the payment page is delivered entirely from the provider (redirect or iframe).
  • SAQ A-EP: E-commerce where processing is outsourced but your website can affect the security of the payment (for example, you control scripts on the page containing the payment form). You still do not receive card data on your own systems.
  • SAQ B: Imprint machines or standalone dial-out terminals only. No electronic storage. Not for IP-connected terminals.
  • SAQ B-IP: Standalone PCI-approved point-of-interaction terminals that connect over IP, not mixed with other devices on the same network segment. No electronic card storage.
  • SAQ P2PE: Hardware terminals used only with a PCI-listed point-to-point encryption (P2PE) solution. You have no access to cleartext card data.
  • SAQ D (Merchant): Any merchant environment that does not fit a shorter SAQ, including any merchant that stores electronic card data.

Before starting any SAQ, confirm with your acquirer that you are eligible to self-assess and that you meet every eligibility criterion for the SAQ you intend to use.

What changed on March 31, 2025?

PCI DSS v4.0 introduced 64 new requirements; according to the PCI SSC Coffee with the Council podcast, 51 of them were future-dated and became mandatory on March 31, 2025. After that date, they must be fully considered during any PCI DSS assessment. Key requirements affecting small merchants include:

  • Requirement 8.4.2: "MFA is implemented for all non-console access into the CDE." This applies to all users accessing the cardholder data environment via any non-console path.
  • Requirement 6.4.3: "All payment page scripts that are loaded and executed in the consumer's browser are managed," including authorization and integrity verification. This addresses browser-based skimming attacks.
  • Requirement 11.6.1: A change and tamper-detection mechanism must alert personnel to unauthorized modification of security-impacting HTTP headers and script contents on payment pages. Per the standard, the mechanism must function "at least weekly OR periodically (at the frequency defined in the entity's targeted risk analysis)."
  • Requirement 5.4.1: "Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks."

For SAQ A, the PCI SSC FAQ #1588 blog post states that Requirements 6.4.3, 11.6.1, and 12.3.1 were removed from SAQ A and replaced with an eligibility criterion requiring merchants to confirm their site is not susceptible to script attacks. The FAQ clarifies this criterion "does not apply to e-commerce merchants with a webpage that redirects customers" or to merchants that "fully outsource payment functions...by providing customers with an email with a link." Those using an embedded iframe can meet it by implementing controls like those in 6.4.3 and 11.6.1, or by obtaining confirmation from their PCI-compliant provider. The blog notes these changes "take effect on 1 April 2025" for SAQ A.

How can small businesses reduce their PCI scope?

The simplest way to reduce PCI scope is to handle less card data. The PCI SSC's Guide to Safe Payments for Small Merchants (Version 3.0, April 2024) states: "The best way to protect against data breaches is not to store card data at all." Practical steps from the guide include:

  • Outsource: Consider outsourcing your card processing to a PCI DSS compliant service provider. When you use a validated P2PE solution, card data is encrypted at the terminal and only decrypted by the payment processor.
  • Use a hosted payment page: For e-commerce, send customers to your payment provider's checkout page rather than building your own. If the payment page is fully hosted by a compliant third party and you never touch card data, SAQ A may apply.
  • Do not store card data you do not need: The guide states "IF YOU DON'T NEED CARD DATA, DON'T STORE IT." Do not keep card numbers in email, spreadsheets, databases, or paper files. Ask your payment processor about tokenization, which substitutes card data with tokens that have no value to an attacker.
  • Ask your processor which SAQ applies: Your payment processor can confirm which SAQ they expect based on how you have integrated their service.

Do I need vulnerability scans or penetration tests?

According to the PCI SSC ASV Resource Guide (v12, July 2024), quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are required for merchants completing SAQ A, SAQ A-EP, SAQ B-IP, and SAQ D. The guide clarifies that ASV scan requirements in SAQ A apply to e-commerce merchant systems that host the webpage that either redirects payment transactions to a TPSP or includes an embedded payment form. SAQ B and SAQ P2PE do not include ASV scan requirements.

As we covered in vulnerability scan vs penetration test, a scan finds known weaknesses quickly; a penetration test proves what an attacker can actually do. For small businesses, start with the scans your SAQ requires.

What documentation does PCI DSS require?

PCI DSS v4.0.1 specifies documentation requirements across multiple requirements. According to the standard, Requirement 12.5.1 covers inventory of system components, Requirement 12.8 covers third-party service provider management, and Requirement 12.10.1 covers incident response plans. Even for small merchants, you should be able to point to:

  • A list of cardholder data environment components (12.5.1): Know which systems, terminals, and applications handle card data.
  • Service provider agreements (12.8): Confirm that third parties (payment processors, hosting providers, POS vendors) are PCI-compliant and understand their responsibilities.
  • An incident response plan (12.10.1): Know what to do if you suspect a breach. Your plan should include who to notify, including your acquirer.

For small businesses, this does not need to be elaborate. A written information security program that covers your card environment and references your SAQ can satisfy most documentation needs. If you do experience a breach involving card data, notification obligations under state or provincial law apply separately from PCI DSS requirements.

What should Canadian and US business owners take from this?

PCI DSS is the same standard on both sides of the border because it is a contractual requirement from the card brands, not a local law. Whether you operate in Vancouver or Dallas, the requirements and SAQs are identical. The difference is in the privacy and breach notification laws that may also apply: PIPEDA's safeguards requirement in Canada, various state breach notification laws in the US.

A useful question to put to your payment processor or IT provider this week: "Which SAQ do we file, and does any card data touch our own systems or staff email?"

If the answer is unclear, that is the gap to close. Your processor should be able to confirm which SAQ applies to your integration. If you are unsure where your business stands on security controls beyond card payments, a free cybersecurity assessment can help identify which areas need attention. The assessment takes under 5 minutes, covers 22 security areas, and requires no signup.

This article is intended for general informational purposes only and does not constitute professional security, legal, or compliance advice. PCI DSS requirements are based on the standard and official PCI SSC guidance as of the date of publication and may change. Cyber Unit is not a QSA, ASV, or PCI-certified body. Organizations should consult their acquirer, payment processor, or a Qualified Security Assessor to determine their specific compliance obligations.