The Complete PCI DSS 4.0 Compliance Guide for Canadian Fintech (2026)

Twelve requirements, one payment platform, and a version of PCI DSS that finally wants proof you actually do this stuff — every day, not just audit week.

If you run a Canadian fintech, PCI DSS has a way of showing up uninvited. You add a card-on-file feature, or a partner bank asks for your Attestation of Compliance, or a payment processor sends over a self-assessment questionnaire and suddenly the whole team is Googling “what is a CDE” at 11pm.

Here is the good news. PCI DSS 4.0 is big, but it is not mysterious. It is twelve requirements that mostly boil down to the same security hygiene your SOC 2 and ISO 27001 auditors already ask about — just aimed squarely at one thing: keeping card data from leaking.

This guide walks a Canadian fintech through all of it. What version 4.0 actually changed, which requirements are now mandatory, how the merchant levels decide your validation path, and where PCI overlaps with the Canadian obligations you are already carrying — PIPEDA, Loi 25, OSFI. No filler, just the map.

PCI DSS 4.0 in One Paragraph

PCI DSS (Payment Card Industry Data Security Standard) is the security standard every organization that stores, processes, or transmits payment card data must meet. It is set by the PCI Security Standards Council and enforced by the card brands — Visa, Mastercard, American Express, Discover, and in Canada also Interac — through your acquiring bank or payment processor.

Version 4.0 is the current standard (the 4.0.1 revision landed in mid-2024). Its future-dated requirements stopped being “best practice” and became mandatory on 31 March 2025. So if you are validating in 2026, you are validating against the full 4.0 — no grace period left.

Does PCI DSS Even Apply to Us?

Quick gut check, because a lot of Canadian fintechs assume they are off the hook when they are not. If a primary account number (a card number, the “PAN”) ever touches your systems — stored, processed, or passed through — PCI applies. Even if you never store a card, routing it through your servers pulls you into scope.

❌ “We use Stripe, so we’re fine”

Using a processor reduces your scope — it does not delete it. You still owe an SAQ (usually SAQ A), and if your checkout page loads scripts, PCI 4.0’s new payment-page rules apply to you too.

◑ “We only touch tokens”

Tokenization and P2PE genuinely shrink scope. But you have to prove the card data never lands in your environment in the clear. That proof is the SAQ, and the scope work behind it.

❌ “We’re pre-revenue”

Card brands do not care about your stage. The moment you accept a live card, your merchant level and validation obligations kick in. Better to design for it now than retrofit later.

The 12 Requirements, Grouped by Goal

PCI DSS organizes its twelve requirements under six control objectives. This is the table to bookmark — it is the entire standard on one screen.

Goal	#	Requirement
Build & maintain a secure network	1	Install and maintain network security controls (firewalls, segmentation)
Build & maintain a secure network	2	Apply secure configurations to all system components (no vendor defaults)
Protect account data	3	Protect stored account data (encryption, truncation, key management)
Protect account data	4	Protect cardholder data with strong cryptography in transit over public networks
Maintain a vulnerability program	5	Protect all systems against malware (including new anti-phishing controls)
Maintain a vulnerability program	6	Develop and maintain secure systems and software (incl. payment-page scripts)
Strong access control	7	Restrict access to system components by business need-to-know
	8	Identify users and authenticate access (MFA everywhere into the CDE)
	9	Restrict physical access to cardholder data
Monitor & test networks	10	Log and monitor all access to system components and cardholder data
Monitor & test networks	11	Test security of systems and networks regularly (scans, pen tests, script monitoring)
Maintain a security policy	12	Support information security with organizational policies and a documented program

What Actually Changed in 4.0 (and Is Now Mandatory)

If you last looked at PCI under 3.2.1, this is the part that matters. Version 4.0 added a batch of “future-dated” requirements that were optional until 31 March 2025 and are now simply Required. These are the ones that trip up fintechs at validation time.

Requirement	What 4.0 now demands	Why it exists
8.4.2 / 8.5 — MFA	Multi-factor authentication for all access into the cardholder data environment, not just remote/admin access. It must resist replay and can’t be bypassed.	Stolen passwords are the #1 way card environments get breached.
8.3.6 — Passwords	Minimum 12-character passwords (up from 7) where passwords are still used as a factor.	Short passwords fall to modern cracking in minutes.
5.4.1 — Anti-phishing	Processes and automated mechanisms to detect and protect personnel from phishing attacks.	Phishing is how most credential theft starts.
6.4.3 & 11.6.1 — Payment-page scripts	Inventory, authorize, and monitor every script that loads on your payment page; alert on unauthorized changes to the page.	Directly targets e-skimming / Magecart attacks that steal cards client-side.
A3 / 12.3.1 — Targeted Risk Analysis	Document a targeted risk analysis to justify the frequency of certain recurring activities.	Moves PCI from a rigid checklist toward risk-based reasoning.
10.4.1.1 — Log review	Automated mechanisms to perform audit-log reviews (manual daily review no longer cuts it at scale).	Humans miss things in log noise; machines don’t get tired.
12.x — Roles defined	Roles and responsibilities documented and assigned for every requirement.	“Everyone assumed someone else owned it” is a classic audit finding.

The other big 4.0 idea: the Customized Approach. Alongside the traditional “Defined Approach” (meet the requirement exactly as written), 4.0 lets mature teams meet the objective of a control with their own method — if they can back it with a targeted risk analysis and evidence. Powerful, but it puts the burden of proof on you. Most fintechs stick with the Defined Approach until they have the documentation muscle for it.

Your Merchant Level Decides Everything

How you validate PCI — a full audit versus a self-assessment — depends on your annual transaction volume. The card brands set slightly different thresholds, but Visa’s levels are the ones most people mean:

Level	Annual card transactions	How you validate
Level 1	Over 6 million (any channel), or any merchant that’s had a breach	Annual Report on Compliance (ROC) by a QSA, quarterly ASV scans, penetration test
Level 2	1 million to 6 million	Annual SAQ (often signed off by an ISA), quarterly ASV scans
Level 3	20,000 to 1 million e-commerce	Annual SAQ, quarterly ASV scans
Level 4	Under 20,000 e-commerce (or under 1 million total)	Annual SAQ, quarterly ASV scans (as required by acquirer)

Most early-stage Canadian fintechs sit at Level 3 or 4 and validate with a Self-Assessment Questionnaire. Which SAQ you use depends on how you handle cards:

SAQ type	Fits you if…
SAQ A	Fully outsourced card handling; a third party (e.g. a hosted payment page or iframe) does everything. Card data never touches your servers.
SAQ A-EP	E-commerce site that doesn’t receive card data but controls how it’s collected (e.g. a direct-post or JS that could affect the payment page).
SAQ B / B-IP	Standalone terminals or PIN-entry devices, no electronic card storage.
SAQ C / C-VT	Payment application connected to the internet (C) or a virtual terminal (C-VT), no card storage.
SAQ P2PE	Only a validated point-to-point encryption solution, hardware terminals.
SAQ D	Everyone else — merchants who store card data, and all service providers. The big one.

Are you a “service provider”? Lots of fintechs are, and don’t realize it. If you store, process, or transmit card data on behalf of another company — a payments API, a BNPL provider, a platform that moves money for merchants — you’re a service provider, and your validation bar is higher (SAQ D or a full ROC, plus six-month cycles on some controls). Get this classification right early; it changes your whole roadmap.

Getting Compliant: The Path That Actually Works

You don’t tackle twelve requirements at once. You do this in an order that keeps scope small and evidence flowing.

Scope it

Map every system that stores, processes, transmits, or connects to card data. This defines your CDE — and shrinking it is the single highest-leverage move you can make.

Segment it

Isolate the CDE from the rest of your network so the other 90% of your systems fall out of scope. Fewer in-scope systems, fewer controls to prove.

Close the gaps

Run a gap assessment against all twelve requirements. MFA, encryption, logging, and the new 4.0 items are where fintechs usually have work to do.

Collect evidence

Stand up continuous evidence collection so proof of each control gathers itself — timestamped — instead of being screenshotted the week before.

Validate

Complete your SAQ or ROC, run the quarterly ASV scan and (if required) the pen test, and sign the Attestation of Compliance.

Stay ready

4.0 is a continuous standard. Monitor controls, review logs, re-confirm scope, and keep the evidence current so next year is a refresh, not a rebuild.

Steps 1 and 2 carry the most weight. We break them down in the companion guide: PCI DSS Scoping & Network Segmentation: The Evidence Checklist Auditors Expect.

The Canadian Angle: Where PCI Meets Your Other Obligations

There’s no Canada-specific version of PCI DSS — the standard is global — but a Canadian fintech never carries PCI alone. You’re usually juggling privacy law and, if you’re regulated, OSFI expectations at the same time. The upside: the controls overlap heavily. Build once, satisfy several.

Obligation	What it covers	Overlap with PCI DSS
PCI DSS 4.0	Payment card data security	—
PIPEDA (federal)	Personal information handling & breach reporting	Encryption, access control, breach response, safeguards
Loi 25 (Quebec)	Privacy for Quebec residents; strict enforcement live	Access control, data minimization, incident reporting, vendor management
OSFI B-13	Technology & cyber risk for federally regulated FIs	Risk management, monitoring, resilience, third-party risk
FINTRAC / PCMLTFA	AML obligations for money services businesses	Record-keeping, access logging, identity controls

Look down the “overlap” column and the pattern jumps out. Access control, encryption, logging, incident response, vendor risk — the same handful of controls answer PCI, PIPEDA, Loi 25 and OSFI at once. This is exactly why treating each framework as a separate project is the expensive way to do it. Map your controls once and each new obligation mostly reuses evidence you already have. We go deep on that idea in the SOC 2 vs ISO 27001 vs NIST control-mapping guide.

Snapshot vs Continuous: The 4.0 Mindset Shift

The single biggest thing to internalize about PCI 4.0: it stopped rewarding the once-a-year scramble. The whole standard is nudging you toward proving controls work all the time.

🚫 The 3.2.1 Habit

Screenshot everything the month before the assessment
Manual log review, if it happens at all
MFA only for remote admins
Scope re-checked “whenever”
Evidence stale the day after it’s captured

✅ The 4.0 Way

Evidence collected continuously and timestamped
Automated log review that flags anomalies
MFA on every path into the CDE
Scope confirmed at least every 12 months, documented
Always audit-ready, because the proof is always current

⚡ The Fintech Fast-Track

If you remember nothing else from this guide:

1. Shrink the scope
Segmentation is your cheapest control.

2. Get the SAQ right
Wrong SAQ = wrong roadmap.

3. Automate the evidence
4.0 wants continuous, not annual.

4. Reuse across frameworks
PCI controls double for Loi 25 & SOC 2.

Make PCI DSS 4.0 a Refresh, Not a Fire Drill

PCI DSS 4.0 rewards teams that can prove their controls work continuously — and punishes the ones still living in screenshot folders. A compliance automation platform maps your PCI controls, collects the evidence automatically, and reuses that same evidence across SOC 2, ISO 27001 and Loi 25 so you’re not building five programs in parallel.

Prove it once. Prove it always.

Explore PCI DSS Compliance with Mindsec

Frequently Asked Questions

What is PCI DSS 4.0 and when did it become mandatory?

PCI DSS 4.0 is the current version of the Payment Card Industry Data Security Standard, the security framework every organization that handles payment card data must meet. It replaced version 3.2.1, which was retired on 31 March 2024. Version 4.0’s future-dated (“best practice”) requirements became fully mandatory on 31 March 2025, so any assessment in 2026 is measured against the complete 4.0 standard with no remaining transition period.

Does PCI DSS apply to Canadian fintech companies?

Yes. PCI DSS is a global standard enforced by the card brands — Visa, Mastercard, American Express, Discover and Interac — through your acquiring bank or processor, not by a Canadian government body. If your fintech stores, processes or transmits cardholder data, or can affect how a payment page collects it, PCI DSS applies regardless of where you’re incorporated. Canadian fintechs typically carry it alongside PIPEDA, Quebec’s Loi 25, and (if federally regulated) OSFI’s technology and cyber-risk expectations.

What are the main new requirements in PCI DSS 4.0?

The headline additions are: multi-factor authentication for all access into the cardholder data environment (not just remote admin access), a 12-character minimum password length, automated audit-log reviews, anti-phishing mechanisms, and new client-side controls to inventory and monitor scripts on payment pages to counter e-skimming. Version 4.0 also introduced the Customized Approach and the requirement to document a targeted risk analysis for certain recurring activities. Most of these were optional until 31 March 2025 and are now required.

How do I know which PCI DSS validation level and SAQ apply to us?

Your merchant level is set by annual transaction volume — Level 1 (over 6 million transactions) needs a formal Report on Compliance by a QSA, while Levels 2 through 4 usually complete a Self-Assessment Questionnaire. Which SAQ you use depends on how you handle cards: fully outsourced checkout is typically SAQ A, while storing card data or acting as a service provider pushes you to SAQ D. If you process or transmit card data on behalf of other businesses, you’re a service provider and face a higher validation bar. Getting this classification right first is what keeps the rest of the roadmap accurate.

How does PCI DSS overlap with SOC 2, ISO 27001 and Loi 25?

Heavily. Access control, encryption, logging and monitoring, incident response, and vendor risk management appear in all of them. In practice, the same MFA enforcement record or encryption configuration can serve as evidence for PCI DSS, SOC 2, ISO 27001 and Loi 25 simultaneously. That’s why mapping your controls once and reusing the evidence — rather than running each framework as a separate project — is dramatically cheaper. A compliance automation platform is built to do exactly that cross-framework mapping.