PCI DSS compliance for Canadian businesses
If your business takes card payments, PCI DSS applies to you. It is not Canadian law and no regulator enforces it; it is a condition of your merchant agreement, enforced by the bank or processor that gives you the ability to accept cards. This page covers what it actually requires, which self-assessment questionnaire you are likely on, and the one decision that determines whether compliance is an afternoon or a project.
What is PCI DSS?
PCI DSS is the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council on behalf of the card brands. It sets out security requirements for any organisation that stores, processes or transmits cardholder data. Compliance is contractual rather than legal in Canada: you agreed to it when you signed with your acquirer, and the consequences for ignoring it are fees, higher transaction rates, and liability if card data is stolen through you.
Anyone who touches card data.
A restaurant with a terminal, a shop with an online store, a rental business taking deposits over the phone. Size does not exempt you. What changes with size is how you demonstrate compliance, not whether you have to.
Your acquirer, not the government.
The bank or payment processor that provides your merchant account sets your deadlines and validation requirements. They are the correct first phone call, and their answer overrides any general guidance including this page.
Fees now, liability later.
Non-compliance fees and higher per-transaction rates are the routine cost. The serious one arrives after a breach, when the forensic investigation and the card-brand assessments land on the merchant that was out of scope on paper and in scope in reality.
Shrink the scope before you do anything else
Almost every expensive PCI project we have seen was expensive because nobody asked the scoping question first. PCI DSS applies to the systems that store, process or transmit cardholder data, plus anything connected to them. The cheapest compliance programme is the one with the smallest number of systems inside that boundary.
Stop storing card numbers. All of them.
Card numbers in a spreadsheet, in a CRM note, on a paper form in a drawer, in a recorded phone call. Each one drags that system into scope. Removing stored card data is the single largest scope reduction available and it usually costs nothing but discipline.
Let the processor handle the card.
A hosted payment page or an iframe from your processor means the card number never touches your website or your network. That difference moves an ecommerce business between very different questionnaires and workloads.
Separate the payment network.
Card terminals on their own VLAN, not sharing a flat network with guest wifi and the back office. Segmentation is what stops the rest of your business being in scope, and it is ordinary network work. See network segmentation.
Prefer P2PE and modern terminals.
Point-to-point encryption encrypts the card at the reader, so your environment never sees usable data. It carries its own validated questionnaire and is generally the least demanding route for a business with physical terminals.
The honest summary: the work is mostly deciding not to hold card data, not buying security products. A provider whose first suggestion is a tool rather than a scoping conversation is selling before diagnosing.
Which self-assessment questionnaire applies to you
Most Canadian small businesses validate with a self-assessment questionnaire rather than an external audit. Which SAQ you complete depends entirely on how you take payment, and the difference in length between them is large. Your acquirer confirms which one you are on.
| SAQ | Typical situation | Relative effort |
|---|---|---|
| A | Ecommerce or mail order where payment is fully outsourced to a hosted page or iframe. You never see the card. | Shortest by a wide margin |
| A-EP | Ecommerce where your site does not receive card data but does control how the payment page is delivered. | Substantially longer than A |
| B | Standalone terminals with no electronic cardholder data storage, dial-out or imprint machines. | Short |
| B-IP | Standalone, PTS-approved terminals connected over IP, no electronic storage. | Short to moderate |
| C | Payment application connected to the internet, no electronic cardholder data storage. | Moderate |
| P2PE | Terminals on a validated point-to-point encryption solution. | Among the shortest |
| D | Everything else, including any merchant that stores cardholder data. | By far the longest |
The gap between SAQ A and SAQ D is the difference between a short annual form and a security programme. That gap is decided by architecture, which is why the scoping section above comes before this one.
What compliance actually asks you to have in place
Stripped of the numbering, the requirements are the controls a competent IT setup should have anyway. That is worth knowing, because it means PCI work is rarely wasted even if you later change how you take payment.
A firewall, segmentation, and no default passwords.
Documented rules rather than whatever the installer left, the payment network separated from everything else, and vendor defaults changed on every device including the terminals and the access points.
Do not keep it, and encrypt what you must transmit.
No storage of the full card number unless you genuinely cannot avoid it, never the security code, and TLS on anything crossing a public network. Most merchants can satisfy this by removing storage entirely.
Unique logins, least privilege, MFA.
Named accounts rather than a shared one everyone knows, access limited to people whose job needs it, and multi-factor authentication on remote and administrative access. See MFA and identity.
Logs that exist, and someone reading them.
Logging on the systems in scope, retained, and reviewed. This is where a managed SOC does the work, because logs nobody reads satisfy the letter and none of the intent.
Vulnerability scans, and testing where required.
Some questionnaires require quarterly external scans by an Approved Scanning Vendor, and some require penetration testing. Which apply to you depends on your SAQ, so establish that first rather than buying testing you may not need.
A written policy and annual training.
An information security policy that exists as a document, and staff who have been trained on handling card data. Unglamorous, routinely skipped, and the first thing asked for after an incident.
Go to the source rather than to a vendor page, including this one: the PCI Security Standards Council publishes the standard, every SAQ and the current version history at pcisecuritystandards.org. The standard is revised periodically, so check the current version and your validation deadline with your acquirer rather than relying on any summary.
What North Star does, and what we do not
Being clear about this saves everyone time, because the PCI market is full of providers implying more than they hold.
The technical work behind the questionnaire.
Network segmentation, firewall configuration and documentation, MFA rollout, logging and monitoring, patching, and finding where card data is sitting in systems nobody thought about.
Help you answer it honestly.
Working through the questionnaire with you, identifying which answers are currently a no, and quoting the work to make them a yes. The same service we provide for customer security questionnaires and insurance renewals.
Sign off as a QSA.
North Star is not a Qualified Security Assessor and does not perform ASV scans. Where your level or your acquirer requires either, you need a qualified firm and we will say so and work alongside them.
Sectors where this comes up most in our work are retail, hospitality and equipment rental, all of which take cards in more than one way and tend to have card data in more places than expected.
Find out how much of this actually applies to you
Most merchants are on a shorter questionnaire than they fear, and the ones who are not usually have card data somewhere they forgot. The free assessment finds both, in writing, within a business day.
Start the free assessment Back to ComplianceFrequently asked questions
Is PCI compliance a legal requirement in Canada?
No. PCI DSS is not Canadian law and no government regulator enforces it. It is a contractual obligation you accepted when you signed your merchant agreement, and it is enforced by the acquirer or payment processor that lets you accept cards. In practice that distinction matters less than it sounds: non-compliance brings fees and higher transaction rates, and after a breach it brings liability. Separately, Canadian privacy law does apply to the personal information involved, so PIPEDA obligations sit alongside PCI rather than instead of it.
Which PCI SAQ do we need to complete?
It depends entirely on how you take payment, and your acquirer confirms it rather than you choosing. Ecommerce that fully outsources payment to a hosted page or iframe is usually SAQ A, the shortest. Standalone terminals with no electronic storage are usually SAQ B or B-IP. A payment application connected to the internet is usually SAQ C. Validated point-to-point encryption has its own short questionnaire. Anything that stores cardholder data falls to SAQ D, which is by far the longest. The gap between A and D is the difference between a short annual form and a security programme.
How do we reduce PCI scope?
Four things, in order of impact. Stop storing card numbers anywhere, including spreadsheets, CRM notes, paper forms and recorded calls, because each of those drags a system into scope. Use a hosted payment page or iframe so the card never touches your website or network. Put payment terminals on their own network segment rather than a flat network shared with guest wifi and the back office. And prefer terminals on a validated point-to-point encryption solution, which encrypts the card at the reader so your environment never sees usable data. Scope reduction is almost always cheaper than compliance work on a large scope.
Do we need a penetration test for PCI?
It depends on your questionnaire. Some SAQ types require quarterly external vulnerability scanning by an Approved Scanning Vendor, and some require penetration testing, while the shortest questionnaires require neither. This is a good reason to establish which SAQ applies before buying any testing, because merchants routinely purchase testing their validation type does not ask for. North Star provides penetration testing from $2,500 but is not an Approved Scanning Vendor, so where ASV scanning is required you need a qualified firm for that part.
Can North Star make us PCI compliant?
We can do the technical work and help you answer the questionnaire honestly, which for most small merchants is the substance of it: network segmentation, firewall configuration and documentation, multi-factor authentication, logging and monitoring, patching, and finding card data sitting in systems nobody remembered. What we cannot do is sign off. North Star is not a Qualified Security Assessor and does not perform ASV scans, so where your level or your acquirer requires either, you need a qualified firm and we will tell you so and work alongside them.
We only take a few cards a year. Does PCI still apply?
Yes. There is no volume floor that exempts a merchant from PCI DSS. What changes with transaction volume is your merchant level and therefore how you validate, not whether the requirements apply. A very small merchant taking payments through a hosted page may find validation is a short annual self-assessment questionnaire, which is a modest obligation. The risk for small merchants is usually not the paperwork but the card numbers written on order forms or kept in an inbox, which quietly puts them on a much longer questionnaire than they think.