PCI DSS Compliance for Cloud-Native Banking in 2026
A practical guide to PCI DSS v4.0 for fintechs and cloud-native banks: who needs it, the 12 requirements summarized, how to handle Kubernetes and containerized environments, scope reduction through tokenization and segmentation, the SAQ vs ROC assessment path, and how Crassula's stack supports compliance.
What PCI DSS is and who must comply
PCI DSS - the Payment Card Industry Data Security Standard - is a global set of technical and operational controls for any organisation that stores, processes, or transmits payment card data. It is maintained by the PCI Security Standards Council, a body founded by Visa, Mastercard, American Express, Discover, and JCB.
If your product touches a primary account number (PAN) in any way, PCI DSS applies to you. That includes card issuers, payment processors, acquiring banks, fintech platforms handling card transactions, and any SaaS service that sits in the data flow between a cardholder and a payment network.
Card issuers
Any platform that issues virtual or physical cards and holds card numbers must meet PCI DSS requirements for storing and transmitting PANs.
Payment processors
Any intermediary routing card transactions between a merchant and a card network - including BaaS providers and payment gateways - is in scope.
Service providers
Cloud platforms, managed-service providers, and SaaS vendors that can affect the security of a client's cardholder data environment are also in scope.
As of March 31, 2025, PCI DSS v4.0.1 is the only active version. All 64 new or updated requirements introduced in v4.0 are now mandatory - the transition period is over. Assessments in 2026 are assessed against v4.0.1, and there is no grandfathering for legacy environments.
Non-compliance carries real financial consequences. Acquiring banks may levy monthly fees of $5,000 to $100,000 per month for unresolved violations. A data breach in a non-compliant environment can trigger card-scheme fines, mandatory forensic investigation, and loss of card-processing rights.
Let's discuss your project and see how we can launch your digital banking product together
Request demoThe 12 requirements summarized for banking
PCI DSS v4.0.1 organises its controls into 12 requirement families grouped under six objectives. The table below maps each requirement to the controls most relevant for a fintech or cloud-native bank.
| # | Requirement | What it means in practice |
|---|---|---|
| 1 | Network security controls | Firewalls, security groups, and VPC rules that isolate the cardholder data environment (CDE) from other networks. |
| 2 | Secure configurations | No default passwords; hardened OS and container images; no unused ports or services. |
| 3 | Protect stored account data | Encrypt PANs at rest using AES-256 or equivalent. Render them unreadable in all storage - databases, backups, logs. |
| 4 | Protect cardholder data in transit | TLS 1.2+ for all transmission; no unencrypted protocols within the CDE. |
| 5 | Protect against malicious software | Anti-malware for applicable systems; container image scanning in CI/CD pipelines. |
| 6 | Secure systems and software | Patch management, secure SDLC, web application firewall, payment-page script integrity (new in v4.0). |
| 7 | Restrict access by business need | Role-based access control (RBAC); least-privilege principles applied to service accounts and humans. |
| 8 | Identify users and authenticate access | MFA required for all access to the CDE, including non-administrative users (new mandate in v4.0). |
| 9 | Restrict physical access to cardholder data | Physical media controls; visitor logs; destruction procedures. In cloud, maps to data-centre security attestation from the CSP. |
| 10 | Log and monitor all access | Audit trails for all CDE activity; SIEM integration; tamper-evident log storage; at least 12 months retention. |
| 11 | Test security regularly | Quarterly ASV scans, annual penetration tests, internal vulnerability scans; IDS/IPS where applicable. |
| 12 | Support information security with policies | Documented security policy, risk assessments, security awareness training, third-party vendor management. |
One of the most significant conceptual shifts in v4.0 is the move from annual compliance events to continuous monitoring. Controls that were once checked once a year during an audit now must be verifiable as always-on. This affects how you design logging, automated scanning, and access reviews.
PCI DSS in a cloud-native and containerized environment
Traditional PCI DSS guidance was written for server rooms with fixed IP ranges. Cloud-native environments - Kubernetes clusters, serverless functions, ephemeral containers, multi-account cloud setups - require a different approach to most of the 12 requirements. The standard accommodates this through a "Customized Approach" that lets you meet a security objective through controls suited to your actual architecture.
The shared responsibility model. When you run on a public cloud, the cloud service provider (CSP) owns the physical and hypervisor layer. You own everything above it. Mapping this clearly is the first step of cloud PCI scoping.
| Layer | Owner | PCI controls |
|---|---|---|
| Physical infrastructure and hypervisor | Cloud service provider (CSP) | Physical security, hardware isolation. CSP provides an Attestation of Compliance (AoC). |
| VPCs, security groups, IAM policies | Your team | Network segmentation, least-privilege IAM, encryption in transit between services. |
| Kubernetes cluster, control plane | Your team | Cluster hardening, RBAC, pod security standards, image scanning, admission controllers. |
| Application and business logic | Your team | mTLS between services, input validation, secure SDLC, WAF for payment pages. |
| Data at rest (databases, object storage) | Your team | KMS-backed encryption, key rotation, access logging, backup encryption. |
Zero-trust and service mesh. In a microservices architecture, the old "castle and moat" perimeter does not exist. Each pod and service needs its own identity. A service mesh like Istio or Linkerd enforces mutual TLS between all services, provides per-request observability, and limits blast radius - if one container is compromised, mTLS prevents lateral movement to adjacent services. This maps directly to Requirement 4 (encryption in transit) and supports the continuous monitoring mandate in Requirement 10.
Policy as code. Tools like Open Policy Agent (OPA) or Kyverno let you define PCI controls as code and enforce them at admission time. Common policies include: prevent root-privileged containers, block public-facing load balancers for internal services, require image provenance from a signed registry, and detect configuration drift against a known-good baseline. Combined with a Cloud Security Posture Management (CSPM) tool, this gives you the continuous compliance evidence that v4.0 requires.
Cryptographic key management in cloud. PCI DSS v4.0 requires a hierarchical key structure. Data Encryption Keys (DEKs) encrypt individual records; Key Encryption Keys (KEKs) encrypt the DEKs themselves. Automated rotation of both key types is required. In cloud environments, this is typically handled by a managed KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) with customer-managed keys. For highest-assurance environments, an HSM-backed key store satisfies the FIPS 140-2 Level 3 requirement.
Scope reduction through tokenization and network segmentation
The single most effective way to reduce PCI compliance cost and complexity is to minimize the size of your cardholder data environment. Fewer systems in scope means a smaller audit, less evidence to gather, and a lower attack surface. Two techniques drive scope reduction: tokenization and network segmentation.
Tokenization. A tokenization system replaces the raw PAN with a surrogate value (the token) that has no cryptographic relationship to the original. Systems that only ever see the token - your CRM, your customer portal, your analytics pipeline - are out of scope. The only in-scope components are the tokenization vault, the key management system, and any application that calls the de-tokenization API.
For a token to remove a system from scope, two conditions must hold: the token-only system must have no access to the vault, the keys, or the de-tokenization endpoint; and the token must be irreversible by the receiving system without an API call to the vault. If both conditions are met, the PCI Security Standards Council's tokenization guidelines confirm that those systems fall outside the CDE.
Network segmentation. Segmentation separates systems that hold or touch PANs from those that do not. In a Kubernetes environment, this means dedicated namespaces or node pools for CDE workloads, network policies that block all traffic from non-CDE namespaces to CDE namespaces (except explicitly allowed paths), and separate VPCs or accounts for cardholder data processing. A flat network architecture - where every pod can reach every other pod - can pull an entire platform into scope, turning a small CDE into a company-wide audit.
Tokenization benefits
- Removes entire application tiers from PCI scope
- Protects data even if a non-CDE system is breached
- Works alongside encryption (complementary, not alternative)
- Required access controls are simpler to audit
Segmentation benefits
- Limits blast radius of a security incident
- Reduces number of systems subject to full PCI controls
- Enables different security postures for CDE vs non-CDE
- Provides clear audit boundary for QSA or SAQ
Scoping errors are the most common - and expensive - failure mode in PCI assessments. A common mistake is assuming that encryption alone removes a system from scope. Encryption protects data within the CDE but does not shrink the CDE boundary. Only tokenization (when implemented correctly) and proven segmentation remove systems from scope.
SAQ vs ROC, merchant levels, and the assessment process
PCI DSS validation requirements depend on your merchant or service provider level, which is set by the card schemes (Visa, Mastercard, etc.) based on annual transaction volume and risk profile.
| Level | Transaction threshold | Validation method |
|---|---|---|
| Level 1 | Over 6 million card transactions/year (merchants); over 300,000/year (service providers or prior breach) | Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA); quarterly ASV scans |
| Level 2 | 1 to 6 million transactions/year | Annual SAQ or QSA-led assessment; quarterly ASV scans |
| Level 3 | 20,000 to 1 million e-commerce transactions/year | Annual SAQ; quarterly ASV scans |
| Level 4 | Under 20,000 e-commerce or under 1 million total transactions/year | Annual SAQ recommended; ASV scans as required by acquirer |
SAQ (Self-Assessment Questionnaire). The SAQ is a self-declaration. There are several SAQ types (A, A-EP, B, B-IP, C, C-VT, D, P2PE-HW) that apply depending on how you handle card data. SAQ-A covers merchants that fully outsource card data handling and never touch the PAN. SAQ-D - the most comprehensive - applies when you store, process, or transmit card data yourself, and it mirrors almost the full set of PCI DSS controls. Completing SAQ-D typically takes six to twelve months for a fintech from scratch. The output is an Attestation of Compliance (AoC), which is 3-5 pages for SAQ-based assessments.
ROC (Report on Compliance). The ROC is an independent audit performed by a QSA or a certified Internal Security Assessor (ISA). It is required for Level 1 entities, and is common for service providers and fintechs that process large volumes. The AoC from a ROC assessment is 10-15 pages and carries more weight with card schemes and enterprise customers. Many fintechs voluntarily pursue a ROC-level assessment before they technically need it, because enterprise banking clients and card scheme partners often require it as a condition of partnership.
Payment Facilitators (PayFacs) almost always inherit Level 1-style obligations even at lower volumes, because they aggregate sub-merchant transactions. If your platform is a PayFac or enables merchants to accept cards through your infrastructure, check your card-scheme agreements carefully - you may be subject to ROC requirements from day one.
How Crassula's stack supports PCI scope reduction
Crassula's white-label banking platform is designed to handle the most sensitive parts of the card data environment, allowing clients to build card and payment products without taking on the full burden of CDE ownership themselves.
Tokenized card data
PANs issued on the Crassula platform are stored and transmitted in tokenized form. Client applications work with tokens, not raw card numbers, keeping the majority of client systems out of PCI scope.
Encrypted data at rest and in transit
All cardholder data stored on Crassula infrastructure is encrypted with AES-256. All inter-service communication uses TLS 1.3. KMS-managed key rotation is automated.
Network segmentation
CDE workloads run in dedicated, hardened namespaces with strict egress/ingress policies. Non-CDE application tiers are separated at the network layer and cannot reach card data stores.
Audit-ready logging
All access to cardholder data environments is logged with tamper-evident trails retained for at least 12 months. Clients receive log exports for their own compliance reporting.
When you build a card issuing or payment product on Crassula, you inherit the security controls already built into the platform rather than implementing them from scratch. This reduces the scope of your own PCI assessment to the integration points between your application and the Crassula APIs - rather than the full cardholder data stack. Your QSA will still need to review those integration points, but the heaviest compliance work sits on the platform side.
For teams launching a first card program or payment product, this approach can compress the time to first PCI assessment from 12-18 months (building your own CDE) to 3-6 months (scoping only the integration layer). Contact the Crassula team for a technical overview of the shared-responsibility boundary and the documentation your QSA will need.
FAQ
PCI DSS (Payment Card Industry Data Security Standard) is a set of security controls that applies to any organisation that stores, processes, or transmits payment card data - including PANs, CVVs, PINs, and track data. If your fintech issues cards, processes card transactions, or sits in the data path between a cardholder and a card network, PCI DSS applies to you. This includes card issuers, payment processors, payment facilitators, and service providers that host or manage card data on behalf of clients. If you only pass card data to a fully PCI-compliant third party and have no access to the raw card numbers, you may fall into a reduced-scope SAQ category.
PCI DSS v4.0 (now at v4.0.1, the current active version) made several significant changes from v3.2.1. The most important for cloud-native fintechs are: MFA is now required for all access to the CDE, not just administrative access; payment-page scripts must have integrity controls to prevent client-side skimming (Requirement 6.4); the "Customized Approach" allows organisations to meet security objectives through controls suited to their own architecture rather than prescriptive controls; continuous monitoring is explicitly required instead of point-in-time annual checks; and all 64 new requirements introduced in v4.0 became mandatory as of March 31, 2025. There is no grandfathering - as of 2026, all assessments use v4.0.1 as the baseline.
Cloud PCI DSS compliance starts with understanding the shared responsibility model: your cloud provider handles physical security (and provides an AoC to prove it), while you own everything from the virtualisation layer up. Key steps are: define the CDE boundary precisely (which services, accounts, and namespaces touch PANs); implement network segmentation to isolate the CDE; enforce encryption in transit using TLS 1.3 and mutual TLS between microservices; manage encryption keys in a cloud KMS with automated rotation; enforce least-privilege RBAC and MFA for all CDE access; deploy policy-as-code (OPA, Kyverno) to prevent non-compliant configurations from reaching production; set up SIEM and centralized logging with 12-month retention; and run quarterly ASV scans plus annual penetration tests. The "Customized Approach" in v4.0 gives you flexibility to document how Kubernetes-native controls satisfy requirements that were originally written for physical data centres.
Tokenization replaces a raw PAN with a surrogate token that has no mathematical relationship to the original. Any system that only ever sees the token - your CRM, analytics platform, or customer portal - is out of PCI scope, as long as it cannot call the de-tokenization API and cannot access the key vault. Network segmentation separates CDE systems from non-CDE systems at the network layer using firewalls, VPC boundaries, Kubernetes network policies, and dedicated namespaces or accounts. Systems on the non-CDE side cannot initiate connections to the CDE and are therefore excluded from the audit. The two techniques are complementary: tokenization removes individual data elements from scope; segmentation removes entire network tiers. Together they can shrink a platform-wide compliance project to a much smaller, well-defined CDE perimeter.
An SAQ (Self-Assessment Questionnaire) is a self-declaration that your environment meets PCI DSS requirements. It applies to lower-volume merchants and some service providers, and is completed internally (though evidence must be kept to support the attestation). A ROC (Report on Compliance) is an independent audit performed by an external Qualified Security Assessor (QSA) or a certified Internal Security Assessor (ISA). It is required for Level 1 merchants and service providers, and is increasingly expected by enterprise clients and card-scheme partners as a condition of doing business. The output of a ROC-based assessment is a detailed technical report plus an Attestation of Compliance (AoC). For most fintechs that handle card data directly, the path to a Level 1 service-provider ROC is the eventual destination, even if they start with an SAQ while building volume.
