GDPR's right to erasure and sandbox data masking solve two different problems, and treating them as interchangeable is how compliance programs get caught flat-footed during an audit. Erasure under Article 17 means a data subject's personal data gets deleted from systems where it's processed for a real business purpose. Masking means that same data gets replaced with realistic fake values in non-production environments where no legitimate processing purpose exists in the first place. They're related. They are not the same control, and a Salesforce admin who conflates them will eventually explain to a data protection officer why a deletion request from six months ago is still sitting in three sandboxes.
This matters more than it sounds, because most GDPR right to erasure Salesforce sandbox questions come from exactly that confusion: a company deletes a contact in production, feels compliant, and never checks whether that same contact's name, email, and case history are still readable in a full sandbox the support team uses for training.
What the right to erasure actually obligates you to do
Article 17 gives data subjects the right to have personal data deleted without undue delay, under specific conditions: the data's no longer necessary for its original purpose, consent is withdrawn, the subject objects to processing, or the data was processed unlawfully. Once a valid request lands, the controller has roughly a month to act, and that obligation extends to every system where the data lives, not just the primary production database.
Salesforce orgs rarely store personal data in one place. A single contact record touches Accounts, Cases, Opportunities, Chatter posts, attached files, and often a handful of custom objects built by whoever owned the CRM three reorgs ago. Erasure means finding and deleting the data everywhere it's processed for a business reason. It does not mean finding every copy of it anywhere on Earth, because sandboxes used purely for development and testing fall into a different bucket.
Why masking isn't erasure, and shouldn't try to be
Here's the distinction that trips people up: masking doesn't delete anything. It overwrites real values with fake ones that preserve format and referential integrity, so a masked sandbox still has a record in the Contact object, it just no longer contains John Smith's actual phone number. That's by design. Developers need realistic-looking data to build and test against, and deleting records wholesale would break the very automation the sandbox exists to validate.
Regulators generally accept that non-production environments with properly masked data present a much lower risk profile than environments holding live PII, because the personal data simply isn't there anymore in any recoverable form. But masking a sandbox after an erasure request does not retroactively satisfy that request if the production record wasn't also handled. The two actions need to happen independently, and compliance programs that only track one of them have a gap they usually don't notice until an audit asks for proof.
Where the two obligations actually intersect
The overlap point is the sandbox refresh. Every time a full or partial sandbox gets refreshed from production, it pulls a fresh copy of whatever personal data exists in production at that moment, including anyone whose erasure request was processed last week. If masking runs automatically post-refresh, as it should, that data gets replaced before anyone can query it. If masking is manual, delayed, or skipped for a release crunch, real PII for people who formally requested deletion sits in a sandbox that forty people can access.
This is the scenario that should worry IT directors more than the erasure request itself. A deletion handled correctly in production, followed by a refresh with no masking step enforced, effectively undoes the deletion inside the sandbox. The data subject's record is gone from production and alive again in UAT. Nobody did anything maliciously; the refresh cadence and the masking cadence just weren't synchronized.
| Scenario | Erasure Requirement | Masking Requirement |
|---|---|---|
| Production contact requests deletion | Delete or anonymize in production within statutory window | Not directly applicable until next refresh |
| Sandbox refreshed from production | Not a new erasure event | Mask immediately, before any user logs in |
| Deleted contact's data already cloned to sandbox pre-deletion | Technically satisfied in production | Sandbox still holds real PII until next masking pass |
| Masked sandbox queried by developer | No personal data exposed | Requirement met if masking ran before access |
The table makes the dependency obvious once it's written down, but most masking policies are documented as a sandbox-hygiene control rather than a GDPR control, which is exactly why the connection gets missed in audits.
Building a policy that covers both without doubling your workload
You don't need two separate programs for this. You need one data lifecycle policy that treats production deletion and sandbox masking as sequential checkpoints on the same pipeline, not unrelated chores owned by different teams. Legal or the DPO owns the erasure workflow; Salesforce admins own the refresh and masking workflow. The connective tissue is a rule that no sandbox refresh completes without an automatic masking pass, no exceptions for deadlines.
In practice that means masking triggers off the refresh event itself, not off a calendar reminder someone might miss during a busy sprint. MaskEzee hooks into the sandbox refresh process directly so masking runs the moment the copy completes, before any user session touches the data. That closes the exact gap described above: the window between refresh and masking where real PII is briefly sitting in a lower environment, erasure request or not.
It also helps to keep a short audit log showing when each sandbox was last masked and which refresh triggered it. When a DPO asks whether a specific sandbox could contain data belonging to someone whose erasure request was processed in March, you want a timestamp, not a guess.
Mistakes that create a compliance gap nobody notices until it's too late
The most common failure is assuming masking is a one-time setup. Teams configure masking rules once, feel good about it, then add a new custom object with a free-text field six months later and never update the masking configuration to cover it. The field sails through every refresh after that holding real data, invisible to anyone who isn't specifically auditing field-level coverage.
The second failure is scope creep in partial sandboxes. Partial copy sandboxes are often assumed to be lower risk because they hold less data, but a partial copy built around a flawed filter can still pull in exactly the records tied to a recent erasure request if the filter logic doesn't exclude them. Smaller data volume isn't the same as lower risk; it just means fewer records to check, and fewer records checked usually means less scrutiny, not more.
The third, and the one I find most avoidable, is treating masking and erasure as owned by completely separate tools with no shared visibility. If your DPO can't see when the last masking run happened and your admin can't see when the last erasure request closed, you have two halves of a control that never talk to each other. Fixing that doesn't require new software so much as a shared log and a five-minute conversation between the two teams.
What good looks like in practice
A defensible setup has three characteristics. Masking runs automatically on every refresh, with no manual trigger step that a deadline can override. Field coverage is reviewed whenever schema changes, not just at initial setup, so new custom fields don't become blind spots. And there's a log that ties masking events to refresh events, so an audit question about a specific sandbox has a timestamped answer instead of a shrug.
None of this replaces the production-side erasure workflow, and it shouldn't try to. What it does is make sure that workflow's results actually stick once a sandbox refresh pulls a new copy of your org. Erasure deletes the data where it matters most. Masking makes sure deletion doesn't get quietly undone every time someone clicks refresh.
Frequently Asked Questions
Does masking a Salesforce sandbox satisfy a GDPR right to erasure request?
No. Masking replaces real values with fake ones in a non-production environment, but it doesn't delete anything in production where the original processing occurred. An erasure request has to be handled at the production record level; masking only prevents that same data from reappearing with real values the next time a sandbox gets refreshed.
Can a deleted contact's data come back after a sandbox refresh?
Yes, if the refresh pulled a copy of that contact's data before the production deletion was processed, or if a prior sandbox snapshot was never masked. The data reappears in the sandbox even though it's gone from production, which is why masking needs to run automatically immediately after every refresh rather than on a manual schedule.
Do partial copy sandboxes carry less GDPR risk than full sandboxes?
Not necessarily. A partial copy holds less total data, but if the record selection filter includes anyone whose personal data should have been excluded or erased, that smaller dataset is just as exposed. Risk depends on what data is present and whether it's masked, not on the sandbox's overall size.
Who should own the connection between erasure requests and sandbox masking?
Legal or the data protection officer typically owns the erasure workflow, while Salesforce admins own sandbox refresh and masking. Neither can manage the full risk alone, so the two teams need a shared log showing when sandboxes were last masked relative to when erasure requests were closed.
How quickly should masking run after a sandbox refresh to stay compliant?
Masking should run immediately, as part of the refresh process itself, with no gap where real data is accessible to users. Any delay between refresh completion and masking creates a window where production personal data, including records tied to active or recent erasure requests, sits unmasked in a lower environment.