SOX and GDPR Compliance in a Salesforce Release Process

Short answer: SOX asks you to prove that whoever built a change did not release it, and that every production change traces back to an approved request. GDPR asks you to prove personal data was minimised and protected, including in sandboxes. A normal pipeline already produces most of that evidence, so the work is enforcing the controls in the pipeline rather than reconstructing them by hand once a year.

What do SOX and GDPR actually require from a release process?

Two different laws with one overlapping demand: controls that are designed, enforced and evidenced.

• SOX (Sarbanes-Oxley) applies to US-listed companies. Section 404 requires management to assess internal control over financial reporting. In practice your auditor tests IT general controls: who can change the systems that produce financial numbers, and how those changes are approved.
• GDPR applies whenever you process the personal data of people in the EU. For a release process the relevant duties are data minimisation (Article 5), data protection by design and by default (Article 25) and security of processing (Article 32).

Neither names a tool. Both want a control, evidence it ran, and evidence it ran every time.

Which parts of a Salesforce org are in scope?

Not all of it, and deciding early keeps the audit small. SOX scope follows the financial numbers:

• Objects and automation feeding revenue recognition, billing, quoting and forecasting: Opportunity, Order, Product, Price Book, CPQ or Revenue Cloud configuration, discount approval processes.
• Anything that can change those values without a human in the loop: Flows, Apex triggers, validation rules, integration users.
• Profiles, permission sets and permission set groups granting edit access to the above.

GDPR scope has the opposite shape: it follows personal data wherever it lives, usually Contact, Lead, Case, Person Account, chat transcripts, and every sandbox copy.

Write the scope down before the audit. Answering that question for the first time in an audit meeting is how a review becomes a two-week fire drill.

How do you enforce separation of duties without slowing releases down?

Separation of duties means the author of a change cannot be the person who promotes it to production. Change sets cannot enforce that: whoever can deploy can also build. Push the control into the pipeline:

1. Take deploy rights away from humans in production. Only the pipeline's dedicated integration identity deploys. Modify All Data and Modify Metadata in production belong to that identity, not to developers or admins.
2. Make the pull request the control point. Require at least one approving review from somebody other than the author, and disable self-approval in branch protection.
3. Split approval by environment. A UAT promotion can be signed off by the tech lead. A production release also needs the business owner of the affected process.
4. Log the emergency path instead of banning it. Break-glass deployments will happen. Define who may trigger one, require a retrospective work item within 24 hours, and record it as an exception. Auditors accept documented exceptions, not invisible ones.

What change evidence will an auditor accept?

Auditors sample. They pick a few production changes and ask you to walk each from request to release. A pipeline answers with links, not screenshots:

• The work item, with the business reason and the requester.
• The commits, showing exactly which metadata changed.
• The pull request, with reviewer identity and timestamp.
• The test evidence: Apex tests, coverage, static analysis or automated code review output.
• The deployment record: target org, deploy ID, who triggered it, and the outcome.

Two properties make that evidence pass: it must be immutable, and complete, meaning no route to production skips it. A pipeline covering 90% of changes still fails, because the sample can land on the other 10%.

How do you handle personal data in sandboxes without breaking GDPR?

A full sandbox refresh copies production personal data into an environment with looser access and more people in it. That is a processing activity, and it needs justifying like any other.

• Seed, do not clone. Pull a representative slice instead of the whole database. Less data means less exposure and a faster refresh.
• Mask on arrival. Anonymise or pseudonymise personal fields as part of the refresh, never as a follow-up task somebody remembers on Friday. Salesforce Data Mask covers the standard patterns.
• Restrict sandbox access like production. Same profiles, same offboarding. A partial sandbox with real email addresses and a permissive profile is the most common finding we see.

How long do you have to keep the evidence?

Longer than Salesforce keeps it for you. Setup Audit Trail holds a rolling 180 days and can be downloaded as CSV. Field History Tracking retains roughly 18 months in the UI and 24 through the API, unless you licence Field Audit Trail with Shield and set a retention policy. SOX cycles are annual and evidence is requested for the whole period, so the native windows are not enough.

Git plus your DevOps platform fixes this: repository history is permanent, and deployment records live outside the org.

What does a compliant pipeline look like end to end?

1. Every change starts as a work item with a business reason, and lands in version control.
2. Automated review and tests run on the pull request, before a human looks.
3. An approver who is not the author signs off, with a second approver at the production gate.
4. Only the pipeline identity deploys, and every deployment writes an immutable record.
5. Sandbox refreshes are seeded and masked by the same automation, and evidence exports on demand.

None of this needs a separate compliance product. It needs the release process you already wanted, configured so the controls are the only path. Most Salesforce DevOps platforms support it, including Copado, Gearset, AutoRABIT, Flosum and Serpent. More guides live in our SF Guides library.

FAQ

Does SOX apply to our whole Salesforce org?

No. Scope follows financial reporting, so quoting, orders, billing and revenue objects plus the automation touching them. Document the boundary yourself, before the auditor draws it wider.

Can we be SOX compliant using change sets?

It is very hard. Change sets cannot separate the author from the deployer and leave no linked approval record, so you end up building a manual evidence layer beside them.

Is a full sandbox with production data a GDPR breach?

Not automatically, but it is a processing activity you must justify, minimise and secure. Seeding a subset and masking personal fields on refresh is the practical route.

Who should approve a production release?

Someone other than the author, plus the business owner of the affected process for anything in SOX scope. Record both approvals against the change.