Most Salesforce teams obsess over masking Account, Contact, and Case records, then forget the PII sitting quietly in their codebase. Apex test classes, static resources, and seed data scripts frequently contain real customer names, emails, and phone numbers copied from production during a rushed debugging session. Salesforce apex test data masking almost never makes it onto the compliance checklist, which is exactly why it is one of the easiest ways to fail a GDPR audit.
Admins tend to think of masking as a database problem. Run the tool, scrub the fields, refresh the sandbox, done. But test data doesn't live in fields alone. It lives in version control, in static resource files, in hardcoded strings inside a class that a developer wrote at 11pm to get a deployment through. None of that gets touched by a standard object-level masking job.
Why Apex test classes become a PII archive
Writing a good unit test requires realistic data. A developer testing a lead conversion trigger needs a lead with a plausible name, email, and phone number. The fastest way to get that data is to copy a real record from production and paste it straight into the test class as a literal string.
It works. The test passes. Nobody thinks twice about it because the class lives in a sandbox, not production. That assumption is the entire problem. Sandboxes get cloned, shared with contractors, connected to CI pipelines, and sometimes exported into public or semi-public repositories.
Once that string is committed to version control, it has a permanent home. Git history doesn't forget. Even if someone later replaces the value with a fake one, the original PII sits in an earlier commit, retrievable by anyone with repo access and a bit of patience with git log.
Where the PII actually hides
It rarely shows up in one obvious place. It spreads across a handful of locations that most masking tools never scan:
- Hardcoded literals inside @isTest methods, especially in older classes written before a team had a data factory pattern
- Static resources used to bulk-insert test records, often CSV or JSON files exported directly from a full copy sandbox
- Custom test data factory classes that reference a fixed set of names and emails reused across hundreds of test methods
- Debug logs and System.debug statements that print full record details during test execution, then get archived in a CI tool
- Mock response classes for callouts, which sometimes embed a real customer payload copied from an integration log
Each of these gets copied forward every time a developer clones the class as a template for new functionality. A single leaked record from 2019 can end up duplicated across dozens of classes by 2025, each one a fresh exposure point.
Why SeeAllData=false doesn't protect you
Some teams assume that because their tests run in isolated data with SeeAllData set to false, PII exposure isn't a concern. That is a misunderstanding of what the annotation actually does. SeeAllData controls whether a test can query existing org data during execution. It says nothing about what literal values a developer typed into the test method itself.
A test class can be perfectly isolated from org data and still contain a real customer's name and phone number as a hardcoded string. The isolation protects data integrity during test runs. It does nothing for data privacy in your source code.
This is worth repeating because it is the single most common misconception we run into with Salesforce architects who assume their DevOps hygiene already covers privacy risk. It doesn't. Test isolation and data masking solve different problems, and treating them as interchangeable is how PII ends up in a public GitHub repo.
The CI/CD gap nobody budgets for
Modern release pipelines run Apex tests dozens of times a day. Every test run against a sandbox executes those hardcoded values, and if the sandbox is refreshed with masked production data but the test class still references an unmasked literal, you now have two versions of the same person's record inside a single org: one fake, one real.
Worse, CI logs from tools like Bitbucket Pipelines, Copado, or Gearset often persist for months. If a test class prints record details on failure, that log becomes a second, unmanaged copy of the exact PII your masking policy was supposed to eliminate. Nobody audits CI logs during a GDPR review, which is precisely why they're a good place for a regulator to ask an uncomfortable question.
Full copy sandboxes compound the risk because they often get refreshed on a schedule and connected directly to CI branches for regression testing. If the refresh process masks object data but the deployed metadata still contains hardcoded PII in test classes, the org is only partially compliant, and partial compliance rarely holds up under scrutiny.
Fixing it without breaking your test coverage
The instinct to just delete the old hardcoded values is understandable, but it risks breaking assertions that depend on specific field lengths or formats, like a validation rule checking email domain patterns. The fix has to preserve data shape while removing the real identity behind it.
That means replacing literal PII in test classes with structurally realistic fake data, generated the same way MaskEzee generates masked production values, so a test asserting on an email format or a phone number pattern still passes. It also means scanning static resources and mock JSON payloads as part of the same masking pass applied to sandbox objects, not as a separate manual step someone forgets under deadline pressure.
| Location | Typical PII found | Standard masking tool coverage |
|---|---|---|
| Apex test class literals | Names, emails, phone numbers | None |
| Static resources (CSV/JSON) | Bulk customer records | Rare |
| Mock callout responses | Full customer payloads | None |
| CI/CD debug logs | Record dumps on test failure | None |
| Sandbox object data | Full field-level PII | Standard |
The table makes the gap obvious. Most masking budgets go entirely toward the bottom row while the top four rows sit unaddressed, often for years, in codebases that dozens of contractors and partner developers have touched.
Building a source-code scan into your masking policy
A practical fix starts with a static scan of your Apex codebase for patterns that look like real PII: email regex matches, phone number formats, and repeated name strings that don't match your organization's known test data conventions. This can run as a pre-commit hook or a scheduled job against your main branch, flagging matches for manual review before they spread further.
From there, replace flagged literals with a shared test data factory that generates masked, format-valid values on the fly rather than hardcoding anything. This is more work upfront than copy-pasting a production record, but it pays for itself the first time a contractor's laptop with repo access gets lost, or a public fork accidentally exposes a private repo's history.
Pair that with masking static resources and mock payloads during the same refresh cycle that masks your sandbox objects. If MaskEzee is already running before every refresh, extending that same policy to scan bundled static resources closes a gap that would otherwise sit outside the tool's normal scope entirely.
I'd argue this is the single most overlooked line item in Salesforce compliance planning. Teams spend months tuning field-level masking rules and almost none auditing what's sitting in their own Apex classes, which is backwards given how easily source code travels compared to a locked-down sandbox.
Frequently Asked Questions
Does Salesforce data masking cover Apex test classes automatically?
No. Standard sandbox masking tools operate on object and field data, not on source code. Hardcoded PII inside an Apex test class literal is untouched by a normal masking refresh and has to be found and fixed separately.
Can SeeAllData=false in a test class prevent PII exposure?
Not on its own. SeeAllData controls whether a test can query existing org records during execution, but it has no effect on hardcoded literal values a developer typed directly into the test method. A test can be fully isolated and still contain a real customer's email address.
Where else besides test classes does hardcoded PII typically show up?
Static resources used for bulk test data inserts, mock callout response classes, and debug logs generated during CI test runs are the most common places. All three tend to be copied forward and reused across many classes over time.
Should we just delete old hardcoded PII from test classes?
Deleting values outright risks breaking assertions tied to specific formats, like email domain checks or phone number length validation. Replace the real values with structurally valid fake data instead, so the test logic still passes.
How often should a codebase be scanned for hardcoded PII?
A pre-commit hook catches new instances before they merge, and a scheduled scan of the full main branch every quarter catches anything older that slipped through before the policy existed. Doing both is more reliable than relying on one alone.