PCI DSS compliance testing for fintech teams. A step-by-step guide for PCI DSS v4.0

If your fintech handles card data, even if you never see a raw PAN, you're in PCI DSS scope. The question isn't whether you need to comply. It's whether your testing workflow is rigorous enough to survive a QSA audit without months of remediation and a compliance bill that rivals your Series A.

This guide is written for QA leads and CTOs who need to move from knowing what PCI DSS requires to knowing exactly how to test it, across APIs, mobile SDKs, microservices, and cloud-native architectures that the standard wasn't originally designed for.

We'll skip the 'PCI DSS stands for...' intro. You already know what it stands for.

Why PCI DSS compliance testing hits differently in fintech

The PCI Security Standards Council built PCI DSS around a relatively simple mental model: a merchant has a payment terminal, a cardholder swipes a card, and the data travels through a handful of known systems to a processor. Compliance meant locking down that path.

That model describes almost no fintech company operating today.

The architecture mismatch

A modern fintech payment flow might look like this:

• Mobile app collects card details via a third-party SDK

• SDK tokenizes and sends to your API gateway

• Gateway routes through a fraud scoring microservice

• Payment microservice calls a card vault (yours or outsourced)

• Vault communicates with the card network via a processor

• Transaction event is logged to an analytics pipeline

• Support dashboard pulls masked card data from the CRM

Every single component in that chain is a potential PCI DSS scope expansion. The analytics pipeline that "only receives masked data", is it actually masked at ingestion, or at display? The support dashboard, does it log raw API responses somewhere? The fraud microservice, can it access the vault directly?

Data point:

In 2025, payment data breaches cost fintech companies an average of $5.85 million per incident. 64% of those breaches involved payment card data. The financial sector consistently reports the highest breach costs of any industry, and most of those breaches exploit exactly the kind of integration complexity described above.

What PCI DSS 4.0 changed, and why it matters right now

PCI DSS 4.0 became the only active standard in March 2025, replacing v3.2.1. This isn't a version bump, it's a compliance philosophy shift. The key changes that affect fintech QA teams specifically:

• MFA is now required for all CDE access, not just administrators. If a developer can SSH into a production payment service, that needs MFA.

• Authenticated vulnerability scanning (Req 11.3.1.2) is now mandatory, meaning your scanner needs valid credentials, not just network access.

• APIs are now explicit audit targets under Req 6.2.4 and the secure development requirements.

• Targeted Risk Analysis (TRA) is required if you use the Customized Approach for any control.

• Payment page script integrity is mandatory, any JavaScript on a checkout page must be validated.

• Evidence must demonstrate continuous compliance, not just annual-snapshot compliance.

That last point is the one that breaks the most teams. If your QA process treats PCI as a once-a-year audit event rather than a continuous testing discipline, you'll spend the two months before your assessment scrambling to retroactively prove controls that were supposed to have been running all year.

Step 1. Define your CDE before you test anything

Scoping is where most fintech teams bleed time and fail audits. Scope too broadly and you're testing and documenting systems that don't need to be in scope. Scope incorrectly and your QSA will catch it, the audit fails, and you start over. Neither option is good.

The three CDE boundary questions

The CDE (Cardholder Data Environment) consists of three layers, and most teams only answer the first correctly:

• Layer 1, Direct scope: Systems that store, process, or transmit cardholder data.

• Layer 2, Connected scope: Systems that connect to Layer 1 systems, even if they never touch card data themselves.

• Layer 3, Security scope: Systems that could affect the security of Layers 1 or 2, your logging infrastructure, identity provider, secrets manager, CI/CD pipeline.

If your CI/CD pipeline deploys code to a payment service, your CI/CD pipeline is in scope. Full stop. This surprises a lot of engineering teams.

Hidden scope traps in fintech architectures

These are the systems that silently expand your CDE without anyone noticing until a QSA audit:

• Analytics pipelines: An analytics service that receives transaction events "for reporting" sometimes receives pre-tokenized data, depending on when in the payment flow the event fires. Audit your event schemas.

• Test and staging databases: Shadow systems that were seeded with production card data months (or years) ago. Run a discovery scan on non-production environments, they're almost always overlooked.

• Support dashboards: If support agents can view the last 4 digits of a card, what does the API response actually return? Inspect the payloads, not just the UI.

• Logging infrastructure: Does your logging aggregator (Datadog, Splunk, ELK) ever receive raw card data from error traces, API debug logs, or SDK exceptions? This is one of the most common compliance failures in fintech.

• Collaboration tools: Slack integrations, Jira webhooks, or email notifications that include transaction details can pull systems into scope unexpectedly.

Tokenization does not automatically reduce your scope

This is probably the most common misconception in fintech compliance. Teams implement tokenization, often through Stripe, Braintree, or a card vault, and assume their CDE effectively disappears. It doesn't.

Tokenization reduces scope. Poorly implemented tokenization reduces it less than you think. Three things to check:

• When does tokenization happen? If raw card data transits your server before tokenization (even for milliseconds), that server is in scope.

• What does your vault return? Some vault APIs return partial PANs alongside tokens. If those responses are logged, you're storing cardholder data.

• Who has vault access? If a developer can call the detokenization endpoint directly, that access path is in scope and needs the full set of Req 8 controls.

Microservices and where the CDE line falls

In a monolith, the CDE boundary is relatively clean. In a microservices architecture, it's a negotiation that happens service by service.

The rule: a service is in scope if it can initiate or receive connections to or from a CDE system, regardless of whether it processes card data. Apply this to:

• Sidecar proxies: If an Envoy or Linkerd sidecar proxies traffic to a payment service, that sidecar is in scope.

• Ingress controllers: An ingress controller that routes to in-scope services needs to be treated as in-scope.

• Service accounts: Any Kubernetes service account with permissions to call in-scope services falls under Req 8 access control requirements.

• Secrets managers: If HashiCorp Vault or AWS Secrets Manager holds credentials for CDE systems, it's in security scope for PCI.

Step 2. Gap assessment. Knowing what you're missing before you test

Priority controls for fintech teams

Every competitor article walks you through all 12 PCI DSS requirements in sequence. We're not doing that, you can read the standard. What's more useful is knowing which requirements have the highest fintech-specific failure rate and why.

The TRA. Demystified for engineering teams

The Targeted Risk Analysis (TRA) is one of PCI DSS 4.0's most misunderstood requirements. It's mandatory if you implement any control using the Customized Approach, meaning you're meeting a security objective with a different control than the one PCI specifies.

In engineering terms, a TRA is a documented answer to four questions for each customized control:

The artifact your QSA wants to see isn't a Word document written the week before the audit. It's a living document with dated entries, mapped to specific infrastructure configurations, with owners named. If your team is building one from scratch, give it at least two sprints of dedicated time.

SAQ type selection. Getting it wrong costs months

For fintech teams that don't store card data directly, SAQ type selection is the first major compliance decision. Most teams pick SAQ A and discover they actually need SAQ A-EP or SAQ D during the assessment.

Step 3. Vulnerability assessment. The QA team's baseline

Vulnerability scans are not penetration tests. This distinction matters enormously for compliance purposes: scans find known vulnerabilities in known places. Pen tests prove those vulnerabilities are actually exploitable and quantify how far an attacker would get.

Both are required. Neither substitutes for the other.

Internal vs. external scans in cloud-native environments

In a traditional on-premise environment, internal and external are obvious: internal means inside the firewall, external means from the internet. In cloud-native fintech architectures, the lines blur.

• An internal scan covers systems reachable from within your VPC or private network, including services exposed only to other services via service mesh.

• An external scan covers internet-facing assets: API gateways, load balancers, web applications, remote access endpoints.

• VPC peering and cloud interconnects can make systems "external" to one environment while "internal" to another. Scope both sides.

Authenticated scanning. The requirement nobody has implemented yet

Requirement 11.3.1.2 in PCI DSS 4.0 mandates authenticated internal vulnerability scans. In practice, this means your scanner must log in to target systems with valid credentials, not just probe them from the network.

What this looks like operationally:

• Create a dedicated scanning service account with read-only access to target systems.

• Configure your scanner (Tenable, Qualys, Rapid7) to use those credentials for each scan job.

• Verify credentials are rotated on the same schedule as other service accounts under Req 8.

• Ensure scan accounts are excluded from lockout policies that would break scheduled scans.

Common mistake:

Teams configure authenticated scanning in a test environment and then forget to replicate the service account setup when production infrastructure is expanded. After an infra change, scans silently fall back to unauthenticated mode and continue running, producing reports that satisfy no one.

What a clean scan report needs to show your QSA

Running a scan is the easy part. Producing a report your QSA will accept without follow-up questions is harder. A compliant scan report includes:

• Scan date and environment: Which systems were scanned, from where, with which credentials.

• Critical and high findings with CVSS scores: Not just a count, each finding needs severity classification, affected system, and CVE reference where applicable.

• Remediation status: Which findings were fixed, mitigated, or accepted as risk, with dates.

• Retest evidence: A second scan confirming remediation, not just a verbal assertion.

• False positive documentation: Any findings marked as false positives need written justification that a QSA can review.

If your scan tool exports a PDF and you send it as-is, expect follow-up questions. QSAs want to see that you understood the results, not just that you ran the tool.

Need help building a compliant scan workflow?

DeviQA's security testing team works with fintech companies to build authenticated scanning pipelines integrated into CI/CD, with QSA-ready reporting built in from day one.

Book a strategic QA consultation

Schedule a call

Step 4. Penetration testing. The highest-stakes test in your compliance workflow

Most fintech teams spend 80% of their security testing budget on network-layer testing, firewalls, ports, network segmentation, and treat application-layer testing as a secondary checkbox. This is exactly backwards for most fintech architectures, where the real attack surface is APIs and payment flows, not firewall rules.

Under PCI DSS v4.0, it's not enough to find vulnerabilities. You have to prove they're real, exploitable, and tied to a specific risk. That's how you earn trust with your QSA.

What requirement 11.4 actually mandates

Req 11.4 requires annual external and internal penetration tests, but the details matter more than the cadence:

• External pen test: covers internet-facing systems that interact with or could affect the CDE.

• Internal pen test: covers systems within your network that could be used for lateral movement to reach cardholder data.

• Application-layer testing: must cover OWASP Top 10 vulnerabilities and those listed in Req 6.2.4, including injection, broken authentication, XSS, and IDOR.

• Segmentation testing: if you use network segmentation to reduce scope, those controls must be tested annually (or every 6 months for service providers).

• Post-change testing: any significant change to the CDE requires a targeted retest within 30 days.

API penetration testing for payment platforms

This is the section that doesn't exist in most PCI compliance guides. APIs are the primary attack surface for fintech products, and they require a completely different testing approach from traditional web application testing.

For each payment API endpoint, your pen test should cover:

• Authentication bypass: Can requests be made without a valid token? Can a valid token from one user access another user's payment data (BOLA, Broken Object Level Authorization)?

• Excessive data exposure: Does the API response include more data than the client needs? Raw PANs or CVVs in error responses, full card details when only last-4 is displayed.

• Parameter manipulation: Can transaction amounts, currency codes, or merchant IDs be manipulated in transit? Test both request parameters and JWT claims.

• Rate limiting validation: Is there effective rate limiting on payment initiation endpoints? Unlimited retries against card validation endpoints can enable card testing attacks.

• OAuth scope escalation: Can a token issued with limited scope (read-only) be used to perform write operations (initiate payments)?

• Injection in payment parameters: SQL injection in amount fields, NoSQL injection in filter parameters, command injection via webhook URLs.

Mobile SDK security testing. The compliance gap nobody audits

Most fintech mobile apps use a third-party payment SDK, Stripe iOS, Braintree, Checkout.com, or similar. The SDK is PCI-certified. Your integration of that SDK may not be.

What to test in your mobile payment integration:

• Crash log contamination: Does the app's crash reporting tool (Firebase Crashlytics, Sentry) capture card entry field content in crash reports? Test by triggering crashes during card entry.

• Device storage: Does the app write any card data to local storage, SQLite, or shared preferences, even temporarily? Use a jailbroken/rooted test device and inspect storage after payment flows.

• Keyboard caching: Are PAN entry fields using secure text input that suppresses keyboard caching and autocorrect? Test by checking iOS/Android autocomplete suggestions after typing card numbers.

• SSL pinning: Is certificate pinning implemented and functional? Test with an MITM proxy (Charles, Burp Suite) to verify.

• Jailbreak/root detection: Does the app detect and respond appropriately to compromised device environments? Test on jailbroken iOS and rooted Android.

• Screenshot prevention: Is FLAG_SECURE (Android) or equivalent (iOS) applied to screens that display card data?

Segmentation testing. Proving your CDE isolation holds

If you've reduced your PCI scope by segmenting the CDE from the rest of your network, you must prove that segmentation works. Telling your QSA "we have VPC isolation" is not proof. A segmentation test is.

A segmentation test works like this:

• Start from a system that's explicitly out of scope, a development environment, a corporate workstation, or an external network.

• Attempt to reach any CDE system via any route: direct network access, API calls, credential reuse, path traversal.

• Document every attempt and its result. The QSA wants to see failed attempts with error evidence, not just a pass/fail summary.

• Test all segmentation methods, VPC boundaries, security groups, network ACLs, API gateway authorization, service mesh policies.

Methodology note:

PCI DSS 4.0 requires a documented, industry-standard methodology for penetration testing, NIST SP 800-115, OWASP Testing Guide, PTES, or OSSTMM. For fintech environments with heavy API surface area, the OWASP Testing Guide is typically the best starting point. NIST adds rigor for infrastructure-heavy environments. Whatever you choose, document it before the test starts, not after.

Choosing and qualifying your pen tester

For Level 1 merchants (over 6 million card transactions annually), you'll need a Qualified Security Assessor (QSA) from the PCI SSC's approved list. For other levels, you have more flexibility, but the tester must be independent and qualified.

Questions to ask before hiring a pen testing firm for PCI work:

• Do they have experience with fintech architectures specifically, not just general web applications?

• Can they provide sample reports that have been accepted by QSA firms?

• Do they understand API security testing, not just network penetration?

• Can they test mobile applications alongside server infrastructure?

• Will they provide a letter of attestation and clear CVSS-scored findings, not just a generic report?

Step 5. Automate vs. manual. The decision map your team needs

Every PCI compliance platform will tell you they can automate compliance. That's partially true and partially dangerous. Automation handles evidence collection, configuration monitoring, and scheduled scanning beautifully. It cannot replace human judgment in application security testing, and QSAs know the difference.

What automation handles well

What must remain human-tested

These controls require human judgment and cannot be reliably automated. Submitting automated evidence for these will trigger QSA follow-up questions at best and audit failure at worst:

• Business logic vulnerabilities in payment flows: A scanner cannot understand that processing a $0.01 transaction followed by a $10,000 refund is a fraud pattern, not a legitimate flow.

• Authorization bypass in multi-step transactions: Testing whether a user can skip the 3DS verification step by manipulating session state requires a human tester who understands the flow.

• Complex social engineering scenarios: Required under certain Req 12 controls, these cannot be scripted.

• Segmentation boundary validation: Automated tools can check network access; they can't reason about whether an API authorization policy is logically equivalent to network isolation.

• Custom control validation under TRA: If you've implemented an alternative control, proving it works requires a human who understands both the risk and the control.

Building PCI testing into your CI/CD pipeline

The teams that sail through PCI audits aren't the ones with the most expensive compliance platforms. They're the ones that built compliance evidence into their engineering workflow, so every deployment generates its own audit artifacts.

Here's how to map pipeline gates to specific PCI requirements:

• SAST (Req 6.2.4): Static analysis scanning on every PR merge. Flag hardcoded secrets, known vulnerable patterns, and cryptographic misuse. Tools: Semgrep, Checkmarx, SonarQube.

• DAST on staging (Req 6.2.4): Dynamic application security testing against a staging environment before production deployment. Tools: OWASP ZAP, Burp Suite Enterprise.

• SBOM generation (Req 6.3): Generate a Software Bill of Materials on every build to track third-party components and known CVEs.

• Secret scanning (Req 3, 8): Scan committed code and container images for secrets before they reach any environment.

• Infrastructure policy checks (Req 1, 2): Validate IaC (Terraform, CloudFormation) against security baselines before deployment. Tools: Checkov, tfsec, AWS Config Rules.

One Fortune 500 fintech reduced compliance preparation hours by 80% by building evidence collection directly into their engineering workflows, every deployment became an audit artifact, and the annual audit became a matter of presenting what already existed, not scrambling to create it.

Integrate PCI testing into your development pipeline

DeviQA helps fintech engineering teams build compliance-aware QA pipelines, from SAST/DAST integration to automated evidence collection, so your next PCI audit is a review, not a remediation project.

Book a strategic QA consultation

Schedule a call

Step 6. Evidence collection, QSA audit, and staying compliant post-certification

What a QSA actually looks for

QSAs are not looking for perfect systems. They're looking for evidence that you understand your environment, you know what controls are in place, and those controls are working consistently, not just during the audit window.

The most common QSA finding for fintech teams: documentation describes a control that the live system doesn't match. A firewall rule that was supposed to block inter-service traffic was removed during an incident 4 months ago and never reinstated. The policy says MFA is required for CDE access; two developer accounts created last quarter don't have it configured.

Under PCI DSS 4.0, QSAs prioritize evidence of consistency between documentation and live systems. Infrastructure-as-code teams fare significantly better than teams relying on manual configuration, because IaC creates a verifiable audit trail for every change.

Evidence artifacts by requirement. What QSAs want to see

The continuous compliance testing cadence

Compliance is not an annual event with a finish line. It's a continuous state that requires a testing cadence aligned to your risk profile.

• Quarterly: Internal and external vulnerability scans, access rights review, firewall rule review, ASV external scan.

• Annually: Full penetration test (internal + external + application layer), segmentation test, policy review, risk assessment.

• Every 6 months (service providers only): Additional segmentation testing, PCI DSS compliance review.

• After significant changes: Targeted security review and retest within 30 days of any change to CDE systems, major new feature releases touching payment flows, new API integrations with payment processors, cloud region expansions that affect CDE.

Realistic timelines and cost benchmarks

How long does PCI DSS compliance take? The honest answer is: it depends almost entirely on your starting architecture and how early you begin.

These ranges assume you're working with a QSA from the start, not discovering scope issues during the assessment. Bringing in a QSA 2–3 months before your validation deadline, not 2 weeks before, is one of the highest-leverage decisions you can make.

Common PCI testing failures in fintech, and how to avoid them

Failure 1: Scoping too broadly OR too narrowly

Both mistakes are expensive, just in different ways. Over-scoping inflates your testing surface and audit costs without reducing risk. Under-scoping causes audit failures.

The most common under-scoping mistake: assuming that because a service doesn't store card data, it's out of scope. Remember: connected systems and security-affecting systems are in scope regardless of whether they touch card data.

Run a formal data flow exercise before any scoping decision. Map every API call, every log destination, every third-party integration that touches your payment flow. Use automated data discovery tools to find cardholder data in places you don't expect it.

Failure 2: Third-party risk treated as someone else's problem

Your payment processor is PCI-compliant. Your card vault is PCI-compliant. Your fraud engine has a SOC 2 report. None of that eliminates your responsibility for how you integrate with those systems.

What you're accountable for in third-party integrations:

• How you transmit data to them (TLS version, certificate validation, API authentication)

• What you log about those API calls (do your logs contain their responses, including any card data?)

• Their incident response process, you need written agreements covering how they notify you of breaches

• Their PCI compliance status, obtain their AoC (Attestation of Compliance) annually and store it as evidence

Failure 3: Change management gaps between assessments

The most dangerous PCI compliance pattern: pass the annual assessment, then spend the next 11 months shipping features without triggering security reviews. By the time the next assessment comes around, the system the QSA is auditing looks nothing like the one they certified.

The fix isn't bureaucracy. It's a two-question checklist attached to every feature ticket:

• Does this feature touch any system in our CDE, or create a new connection to a CDE system?

• Does this feature change how cardholder data is transmitted, stored, or processed?

If the answer to either question is yes, a security review and targeted test is triggered before the feature ships. This is the simplest compliance-engineering integration and the one that prevents the most audit surprises.

Failure 4: Treating the KYC flow as out of scope

KYC (Know Your Customer) flows are where fintech companies collect identity documents, government IDs, and sometimes payment instrument data. Whether this data is in PCI scope depends on whether card data is collected during KYC onboarding.

In many neobank onboarding flows, the card linking step happens within or immediately after KYC. If your KYC platform receives card data, even to validate a card before linking it, that platform may be in CDE scope. Test the data flow explicitly, don't assume the KYC vendor's compliance covers your integration.

The PCI DSS testing framework for fintech. Summary

If you've absorbed everything above and need a single reference to share with your team, here it is: the complete testing workflow distilled into decision points.

The bottom line

PCI DSS compliance testing in fintech isn't harder than it is in other industries. It's different, specifically because of microservices architectures, third-party SDK complexity, API-first payment flows, and the speed at which fintech products evolve.

The teams that make compliance look easy are the ones who treated it as an engineering discipline from day one: scoped their CDE carefully, built testing into their deployment pipeline, and ran continuous evidence collection rather than annual fire drills.

The teams that struggle are the ones who treated PCI as something that happens to them once a year, rather than something they build into how they ship software.

The gap between those two groups isn't budget. It's workflow.

Ready to build a PCI-compliant QA practice for your fintech?

DeviQA specializes in security and compliance testing for payment platforms, neobanks, and fintech startups. From CDE scoping and API penetration testing to CI/CD pipeline integration and QSA audit preparation, we've built the compliance workflow for teams who want to ship fast without compliance debt.

Book a strategic QA consultation

Schedule a call

About the author

Ievgen Ievdokymov

Senior AQA engineer

Ievgen Ievdokymov is a Senior AQA Engineer at DeviQA, focused on building efficient, scalable testing processes for modern software products.