10 Tips to Pay Back Your Salesforce Technical Debt

It can take hours of combing through Profiles, Permission Sets, Permission Set Groups, and more to understand a user’s rights in Salesforce (and how they got them). When your security team is fielding urgent requests for insight into what sensitive data employees who left to work for a competitor could have taken with them, time is of the essence.   

When timeliness causes a pressure to get things done, it can do more harm than good. Granting system-wide access to individuals in Salesforce can give users access to all your data and puts your organization at risk. 

Erick Mahle, Senior Director of CRM at First Advantage, joined David Gibson, Senior VP of Strategic Programs at Varonis, to share best practices for managing and analyzing permissions in Salesforce and how the need for quick solutions can result in undesired outcomes.  

Understanding technical debt 

When organizations forgo standards around Profiles and Permissions in Salesforce, the consequences can pile up into technical debt.  

Being lax in granting users access and not actively reviewing Salesforce Profiles and Permissions happens often, and there are always new projects coming that can keep the debt rolling in. However, when organizations let that technical debt rise, the danger of a cyberattack also increases.  

How can organizations proactively minimize access to their sensitive data and avoid piling on more risk? Erick shared his tips to help businesses pay back their technical debt.  

1. Slow down. 

The simple idea is not to add any more debt than you have to, but that can be easier said than done. Be mindful of what data you’re adding to Salesforce and try your best to use Profiles and Permission Sets that already exist, so you aren’t adding more to the list. 

2. Scrutinize your administrators. 

Ask yourself, who really needs to be a system administrator? Would super admin access suffice? Maybe the user doesn’t need either level of permissions. Limiting your list of administrators and having parameters for who has access gives you better insight into possible risks and is a recommended best practice. 

3. Plan your transition from Profiles to Permissions Sets and Permission Set Groups. 

Salesforce plans to retire Permissions on Profiles by 2026. Auditing the Profiles and Permission Sets you have now and removing unused and redundant Profiles, as well as getting in the habit of not creating new Profiles can help ease this transition before the change officially rolls out. 

4. Leverage assignment expiration when possible. 

A newer feature with Permissions Sets and Permission Set Groups lets you grant assignments with expiration dates, which can help eliminate lingering access for users who no longer need it. If your super admin is on vacation for a week, you can now set an expiration date on their backfills’ access.  

5. Check your organization-wide sharing defaults. 

The sharing defaults for your internal and external audiences may surprise you. Sometimes different departments don’t know what data is sensitive or regulated, and they might make changes or alter the defaults. Routinely check your sharing default configurations to avoid public read rights for everyone by running a Salesforce Security health check on a regular basis. Or, use an automation tool like Varonis to continuously do it for you.  

6. Check guest user profiles. 

If you’re using communities in Salesforce, pay attention to your guest user permissions. Auditing access here can identify guest permissions you aren’t aware of due to updates, new releases, or settings that may have changed. Improperly deactivated and unmaintained Salesforce communities, dubbed as "ghost sites” by the Varonis Threat Labs, remain accessible and vulnerable to risk. 

7. Make sure UAT and sandbox environments are locked down.  

Whether you’re including full or partial data in a sandbox environment in Salesforce, it’s still data that should be shared with caution. Sandbox environments are often full clones of production environments and contain sensitive customer data that system admins and compliance teams may not be aware of. Most of the time, users are granted more access in sandbox environments to make more changes, which winds up giving them access to a lot of data they don’t need or are aware of.  

8. Be mindful of how you manage data in sandboxes.  

Tying into the point above, Erick suggests exporting contacts into an Excel sheet and briefly modifying any names or sensitive data to aliases such as “account 1,” “account 2,” etc., so that sensitive data is concealed. 

9. Beware of broad permissions such as “export” and “modify all data.” 

With too many system administrators comes the risk of unwarranted exports and modifications to data. Someone who doesn’t know the best practices or understand the danger involved with this level of access could be granting more permissions to others, thereby adding more technical debt to the organization. Giving unwarranted access to users is very risky and lead to a toxic combination. For example, giving a disgruntled sales rep read all and export permissions gives them the ability to leave the company with your entire environment.

10. Identify and remove unused and redundant Profiles and Permissions.  

When system administrator access is granted to individuals for specific needs, the list of users starts to add up. Removing unused Profiles and Permissions can help minimize the risk of data being shared or modified when it isn’t supposed to be and help prepare for the upcoming Profile retirements.  

How Varonis can help: 

Varonis’ data security teams untangle settings in Salesforce so you don’t have to, providing you with an aggregate view of user Permissions with a simple click of a button.  

Our SaaS platform quickly gives you real-time visibility into your at-risk sensitive data and automates actions needed to reduce your blast radius. 

To learn more about untangling Profiles and Permissions in Salesforce and how Varonis can help, watch the full session here.