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 scoping decisions that usually determine how much work is in front of you.
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 payment brands or acquirer set the contractual consequences of non-compliance. A breach can add investigation and operational work, with exact exposure depending on the agreement and incident.
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.
Contractual cost and incident exposure.
Your acquirer or payment brands set the consequences for missed validation, which may include fees or changed terms. A breach can also create investigation, notification, legal, and operational work; the exact exposure depends on the agreement and incident.
Shrink the scope before you do anything else
A PCI project becomes more complex when the scoping question is skipped. PCI DSS applies to the systems that store, process or transmit cardholder data, plus anything connected to them. Reducing the environment in scope can reduce the work required, subject to the applicable standard and validation method.
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 may bring that system into scope, so confirm the boundary with your acquirer. 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 can help limit which systems are in scope, but the boundary depends on the implemented controls and validation method. See network segmentation.
Prefer P2PE and modern terminals.
A validated point-to-point encryption solution can reduce the cardholder-data exposure of eligible terminals. The applicable questionnaire and eligibility criteria come from the current PCI SSC materials and your acquirer; do not self-select based on this summary.
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
Many small businesses use a self-assessment questionnaire, but whether validation is required, and which SAQ is appropriate, depends on the payment environment and the compliance-accepting entity. Your acquirer confirms the applicable path.
| 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-HW | Eligible 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 effort difference between SAQ A and SAQ D can be material; the applicable questionnaire depends on the payment flow and environment. 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. Removing unnecessary storage can reduce the environment in scope, but confirm the result with the acquirer and current SAQ guidance.
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 and SAQs are revised periodically. Review the current version and validation deadline with your acquirer rather than relying on any summary. See the PCI SSC FAQ on SAQs and its current SAQ eligibility guidance.
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
Share how payments are taken, where cardholder data may go, which systems connect to the payment flow, and any deadline or questionnaire your acquirer supplied. The assessment maps the known scope and practical next steps for review.
Start the free assessment Back to ComplianceFrequently asked questions
Is PCI compliance a legal requirement in Canada?
PCI DSS is a private industry standard, not a Canadian statute. The payment brands, acquirer or other compliance-accepting entity determine applicable validation and contractual requirements. Canadian privacy obligations can apply separately to personal information, so PIPEDA and provincial privacy law may sit alongside PCI DSS; confirm the legal position for your business with qualified counsel.
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. Eligible point-to-point encryption hardware may use SAQ P2PE-HW. 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?
Start by mapping where cardholder data is stored, processed, or transmitted, including spreadsheets, CRM notes, paper forms, recordings, payment pages, terminals, and connected systems. Remove unnecessary storage where practical, use a hosted payment flow where appropriate, and separate payment terminals from general business traffic. A validated point-to-point encryption solution may further limit exposure. Confirm the resulting scope and questionnaire with your acquirer; reducing scope is not the same as proving compliance.
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.