PCI DSS 4.0.1 for Small Businesses That Accept Cards

A clothing boutique on Saint-Laurent Boulevard. An Ottawa coffee roaster that sells beans online. An auto repair shop in Kingston that takes deposits over the phone. All three signed a merchant agreement, and somewhere in that contract is a clause requiring them to comply with PCI DSS.

Then one day an email from the acquirer shows up: “Please complete your annual self-assessment questionnaire.” With some providers, a monthly fee appears on the statement until that validation is done.

The good news: for most small businesses, PCI DSS compliance is far simpler than it looks. It all depends on how you take cards.

What PCI DSS is, and who enforces it

PCI DSS (Payment Card Industry Data Security Standard) is published by the PCI Security Standards Council, a body founded by the major card brands: Visa, Mastercard, American Express, Discover and JCB. It applies to any business that stores, processes or transmits cardholder data.

That data includes the card number (the PAN), the cardholder’s name and the expiry date. Sensitive authentication data, such as the security code or the PIN, must never be kept after authorization, even encrypted.

The obligation flows through contracts. The card brands impose the standard on acquirers (the bank or processor that opened your merchant account), and acquirers impose it on merchants. Your acquirer therefore sets your merchant level, based on transaction volume, and decides how you prove compliance. Small merchants almost always land in the lowest level, where an SAQ is usually enough.

What changed with version 4.0.1

Version 4.0.1, published in June 2024, is a limited revision: it clarifies wording without adding or removing requirements. Version 4.0 was retired on December 31, 2024, and the future-dated requirements became mandatory on March 31, 2025. In June 2026, the Council opened a request for comments on the next version; until that version is published, 4.0.1 remains the standard.

These are the requirements small businesses run into most often:

SAQ A, the questionnaire for online stores that fully outsource payment to a provider, was revised in January 2025. Requirements 6.4.3 and 11.6.1 were removed from it and replaced with an eligibility criterion: you must confirm your site is not susceptible to script attacks that could affect your e-commerce system. This mainly concerns sites that embed a payment form in their own pages, for example through an iframe.

Which SAQ should you complete?

The right SAQ depends on how you accept cards. The exact criteria are at the start of each questionnaire, and your acquirer has the final say. As a rough guide:

A craft brewery in the Eastern Townships that sells at the counter, online and by phone has to declare all three channels. Depending on the acquirer, that can mean more than one questionnaire, or SAQ D, plus the attestation of compliance (AOC). For the broader picture, see our article on retail and e-commerce cybersecurity.

Shrink your scope: the cheapest compliance strategy

Every system that sees a card number falls into the scope of the standard. The fewer there are, the shorter your questionnaire.

• Never store card numbers. For recurring billing, use your provider’s tokenization: you keep a token, not the number.
• Let a compliant provider host the payment page. Ask for its attestation of compliance and keep it on file.
• Isolate your terminals. The payment terminal should not share the guest Wi-Fi or the office workstation network.
• Ban paper and email. No card numbers on a notepad by the phone, and none sent by chat.
• Consider a P2PE solution next time you replace terminals: it sharply reduces the requirements at the counter.

Example: a Gatineau catering company kept card numbers for corporate events in a spreadsheet. By switching to its provider’s payment links, it took the spreadsheet, the front desk computer and the shared inbox out of scope.

Online stores: scripts, headers and testing

Web skimming attacks inject a malicious script into the payment page to copy card numbers as customers type them. That is exactly what requirements 6.4.3 and 11.6.1 target.

A few concrete measures:

• Keep a list of the scripts loaded on your payment pages and the pages leading to them, with a reason for each.
• Remove unused plugins and widgets from your e-commerce platform.
• Add security headers, including a Content Security Policy (CSP) that restricts where scripts can load from. Our security headers checker shows where you stand in seconds.
• Protect your site’s admin panel with multi-factor authentication.

Depending on your questionnaire, PCI DSS may also require quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) and, for more complex environments, penetration tests. A penetration test always requires the business’s written authorization: without it, accessing a computer system can be an offence under the Criminal Code (s. 342.1).

The merchant’s annual checklist

• Confirm your merchant level and expected SAQ with your acquirer
• List every channel where cards come in: counter, phone, website, email
• Get the attestation of compliance from each payment and point-of-sale provider
• Turn on multi-factor authentication for payment portals and your site’s admin (which method to choose)
• Require passwords of at least 12 characters
• Change default passwords on terminals, routers and point-of-sale systems
• Inspect terminals periodically for tampering or substitution
• Train staff to spot phishing and fake technicians
• Include notifying your acquirer in your incident response plan
• Complete the SAQ and attestation, and submit them before the deadline

This guide explains the standard in plain language and does not replace the Council’s official documents or legal advice: validate your contractual obligations with your acquirer and your legal counsel, especially after an incident.