Salesforce Administrator
Updated on October 7, 2023.
Data protection is a critical aspect of compliant application lifecycle management. Why? Well, just like you develop a governance framework to comply with regulations in your production instance, you need to do the same in the ALM process.
Depending on your industry and country, you might be subject to regulations like SOX, HIPAA, CCPA, PCI DSS, or GDPR when you use test data or make changes that could impact data integrity in Salesforce. For your data governance framework, you need to think about security; roles and duties; enforcing access controls; and masking, scrambling, or redacting test data.
When it comes to data governance for compliance, security is nonnegotiable. Moreover, data security helps build and maintain customer trust—and that arguably plays a significant role in any company’s success. Salesforce provides a range of security measures you can use, including SSL technology, encryption for user authentication information, and an advanced firewall to prevent intruders from accessing your information.
On top of that, there are a couple of additional measures you can take to beef up your security: encryption and desktop-free data migration.
Advanced measures like encryption help mitigate the risk of data breaches. Even if a bad actor somehow gains access to your information, without the decryption key, there’s a good chance they can’t do anything with it.
Another aspect of data security—and one that’s equally important—is eliminating the risks involved with data transfer in the application lifecycle management process. Let’s say you use a data loader to move data from your production environment to a sandbox. You’ll have to download everything to a CSV on your desktop before pushing it into the sandbox. This opens up a plethora of opportunities for data loss and corruption.
For instance, if you walk away from your laptop while the file is open, someone could see sensitive information. At the same time, if you forget to delete the file from your desktop and you computer is later hacked, you risk bad actors getting their hands on all that data.
You can eliminate this specific risk with a desktop-free data migration tool like Prodly. With Prodly, you neatly sidestep the issue of download data to your desktop. Instead, it always stays within the Salesforce cloud. That means your information is just as safe as it is in your Salesforce production org.
A sound data governance framework includes certain roles that promote accountability within the organization. When it comes to complying with data protection requirements, you may also be obligated to define roles more specifically according to the principle of least privilege. You might also have to enforce segregation of duties (SoD) and set up an auditing function.
A robust Salesforce governance framework includes the following roles and responsibilities:
To further narrow down roles and responsibilities, clearly define which individuals on your team can access, manage, modify, and approve changes to each data type. This ties into implementing access controls, which we discuss later in this blog.
Let’s examine how to implement access controls for regulations like SOX and GLBA.
If you’re subject to SOX compliance, you need to limit who can access financially-impacting information. In ALM, this means ensuring that only authorized team members have access to record data or configuration data that could impact financial reporting processes. It also means you should never replicate sensitive financial data for testing purposes without masking or obfuscating it. Otherwise, you’re leaving your organization open to fraud.
Similarly, if you need to adhere to GLBA regulations, it’s critical to only give access to nonpublic information (NPI) to team members who need it to do their job.
When a release manager is preparing a development environment, they might need access to NPI to seed a sandbox with realistic data.
However, the developer doesn’t need to see the actual information in order to make any changes—all they need to know is how the changes impact that type of data. In this situation, you shouldn’t give the developer access to NPI. This is where data masking or obfuscation comes in, which we discuss shortly.
You should also determine who’s responsible for the auditing of how sensitive info is handled. Some organizations set up a separate auditing function while others integrate auditing into the release management process. Whatever you decide, it’s essential to perform regular audits to ensure your ALM process protects data integrity in Salesforce.
By establishing clear roles and responsibilities, you can promote accountability and efficient data handling. This helps minimize the risk of errors in data management.
Several regulations and industry standards—including SOX, HIPAA, GDPR and PCI DSS—require you to enforce segregation of duties. SOD acts as a checks-and-balances system that keeps your organization in compliance. By enforcing SoD in the ALM process, you ensure that no single person has control over the entire change management process.
Think of it like this: You wouldn’t want the person who cuts your payroll checks to also manage the bank reconciliation process for your company. This could give them the opportunity to—for example—beef up their own salary without anybody else being aware they’re committing fraud.
Similarly, in Salesforce, the individual who modifies metadata or configuration data—in Salesforce CPQ or Billing, for example—should not approve or deploy those changes.
The reason for this is that unauthorized changes can have serious repercussions. Let’s say someone makes a modification that inadvertently affects financially significant information. This can set off a chain reaction that impacts related records—and alters sensitive data. This leads to inaccurate financial reports. When it comes to light that you’ve fallen short in your reporting obligation, it can erode the trust the public and shareholders have in your company—and put you at risk for noncompliance with SOX.
Not all unauthorized changes are made by bad actors. For example, a well-intentioned team member could accidentally modify a critical pricing field. If you don’t catch this error immediately, it can result in widespread miscalculations in your financial reporting. Worse: The process to rectify the situation is likely to be both costly and time-consuming.
Separation of duties drastically reduces this risk. It ensures that all modifications are reviewed by a second—and sometimes third–set of eyes before they’re approved and implemented.
A DevOps compliance tool like Prodly makes it easy for you to adhere to this policy. Prodly lets you set access controls at the environment level during the change management process. That way, you can prevent developers and admins from deploying unauthorized changes to production.
Access controls play a fundamental role in data protection. Because the principle of least privilege applies, you can leverage access controls to ensure employees can only utilize data according to the demands of their job.
Salesforce provides several options for controlling access, including the use of profiles, permission sets, sharing rules, and field-level security. By combining these controls, you can minimize the risk to sensitive info.
Role-based access controls are critical in protecting data privacy. Access controls act as gatekeepers that enforce the usage of your PII or other sensitive data according to the roles and responsibilities you defined.
Remember: Not every team member needs full access to all the information. When you developed your Salesforce governance framework, you already set up a data classification process and determined how each class should be handled. Now it’s a simple matter of math to determine which roles need access to what types of info and how they can use it.
A robust Salesforce change management process includes frequent testing of modifications to code, metadata, or configuration data. To test effectively, you need test data that’s as close to the data in your production org as possible. At the same time, to ensure data protection and privacy, you need to protect sensitive information from unauthorized use. So you can’t just replicate data from production and move it into a sandbox.
Let’s talk about SOX data compliance, for instance. Imagine a scenario where a developer is testing changes to a process that calculates revenue or reports on financial info. They shouldn’t be allowed to see the actual input because they don’t need to know those facts to do their job. Plus, even if the developer is trustworthy, there’s always a chance that a bad actor could gain access to their computer… and the information.
However, the developer does need to know what the impact of the modifications to the process will be on sensitive financial data in the production environment. In other words, they need a real-world scenario to test against without seeing actual financial information.
This is where Prodly’s sandbox seeding and 1-click scratch orgs come in. Both of these solutions allow you to instantly create production-grade environments with high-quality test data—without risking noncompliance.
Sandbox seeding is a highly useful feature that instantly replicates data from your production environment into up to five environments in one go. It offers data masking and data obfuscation so what the admin or developer sees isn’t an accurate representation of the real information at all. You can also use Prodly to redact data at a granular level to anonymize it.
Prodly’s 1-click scratch org solution lets you create a scratch org with the option to install packages, metadata, and data. Before clicking “Create Scratch Org,” you can opt for data anonymization or pseudonymization. After you click, your scratch org appears—with everything that you need to develop high-quality configurations already in it.
In a time where data-centric business models dominate, effective data protection is essential to compliance in Salesforce ALM. The principles we’ve discussed, from clear role definition and segregation of duties to desktop-free data migration and data anonymization, all contribute to a robust data protection strategy. By incorporating these principles into your Salesforce ALM process, you can ensure regulatory compliance while upholding the highest standards of data integrity and security.
What additional measures can I take to enhance my data protection strategy within Salesforce ALM?
In addition to the effective measures listed above, experts advise organizing regular employee training and awareness programs. This helps keep your team updated about the latest data protection practices and potential vulnerabilities. It’s also wise to consider regular third-party audits for objective reviews of your data protection measures.
What is the principle of least privilege?
The principle of least privilege recommends giving users the minimum level of access necessary to perform their job functions. Because you only give users the permissions they need to complete their tasks, you minimize the potential for data exposure or unauthorized access.
How do I protect sensitive data during the testing phase in Salesforce ALM?
You can ensure data security during the testing phase by using anonymized data that closely resembles the actual data but doesn’t contain any sensitive or real information. With Prodly, you can create test environments with real data from production that you mask or redact so it’s unreadable. That way, you don’t risk noncompliance.
The gold standard for documenting SOX in Salesforce CPQ!
