BLOG

By David Chernitzky, CEO, Armour Cybersecurity  ·  Serving Toronto and organizations across North America  ·  Last updated August 25, 2026

Key Takeaways

• PCI DSS applies to all entities in the payment card data flow, not just payment processors. Banks, credit unions, and fintechs issuing or processing card transactions are in scope.
• The current standard, PCI DSS v4.0.1, kept the changes v4.0 introduced to authentication, customized implementation, and targeted risk analysis; the previously future-dated requirements became mandatory on March 31, 2025 and are now in full effect.
• Annual penetration testing against PCI DSS Requirement 11 is mandatory, including segmentation testing where network segmentation is used to reduce scope.
• Ongoing compliance is more demanding than achieving compliance once. Controls must operate continuously, and evidence must be maintained throughout the assessment period.
• A cybersecurity programme aligned to PCI DSS requirements also satisfies significant portions of OSFI B-13, SOC 2, and ISO 27001 control requirements.

Who Actually Needs PCI DSS Compliance?

PCI DSS applies to any entity that stores, processes, or transmits cardholder data, meaning the primary account number from a payment card, along with associated authentication data. The standard is enforced through card brand rules, which means that Visa, Mastercard, American Express, and Discover contractually require compliance from their merchant and acquirer networks.

For financial institutions, scope is broader than many compliance teams initially assess. Banks and credit unions that issue payment cards, process card transactions, or maintain cardholder data environments are in scope. Fintechs that handle card payments through their platforms, even if they partner with a licensed issuer or acquirer, may carry PCI DSS obligations depending on how the data flows through their systems.

The critical first step in any PCI DSS programme is an accurate scoping assessment that identifies all systems, networks, and processes that store, process, or transmit cardholder data, along with all systems connected to them. Underscoping is the most common compliance error and creates both security risk and assessment exposure.

What Are the 12 PCI DSS Requirement Domains?

PCI DSS v4.0.1 organizes requirements across six goals and twelve requirement domains. The goals are: build and maintain a secure network; protect cardholder data; maintain a vulnerability management programme; implement strong access control measures; regularly monitor and test networks; and maintain an information security policy.

The twelve requirements translate these goals into specific controls. Network security controls include firewall configuration and segmentation. Data protection requirements cover encryption of cardholder data in transit and, where stored, at rest. Vulnerability management requires patching and malware protection. Access control requirements mandate unique user IDs, need-to-know access, and physical access controls. Monitoring requirements include audit log management, intrusion detection, and file integrity monitoring. Testing requirements mandate vulnerability scanning and penetration testing. The policy requirement addresses the governance documentation that holds the programme together.

PCI DSS v4.0 introduced a customized implementation approach, carried forward in v4.0.1, that allows organizations to meet the intent of a requirement through alternative controls, provided those controls are validated by a Qualified Security Assessor. This gives larger institutions flexibility in how they satisfy specific requirements, but it increases the evidence and documentation burden rather than reducing it.

What Does PCI DSS Penetration Testing Actually Require?

Requirement 11 of PCI DSS mandates annual penetration testing of cardholder data environment systems, networks, and applications. The testing must cover external and internal perspectives, application-layer and network-layer testing, and confirmation that segmentation controls are effective.

Segmentation testing is particularly important for institutions that use network segmentation to reduce PCI DSS scope. The premise of scope reduction through segmentation is that cardholder data environment systems are isolated from out-of-scope systems. If a penetration tester can breach that isolation, the scope reduction is invalid and controls across a larger environment must be assessed.

PCI DSS testing must be conducted by a qualified tester who is independent of the systems being tested. The organization’s internal IT team or the managed service provider that operates the cardholder data environment cannot conduct the penetration test. Independence is a defined requirement, and assessors verify it during the annual QSA assessment.

Armour Cybersecurity conducts PCI DSS penetration testing with testers experienced in financial institution environments and familiar with the specific documentation and evidence format that QSA assessments require. The test report is structured to support the assessment directly, reducing back-and-forth between the testing team and the assessor.

How Does PCI DSS Interact With OSFI B-13?

For federally regulated financial institutions in Canada, PCI DSS compliance and OSFI B-13 alignment operate in parallel and share significant control overlap. Both frameworks require access management, vulnerability management, network security, logging and monitoring, incident response, and third-party oversight. A programme built with both frameworks in mind produces evidence that satisfies both, rather than maintaining separate documentation for each.

OSFI B-13 is broader in governance expectations, requiring board-level oversight and technology risk integration that PCI DSS does not address. PCI DSS is more prescriptive about cardholder data environment controls. A financial institution subject to both frameworks needs a coordinated programme rather than parallel compliance silos.

What Is the Cost of PCI DSS Non-Compliance?

Card brands impose monthly non-compliance fines on acquirers for merchants and institutions that fail to maintain compliance. These fines are passed down the chain and can reach tens of thousands of dollars per month depending on the institution’s tier and the duration of non-compliance.

Following a cardholder data breach, non-compliant entities face forensic investigation costs, remediation requirements, card replacement costs charged back by card brands, and potential suspension from card brand programmes. For a financial institution, suspension from card processing is an existential event.

Beyond the direct financial consequences, a breach in a cardholder data environment that was assessed as non-compliant eliminates any insurance coverage that requires compliance as a condition. Cyber insurers review PCI DSS compliance status at renewal, and a policy exclusion for known non-compliance can render coverage unavailable precisely when it is most needed.

How Do Fintechs Approach PCI DSS When They Partner With Issuers?

Fintechs that process payments through third-party issuers or acquirers often assume that the partner’s PCI DSS compliance covers their own obligations. This assumption is frequently incorrect. If the fintech’s systems handle, store, or transmit cardholder data, even temporarily, those systems are in PCI DSS scope regardless of the partner’s compliance status. Armour’s PCI DSS readiness support starts by mapping exactly how cardholder data flows through the platform before sizing the programme.

The practical question for fintechs is how cardholder data flows through their technology stack. A fintech that tokenizes cardholder data immediately and never stores the primary account number in its own systems has a very different scope profile than one that processes and routes raw card data through its own infrastructure. A scoping assessment establishes the actual exposure, and the compliance programme is sized accordingly.

Across the 260+ organizations Armour Cybersecurity protects in 52+ industries, the institutions that pass a PCI DSS assessment without a fire drill are the ones that treated scope as the whole game, they tokenized early, segmented hard, and kept the cardholder data environment small, so the annual assessment covers a tight, well-evidenced perimeter instead of sprawling across every system that ever touched a card number.

Frequently Asked Questions

What is the difference between a SAQ and a QSA assessment?

A Self-Assessment Questionnaire is a compliance validation tool for lower-risk entities that meet specific criteria, such as merchants that do not store cardholder data and use a third-party payment processor for all card processing. Banks, credit unions, and fintechs that process significant card volumes or operate cardholder data environments are typically required to use a Qualified Security Assessor for an annual assessment. Your acquiring bank or card brand relationship defines which validation method applies.

How often does PCI DSS require vulnerability scanning?

PCI DSS requires quarterly external vulnerability scans conducted by an Approved Scanning Vendor, and internal vulnerability scans at least quarterly as well. In addition to scans, annual penetration testing is required. Scan failures must be remediated and rescanned until a passing report is achieved. Maintaining passing scan results throughout the year, not just at assessment time, is a common operational challenge.

We had a QSA assessment last year. Are we compliant now?

A QSA assessment validates compliance at a point in time. PCI DSS compliance is a continuous state, not an annual certification. Controls must operate throughout the year, evidence must be maintained continuously, and new system changes must be assessed for impact on the cardholder data environment before implementation. A compliant assessment does not guarantee compliant status if controls degrade between assessments.

How do we reduce our PCI DSS scope?

Scope reduction typically involves tokenization of cardholder data, network segmentation of the cardholder data environment from general business systems, and use of certified third-party payment processors that handle cardholder data on behalf of the institution. Each approach requires implementation, documentation, and validation during the assessment. Armour’s PCI DSS readiness service assesses your current scope, identifies reduction opportunities, and builds the controls and evidence to support scope reduction during the next assessment cycle.

The Bottom Line

PCI DSS is not a certificate a financial institution earns once and files away; it is a continuous state that the card brands, acquirers, and cyber insurers all check. The institutions that handle it well share one habit: they get scope right first, shrink the cardholder data environment through tokenization and segmentation, then build the twelve requirements around that tight perimeter and keep the evidence current all year. Done that way, PCI DSS stops being a standalone burden and starts reinforcing the same controls that OSFI B-13, SOC 2, and ISO 27001 already ask for. Armour Cybersecurity provides PCI DSS readiness support and Requirement 11 penetration testing for banks, credit unions, and fintechs, structured so the evidence answers the assessor the first time and the same controls carry across every framework the institution has to meet.