PCI DSS Compliance Checklist for Fintech Apps (v4.0)
7 Views
Summarize Article
Related Blogs
On March 31, 2025, 51 future-dated requirements in PCI DSS v4.0.1 became mandatory. The PCI Security Standards Council counts 64 new requirements in version 4, and every one of them now carries full weight in an assessment. Fintech teams that last checked their controls in 2023 are working from an old map.
A PCI DSS compliance checklist is the list of controls and evidence a company needs to show it handles cardholder data safely under the Payment Card Industry Data Security Standard. For an app team, it turns 12 broad requirements into tasks with owners and dates.
This guide covers scope and SAQ types, the 12 requirements in plain English and the v4.0 changes that land on developers. The last sections show the fastest way to shrink scope. They finish with a seven-step PCI DSS compliance checklist for launch.
Treat this article as general guidance on fintech compliance. Confirm your own obligations with your acquiring bank and a Qualified Security Assessor (QSA).
Any system that stores, processes or transmits cardholder data falls in PCI scope, and so does any system connected to one or able to affect its security. For a fintech app, that usually means the payment API, the database, the servers around them, the CI/CD pipeline and admin tools. Scope is the biggest cost driver in fintech compliance. Shrink it early.
How you take payments decides which Self-Assessment Questionnaire (SAQ) applies, if you qualify for self-assessment at all. The acquirer sets the validation level based on transaction volume, so ask them first.
| SAQ | Fits when | Effect on your app |
| A | Payment page fully hosted by a PCI-compliant provider, or embedded via iframe | Smallest scope, a short questionnaire |
| A-EP | Your website controls how card data reaches the provider, but never receives it | Your web servers come into scope |
| P2PE | Card-present payments through a validated encryption solution | Narrow scope for in-store terminals |
| D | You store, process or transmit card data yourself | Full scope, every requirement applies |
Service providers that handle card data on behalf of others, such as many payment and lending platforms, use SAQ D for service providers or a full assessment by a QSA.
The 12 PCI DSS requirements fall under six goals, from secure networks to a written security policy. Each requirement holds many sub-requirements. The table below is the core of a PCI DSS compliance checklist for an app team, with the evidence a QSA will ask to see.
| # | Requirement in plain English | What an app team must show |
| 1 | Control network traffic into and out of card systems | Firewall and security group rules, reviewed every 6 months |
| 2 | Configure every system securely | Hardened images, no vendor default passwords |
| 3 | Protect stored account data | No stored CVV, PAN encrypted or tokenized |
| 4 | Encrypt card data sent over public networks | TLS 1.2 or higher on every connection |
| 5 | Protect systems from malware | Anti-malware and anti-phishing controls |
| 6 | Build and maintain secure software | Secure coding against the OWASP Top 10, code review |
| 7 | Limit access by business need | Role-based access, quarterly reviews |
| 8 | Identify and authenticate every user | Unique IDs and multi-factor login |
| 9 | Restrict physical access to card data | Cloud provider attestations, office controls |
| 10 | Log and monitor all access | Centralized, tamper-resistant logs, reviewed daily |
| 11 | Test security regularly | Quarterly scans, yearly penetration tests |
| 12 | Back it all with policy | Written policies, risk analysis, incident plan |
Two items catch app teams most often. Requirement 3 bans storing sensitive authentication data, such as the CVV, after authorization, even encrypted. Requirement 6 now expects an inventory of the bespoke and custom software you run, plus the third-party components inside it.
Building a payment feature and unsure what falls in scope?
WebOsmotic maps your card data flows, sets your SAQ path and builds the app controls with you, so the QSA conversation starts from evidence.
The PCI DSS 4.0 requirements that land hardest on developers cover payment page scripts, multi-factor login and software inventories, plus a few smaller changes. These were future-dated until March 31, 2025. They now apply in full. Any app that last passed under version 3.2.1 needs a gap check within 90 days.
| Requirement | What changed | What developers do |
| 6.3.2 | Inventory of bespoke and custom software and its components | Keep a software bill of materials per release |
| 6.4.2 | Automated protection for public-facing web apps | Run a web application firewall in blocking mode |
| 6.4.3 | Every payment page script authorized and integrity-checked | Script inventory with subresource integrity |
| 8.3.6 | Passwords at least 12 characters | Update validation rules and policies |
| 8.4.2 | MFA for all access into the cardholder data environment | MFA on every admin and console path |
| 11.6.1 | Detect unauthorized changes to payment pages | Header and script change monitoring with alerts |
| 12.3.1 | Targeted risk analysis for flexible-frequency controls | Document why each frequency was chosen |
Version 4 also added a customized approach. A team can meet the objective of a requirement with its own control, if a QSA agrees the control meets that objective. It suits mature teams with strong evidence habits. Smaller teams usually save time with the defined approach.
The council has also looked ahead, running a request for comments on v4.0.1 from June 3 to July 20, 2026, to decide whether a revision is needed. Version 4.0.1 remains the standard in force.
Apps reduce PCI scope by never letting raw card numbers touch their own systems. Tokenization, hosted payment fields and validated point-to-point encryption all do this. The payment provider holds the card data and returns a token, which is useless to an attacker. Your servers store only that token.
The scope reduction can be dramatic. Tokenization pays back faster than almost any other fintech compliance decision, which is why it belongs on every PCI DSS compliance checklist. A team that stores card numbers must meet all 12 requirements across its whole environment. The same team using hosted fields from a PCI-compliant provider may qualify for SAQ A, with a far shorter list.
Three design rules keep scope small:
SAQ A has its own fine print. The council’s January 2025 SAQ A update removed requirements 6.4.3 and 11.6.1 from the questionnaire. In their place, merchants with embedded payment forms must confirm their site is not susceptible to script attacks. The requirements still exist in the standard itself.
The wider security model around a payments product is covered in our guide to building a secure fintech application.
A QSA or acquirer expects records showing each control worked across the whole assessment period, usually 12 months. A single snapshot fails, and so do policies with no proof behind them. Expect to show change tickets, scan reports and access reviews that prove controls ran on schedule.
Build the evidence into delivery, so assessment season becomes an export job. Bank partners often add their own reviews against FFIEC guidance and ask for a SOC 2 report, so map each control once and reuse the evidence across all three:
Teams that already run CI/CD security practices have much of this in place. Pipeline logs, signed builds and dependency scans double as PCI evidence.
A complete PCI DSS compliance checklist for a fintech launch runs from scope to sign-off in seven steps. Work through them in order, because each step depends on the one before. The bulk of the calendar time goes on collecting 3 months of evidence.
Use this sequence for PCI compliance for apps that are about to go live:
Plan 8 to 16 weeks for a first assessment on a new fintech product, longer when card data is stored. Keep the PCI DSS compliance checklist in your tracker, with an owner per line. The cost of each step feeds directly into the build budget, which our fintech app development cost guide breaks down by product type.
Need PCI-ready payments built into the product from day one?
WebOsmotic builds tokenized payments and MFA into fintech products from the first sprint, with the evidence trail a QSA will ask to see.
PCI DSS v4.0.1 is the current version. Its 51 future-dated requirements became mandatory on March 31, 2025. The council collected industry feedback on it from June 3 to July 20, 2026, to decide whether a revision is needed, but v4.0.1 remains in force today.
No. A compliant processor shrinks your scope, often to SAQ A. You still validate every year, and you still own the PCI DSS compliance checklist items that stay in scope. Embedded payment forms also require you to confirm your site is protected against script attacks, under the January 2025 SAQ A eligibility criteria. Read them closely.
Plan 8 to 16 weeks for a first assessment when a processor handles card data. Fintech compliance timelines stretch from there. Apps that store card data, or service providers needing a full Report on Compliance, should plan for 6 months or more, because evidence must cover a full period.
No federal law requires it. PCI DSS is an industry standard set by the card brands through the PCI Security Standards Council, and contracts with your acquirer make it binding. A few states reference it in data security laws. Fines and higher fees follow non-compliance, sometimes for 12 months or more.
A SAQ is a self-assessment for merchants and service providers that qualify. A Report on Compliance is a full assessment written by a QSA, required for the highest-volume merchants and many service providers. A ROC also needs dedicated assessor time, so book the QSA early.
