Data Masking for Banking Test & Dev Environments

In April 2026, Citizens Bank confirmed a data incident tied to a third-party vendor, and the ransomware group Everest claimed to have exfiltrated 3.4 million records. The bank's defense was that most of what was taken was "masked test data" rather than live production records — but plaintiffs' counsel immediately flagged the obvious follow-up question: if the masking was insufficient or reversible, the bank still carries full liability (The CyberSignal). Two months earlier, BSP Financial Group in Papua New Guinea disclosed that a third party had accessed its non-production test environment and taken a portion of the dataset — customer accounts and production systems were unaffected, but the test environment itself was the point of entry (RiskMasters).

Neither incident happened in production. Both happened anyway, because test environments have quietly become one of the most exposed parts of a bank's data footprint. Industry research backs this up directly: 60% of organizations have experienced a data breach or theft in non-production environments, an 11% increase from the year before (QA Financial). Financial services breaches now average $5.56 million per incident, the second-highest of any industry after healthcare (IBM Cost of a Data Breach Report 2025, via IncidentCost.com).

What regulators actually require for banking test data

This isn't a gray area — the rules are explicit, and they apply to test and dev environments just as much as production.

PCI DSS 4.0. Requirement 6.5.4, mandatory since March 31, 2025, states plainly that production account data — including primary account numbers — shall not be used in test or development environments. This is a shall-not requirement with no exception mechanism for internal, access-restricted, or "trusted" test environments, and it applies across dev, test, staging, QA, and UAT (Sovereign Forger). Requirement 3.4 adds that wherever PANs are stored — including in non-production systems — they must be rendered unreadable through encryption, truncation, tokenization, or hashing. If your team needs realistic-looking card numbers, the standard's intent is to use properly generated test data rather than reuse real ones, masked or not, without documented controls (PCI Security Standards Council FAQ).

GLBA Safeguards Rule. The rule treats every environment containing customer information as in-scope — not just production. Programs that apply controls only to the production tier are, by definition, non-compliant. That includes staging, QA, demo, analytics warehouses, ML training sets, and vendor-hosted systems that touch customer data (WealthSchema, GLBA Safeguards Rule implementation guide).

The common thread across both frameworks: there's no "it's just test data" carve-out. As one industry analysis of financial-services test data compliance put it, "the rules that apply to production data now apply to test data as well. There's no hiding behind 'it's just test data' anymore" (QA Financial).

Why "copy and pray" doesn't hold up anymore

The most common failure pattern in banking test environments has a name in the industry: "copy and pray" — teams copy production data directly into test systems with no masking, or with masking implemented so inconsistently that it doesn't actually hold up. Auditors reviewing these environments routinely find the same gaps: missing access logs, no data inventory, and unmasked or under-masked data spread across systems no one fully tracked (QA Financial).

The Citizens Bank case is exactly why this matters beyond a compliance checkbox: "masked" isn't a legal shield if the masking wasn't strong enough to prevent re-identification, or if it was reversible. Courts and regulators can — and increasingly do — force discovery into whether "test data" was actually properly de-identified production data or just relabeled production data (The CyberSignal).

A practical framework for masking banking test data

1. Inventory before you mask anything. Document every instance of sensitive data across every non-production environment first — core banking systems, data warehouses, vendor sandboxes, QA and UAT, analytics. You can't apply the right regulatory requirements to data you haven't found yet (QA Financial).

2. Match masking technique to field type and regulation. Different fields need different treatment to stay both compliant and testable:

• SSNs and account numbers: format-preserving substitution so length and checksum logic still validate correctly.

• Account balances and transaction amounts: shift by a random percentage to preserve realistic ranges without exposing actual figures.

• Customer names: replace with synthetic names from a lookup table rather than blanking them out, so name-matching logic still functions in tests (Sun Technologies, automated TDM guidance).

• Card numbers (PANs): never use live PANs at all — pull test PANs from your acquirer per PCI DSS guidance, don't just mask real ones.

3. Preserve referential integrity across every connected system. A masked customer ID needs to map consistently across the core banking platform, the CRM, the billing system, and any downstream reporting layer — a large Canadian bank's test data program for its Temenos Transact core banking system specifically had to preserve these relationships to keep test results valid while removing real customer exposure (Accutive Security case study).

4. Extend masking to third-party and vendor access. A significant share of banking test-data exposure happens specifically because outside vendors and QA teams need "realistic" data and get more access than they should. One bank's approach to this: mask the data before it ever reaches the vendor's environment, so external teams get functional, realistic data without ever touching real customer records (PFLB case study).

5. Refresh continuously, not through a one-time export. Static test data exports go stale the moment schemas change or new customer fields get added — which is exactly how teams end up quietly re-pulling raw production data "just this once" to catch up.

Common pitfalls that undermine otherwise-good programs

• Partial or reversible masking. Masking that can be reverse-engineered, or that only covers the "obvious" fields (name, SSN) while missing indirect identifiers, doesn't satisfy PCI DSS or GLBA — and as the Citizens Bank case shows, it may not hold up as a legal defense either.

• Assuming vendor environments are someone else's problem. If a vendor's test environment holds your customers' data, your Safeguards Rule obligations still apply to it — the rule explicitly extends to service-provider-hosted systems.

• Treating test environments as lower-priority for security controls. BSP's incident happened in a non-production environment specifically because it had different (and weaker) controls than production. Regulators and attackers both know this, which is exactly why test environments are described as "a prime target" in current QA/compliance guidance (QA Financial).

A short checklist before your next test cycle

• Do you have a current inventory of every non-production environment and vendor sandbox that touches customer or cardholder data?

• Is masking applied automatically and consistently, or does it depend on someone remembering to run a script before a data refresh?

• Does your masked data preserve referential integrity across every connected banking system, so tests still produce valid results?

• If a regulator or plaintiff's counsel asked you to prove your masking is irreversible, could you show the documentation today?

• Do vendor and third-party teams ever get direct access to unmasked production data, even temporarily?

The bottom line

Banking test environments have to work like production — realistic data, complex relationships, accurate edge cases — without being production from a compliance standpoint. That gap only closes safely with masking that's automated, consistently applied, and genuinely irreversible, not a one-time export or a manual scrub that misses indirect identifiers.

C² Data Privacy Platform discovers sensitive data across your core banking systems, databases, and vendor-facing environments and masks it automatically before delivery — so test and QA teams get realistic data without the regulatory or legal exposure that comes with "copy and pray." Book a demo to see it run against your own schema.

Sources: The CyberSignal — "Citizens Bank Hit With Two Federal Lawsuits After Everest Attack", RiskMasters / BSP Financial Group market announcement, QA Financial — "Test data compliance in financial services under the spotlight", IncidentCost.com — Financial Services breach cost data, PCI Security Standards Council — Navigating PCI DSS, WealthSchema — GLBA Safeguards Rule implementation guide, Accutive Security case study, PFLB case study, C² Data Technology.