What merchants need to know about PCI compliance

What PCI DSS is, and who actually enforces it

PCI DSS is a set of security requirements for handling card data, published by the PCI Security Standards Council and enforced by Visa, Mastercard, American Express and Discover through their operating rules. It reaches your business through your merchant agreement and your acquirer, which is the bank or processor that holds your merchant account and answers to the card brands for it.

No government body enforces PCI DSS in Canada. It is a contractual standard, not a statute, and the consequence of ignoring it is contractual too: a monthly non-compliance fee, and, if card data is exposed while you are unvalidated, the costs the networks pass down through your acquirer. Privacy law is a separate obligation that runs alongside it. Federal privacy legislation can require you to report a breach of security safeguards to the Privacy Commissioner and to the people affected, on its own timeline, whether or not any card data was involved.

The standard binds every party that stores, processes or transmits cardholder data, plus anything whose systems could affect the security of that data. That covers the smallest single-location merchant as fully as the largest chain. What changes with size is how you prove compliance, not whether the rules apply to you.

The practical question is never whether PCI DSS applies. It is how much of it applies, and that depends entirely on where card numbers travel inside your business.

Merchant levels, and what puts you in one

Your merchant level is set by how many card transactions you run in a year on a given brand, and it decides how you validate rather than which rules apply to you. Every level follows the same standard. Only the proof differs.

Visa and Mastercard publish thresholds in the same shape. Level 1 covers merchants above roughly six million transactions a year on that brand. Level 2 covers one million to six million. Level 3 covers twenty thousand to one million e-commerce transactions. Level 4 covers everything below that, which is where most Canadian small and mid-sized businesses sit. American Express and Discover set their own thresholds, so a business can hold different levels on different brands at the same time.

Three things move a merchant up that nobody expects. Transaction counts are aggregated across locations under common ownership, so four stores are counted as one business rather than four. A card brand can designate any merchant Level 1 at its discretion. And a compromise is the most common reason for that designation, which means a breach can change your validation requirement permanently, on top of everything else it costs.

At Level 1, validation is an annual Report on Compliance produced by a Qualified Security Assessor or by a trained internal auditor, with quarterly external scanning alongside it. Below that, validation is a self-assessment questionnaire and a signed Attestation of Compliance. Some brands add conditions at Level 2 — a questionnaire signed off by a qualified assessor, or by staff who have completed the Council’s training. Your acquirer assigns your level and tells you what it expects, so confirm it there rather than inferring it from your volume.

Which SAQ your acceptance method puts you on

The self-assessment questionnaire you complete is decided by how card data moves through your business, not by your industry, your revenue or your card brand. There are several questionnaires, they differ enormously in length, and picking the wrong one is the most expensive mistake in this whole subject.

One eligibility rule cuts across all of them: every questionnaire except SAQ D requires that you do not store cardholder data electronically. A single spreadsheet of card numbers moves you to the long questionnaire no matter what the rest of your setup looks like.

SAQ A — card handling fully outsourced. Card-not-present acceptance where the customer enters the card on a page or field hosted by a validated provider and nothing reaches your servers. Hosted checkout, payment links and embedded fields that post the card straight to the provider all sit here. It is the shortest questionnaire, mostly concerned with the third parties you depend on and with confirming that the delegation is real.

SAQ A-EP — e-commerce that influences the payment page. Your servers still never receive the card, but your website controls how the payment form is delivered — a page that posts directly to the provider, or a checkout your own code assembles around a provider element. Because a compromised page can redirect a card, the questionnaire is far longer than SAQ A, and it covers the scripts your checkout loads.

SAQ B — standalone dial-out terminals or imprint machines, with no electronic storage of cardholder data. Short, and largely about physical control of the device.

SAQ B-IP — standalone approved terminals connected over IP, with no electronic storage of cardholder data. Slightly longer than SAQ B because the network connection is now in scope.

SAQ C-VT — card details keyed one at a time into a web-based virtual terminal on a dedicated, isolated computer, with no electronic storage. Practical for back-office and phone orders, but only if the machine really is isolated and nothing is written down.

SAQ C — a payment application connected to the internet, with no electronic storage of cardholder data. This is where many integrated point-of-sale setups land.

SAQ P2PE — hardware terminals that are part of a validated point-to-point encryption solution listed by the PCI Security Standards Council, with no electronic storage. The shortest of the card-present questionnaires, and the reason a validated P2PE deployment is worth asking about explicitly.

SAQ D — everything else, plus every merchant who stores cardholder data electronically. A custom checkout that relays the card through your own server, card numbers typed into a CRM, an order system that retains a PAN: all of it lands here. The full requirement set applies, with quarterly external scanning, and compliance stops being a form and becomes a programme.

Two questionnaires can look plausible for the same business, which is why the answer comes from a data-flow diagram rather than from a description of your industry. Your acquirer confirms which one it will accept, and a qualified security assessor confirms it where one is engaged. The distance between SAQ A and SAQ D is measured in months of work, so it is worth designing your flow deliberately rather than discovering it during an assessment.

What reducing scope means, and what actually reduces it

Scope is the set of systems, people and processes that store, process or transmit cardholder data, plus anything connected to them that could affect their security. Reducing scope means removing card data from places you control so there is less for the standard to attach to — and, in practice, fewer questions on your questionnaire.

Four technical choices genuinely reduce it. A hosted payment page or payment link moves card entry onto the provider’s domain. Embedded fields served from the provider inside an iframe keep your checkout in your own design while the card posts from the customer’s browser straight past your servers. Tokenization replaces a stored card number with a reference only the provider can resolve, so card-on-file stops being card data in your systems. And a validated point-to-point encryption terminal encrypts the card inside the reader, before your network ever sees it. Network segmentation is the fifth, and it is the one that matters when card data has to exist somewhere on your premises.

Several things that feel like security do nothing for scope. A TLS certificate encrypts a connection, which is required, but it does not decide who receives the card at the other end. A privacy policy is a disclosure, not a control. Your provider being a Level 1 service provider is evidence about their systems. Encrypting a spreadsheet of card numbers keeps you squarely on SAQ D, because the data is still there. A firewall on its own segments nothing unless the rules actually separate the card path from everything else.

The test is simple enough to run in a meeting. Draw where a card number enters your business, every system it touches, and where it stops. If the line passes through a server, a CRM, a call recording, an inbox or a piece of paper you control, that thing is in scope. If the line goes from the customer’s browser or the terminal’s reader directly to the provider, most of the standard has nothing in your environment to attach to.

The data you must never store

Sensitive authentication data can never be retained after a transaction is authorized, by anyone, in any form. The prohibition is absolute. Encrypting it does not make it permissible, and it applies equally to a database, a spreadsheet, a scanned form, a call recording and a notebook behind the counter.

Four items fall under it. Card verification values — the CVV, CVC or CID printed on the card. PINs and PIN blocks. Full magnetic-stripe track data after authorization. Full EMV chip data after authorization. There is no business case that overrides any of these, and no configuration in which keeping them is allowed.

The primary account number — the card number itself — is different: it may be stored where you have a genuine business need, but only rendered unreadable, and only displayed masked to the few people whose work requires it. In almost every case the better answer is not to store it at all. Keep a token instead. A token is a reference only your provider can resolve back to the credential, it is useless anywhere else, and holding tokens rather than card numbers is precisely what keeps stored payment methods out of your assessment.

Prohibited data usually arrives by accident rather than by decision. A call recording captures a customer reading out a CVV. A support ticket contains a screenshot of a full card number. An order note records a card so the team can charge it again next week. A scanned authorization form sits in a shared drive. None of these were anyone’s policy, and all of them are storage.

What changes your scope without anyone noticing

Scope almost never grows because a business decided to start handling card data. It grows through ordinary operational choices that nobody flags as a payments decision, and the merchant usually finds out months later.

A new plugin on the storefront is the most common one. A checkout extension, an analytics tag or a chat widget added to the payment page can change how the payment form is delivered and move an SAQ A merchant onto SAQ A-EP without a single line of your own code changing. Anything that loads a script on the page where a card is entered belongs on the list of things you review before installing.

A call centre is the second. The day someone starts taking card numbers by phone and typing them into an order system, a ticket or a CRM, that system holds cardholder data and your questionnaire changes. The same applies to a spreadsheet built to track deposits, an email thread where a customer sent a card number and nobody deleted it, and a staff member forwarding a full PAN to a colleague to process later.

Two quieter ones are worth a calendar reminder. Integrations, plugins, point-of-sale applications and terminal firmware drift onto unsupported versions, and an unsupported version is a control failure whether or not anything has gone wrong. And a new channel — a second storefront, a mobile app, a marketplace, a franchise location, a phone-order process added over a busy season — arrives without anyone asking where card data goes inside it.

If any of that describes how your business now operates, reassess which questionnaire applies immediately rather than waiting for your renewal date. A merchant validated on SAQ A while operating on an SAQ D flow is not partially validated. They are not validated at all, and that is the state in which a breach is most expensive.

Annual re-validation and quarterly scanning

PCI DSS validation is annual and does not carry forward. You complete the questionnaire again each year, sign a fresh Attestation of Compliance, and do it against the version of the standard in force at that time, because the standard is revised periodically and requirements move between revisions.

Where your questionnaire includes the external scanning requirement — SAQ A-EP, B-IP, C and D among them — you also run quarterly external vulnerability scans through an Approved Scanning Vendor and hold passing results across the year, not just one clean scan at renewal. SAQ D adds internal scanning and penetration testing on top. SAQ A, at the other end, has no scanning requirement at all, which is a large part of why keeping card entry off your systems is worth the design effort.

Re-validate out of cycle whenever your acceptance changes. A new checkout, a new sales channel, a phone-order process, a POS migration or a plugin on the payment page can each change which questionnaire applies well before your anniversary date. Validating against how you took payments last year is a common and entirely avoidable failure.

Keep the evidence where someone other than you can find it: the completed questionnaire, the signed attestation, scan reports, the date of your last staff training and the list of who has access to what. Your acquirer decides what it collects and how, and a portal that asks you to confirm compliance is recording your attestation, not performing your assessment.

What your provider’s compliance does and does not do for you

A provider’s PCI DSS validation is evidence about the provider’s systems and nothing else. No service provider’s compliance transfers to a merchant: under the card network rules, each merchant validates its own compliance, for its own environment, every year. A provider that tells you its certification makes you compliant is describing something the rules do not permit.

What a validated provider does change is architecture, and that is worth a great deal. RapidCents is validated as a PCI DSS Level 1 service provider, covering the RapidCents processing environment — the gateway, hosted checkout, payment links, Rapid.js, tokenization and the secure card vault, the merchant dashboard and virtual terminal, and the infrastructure behind them. Because card data is captured on a RapidCents-controlled surface and returned to your systems as a token, most of the standard’s technical requirements have nothing in your environment to attach to. That is what keeps a typical merchant on a short questionnaire.

The rest stays with you in every configuration: who has access to your dashboard, systems and terminals and how that access is removed; how staff handle card numbers taken by phone, by mail order or across a counter; the security of the networks, servers, endpoints and devices you control; the versions your integration, plugins and terminal software run; your internal authorization of refunds and of charges against stored payment methods; and the annual questionnaire and attestation themselves.

One more thing to be clear about. It is common industry practice to charge a monthly PCI non-compliance fee to merchants who have not completed and recorded their annual validation. The fee is not a payment for compliance and does not satisfy the standard. A merchant who pays it every month and never validates carries the full liability of a non-compliant merchant in a breach. Completing the questionnaire and recording it against your account is what removes the fee, and is the only part that actually addresses the requirement.

Where to start if none of this has been done

Start with a data-flow diagram, not with a questionnaire. Write down every way a customer can pay you — the storefront, the terminal, the phone, the invoice, the recurring charge, the one-off link someone sends from their laptop — and for each, where the card number goes and where it stops. Most businesses find at least one path nobody had accounted for.

Then decide the flow you want before you fill in anything. If a path puts card data on your systems and there is a way to move it off — a hosted page instead of a form you built, a token instead of a stored number, a validated terminal instead of keying into a computer — change the path first. Choosing the questionnaire before fixing the flow means committing to answer the long one for another year.

Only then pick the questionnaire, confirm it with your acquirer, and work the gaps it exposes. Give each gap an owner and a date. Train the people who touch cards on the one rule that prevents most incidents: a card number never gets written down, emailed, messaged or read into a recording.

Finally, write down what you would do in the first hour if you suspected a compromise, and keep it somewhere findable. Preserve evidence rather than rebuilding, contain rather than erase, notify your provider within the window your agreement sets, and remember that privacy law may impose its own reporting duty on its own clock. The hour you spend writing that page is the cheapest hour in this entire subject.