Which PCI DSS SAQ Do You Need?

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.

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.

Merchant Level and SAQ Type Are Two Different Questions

Teams collapse these into one and then argue about the wrong variable. Your merchant level is set by annual transaction volume as defined by each card brand, and it decides whether you may self-assess at all. Visa's tiers run from Level 1 at more than six million transactions a year down to Level 4 for the smallest merchants, with Level 1 merchants generally required to produce a Report on Compliance signed by a QSA or a qualified internal assessor rather than any SAQ. Your SAQ type, if you are eligible to self-assess, is decided entirely by payment architecture.

So volume determines whether you get a questionnaire, and architecture determines which one. A Level 4 merchant with a homegrown card form is on SAQ D despite tiny volume. A Level 2 merchant with a true hosted redirect may still be on SAQ A. The two answers move independently, and the only party who can confirm both for you is your acquiring bank, because they are the entity that actually receives your attestation and they can impose stricter requirements than the card brand baseline.

Service providers have their own tiering, and this is where B2B SaaS companies get caught. If you store, process or transmit cardholder data on behalf of your customers, or if you could affect the security of their cardholder data environment, you are a service provider regardless of how you describe yourself commercially. Service providers self-assessing use SAQ D-SP, which is a different document from the merchant SAQ D, and above the Council's volume threshold they need a Report on Compliance instead. A company that has been sending customers a merchant SAQ D for years, when it should have been producing D-SP, will eventually meet a procurement team that knows the difference.

The Eligibility Criteria Are the Part People Skip

Every SAQ opens with a short list of eligibility statements, and you are attesting that all of them are true. This is the most consequential page in the document and the one most often skimmed. If a single criterion does not hold, you are not eligible for that SAQ, and completing it anyway produces an attestation that is void in exactly the moment it matters, which is when a customer's security team or your acquirer reads it during an investigation.

SAQ A is the sharpest example because its criteria have moved. The Council revised SAQ A in early 2025, removing the two payment page script requirements that had been added under version 4.0 and replacing them with an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect the payment page. That is a lighter compliance burden and a heavier attestation. You are no longer implementing a control and evidencing it, you are asserting a property of your own site. Before you sign that, someone should actually look at what third-party JavaScript loads on the page hosting your payment iframe, because tag managers, analytics, session replay tools and chat widgets all execute in that context.

Version numbers matter here in a way they do not for most frameworks. Pull the current SAQ from the Council's document library rather than reusing last year's PDF, and read the eligibility page before you read anything else. The requirement set changes between versions, and so do the criteria that decide which set applies to you.

What Else the SAQ Drags In

Quarterly ASV scans. Any SAQ covering internet-facing systems in scope, which means A-EP, B-IP, C and D, requires quarterly external vulnerability scans by an Approved Scanning Vendor, with passing results. SAQ A does not. Teams that budget for the annual work and not the quarterly cadence discover in month ten that they need four passing scans and have one.

Annual penetration testing and segmentation testing. Requirement 11.4 calls for internal and external penetration testing on an annual basis, plus testing to confirm that segmentation actually isolates the cardholder data environment. Merchants relying on segmentation test it annually; service providers test it every six months. If you claimed scope reduction through segmentation, this is the test that proves the claim, and a test scoped against the wrong network boundary invalidates the reduction rather than confirming it. Our testing work is scoped against the declared boundary for exactly this reason, and published pricing starts at $1,000 so the test is not the line item that gets dropped.

The attestation itself. The AOC is signed by an executive officer, and it is a representation to your acquirer. It is not an internal document. Whoever signs should have been briefed on what was assessed, what was excluded and why, and what remains open.

Where Cardholder Data Turns Up After You Thought You Removed It

Scope reduction on paper is undone by ordinary operational behaviour, and these are the leaks we find most often when we walk a payment environment.

Support tickets are the biggest one. A customer pastes a full card number into a chat or an email because their payment failed, and now the primary account number sits in your help desk platform, your email archive, your search index and your backups. The control is not training alone. It is detection and automated redaction at ingest, plus a documented purge process, because customers will keep doing it regardless of what you tell them.

Call recordings are the second. If your support team takes payments by phone and the call is recorded, the recording contains card data unless the system pauses recording during entry. Many teams enable recording for quality purposes years after the payment process was designed and never connect the two.

Then there are logs. An application that logs full request bodies on error will capture the card number on exactly the transactions that fail, which is a small percentage of a large number. Check what your error tracking service receives, not just what your application writes to disk. Screenshots attached to bug reports are the same problem in a different container.

The last one is legacy storage. Old order tables with a truncated PAN column that turns out not to be truncated in rows written before 2019, database exports sitting in an analytics warehouse, and CSV files in shared drives from a migration nobody finished. Any of these puts you back in SAQ D territory no matter how clean the current checkout flow is, which is why scope work should start with a search for card data rather than a diagram of the intended flow.

When Not to Hire Anyone for This

If you are a small merchant with a genuine hosted redirect, no card data anywhere in your systems, and an acquirer asking for SAQ A, complete it yourself. It is a short document, the eligibility criteria are readable, and paying a consultant to fill in a form you can fill in is not a good use of the budget. Spend an hour auditing the scripts on your payment page instead, which is the part that actually carries risk.

If your processor offers a compliance portal with the questionnaire built in and your flow is simple, use it. Those tools are adequate for uncomplicated SAQ A and B situations, and they are usually included in what you already pay.

Outside help earns its cost in three situations. When you are not certain which SAQ applies and the answer changes the engineering plan, because a scoping error is expensive in rework rather than in fees. When you are a service provider facing customers who will read the attestation carefully, where D-SP versus D and the segmentation evidence are the things that get challenged. And when scope reduction is achievable but requires architectural change, where the value is in the engineering decision rather than in the paperwork that follows it. If none of those describe you, the honest recommendation is to complete the questionnaire yourself and spend the money on the things it asks you to have. If one of them does, our PCI DSS work for SaaS starts with scope rather than with a questionnaire, and you can describe your payment flow and get a straight answer on which document you owe.