If your product touches payment card data, PCI DSS applies to you. The good news is that most SaaS and fintech companies can make the project small and predictable, if they scope it right. This guide covers when you actually need PCI DSS, how to shrink it, the annual penetration test v4.0 now requires, and the difference between an SAQ and a ROC, in plain language.
Book a free scoping callThe trigger is simple to state. PCI DSS applies the moment you store, process, or transmit cardholder data. If a real card number, what the standard calls the primary account number, ever flows through your systems, sits in your database, or passes through your servers, you are in scope and you have obligations.
Where it gets more nuanced is the modern payment stack. If you use a provider like Stripe, and you rely on their hosted fields so the raw card number goes straight from the customer's browser to the processor and never lands on your infrastructure, your scope drops dramatically. Many SaaS and fintech companies in that position qualify for the shortest form of validation. But note the word "dramatically," not "entirely." Using a processor reduces scope, it does not always eliminate PCI DSS. You still have responsibilities for how you integrate, how you protect the systems around the payment flow, and how you manage access. The safe assumption is that PCI DSS is in play, and the real question is how small you can make it.
The cheapest PCI DSS project is the one you shrink before you start. Everything in PCI DSS is measured against your cardholder data environment, the CDE, which is every system that stores, processes, or transmits cardholder data, plus anything connected to it. The larger that environment, the more systems you have to harden, monitor, test, and document. So the highest-leverage work happens before any assessment: make the CDE as small as you can.
In practice, for SaaS and fintech, that means a few concrete moves:
Rule of thumb: every system you can honestly keep out of the cardholder data environment is a system you do not have to secure, test, and document to PCI DSS. Scope reduction is the single biggest lever on cost and timeline.
There are two ways to validate PCI DSS compliance, and which one applies to you comes down to volume and how you handle card data.
Most SaaS and fintech companies qualify for an SAQ. You attest to a defined set of controls that matches how you handle card data, rather than sitting through a full external audit. Companies that use tokenization and hosted payment fields generally land on one of the shorter SAQ types, which is by far the lighter path. It is still real work, but it is proportionate.
Larger organizations, typically those handling higher transaction volumes, need a formal Report on Compliance produced with a Qualified Security Assessor, a QSA. This is a full external assessment against the standard. It is more involved and more expensive than an SAQ, and it is the right path when the numbers require it.
Which one you fall under is not something we invent. The card brands set annual transaction volume levels that determine whether you can self-assess or need a ROC via a QSA. Part of a good scoping exercise is figuring out honestly which side of that line you are on before you commit to a plan.
This is the part teams underestimate. PCI DSS v4.0 requires penetration testing of the cardholder data environment at least once every twelve months, and again after any significant change to that environment. It is not optional, and it is not something a questionnaire can substitute for. The test has to cover both the network and application layers, and it has to confirm that the segmentation keeping your CDE separate from the rest of your systems actually holds under a real attacker's pressure.
That is exactly why PCI DSS is a security project, not just a paperwork project, and why a security partner matters more here than in some other frameworks. You need people who can build the controls and then genuinely test them. We deliver the penetration test as part of our security services, with our partner Lorikeet Security, so the readiness work and the required test come from one team that understands both sides.
The honest answer on both is that it depends on scope, which is why scope reduction comes first. A company that has kept its cardholder data environment small through tokenization can move quickly once the readiness work is done. A larger environment heading toward a Report on Compliance takes longer, because there is simply more to remediate, test, and validate.
On cost, it helps to separate the pieces. Our readiness work is fixed scope, so you know the number before you start and it does not drift as the project runs. The QSA and approved scanning vendor fees, where they apply, are separate and typically quoted in USD by those firms directly. The penetration test is its own defined engagement. We would rather tell you the shape of the cost honestly than quote a single misleading figure, because the biggest variable is always how large your environment is. You can see how the readiness program itself is structured on our compliance services page.
PCI DSS rewards a partner who can do both the compliance and the security, because the standard demands both. We are a Toronto team that brings readiness and the required penetration testing under one roof, so you are not stitching together a compliance advisor and a separate testing firm who never talk to each other. Our founder is a published security researcher with six CVEs, including CVE-2024-45163, a CVSS 9.1 kill-switch for a variant of the Mirai botnet, so the controls we build and test hold up to real scrutiny. We quote fixed scope, and, just as important, we help you minimize scope first, so you are paying to secure and validate a small environment rather than an accidental sprawling one.
Tell us how you handle card data and who is asking for PCI DSS. We will help you figure out the smallest honest scope, whether you need an SAQ or a ROC, and what readiness plus the required pentest looks like.
Book a free scoping callUsually yes, but a much smaller version of it. Using a provider like Stripe with hosted payment fields means the raw card number never touches your servers, which dramatically reduces your scope and often qualifies you for the simplest Self-Assessment Questionnaire. It does not always eliminate PCI DSS entirely, because you still have obligations around how you integrate, protect your systems, and manage access. The goal is to keep your cardholder data environment as small as possible, not to assume the processor removes it.
A SAQ is a Self-Assessment Questionnaire. It is a way for a merchant or service provider to validate PCI DSS compliance by attesting to a defined set of controls, rather than going through a full external audit. There are different SAQ types depending on how you handle card data. Most SaaS and fintech companies that use tokenization and hosted payment fields qualify for one of the shorter SAQs, which is far less work than a full Report on Compliance.
Yes. PCI DSS v4.0 requires penetration testing of the cardholder data environment at least once every twelve months and after any significant change to that environment. The test has to cover both the network and application layers and confirm that the segmentation keeping your cardholder data environment separate actually holds. This is a core reason to have a security partner rather than only a compliance advisor.
It depends almost entirely on scope. A company that has kept its cardholder data environment small through tokenization can often reach a completed SAQ in a matter of weeks once the readiness work is done. A larger environment heading toward a Report on Compliance takes longer because there is more to remediate and validate. The fastest path is to reduce scope first, then run readiness against a small, well-defined environment.
Not in the way ISO 27001 is. PCI DSS is a standard that you validate compliance against, either through a Self-Assessment Questionnaire or a Report on Compliance signed off by a Qualified Security Assessor. There is no single certificate that lasts for years. Instead you attest or are assessed against the standard, typically on an annual cycle, and maintain the controls continuously.