Securing Salesforce Sandboxes
Salesforce sandboxes are indispensable for development and testing; however, they can become a security blind spot if not handled correctly. Too often, companies copy production data (including customer PII) into sandboxes under the assumption that “it’s just a sandbox.”
In reality, any personal data in a sandbox is at risk of exposure, especially since sandbox environments usually have looser controls. Developers, QA teams, or third-party vendors may gain broad access to sensitive information outside of production safeguards. Read our Salesforce Security & Compliance Negotiation Guide.
The solution is to secure sandbox test data through the use of Salesforce data masking and encryption best practices. By anonymizing or encrypting data and tightening access, you can reap the benefits of realistic test environments without putting real customer information in jeopardy.
Just as importantly, you can work with Salesforce to get the right tools (like Data Mask and Shield) bundled or discounted as part of your license negotiations.
Why Unmanaged Sandboxes Are High-Risk
Copying production data verbatim into a sandbox means duplicating your sensitive data footprint. Sandboxes often have weaker controls, so any personal data in them faces similar breach and compliance risks as production data – if not more. Think of a sandbox refresh as instantly doubling your exposure. Our goal is to minimize sensitive data in sandboxes (data minimization) and enforce strong controls (least privilege access) so you can safely develop and test without putting real customer data in harm’s way.
Where Exposure Happens in Sandboxes
Even a well-intentioned sandbox can leak data if you’re not careful. Common points of exposure include:
- Over-privileged access: Developers and vendors are often given broad or admin rights in sandboxes, allowing them to see data they shouldn’t.
- Using real customer records: Copying actual customer data for debugging, testing, or demos means personal details are being exposed outside production controls.
- Attachments and logs: Files like contracts, IDs, or system logs with PII get copied into sandboxes but are often forgotten in data scrubbing.
- Integrated test systems: Connected dev/test systems and APIs can receive real personal data from sandboxes if integrations aren’t disabled or sanitized.
- Forgotten sandboxes: Sandboxes that aren’t actively used (and not refreshed or deleted) may sit around indefinitely, still containing sensitive data that people can access.
Salesforce Native Controls to Secure Sandbox Data
Before looking at third-party tools, leverage Salesforce’s built-in options to protect sandbox data:
Salesforce Data Mask (Add-On)
Salesforce Data Mask is a tool that automatically anonymizes sensitive data in sandboxes. It replaces real values (names, emails, IDs, etc.) with fake but realistic values. After each sandbox refresh, your org looks functional for testing but contains no actual customer PII.
Salesforce Shield Platform Encryption
Shield Platform Encryption encrypts field data at rest in your org (including in sandboxes) using strong encryption. It’s great for compliance and as a safety net — stolen database files would be useless gibberish. However, encryption doesn’t hide data from authorized users in the app, so it does not replace masking. Use it as a supplemental layer of defense.
Read how to secure your Salesforce contract. Ensuring Compliance in Your Salesforce Contract: HIPAA, FedRAMP, and More.
Bring Your Own Key (BYOK)
If you use Shield encryption, you can supply your own encryption keys and extend BYOK to sandboxes as well. Use distinct keys for non-prod orgs. This gives you control to rotate or revoke a sandbox key as a “kill switch” if needed, without impacting production.
Enforce Least Privilege Access
Treat sandbox security like production. Nobody should have more access than necessary — for example, most developers shouldn’t be full administrators in a test org. Lock down permissions, and require everyone to log in via your corporate SSO with MFA. This prevents the use of generic or insecure sandbox accounts.
Use Smaller, Synthetic Data Sets
Don’t fill sandboxes with full production dumps. Instead, seed them with a minimal subset of records and synthetic data (fake yet plausible data). This approach satisfies testing needs while practicing data minimization and drastically reducing exposure.
Data Masking Design: Policy Before Tooling
Having a clear policy for data masking is crucial before you run any tools. Key considerations:
- Classify your data: Identify which fields contain sensitive info and categorize them. Consider direct identifiers (names, emails, national IDs), quasi-identifiers (dates of birth, ZIP codes), confidential attributes (salaries, health info), and free-text notes that might hide PII.
- Pick the right masking method: Decide how you will mask each type of data. Options include tokenization (replacing values with reference tokens), randomization or shuffling (mixing up values among records), hashing (irreversible scrambling, useful for IDs or unique keys), format-preserving substitution (fake data that looks real, e.g. same format phone numbers or credit card numbers), generalization (e.g. converting an exact age to an age range), or simply nulling out data that isn’t needed in the sandbox.
- Preserve relationships: Ensure your masking keeps referential integrity. If “John Doe” is replaced with “Jake Deer” in one table, use deterministic masking so that every reference to John Doe becomes Jake Deer across the dataset. This way, lookups, reports, and cross-object relationships still work in the sandbox.
- Cover everything and document it: Include all data in your masking scope – not just structured fields, but also file attachments, documents, Chatter posts, and any place PII could reside. Have a repeatable masking process (a runbook) that covers pre-refresh steps, the masking execution, and post-mask validation. Every time you create or refresh a sandbox, you should consistently apply the same data sanitization steps.
Operational Guardrails for Secure Sandboxing
Processes and policies make your sandbox security truly effective:
- Standardize sandbox setup: Use a checklist whenever you create or refresh a sandbox. For example: disable outbound integrations (to prevent accidental emails or data leaks), load or subset the needed test data, run your masking jobs, then re-enable integrations or automations. A consistent process ensures nothing important is skipped.
- Lock down user access: Give each sandbox user the minimum permissions they need. Ideally, use separate admin accounts for prod and sandboxes. If someone needs temporary admin access in a sandbox, grant it for that limited time and then revoke it. Also, consider IP whitelisting and restricting third-party vendor access to dedicated sandboxes that contain only the data they require.
- Monitor for misuse: Watch activity in sandboxes by enabling logs or event monitoring. Look out for things like bulk data exports or unauthorized queries. Regularly reviewing these logs can alert you to any data exfiltration attempts or inappropriate usage in non-prod.
- Manage sandbox lifespan: Sandboxes shouldn’t live forever. Assign each sandbox an owner and set an expected lifespan or end date. When a project is finished, promptly delete that sandbox (or at least refresh it to wipe data). This prevents forgotten sandboxes from becoming long-term data liabilities.
- Keep audit records: Document your sandbox data protection measures. Maintain a list of which fields are masked/encrypted, when masking was last run in each sandbox, and who has access to each environment. These records will help prove to auditors (and management) that you’re controlling test data properly and consistently.
Negotiation Tips to Get the Right Tools
Acquiring add-ons like Data Mask and Shield Encryption can be pricey, so use savvy negotiation to get them on favorable terms:
- Bundle or discount Data Mask: When buying or renewing Salesforce Shield, push to include Data Mask at little or no extra cost. Emphasize that sandbox masking is a compliance necessity for you, not optional.
- BYOK coverage in non-prod: If you use BYOK for encryption keys, ensure that using those keys in sandboxes comes at no extra charge. Confirm that non-production orgs are covered in your Shield license.
- Pilot first, then commit: Negotiate a trial of Data Mask or Shield in one sandbox. Use the pilot results to justify the purchase and push for a better price. Salesforce is more flexible when they know you’re serious but need proof of value.
- Ask for setup support: Request some free enablement support or training hours as part of the deal. Salesforce could help you design a masking policy or assist with initial setup. This ensures you can implement the tools effectively (and it increases the product’s success in your org).
- No usage limits: Ensure the contract lets you run the masking tool as often as needed in all your sandboxes. There should be no cap on the number of sandboxes or runs. Get that in writing so you can mask data after every refresh without surprise costs or restrictions.
Sandbox Types and Data Considerations
Not all sandboxes are the same. The type of sandbox affects your strategy for test data:
- Developer / Developer Pro: These have very limited storage (only hundreds of MB) and, by default, copy no production records (only metadata). Use them for unit tests or development work with synthetic data. You can refresh Developer sandboxes anytime since they’re small and quick to reset.
- Partial Copy: A Partial Copy sandbox brings over a sample of production data (based on a template you define) and has a moderate storage limit (a few GB). It’s useful for realistic testing without the full data volume. However, it still contains real customer info, so you must mask and anonymize those records. Partial sandboxes refresh less frequently (typically every 5 days), so schedule your masking runs accordingly.
- Full Copy: A Full sandbox is a complete replica of production, making it the highest-risk environment if left unmasked. Full sandboxes can usually only be refreshed about once a month and you have a limited number available. Use them sparingly – if a Partial copy plus synthetic data covers your needs, you might not need to refresh a Full sandbox as often. When you do use a Full sandbox, ensure all sensitive data is masked immediately post-refresh.
Keep sandboxes lean by excluding large or unnecessary data (like old log records or huge file attachments) from copies.
This improves masking performance and reduces risk. And if you find you need more or larger sandboxes for safe testing, plan carefully – you might avoid buying an extra Full copy by using Partial sandboxes efficiently. For more on sandbox limits and entitlements, see our Sandbox Licensing guide (Pillar 9).
90-Day Implementation Blueprint
Need to quickly lock down your sandboxes? Here’s a high-level three-month plan:
- Weeks 1–2: Inventory and classify your Salesforce data to identify all sensitive fields. Draft a masking policy for those fields and choose your tools (Salesforce Data Mask or another solution). Also, decide on your encryption approach (if using Shield, plan how you’ll manage keys for sandboxes).
- Weeks 3–4: Run a small proof-of-concept. For example, take a Developer or Partial sandbox and mask a sample of sensitive data to ensure the results remain usable for testing. Work out any kinks in the process and gather feedback from the team.
- Weeks 5–8: Implement at scale. Apply your masking process to a Full sandbox and automate it to run immediately after each refresh. In parallel, tighten sandbox access controls (review user permissions, enforce MFA/SSO, and lock down or stub any external integrations).
- Weeks 9–12: Operationalize and hand off. Finalize runbook documentation and train admins/developers on the new procedures. Conduct a final spot-check to confirm no real PII remains in sandboxes. By the end of this phase, you should have all necessary Salesforce features enabled and a repeatable, secure sandbox process in place.
Quick Checklist for Secure Sandbox Data
- ☑ Inventory sensitive data – List all objects/fields with PII or other confidential info in Salesforce.
- ☑ Define masking policy – Decide how each sensitive field will be anonymized in sandboxes (mask, truncate, delete, etc.).
- ☑ Plan encryption – If using Salesforce Shield, determine which fields to encrypt and prepare your encryption keys for sandboxes.
- ☑ Separate sandbox keys – Use distinct encryption keys for non-production orgs so you can revoke or rotate them independently from prod.
- ☑ Enforce least privilege – Limit sandbox user permissions; nobody gets more access than they truly need.
- ☑ Isolate third-party access – Give vendors or offshore developers their own masked sandbox or very limited access to a shared one (never full org access).
- ☑ Disable outbound integrations – Turn off or stub out any sandbox integrations that would send data to external systems (no real PII should leave the sandbox).
- ☑ Enable activity logging – Monitor sandbox usage through logs or alerts (e.g. flag any large data export or unusual access).
- ☑ Set sandbox expirations – Refresh or delete sandboxes after a set period or at project end (no indefinite lifespans for test orgs).
- ☑ Document & audit – Keep records of masking runs, which fields are masked, and sandbox access reviews to satisfy audits.
FAQs
Q: Do we still need masking if we use Shield encryption?
Yes. Shield’s encryption protects data at the storage level, but it doesn’t hide data from users who have access to the app. Sandbox users with permissions would still see actual values if you only encrypt. Masking, on the other hand, replaces the sensitive data with fictional values, so even authorized users only see fake PII. In short, you should still mask sandbox data even if it’s encrypted.
Q: Can we enable BYOK in sandboxes and rotate keys independently of prod?
Absolutely. When you create a sandbox from an org using BYOK, it will carry over the production encryption settings at first. You can then upload a different tenant secret (encryption key) for that sandbox. This lets you manage the sandbox’s key separately – you can rotate or revoke it on its own schedule without affecting the production org’s encryption.
Q: How do we preserve test integrity when masking data?
Use deterministic, format-preserving masking for any field that drives reports, lookups, or deduplication logic. Deterministic masking means the same original value is always replaced with the same masked value everywhere (preserving relationships and consistent reporting). Format-preserving means the masked data retains the structure of the real data (so things like phone number lengths, email formats, or ID patterns still look valid). By doing this, your tests and reports will behave correctly on masked data just as they would on real data.
Q: What should vendors or offshore developers be allowed to access in non-prod?
As little as possible. Ideally, give outside teams their own sandbox loaded with only the data they need (and make sure that data is masked or dummy data). Don’t grant broad access to your full sandboxes unless absolutely necessary. In general, apply least privilege and need-to-know: no one in a test environment should see sensitive customer information that isn’t strictly required for their testing task.
Q: How often should we run the masking jobs?
After every single refresh that pulls in production data, without fail, whenever a sandbox is populated with fresh prod data, trigger the masking process immediately (this can be automated to happen right after sandbox creation). If a sandbox isn’t refreshed frequently, you should mask it at least once when it’s created. The key is to never let unmasked production data sit in a sandbox – always mask it as soon as it appears.
Q: What’s the fastest way to start if we’re under audit pressure?
Focus on a quick win. Pick your most sensitive sandbox (for example, a Full Copy) and mask a few critical fields right away – even if you have to do it manually or using a trial tool. At the same time, lock down access to that sandbox (remove any unnecessary users). This will give auditors immediate evidence that you’re addressing the issue. Then present your broader plan (like the 90-day blueprint above) to show that a comprehensive solution is in progress. Auditors appreciate seeing both immediate action and a solid long-term plan.
Read more about our Salesforce Contract Negotiation Service.
