Managing Salesforce Risk with Security Measures

Most Salesforce breaches start with an ordinary admin decision. A sharing rule gets widened for a project and never narrowed again. A connected app keeps its access after the vendor relationship ends. A guest profile picks up a permission nobody meant to grant. The platform itself is rarely the weak point.

Attackers know this. In September 2025, an FBI alert coordinated with CISA named two groups, UNC6040 and UNC6395, that went after OAuth tokens and third-party integrations to get into Salesforce environments.

With the average data breach now costing organizations $4.4 million worldwide, it makes sense to build safeguards into configuration, development, integrations, and monitoring before something goes wrong.

Where configuration goes wrong

A small configuration change can alter who sees which records and what they can do with them. When you review an org, start with four areas:

• Sharing rules that open records to more people than the business needs
• Profile permissions that allow actions on restricted objects
• Permission sets that quietly work around other access controls
• Organization-wide defaults that expose sensitive records to every internal user

Experience Cloud sites deserve their own review. Misconfigured sites have exposed Social Security numbers, financial records, and health department data to visitors who never logged in.

Since these gaps come from setup, so does the fix. The regulations that govern your data are a good starting point, because they spell out which controls you need.

The regulations behind your security design

Five frameworks show up in most Salesforce implementations. GDPR covers EU personal data, HIPAA covers protected health information, PCI-DSS covers payment card data, SOX covers financial reporting, and FedRAMP covers cloud services sold to U.S. federal agencies.

GDPR

GDPR applies to any organization that processes the personal data of people in the EU, wherever the organization is based. Article 32 of the GDPR requires security appropriate to the risk and names encryption and the ongoing confidentiality, integrity, availability, and resilience of processing systems as examples. The most serious violations can bring fines of up to €20 million or 4% of annual global turnover.

HIPAA

HIPAA applies to covered entities and their business associates. The HHS Office for Civil Rights sets civil penalties in four tiers based on culpability. Under the inflation-adjusted amounts HHS published on January 28, 2026, the minimum per violation runs from $145 for the lowest tier to $73,011 for willful neglect that goes uncorrected for 30 days. That top tier can reach $2,190,294 per violation, and the regulation caps identical violations at the same amount per calendar year. Under a 2019 enforcement discretion notice, HHS applies lower annual caps to the three lower tiers.

If you store protected health information in Salesforce, plan for unique user IDs, access controls, encryption where appropriate, audit controls, and integrity protections that hold up in an investigation.

PCI-DSS and SOX

PCI-DSS applies to any organization that stores, processes, or transmits payment card data. It requires restricted access, unique authentication, audit logging, and protection of stored cardholder data. SOX applies to public companies and their internal controls over financial reporting. If Salesforce feeds those reports, you need segregation of duties, role-based permissions, documented change control, and audit trails.

FedRAMP

FedRAMP, which governs cloud services used by federal agencies, changed a great deal in 2026. Under the Consolidated Rules for 2026 (CR26), released in June, "FedRAMP Authorization" became "FedRAMP Certification," and the Low, Moderate, and High labels gave way to Classes A through D. Class A is a new entry tier that replaces FedRAMP Ready. The legacy Low baseline maps to Class B, Moderate to Class C, and High to Class D. FedRAMP is explicit that a class describes how much assessment information a provider supplies, not how secure the service is.

The FedRAMP Marketplace now lists Salesforce Government Cloud Plus as a Rev5, Class D (High) offering in ongoing certification. It originally earned a Joint Authorization Board P-ATO at the High level in 2020. Certification does not settle every question for a given agency, though. Each agency still makes its own risk decision, and customers remain responsible for the controls they configure inside their orgs. Flosum's guide to Salesforce FedRAMP compliance maps those customer-side controls in more detail.

FedRAMP also requires continuous monitoring. Core controls include least privilege, audit logging, incident response, vulnerability management, and appropriate cryptography. Classes B through D require an independent assessment at least once a year. FedRAMP 20x, the newer certification path, relies on Key Security Indicators and machine-readable evidence that is validated on an ongoing basis.

What the frameworks share

The rules differ, but the controls overlap. Each framework expects access limited to a legitimate business need, encryption in storage and in transit, audit trails of access and changes, retention rules from creation to deletion, and an incident response process that supports investigation and reporting.

Four layers of control

A sound Salesforce security program covers platform configuration, the development pipeline, integrations, and monitoring. Each layer catches a different kind of failure.

Platform configuration

Configuration sets the baseline for how users reach data. Set organization-wide defaults to the most restrictive level the business can work with, then open access where it's needed through role hierarchies and sharing rules. The Salesforce Security Implementation Guide documents these data-access controls in detail.

Every sharing rule should have a written business reason and a review date. Field-level security should protect sensitive fields whether users reach them through a page, the API, a report, or anything else.

Profiles and permission sets decide what users can do, so review administrative permissions, broad data-access permissions, guest access, and external-user settings on a schedule. Keep external organization-wide defaults restrictive on objects that hold sensitive data, and give guest users only what unauthenticated access requires. Where your compliance model calls for it, Shield Platform Encryption adds encryption at rest for supported data.

Development pipeline

Pipeline controls keep vulnerable code and unsafe configuration out of production. Automated checks can include unit tests, linters, metadata validation, and static application security testing (SAST) for Apex and Lightning Web Components. SAST should flag hardcoded credentials, injection risks, cross-site scripting, insecure data handling, and permission changes that could expose data. Run these checks in a sandbox that mirrors production so problems surface before users see them.

Branch protection puts a human reviewer behind the automated checks. Production branches should require review and approval, and your change-control policy should limit who can push changes directly. Policy-as-code can turn written requirements on access, credentials, and other sensitive settings into checks that run the same way every time.

Integrations

Integrations are where Salesforce data crosses a trust boundary, which is exactly what UNC6395 exploited. Connected Apps should use narrow scopes, sensible token policies, IP restrictions where they fit, and admin approval for users.

Named Credentials keep secrets out of code by centralizing authentication settings. When you review Connected Apps, look for unused apps, excessive OAuth scopes, long token lifetimes, and access that isn't limited to approved users. Test the API to confirm that object access, field-level security, and sharing behave as expected for integration users, and give each integration account only the permissions its business process needs. Watch API consumption as well, since a sudden spike against your API request limits can be an early sign of a compromised integration.

Monitoring and detection

Event Monitoring captures API usage, exports, logins, report runs, and other activity. Security teams can use it to spot unusual access volumes, unexpected downloads, repeated failed logins, and activity on sensitive records. Transaction Security applies policies to selected events and can block an action or require extra authentication.

Setup Audit Trail records who changed the configuration and when. Field History Tracking records changes to selected fields, including old and new values where supported. If you need records longer than the native retention windows allow, plan the export before they expire. These records support reviews and investigations, and they let you link a configuration change to a later security event.

Incident response

Write your response procedures before you need them, because the reporting clocks are short:

• GDPR: 72 hours to notify the supervisory authority when notification is required.
• HIPAA: individual notices without unreasonable delay and no later than 60 days. When HHS must be told depends on how many people the breach affects.
• PCI-DSS: obligations depend on the card brands, your acquirer, and the applicable incident response requirements.
• FedRAMP: under CR26, the deadline for an initial incident report depends on the certification class and the incident's Potential Agency Impact N-rating (N1 to N5). It ranges from 15 minutes for the most severe incidents at Class D to one business day for the least severe in lower classes. The new rules can be adopted now and become mandatory on January 1, 2027.

For Salesforce specifically, your plan should cover ending active sessions, revoking permissions, preserving logs and field history, and reviewing or revoking connected-app tokens. Decide in advance how you will restore deleted records if an attacker or a bad deployment removes data. The plan should also name who can declare an incident, who can isolate affected systems, how evidence is preserved, and how systems are checked before they go back into normal use. A tabletop exercise will show whether the plan works under time pressure.

Retention and deletion

Regulators expect you to keep some records and delete others once you no longer have a reason to hold them. GDPR sets no fixed retention period. It says personal data should be kept only as long as its purpose requires. HIPAA generally requires required policies, procedures, and related documentation to be kept for six years.

A Salesforce retention plan has to account for active records, audit data, backups, archives, legal holds, and deletion requests. To handle a GDPR erasure request, you need to find the person's data across standard and custom objects, understand how related records cascade, and deal with copies in your backups.

Legal holds must win over routine deletion whenever records need to be preserved. Document your retention settings and check them periodically to make sure deletion jobs aren't removing data you're required to keep.

Keeping controls working with automation

Every control above needs regular validation, because Salesforce orgs change constantly. Manual checks are slow and inconsistent. Organizations that make extensive use of security AI and automation save an average of $1.9 million in breach costs compared with those that don't.

Flosum DevOps validates each change against a dependency graph of your org before deployment, so missing references and downstream impacts show up before release. It routes changes through approvals and keeps an audit trail, applies policy-based governance to the release process, and lets teams reverse a deployment with one-click rollback.

Flosum offers three deployment options: Salesforce-native, Flosum-hosted cloud, and customer-hosted. According to Flosum's architecture documentation, the functional product is the same in all three. What changes is where compute runs, where data rests, and who operates the infrastructure.

FAQs

Book a meeting with Flosum to see which controls and deployment option fit your Salesforce security requirements.

‍