You need the SAQ that matches how you actually handle cardholder data: SAQ A for fully outsourced e-commerce, SAQ A-EP for redirect/iframe setups where your server still touches the payment page, SAQ B or B-IP for standalone terminals, SAQ C for a connected POS application, SAQ C-VT for manual virtual terminal entry, SAQ P2PE for validated point-to-point encryption, and SAQ D for everyone else, including all service providers. The right answer depends on your payment flow, not your company size.
Why the SAQ Question Trips Up So Many Canadian SaaS Teams
Self-Assessment Questionnaires exist because not every merchant needs a full Report on Compliance. Visa, Mastercard, and the other card brands let lower-risk merchants attest to a subset of PCI DSS controls instead of undergoing a full audit. The trouble is that "lower-risk" is defined by exact technical criteria, and most founders and engineering leads guess based on transaction volume instead of architecture. That guess is usually wrong, and it either leaves gaps an acquiring bank will flag later or forces a company to answer questions about infrastructure it does not even touch.
We see this constantly with Toronto, Waterloo, and Vancouver SaaS companies selling into the US and Canadian enterprise market. A product team assumes that because Stripe or another processor "handles PCI," they qualify for the shortest questionnaire. Sometimes that is true. Often it is not, because the way checkout is built, whether it is a hosted redirect, an embedded iframe, or a custom form posting to the processor, determines the SAQ type, not the vendor name on the invoice.
The SAQ Types, Explained by Payment Flow
SAQ A: Fully Outsourced E-commerce
This is the shortest questionnaire, built for merchants who redirect customers entirely to a third-party payment page or use an iframe where the merchant's own web server never receives, transmits, or stores cardholder data and has no control over how the payment page is delivered. If your checkout is a true redirect or a properly isolated iframe with no script on your page that could alter the payment fields, SAQ A is likely your fit.
SAQ A-EP: Partially Outsourced E-commerce
This applies when your website controls how the payment page is delivered to the browser, for example an iframe embedded via JavaScript you host, even though the actual card data still goes straight to the payment processor. A-EP has significantly more requirements than SAQ A because your own infrastructure is now part of the attack surface, even without directly touching card numbers.
SAQ B and B-IP: Standalone Terminals
These cover merchants using standalone, dial-out payment terminals or IP-connected terminals that are not connected to any other system in the environment. Rare for SaaS companies, common for retail and hospitality.
SAQ C: POS Systems Connected to the Internet
For merchants with a payment application system connected to the internet where the environment has some segmentation from other systems. If you run an integrated point-of-sale platform, this is typically your bucket.
SAQ C-VT: Virtual Terminals
Manual, keyed-in entry through a virtual terminal on an isolated computer with no other electronic cardholder data storage. Common for support teams that take card numbers over the phone.
SAQ P2PE: Validated Point-to-Point Encryption
For merchants using a PCI-listed P2PE solution end to end, which dramatically reduces the number of applicable requirements because the encryption removes the merchant's systems from the cardholder data environment almost entirely.
SAQ D: Everyone Else
SAQ D is the full questionnaire, mapped closely to the complete PCI DSS requirement set. It applies to merchants who do not qualify for any of the above, and it applies to all service providers eligible to self-assess. If you store cardholder data, process it directly, or run a custom payment integration that does not fit the outsourced models, expect SAQ D. This is also the version most B2B SaaS companies with any homegrown billing logic end up needing, which is exactly why scope reduction matters so much before you pick a questionnaire.
Scope Reduction Should Come Before You Pick an SAQ
The single biggest lever on which SAQ you qualify for is architecture, not paperwork. Before locking in a questionnaire, it is worth asking whether the cardholder data environment can be shrunk. Moving from a self-hosted card form to a hosted redirect or tokenized iframe can drop a company from SAQ D or A-EP down to SAQ A. Removing the ability for support staff to view or key in full card numbers can eliminate an entire category of requirements. Segmenting the systems that touch payment data from the rest of the network narrows what an assessor, or a self-assessment, has to cover at all.
This is the order we walk clients through, and it is the same order covered in our PCI DSS compliance guide for SaaS companies: reduce scope first, then determine the correct SAQ, then build the control set around what remains in scope. Doing it in the reverse order, picking an SAQ and then trying to satisfy every control, almost always costs more in engineering time and creates a larger attack surface than it needed to.
What Happens After You Identify the Right SAQ
Selecting the SAQ is the easy part. The harder part is proving every applicable control is actually in place, which is where most self-assessments stall. Two things tend to catch teams off guard:
- Readiness gaps. Access control, encryption in transit and at rest, logging and monitoring, vendor management, and vulnerability management requirements apply even under the shorter SAQs. A readiness assessment before you sign the attestation catches gaps while they are still cheap to fix.
- Required penetration testing. Several SAQ types, including SAQ D and any environment with a public-facing payment application, require an annual penetration test against the cardholder data environment and, for larger merchant levels, segmentation testing to confirm out-of-scope systems are genuinely isolated. This is not optional evidence collection, it is a hard requirement, and it needs to be scoped correctly or the test itself becomes invalid for attestation purposes.
Acquiring banks and payment processors increasingly ask for evidence, not just a signed form, particularly once a SaaS company starts selling to enterprise customers who run their own vendor risk reviews. Getting the SAQ type right the first time avoids a second round of scoping conversations six months later when a bigger customer's security team asks for your attestation and your penetration test report side by side.
Where Canadian Companies Add a Layer of Complexity
PCI DSS is a card brand requirement, not a law, but Canadian SaaS companies rarely deal with card data in isolation. PIPEDA governs how personal information tied to those transactions is handled, and companies serving Quebec customers also need to account for Law 25's consent and breach notification rules. If your board or enterprise customers are also asking about CPCSC alignment, the scope reduction work for PCI DSS often overlaps directly with the data minimization work CPCSC expects, so it is worth tackling them together rather than as separate projects.
We work with companies across Toronto, Ottawa, Calgary, and Montreal building out both motions at once, because a payment architecture built to reduce PCI DSS scope is usually also the architecture that makes a broader security program easier to defend to enterprise buyers.
Getting the SAQ Decision Right the First Time
The cost of guessing wrong on your SAQ type is not the questionnaire itself, it is the engineering rework and the delayed enterprise deal when a customer's security review catches the mismatch. If you are not certain which SAQ applies to your payment flow, or you suspect your architecture could qualify for a shorter one with some changes, that is exactly the conversation worth having before your next attestation cycle. Our compliance readiness services cover the scoping, the gap assessment, and coordination of the required penetration test in one engagement instead of three separate vendors.
Talk to traztech about your PCI DSS scope and SAQ selection at /contact.