Salesforce DevSecOps for banks and financial services

In most industries, a Salesforce DevSecOps pipeline exists to catch vulnerabilities before they ship. In a bank, an insurer or a payments company it has a second job that matters just as much: it has to produce evidence. Internal audit, external auditors and supervisors do not only ask "is the code secure?" They ask "show me that every change to production was reviewed, approved by someone other than its author, tested, and traceable." A pipeline that finds bugs but leaves no record does half the job.

This post covers what financial-services auditors typically expect from a Salesforce change process, where Salesforce makes that harder than it looks, and a pipeline shape that satisfies both the security team and the audit file. For the general stage-by-stage build, see our Salesforce DevSecOps pipeline post; this one is about the regulated version.

#What auditors and regulators expect

The exact requirements depend on where you operate and what you do, and your compliance team owns the interpretation. The recurring themes are consistent, though.

#Change control

Every change to a production system that supports financial reporting or customer data goes through a defined process: request, review, test, approve, deploy, record. For companies subject to SOX, change management is one of the core IT general controls auditors test under Section 404, alongside access to programs and data. The auditor samples changes and asks for the trail behind each one.

#Segregation of duties

The person who writes a change should not be the only person who approves it, and should not be able to push it to production alone. Auditors look for this in tool configuration (branch protection, required reviewers, who holds deploy rights), not only in a policy document.

#Evidence of code review

A review needs to leave a record: who reviewed, when, what they saw, what was found, and how findings were resolved. Payment-card environments add a specific expectation here: PCI DSS asks that bespoke and custom software be reviewed for vulnerabilities before release.

#Operational resilience (DORA)

For financial entities in the EU, the Digital Operational Resilience Act has applied since 17 January 2025. It asks for an ICT risk management framework that includes controlled change management, plus incident reporting, resilience testing and oversight of ICT third-party providers. Salesforce is an ICT third-party service, and your own customizations on it are your ICT change. Our post on NIS2, DORA and your Salesforce org covers which regime applies to whom.

#Where Salesforce makes this harder

Salesforce is not a typical codebase, and three things trip up regulated teams.

1. Production can be changed in Setup. An administrator with the right permissions can edit a Flow, a permission set or a sharing rule directly in production, bypassing the pipeline entirely. Your change process is only as strong as your control over who holds those permissions, and your ability to detect when someone used them.
2. Much of the risk is metadata, not code. A permission set that grants View All on Account, or a guest profile that gains access to an Apex class, is a one-line XML change. A code review that only reads Apex will miss it.
3. Flows run with real power. A Flow running in system context without sharing can read and write records its user could never open. Flows are changed by admins as often as by developers, so they need the same review path.

#A pipeline shape for regulated teams

Here is a shape that tends to satisfy both security and audit. Each stage either prevents a bad change or produces a record.

#Stage 1: pull request with a security review

Every change starts as a pull request in source control. Branch protection requires at least one approver who is not the author, and blocks merging on a failed check. The security check runs on the change only, so it does not block on old findings the author did not introduce:

vulkro-sf review --range origin/main...HEAD --fail-on high

When the change touches metadata, the review also reports what the change grants and to whom: a guest or external user gaining access to a sensitive field, a dangerous system permission, a weakened OAuth app. Those access changes count toward the gate like any new finding, which is exactly what a metadata-heavy platform needs.

#Stage 2: findings into the code scanning record

Write SARIF so findings land in your source platform's code scanning view, where resolution is tracked against the pull request:

vulkro-sf scan ./force-app --gate-vs origin/main --format sarif > sf.sarif

#Stage 3: deploy by the pipeline, not by people

Production deployments run from the pipeline under a dedicated integration user. Developers do not hold deploy rights to production. This is the control that turns segregation of duties from a policy into a configuration an auditor can inspect.

#Stage 4: release evidence

At release, generate the documents the audit file needs. A plain change log of what metadata was added, removed or changed between two snapshots:

vulkro-sf metadiff ./release-1.4 ./release-1.5 --format json > metadiff.json

A control report and a timestamped evidence file for the release, plus a SHA-256 attestation so you can later show the file was not altered:

vulkro-sf compliance report --framework sox ./force-app --format markdown -o sox-controls.md
vulkro-sf compliance evidence-export ./force-app -o evidence.json
vulkro-sf compliance attest sox-controls.md --submitter "Security team"

Scans are deterministic, so an auditor can rerun the same version on the same commit and get the same result.

#Stage 5: watch production for out-of-band change

The pipeline cannot see changes made directly in Setup. A scheduled, read-only check of the live org closes that gap:

vulkro-sf org audit-trail --target-org prod
vulkro-sf org effective-perms --target-org prod

The first flags permission escalations and Setup changes made out of hours in the Setup Audit Trail; the second lists who actually holds Modify All Data, View All Data, Author Apex and Manage Users today. Both are evidence for the access-control side of your IT general controls, and both are leads to investigate rather than proof of wrongdoing.

#What a scanner does not do for you

A code security tool in DevSecOps produces findings and records. It does not define your change policy, approve changes, or make you compliant with SOX, PCI DSS or DORA. The control design, the approvals and the sign-off stay with your people. What the tooling does is make the control cheap to operate and easy to evidence, every release, instead of a scramble before the audit.

#FAQ

#What is Salesforce DevSecOps for banking?

It is a Salesforce release process that builds security checks into every change and produces the evidence financial regulators and auditors expect: reviewed and approved changes, segregation of duties between authors and deployers, and a traceable record of each production deployment.

#How do you do a Salesforce DevSecOps code review?

Require a pull request for every change, run an automated security check on the changed lines and metadata, require approval from someone other than the author, and keep the findings and their resolution attached to the pull request.

#Does DORA apply to Salesforce?

DORA applies to EU financial entities, and it covers their use of ICT services. If such an entity runs on Salesforce, the org and its customizations fall under that entity's ICT risk management, including change management and third-party risk.

See how this fits your release process with Vulkro for Salesforce, or Start a 14-day trial. Related: what auditors accept from a scanner.