Do You Actually Need PCI DSS?

You need PCI DSS if your business stores, processes, or transmits cardholder data, full stop. If you route payments entirely through a compliant third party like Stripe or Shopify Payments and never touch card numbers directly, you likely only need a short Self-Assessment Questionnaire (SAQ), not the full standard. The confusion isn't about whether PCI DSS applies. It's about how much of it applies to you, and a lot of Canadian SaaS and e-commerce companies are buying far more compliance than their card-data footprint requires.

What PCI DSS Actually Regulates

PCI DSS (Payment Card Industry Data Security Standard) is a contractual requirement from the card brands (Visa, Mastercard, Amex, Discover) enforced through your acquiring bank or payment processor, not a government law. It applies the moment your systems store, process, or transmit primary account numbers (PANs), regardless of company size or country. There's no small-business exemption and no PIPEDA-style threshold. If a card number touches your infrastructure, PCI DSS is in scope.

That said, "in scope" and "full Level 1 assessment" are very different things. The standard has four merchant levels based on annual transaction volume, and most Canadian startups and mid-market SaaS companies land in Level 3 or Level 4, which qualify for self-assessment rather than a formal audit by a Qualified Security Assessor (QSA).

Who Genuinely Needs Full PCI DSS Compliance

Full-scope PCI DSS work is warranted when you:

• Build your own checkout or payment page that captures raw card numbers before sending them anywhere
• Store cardholder data in your own database, even temporarily, for retries or reconciliation
• Operate as a payment facilitator, gateway, or processor for other merchants
• Process over 6 million transactions a year (Level 1, mandatory QSA audit)
• Have had a prior card-data breach (the brands can force you into Level 1 regardless of volume)

Fintech companies, payment platforms, and marketplaces that hold funds or route card data on behalf of third parties fall squarely here. If that's your business model, treat PCI DSS as a real engineering and governance program, not paperwork.

Who Is Over-Buying PCI DSS Compliance

We regularly see Canadian SaaS founders quoted for a full PCI DSS program when their actual card-data exposure is close to zero. The pattern is almost always the same: they use Stripe Checkout, Stripe Billing, or a similar hosted payment page, meaning card numbers never hit their servers. In that setup, the correct scope is usually SAQ A, the shortest self-assessment questionnaire, covering roughly 20 to 25 controls rather than the 300-plus requirements in a full Report on Compliance.

Vendors selling generic compliance platforms often push clients toward broader scope than necessary because it's easier to sell one tier than to correctly scope each customer. This is where an outside opinion earns its cost. Our approach on PCI DSS compliance for SaaS companies starts with a scoping exercise before anything else, because the fastest, cheapest, most defensible path to compliance is architectural: reduce what touches card data, then certify what's left.

Scope Reduction Comes Before Any Assessment

The single biggest lever in PCI DSS is scope reduction, and it's the step most vendors skip because it shrinks the engagement. Before writing a single policy document, we look at:

• Whether card capture can move entirely to a hosted payment page or iframe (Stripe Elements, Braintree Hosted Fields) so raw PANs never enter your environment
• Whether tokenization can replace any internal storage of card numbers for recurring billing
• Network segmentation, so the cardholder data environment (CDE) is isolated from the rest of your infrastructure and doesn't drag your entire AWS account into scope
• Whether third-party logging, analytics, or support tools are inadvertently capturing card data through session replay or form logging

Get scope reduction right and a company that thought it needed a full QSA audit often ends up eligible for SAQ A or SAQ A-EP, a fraction of the effort and cost. This is the same discipline we bring to broader compliance advisory work at traztech: fix the underlying architecture first, then let the paperwork reflect a smaller, truer scope.

PCI DSS Readiness Versus the Required Penetration Test

Once scope is confirmed, readiness work covers the control gaps: firewall configuration, encryption of cardholder data at rest and in transit, access control and least privilege, vulnerability management, logging and monitoring, and vendor management for any third party that touches the CDE. For companies above SAQ A, or anyone with a web-facing CDE, PCI DSS Requirement 11.3 mandates an annual penetration test performed by a qualified tester, plus retesting after significant infrastructure changes. This isn't optional and it isn't the same as a vulnerability scan. Skipping it, or treating an automated scan as a substitute, is one of the most common reasons companies fail their assessment or get flagged by their acquiring bank.

The Canadian Context: PIPEDA, Quebec Law 25, and PCI DSS

PCI DSS is card-brand contractual law, but it doesn't operate in isolation for Canadian companies. Cardholder data is personal information under both PIPEDA and Quebec's Law 25, so a card-data breach triggers separate privacy-law breach notification obligations on top of whatever the card brands require. Treat PCI DSS scoping and privacy-law scoping as one exercise, not two separate binders, since they largely touch the same systems and the same access controls.

We work with SaaS and e-commerce teams across Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal on exactly this overlap, because Canadian fintech and payments companies in particular need PCI DSS, PIPEDA, and often SOC 2 to line up rather than duplicate each other's control work.

How to Tell Which Category You're In

Ask three questions before signing any PCI DSS engagement. Does your platform ever receive a raw card number, even in transit, before it reaches a payment processor? Do you store card data anywhere, including backups or logs? What's your actual annual transaction volume against the card brand thresholds? Honest answers to those three questions usually settle the scope question in under an hour, and they should come before any vendor quotes you a fixed-fee "PCI DSS package" without asking them first.

Get an Honest Scoping Assessment

If you're not sure whether you need SAQ A or a full assessment, that uncertainty is normal and it's worth resolving before you spend money. TrazTech is a boutique Canadian security and compliance consultancy led by a published security researcher, and we scope PCI DSS work honestly, including telling clients when they need less than they think. If your company handles payments and you want a straight answer on what PCI DSS actually requires of you, contact traztech for a scoping conversation.

Merchant or service provider? The distinction that changes everything

The single most expensive misunderstanding in Canadian SaaS is a company assuming it is a merchant when the card brands would classify it as a service provider. A merchant accepts cards for its own goods and services. A service provider is any entity that stores, processes, or transmits cardholder data on behalf of another party, or that could affect the security of someone else's card transactions.

That second clause is where SaaS companies get caught. If you build billing software, run a marketplace that pays out to sellers, host a checkout page for your customers, or supply a widget that renders inside somebody else's payment flow, you are a third-party service provider whether or not a card number ever touches your database. Service providers do not get the short questionnaires. The self-assessment path for a service provider is SAQ D-SP, which tracks close to the full requirement set, and above roughly 300,000 card transactions a year handled or affected, most brands push service providers into a Level 1 assessment with a Qualified Security Assessor and a Report on Compliance.

There is also a set of requirements that only apply to service providers, including quarterly reviews confirming personnel are following security procedures, documented executive responsibility for the card data program, and additional testing of segmentation controls. A company that scoped itself as a Level 4 merchant and later discovers its enterprise customers are asking for a service provider Attestation of Compliance has a much bigger project than it budgeted for. Work out which side of that line you are on before anything else, because everything downstream depends on it.

Who actually asks you for the paperwork

PCI DSS enforcement does not arrive as a regulator's letter. It arrives from two directions. Your acquiring bank or payment facilitator requires attestation as a condition of the merchant agreement, usually annually, and the consequence of not producing it is a monthly non-compliance fee or, less often, account termination. Meanwhile your enterprise customers ask for your Attestation of Compliance during vendor diligence, and they increasingly ask for the actual signed AOC rather than a marketing page saying you are PCI compliant.

Read what they are asking for carefully. An AOC is a specific two to three page document with the assessor or officer signature, the SAQ type, the assessment date, and the list of requirements marked as in place or not applicable. A ROC is the full report and is rarely shared outside the acquirer relationship. If a customer asks for your ROC, they usually mean the AOC, and clarifying saves a week. If they ask for Stripe's AOC because you use Stripe, send them Stripe's, but do not present it as yours. Presenting a processor's compliance as your own is the fastest way to lose credibility with a security team that reads these documents for a living.

What v4.0 changed, and why last year's answer may be stale

PCI DSS version 4.0 replaced 3.2.1, and a large batch of requirements that were best practice on release became mandatory on 31 March 2025. If your last assessment was completed against the old version, several answers you gave are no longer sufficient.

The changes that bite hardest for web-facing companies concern payment page integrity. E-commerce skimming, where an attacker injects a script into a checkout page and harvests card numbers client-side, was the driver. Version 4 added requirements to inventory and authorize every script on a payment page and to detect unauthorized modification of the page delivered to the browser. The Council subsequently revised how these land for the smallest merchants in the 4.0.1 revision of SAQ A, folding the concern into the eligibility criteria rather than the questionnaire body, which means qualifying for SAQ A now carries an assertion about your page's exposure to script attacks. Check the current version of the questionnaire you are about to sign rather than reusing last year's file, because the eligibility text is where the change lives.

Version 4 also brought in targeted risk analysis, which lets you set the frequency of certain controls yourself provided you document the reasoning. This is a genuine improvement and it is also a trap, because an undocumented frequency choice reads as an omission rather than a decision. Write the analysis down.

Scans, tests, and the difference between them

Two technical obligations get conflated constantly. Quarterly external vulnerability scans must be run by an Approved Scanning Vendor against every external-facing IP in scope, and you need four consecutive passing quarters to support an annual attestation. A scan that fails is not the end of it, you remediate and rescan until clean, and the passing scan is the artifact you keep. Internal scans are also required but do not need an ASV.

Penetration testing under Requirement 11.4 is a different exercise entirely, performed at least annually and after any significant change, covering both the network layer and the application layer, from outside and inside the cardholder data environment. If you rely on segmentation to keep systems out of scope, segmentation testing is required on top of that, annually for merchants and every six months for service providers. Assessors check the tester's independence and qualifications, and a scan report submitted in place of a penetration test is one of the more common reasons an assessment stalls. Our penetration testing work starts at $1,000, and for PCI purposes the scoping conversation matters more than the price, because a test that covers the wrong network segment satisfies nothing.

Requirement 12.8: the vendor list nobody maintains

If you outsource anything that touches card data, you owe a maintained list of those providers, written agreements in which each acknowledges responsibility for the cardholder data they hold, a documented due diligence process before engagement, a program to monitor their compliance status at least annually, and a matrix showing exactly which PCI requirements each party owns.

That last item, the responsibility matrix, is the one that gets skipped and the one assessors ask for first. It has to be specific: for each applicable requirement, whether it is yours, theirs, or shared. Producing it forces a conversation most teams have never had, which is why it is valuable beyond the assessment. It is also the artifact that makes your own customer diligence faster, because a well-built matrix answers half the questions an enterprise buyer will send you. Keeping it current is ordinary maintenance work, and it is the kind of thing our retainer model and the free traztech Workspace are built to carry between assessments.

What happens if card data is exposed

The compliance conversation changes shape entirely after an incident. The card brands can require a forensic investigation by a PCI Forensic Investigator, chosen from their approved list, and the acquirer typically funds it and then recovers the cost from you. Compliance status is assessed retroactively against the period of the compromise, so an AOC signed three months earlier offers limited protection if the investigation finds the control was not actually operating. Fines flow through the acquirer, along with account data compromise recovery amounts intended to cover reissuance and fraud losses.

On top of that, cardholder data is personal information, so a Canadian company faces PIPEDA breach reporting to the Privacy Commissioner where there is a real risk of significant harm, notification to affected individuals, and a record of the breach retained for 24 months. Quebec's Law 25 runs its own confidentiality incident process in parallel. Running the card brand process and the privacy process as one incident with two reporting tracks is much easier than discovering the second obligation a week in. If you want that mapped before you need it, that is what compliance and incident response planning are for.

When you should not buy PCI DSS work

We turn down PCI engagements fairly often, and the reasons are worth stating plainly.

If you use a hosted checkout, never see a card number, are not a service provider, and your acquirer has not asked for anything beyond a self-signed SAQ A, you can complete that questionnaire yourself in an afternoon. It is roughly two dozen controls, most of which are policy statements and vendor management items. Paying a consultancy several thousand dollars to fill it in for you is not good value, and any firm quoting a full program against that footprint has either not asked how your checkout works or does not want to know.

If your real driver is a single enterprise customer's questionnaire rather than an acquirer requirement, ask what evidence they would accept. Some will take your processor's AOC plus a description of your integration, particularly when you never handle card data. Ten minutes on that question can remove the project entirely.

If your architecture is about to change, do the engineering first. Moving from a self-hosted form to a hosted payment page can drop you from SAQ D to SAQ A. Doing the assessment before that migration means paying to certify an environment you intend to delete, and then paying again next year. The engineering work is cheaper than the assessment work in almost every case.

And if you are a genuine service provider handling card data at volume, the honest advice runs the other way: do not buy readiness alone. Budget for a QSA relationship, plan a multi-quarter program, and treat the control set as engineering scope rather than documentation. Our PCI DSS work for SaaS companies starts with which of those situations you are actually in, and the first answer is free.