At a glance
- Client: a bank ranked among the top 20 in its market, serving millions of customers daily
- Problem: external development and QA vendors needed realistic data; real client data could not leave the bank
- Before: in-house masking scripts took several weeks for a 40 TB Oracle database, needed specialist skills to maintain, and struggled to keep data consistent across databases
- After: the full 40 TB database masked in 38 hours - roughly 1 TB per hour
- Verification: the bank ran functional testing on the masked database - all business workflows passed, data masked but still consistent
- Environment: a database copy in a closed, secure network with no external access
The problem: realistic data that must not be real
Vendors doing development and QA for the bank needed data that behaves like production. Handing them real client information was not an option - that access had become a target for penetration attacks, putting data security, customer trust and the bank's reputation at risk.
The bank's own answer was a set of internally developed masking scripts. They worked, but they cost more than they returned: several weeks to run against 40 TB of Oracle, specialised skills to maintain, and no reliable way to keep data consistent across multiple databases. In practice this meant delayed incident management and disrupted release cycles - the safety measure had become the bottleneck.
What was done
The bank's Chief Cyber-Security Officer approached PFLB, and the engagement ran on Datasan, PFLB's data masking product.
Datasan works directly at the database level rather than through an ETL pipeline, which is where the speed difference comes from. It supports Oracle, MS SQL and PostgreSQL, masks over a million table rows per minute with customisable masking functions, and holds to GDPR, HIPAA and CCPA requirements so masked data can be shared with external partners.
The sequence was deliberately conservative:
1. PFLB received a copy of the database inside a closed network with no external access. 2. Engineers profiled the database and identified every field of private data requiring masking. 3. The bank approved that list before anything was masked - no assumptions about what counts as sensitive. 4. The masking run was executed.
Results
- The full 40 TB database was masked in 38 hours, about 1 TB per hour, against several weeks previously.
- The bank's team then ran functional testing against the masked database: all business workflows behaved as usual and every test passed. The data was unrecognisable but internally consistent - which is the hard part of masking, and the part naive approaches break.
- Release cycles sped up, because safe data for vendors stopped being a multi-week dependency.
- The risk of client data leaking through the vendor channel was removed rather than mitigated.
Questions this engagement answers
How long does it take to mask a large production database?
At this scale, 38 hours for 40 TB - roughly 1 TB per hour - working at the database level rather than through ETL.
Will masked data still work for testing?
It has to, or the exercise is pointless. Here the bank verified it: functional testing on the masked database passed every business workflow, because masking preserved consistency across related tables and databases.
Can we share data with external QA vendors without breaking compliance?
That is the point of masking done properly - Datasan's functions are built against GDPR, HIPAA and CCPA so the shared copy carries no real client information.
Why not write masking scripts in-house?
The bank did, and they worked - for several weeks per run, with specialist maintenance and consistency problems across databases. The build-versus-buy question here is not capability, it is throughput and upkeep.
Need to share data safely?
If your QA and development partners are waiting on data - or worse, working on real client records - masking throughput is a release-cycle problem, not just a security one.
