Your payment app processes thousands of transactions daily. Credit card numbers flow through your test environment during every QA cycle. And somewhere in your CI/CD pipeline, that data lands on a device shared with hundreds of other companies.

Here’s the question your auditor will ask: “Can you prove that cardholder data never persists on your test infrastructure?”

If you’re using a shared cloud device lab, you’re going to have a very uncomfortable conversation.

The Regulatory Reality: What PCI DSS Actually Says

Let’s start with the standard that governs every payment application. PCI DSS isn’t vague about test environments.

Requirement 6.4.3 states explicitly:

“Production data (live PANs) are not used for testing or development.”

Requirement 6.4.2 requires:

“Separation of duties between development, testing and live environments.”

Requirement 3 (Protect Stored Account Data) applies to any environment where cardholder data exists—including test environments running on third-party infrastructure.

PCI DSS 4.0, which became mandatory in March 2025, introduced 64 new requirements with heightened focus on:

  • Multi-factor authentication for all access to cardholder data environments
  • Authenticated vulnerability scanning
  • Encryption of sensitive authentication data (SAD) prior to authorization
  • Documented roles and responsibilities for every security control

Here’s what this means for your test infrastructure: If your test flows touch anything resembling card data, your test environment falls under PCI DSS scope.

And that includes the shared devices at BrowserStack, Sauce Labs, and AWS Device Farm.

The Shared Infrastructure Problem

When you run tests on a cloud device lab, your app executes on hardware that thousands of other companies use. That creates specific risks for payment applications.

What Cloud Device Lab Providers Actually Say

From AWS Device Farm’s official security documentation:

“Device Farm’s physical mobile device testing data is not encrypted at rest.”
— AWS Device Farm Security Documentation

“It is possible for data to persist between sessions in some cases, especially if you make use of the device system outside the context of your app.”
— AWS Device Farm Security Documentation

“AWS Device Farm is not in scope of any AWS compliance programs.”
— AWS Device Farm Compliance

That last point is critical. AWS—the company that offers HIPAA-eligible and PCI DSS compliant services across most of their platform—explicitly excludes Device Farm from compliance certification scope.

According to Sauce Labs Trust Center, they acknowledge their cleanup process can fail:

“If we encounter any issue during the cleaning process, or we fail to clean the device, we put those devices aside for manual inspection to prevent data and security leaks.”

What happens to your data during that inspection period? Who has access? How long does it persist?

These are questions your QSA (Qualified Security Assessor) will ask. And “we trust the vendor” isn’t an answer that passes audit.

Even BrowserStack’s own alternatives guide acknowledges this reality:

“For sensitive data, consider platforms that offer private device clouds or on-premises solutions for full data isolation.”

The Audit Documentation Gap

PCI DSS 4.0 requires documented proof of security controls. Specifically:

  • Requirement 12.5.2: Scoping must be documented and confirmed by a QSA
  • Requirement 10: All access to cardholder data must be logged and monitored
  • Requirement 11: Regular testing of security systems is required

When your test devices live in a third-party cloud:

  • You can’t document complete device lifecycle
  • You can’t verify cleanup procedures
  • You can’t provide access logs for shared infrastructure
  • You can’t demonstrate data encryption at rest (because AWS admits it doesn’t exist)

This creates gaps in your compliance documentation that auditors will flag.

According to QA Financial, auditors are actively finding these gaps:

“Auditors frequently find test environments lacking critical controls: Missing access logs top the list. Data inventories don’t exist. Uncontrolled and unmasked data spreads everywhere.”

The Fintech Breach Epidemic

This isn’t theoretical. Fintech companies are under sustained attack, and third-party vendors are the primary entry point.

The Numbers

According to DeepStrike’s 2025 analysis, finance accounted for 27% of all global data breaches in 2023—up from 19% in 2022. That makes fintech the most attacked industry.

41.8% of breaches impacting top fintech companies originated from third-party vendors (SecurityScorecard, 2025).

The average cost of a fintech data breach: $5.9 million per incident.

PCI DSS non-compliance fines range from $5,000 to $100,000 per month, depending on transaction volume and duration of non-compliance.

Neontri’s research adds another sobering statistic:

“78% of consumers will stop using a financial app after a security breach, even if their personal data wasn’t compromised.”

Recent Fintech Breaches

Finastra (November 2024): This fintech giant serving 8,000 clients—including major banks—discovered a hacker had accessed their third-party Secure File Transfer Platform. The attacker exfiltrated corporate data, accounting records, and legal agreements over an eight-day period before detection.

Revolut (2022): The digital bank suffered two separate incidents. In one, cybercriminals exploited a software flaw to steal $20 million from corporate funds. In another, a social engineering attack exposed personal data of over 50,000 customers. Post-breach phishing campaigns immediately targeted affected users.

Bank of America (February 2024): Customer data was exposed through a breach at Infosys McCamish Systems, a third-party data processor. Compromised information included names, Social Security numbers, and account details.

LoanDepot (January 2024): A ransomware attack compromised data for 16.6 million customers. Response and recovery costs reached $27 million, plus ongoing class-action litigation.

The pattern is consistent: attackers target the vendors, not the banks directly. Your cloud device lab is a third-party vendor with access to your application code and test data flows.

The Test Data Compliance Crisis

It’s not just breaches. QA Financial reports that test data compliance is falling behind:

“60% of organisations have experienced data breaches or theft in non-production environments, an 11% increase from last year.”

“Test data compliance efforts are falling behind development speed, creating a dangerous gap exploited by bad actors and scrutinised by regulators.”

Curiosity Software’s research confirms this:

“Testers at 45% of organisations do not always comply with security and privacy regulations for test data.”

And Enov8 warns:

“If a breach occurs in a test environment, it can be just as damaging as a breach in production, resulting in stolen customer data, financial losses, and compliance violations.”

What Compliant Fintech Teams Actually Use

Major financial institutions don’t use shared cloud device labs for payment applications. Here’s what they use instead.

Option 1: On-Premise Device Labs

Traditional enterprise solution. You buy devices, rack them in your data center, manage everything internally.

Pros:

  • Complete control over hardware and data
  • Full compliance scope
  • No third-party access

Cons:

  • High capital expenditure ($50,000+ to start)
  • Requires dedicated infrastructure team
  • Device procurement and refresh cycles
  • Limited scalability

Who uses it: Major banks, payment processors, enterprises with existing data center infrastructure.

Option 2: Private Device Clouds (Enterprise)

Dedicated device infrastructure from providers like Kobiton, BrowserStack Private Cloud, or Perfecto.

As BrowserStack’s alternatives guide notes, platforms like Bitbar offer “both cloud and on-premises deployment options, with the latter providing complete data isolation for organizations in highly regulated industries like finance, healthcare, and government.”

Pros:

  • Devices dedicated to your organization
  • Enhanced security controls
  • Vendor-managed infrastructure

Cons:

  • Premium pricing ($10,000+/month)
  • Still relies on vendor security practices
  • Data still transits through vendor networks
  • Compliance scope depends on specific contract terms

Who uses it: Mid-size financial institutions, fintechs with enterprise contracts.

Bank of America and AT&T use private device solutions specifically because they can’t risk shared infrastructure for their mobile testing.

Option 3: Your Own Devices, Peer-to-Peer

The newer approach: use devices you already own, connected through peer-to-peer architecture. No data touches third-party servers.

CircleCI acknowledges the security advantage:

“With a self-hosted testing solution, the developer maintains end-to-end control of the app, the data for testing, and the testing environment. This control makes it easier to address potential security concerns.”

Pros:

  • Complete data sovereignty (data never leaves your network)
  • Your infrastructure = your compliance scope
  • Use existing device investments
  • Scales without per-device cloud fees

Cons:

  • Requires physical devices
  • You manage device health

Who uses it: Security-conscious fintechs, companies with strict data residency requirements, teams that can’t accept third-party risk.

This is the model DeviceLab uses: WebRTC peer-to-peer connections mean your test data flows directly between your CI server and your devices. Nothing routes through our infrastructure.

The Cost Myth

“Cloud device labs are cheaper than on-premise” is the conventional wisdom. But for fintech teams, the math doesn’t hold.

True Cost of Shared Cloud Device Labs

Cost Component Cloud Device Lab Hidden Costs
Per-device pricing $250-400/month Per device
Compliance documentation Not provided Legal/consultant time
Audit preparation Limited support QSA fees, remediation
Incident response Vendor-dependent Unknown exposure
Data sovereignty Not guaranteed Regulatory risk

When you factor in:

  • Time documenting why your test infrastructure doesn’t need PCI scope (it probably does)
  • Audit findings and remediation cycles
  • Risk of breach through third-party vector
  • Premium pricing for “private” cloud tiers

The cloud device lab often costs more than alternatives.

True Cost of Private/On-Premise Alternatives

Solution Monthly Cost Compliance Impact
Own devices + DeviceLab $99/device Your infrastructure, your scope
Enterprise private cloud $10,000+ Depends on contract
On-premise lab CapEx + OpEx Full control

For a 20-device test lab:

  • Shared cloud: ~$5,000-8,000/month + compliance overhead
  • Own devices + P2P: ~$2,000/month, complete data sovereignty

Regulatory Expectations Are Tightening

PCI DSS 4.0 is just the beginning. Regulatory pressure on fintech testing is increasing across jurisdictions.

United States

OCC, FDIC, and Federal Reserve require banks to notify regulators of data breaches within 36 hours of identification. Third-party vendor breaches count.

FFIEC (Federal Financial Institutions Examination Council) mandates documented security testing procedures, including mobile applications.

BSA/AML compliance requires that testing infrastructure—including device labs—support audit trail requirements.

European Union

PSD2 (Payment Services Directive) requires strong customer authentication testing on actual devices.

DORA (Digital Operational Resilience Act) coming into full effect mandates ICT third-party risk management, including testing vendors.

United Kingdom

FCA (Financial Conduct Authority) requires firms to demonstrate operational resilience, including technology testing infrastructure. Their examination manual specifically addresses IT security and third-party dependencies.

The direction is clear: regulators want documented proof that your testing infrastructure meets the same security standards as production.

Questions to Ask Before Your Next Audit

Before you face your QSA, ask your team:

1. Where do test devices physically reside?
If the answer is “a third-party data center,” you have third-party risk that requires documentation.

2. What data do our test flows actually contain?
Even “synthetic” test data often includes card number formats, authentication patterns, and PII structures that could trigger PCI scope.

3. Can we demonstrate data encryption at rest on test devices?
AWS Device Farm admits physical device data isn’t encrypted at rest. Can you explain that to your auditor?

4. What’s our cleanup verification process?
“We trust the vendor” isn’t documentation. What evidence do you have that cardholder data never persists?

5. Who has access to our test infrastructure?
Include vendor employees, contractors, support staff. That’s your third-party access list.

6. What happens if our device lab vendor gets breached?
41.8% of fintech breaches come through vendors. What’s your notification and response plan?

The Path to Compliant Mobile Testing

For fintech teams, the choice is becoming clearer:

Accept third-party risk with shared cloud device labs, document extensively, hope auditors don’t probe too deeply, and carry the exposure of vendor breaches.

Or eliminate the risk by controlling your own test infrastructure.

The second option used to mean massive capital investment. Today, solutions exist that let you:

  • Use devices you already own
  • Keep all data on your network
  • Maintain complete compliance scope
  • Scale without enterprise contracts

Your payment app deserves testing infrastructure that won’t create audit findings or become the vector for your next breach.

When your QSA asks about test environment security, the best answer is: “Our data never leaves our network.”

Frequently Asked Questions

Does PCI DSS allow test data on shared cloud device labs?

PCI DSS Requirement 6.4.3 states “Production data (live PANs) are not used for testing or development.” Cloud device labs where data can persist between sessions create compliance risk, as you cannot guarantee complete data removal from shared infrastructure. For PCI DSS compliance, you need documented proof of data handling—which shared cloud providers typically cannot provide at the device level.

What mobile testing does PCI DSS 4.0 require for fintech apps?

PCI DSS 4.0 requires encryption of cardholder data at rest and in transit, authenticated vulnerability scanning, regular penetration testing, and documented security controls. Test environments must meet the same security standards as production when handling any card data formats. The 64 new requirements in PCI DSS 4.0 place heightened emphasis on MFA, documented roles, and third-party risk management.

How do banks test their mobile apps securely?

Major banks like Bank of America and AT&T use on-premises or private device cloud solutions. These provide dedicated devices, no shared infrastructure, complete data control, and full compliance scope—eliminating third-party risk from the testing pipeline. The premium cost is justified by eliminating audit findings and breach exposure.

What are the risks of using BrowserStack or AWS Device Farm for fintech apps?

AWS Device Farm explicitly states physical device data “is not encrypted at rest” and “data can persist between sessions.” AWS also confirms Device Farm is “not in scope of any AWS compliance programs.” For PCI DSS regulated apps, this creates documentation gaps during audits and potential compliance violations. Sauce Labs acknowledges cleanup can fail, with devices set aside for manual inspection.

What’s the cost of PCI DSS non-compliance for fintech companies?

PCI DSS non-compliance fines range from $5,000 to $100,000 per month depending on transaction volume and duration of non-compliance. Beyond fines, breaches cost fintech companies an average of $5.9 million per incident, plus reputational damage. 78% of consumers will stop using a financial app after a security breach—even if their data wasn’t compromised.

Building a payment app? DeviceLab lets you create a private device cloud using your own devices. Peer-to-peer WebRTC architecture means test data flows directly from your CI to your devices—nothing touches third-party servers. PCI DSS scope stays where it belongs: under your control.

Sources