Shield Platform Encryption and data masking solve two different problems, and treating them as interchangeable is how sandboxes end up full of real customer data behind a false sense of security. Encryption protects data at rest and in transit inside your production org. Masking replaces that data entirely before it ever lands in a sandbox, which is the only approach that satisfies GDPR's data minimization principle for non-production environments. Admins who assume Shield covers both are making an expensive mistake, and I've seen it play out at more than one org during an audit.
This confusion isn't random. Salesforce markets Shield as its flagship security product, and it genuinely is strong at what it does. But what it does is narrower than most IT Directors assume, and the gap shows up exactly where it hurts most: in sandboxes that developers, QA teams, and outside contractors touch every day.
What Shield Platform Encryption Actually Does
Shield Platform Encryption encrypts specific fields at the storage layer using keys you control. Data is scrambled on disk, and Salesforce itself can't read the plaintext without the appropriate key material in place. It's a strong control for insider threat at the infrastructure level and for meeting certain data residency requirements.
Here's the part that trips people up: encryption is transparent to anyone with standard field-level access. A user who opens a Contact record sees the real name, the real phone number, the real email address, decrypted automatically by the platform. Encryption protects data from people who shouldn't have access to the database at all. It does nothing to protect data from people who have legitimate login credentials to the org, which describes every developer and QA tester working in a sandbox.
Shield also only encrypts fields you explicitly configure, and not every field type supports it. Formula fields, some lookup relationships, and certain reporting functions either break or get excluded when a field is encrypted, which is why most orgs encrypt a small, targeted list rather than the whole schema. That selective footprint matters once you start comparing it against what masking needs to cover.
Why Encryption Doesn't Solve the Sandbox Problem
When a sandbox refresh pulls from production, it copies the data as the refreshing user sees it, generally decrypted and whole. Shield's encryption travels with the data, sure, but the keys and access that make records readable in production travel right along with it. A developer logged into a Full or Partial Copy sandbox with standard permissions reads the same real customer PII they would in production, encryption or not.
This is the core design flaw in relying on encryption as a compliance strategy: it protects data from external breach of the database, not from the dozens of internal users who have standing access to that sandbox. Outsourced QA teams, contractors on short-term engagements, and junior devs running unit tests all get full visibility into real names, real emails, real financial and health data if your industry touches those categories.
Masking addresses this by replacing the PII before the sandbox is usable, not by locking it behind a key that legitimate users unlock automatically. Once a field is masked, there's no real data left to leak, whether through a careless SELECT query, a screen share on a support call, or a debug log that gets emailed to a third-party consultant.
Where Admins Get the Two Confused
Part of the confusion comes from Salesforce's own documentation, which bundles Shield Platform Encryption, Event Monitoring, and Field Audit Trail under one Shield umbrella and markets the whole bundle as a security and compliance solution. It is, for certain compliance frameworks. GDPR's requirements around non-production data aren't one of them.
Another source of confusion: some orgs do pair encryption with a naive masking script and assume the combination is redundant. It isn't. Encryption and masking operate at different layers and solve different threat models, so running both isn't overkill, it's correct architecture.
- Encryption protects against unauthorized database access and physical theft of storage media.
- Masking protects against authorized users seeing real PII they have no business need to see.
- Encryption preserves the original data for production use.
- Masking destroys the original data in non-production copies permanently.
Those four points aren't academic distinctions. They determine whether your sandbox refresh process actually satisfies a data protection impact assessment or just looks like it does on a slide deck.
GDPR and the Legal Gap Between Encryption and Masking
GDPR's Article 5 principle of data minimization requires that personal data processed in any context, including testing and development, be limited to what's necessary for that purpose. A sandbox used to test a Flow update or validate a new Apex trigger has no legitimate purpose for holding a real customer's home address or national ID number. Encrypted or not, that data shouldn't be there at all.
Regulators and auditors who examine sandbox practices during a GDPR review aren't asking whether the data was encrypted at rest. They're asking why real personal data exists in an environment that forty contractors and offshore developers can access with a username and password. Encryption doesn't answer that question. Only removing or replacing the data does.
I'd go further: pointing to Shield Platform Encryption during a DPIA as evidence of sandbox compliance is the kind of answer that makes an auditor dig harder, not less. It signals that the team understands security tooling but hasn't thought through the actual data flow between production and sandboxes. That's a worse look than admitting the gap exists and showing a remediation plan.
| Control | Protects against | Covers sandboxes? |
|---|---|---|
| Shield Platform Encryption | Database-level breach, physical theft | No — data decrypts for authorized users |
| Field-Level Security | Unauthorized internal viewing | Partial — admins/devs often need broad access |
| Data Masking | Real PII exposure to any sandbox user | Yes — PII is replaced, not hidden |
Running Both Together: A Practical Architecture
The right setup isn't encryption or masking, it's encryption in production for data-at-rest protection, plus masking applied automatically every time a sandbox is created or refreshed. The two don't conflict. If anything, masking makes your encryption strategy easier to manage, because once PII in sandboxes is fake, you no longer need to worry about key management or decryption permissions in those lower environments at all.
This is also where automation earns its keep. Manual masking scripts run after a refresh leave a window, sometimes hours, sometimes days, where real data sits exposed before anyone remembers to clean it up. MaskEzee ties masking directly to the Salesforce refresh event, so the sandbox never reaches a usable state with real PII intact. There's no gap to audit, because there's no gap to begin with.
For teams running Full Copy sandboxes with Shield already enabled in production, the practical next step is straightforward: confirm which fields hold PII across standard and custom objects, map them against your masking rules, and verify the masking engine runs before any sandbox is handed to a developer or QA contractor. Encryption keeps doing its job in production. Masking makes sure that job never needed to extend into test environments in the first place.
Frequently Asked Questions
Does Shield Platform Encryption protect sandbox data?
No, not in any meaningful way. Shield decrypts data automatically for users with standard field access, so anyone logged into a sandbox with a valid account sees the real PII. Encryption is designed to stop database-level breaches, not to hide data from authorized internal users.
Can I use Shield Platform Encryption instead of data masking?
No. Encryption and masking protect against different threats and neither substitutes for the other. GDPR's data minimization principle requires that non-production environments avoid holding real personal data at all, which encryption alone cannot achieve since it preserves the original data for legitimate use.
Do encryption and masking conflict if used together?
They don't conflict and generally work well paired. Encryption protects production data at rest, while masking replaces PII in sandboxes before anyone accesses it, removing the need to manage decryption permissions in lower environments.
Which Salesforce fields need masking even if they're already encrypted?
Any field containing personal data, including names, emails, phone numbers, addresses, and government ID numbers, needs masking in sandboxes regardless of its encryption status in production. Encryption status in production has no bearing on whether that same data is exposed once it's copied into a sandbox.
Will a GDPR audit accept encryption as proof of sandbox compliance?
Generally no. Auditors assessing non-production environments look at who can access real personal data and why, not whether that data was encrypted in its original location. Demonstrating automated masking on every sandbox refresh is the stronger and more defensible answer during a data protection impact assessment.