As cyberattacks are on the rise, data security is top of mind for Salesforce professionals. Data security refers to the process of protecting constituent information and using data responsibly.
The Salesforce platform offers various features to support data protection; however, developing a robust data protection protocol at your company is as much about developing a culture of careful data management as it is about leveraging Salesforce tools.
It is a key responsibility of admins to stay abreast of the latest policies, methodologies, and tools to keep information safe. In this article, we’ll take a 30,000-foot view on data security by unpacking the three crucial components of a robust data protection protocol:
- Understanding your data and classifying its level of sensitivity to assess potential compliance, regulatory, and security issues that can be mitigated through upfront planning.
- Protecting your data through a comprehensive security and sharing model, and by taking consistent actions to maintain good security practices.
- Monitoring your data to identify and resolve vulnerabilities before they turn into costly problems.
Understanding Your Data
Understanding your data – its level of sensitivity, any regulatory frameworks that may protect it, and who should and shouldn’t have access to it – is the first and most crucial step in developing your organization’s data protection protocols.
Classifying Constituent Data
Personally identifiable information (PII) is any data that can be used to identify a specific individual and is often protected by regulatory frameworks, like GDPR. The storage of PII may require your organization to develop a data protection and management framework that is compliant with the relevant regulation. Some examples of PII include:
- First name and last name
- Email address
- Phone number
- Governmental IDs (i.e. Social Security Number, National Insurance Number, Tax Id, etc.)
Not all PII is equal. While all personal data should be handled with care, some personal data requires special care due to its sensitive nature. PII is any data that can be used to identify a unique person. Sensitive personal data; however, is any personal data that can be used to cause harm to or discrimination against that person. Sensitive data can include information relating to:
- Race or ethnicity
- Religion or spiritual beliefs
- Political beliefs
- Genetic or biometric data
- Sexual orientation and/or gender identity
- Health status
Sensitive data may also take the form of financial information such as credit card numbers or account passwords.
Understanding and classifying your data enables your team to develop the appropriate data protection rules and protocols. For example, PII might require strict access and visibility controls, whereas sensitive data may require encryption and have a specific, time or usage-bound deletion policy.
Your organization should strive to manage data ethically and transparently. Your specific data protection protocols will depend on the types of data you store about constituents, the consent granted to you by those constituents to store and use that data, and any regulatory frameworks that govern that data.
Compliance and Regulation
Data security is paramount for all organizations that manage constituent data. However, data compliance becomes even more critical and complex in highly regulated industries such as healthcare and finance. It is imperative that your team consults with a data security architect who understands compliance and regulation for your specific industry, if it is highly regulated.
Even in less or unregulated industries, admins should familiarize themselves with the key tenets of regulatory frameworks that protect constituent data (i.e. GDPR):
- Consent for clear usage: Organizations should be transparent about how they intend to use data, and must not use data in any way that exceeds the given consent.
- Data minimization: Only the minimum amount of data (especially PII or sensitive data) should be collected and stored.
- Data accuracy: Data should be kept accurate and up to date.
- Limited retention: Data should not be retained for longer than it needs to be – a clear archival or deletion process should be identifiable.
- Data integrity and confidentiality: Data should be securely processed and access only granted to authorized individuals – the appropriate safeguards must be built into any transfers of data between platforms, systems, etc.
- Data subject rights: Individuals should have access, rectification, and erasure rights over their data – these rights should be made clear to data subjects.
- Breach notifications: Organizations must promptly notify data subjects of any breaches to the security of their data and follow an established response plan to handle security breaches.
- Accountability and governance: Organizations should have a demonstrable data protection protocol that is adherent to any regulatory frameworks that are applicable to the data they hold.
While the list above is not exhaustive or specific to a certain policy (i.e. GDPR), it does outline the intention behind most data protection regulations. Be sure to thoroughly research any data protection regulations that may impact your organization.
Protecting Your Data
Salesforce offers a comprehensive suite of configurable tools and features to support data protection. This constellation of tools can seem overwhelming at first, but by organizing them into functions and adhering to data security best practices, admins can take control of the platform’s flexible data protection functionality.
Security and Sharing
We’ll start by differentiating between two important branches of data protection: security and sharing. Security and sharing protocols work together to ensure that Salesforce provides a safe home for your constituent data.
- Security refers to the protection of a Salesforce org from malicious intent or intruder action.
- Sharing refers to the appropriate visibility of data to users who are permitted to access the org.
Security mechanisms thus prevent unwanted or malicious action being taken on any data in an org via an unauthorized attacker, whereas sharing mechanisms ensure that credentialed users of the org can only see and take action on data that they are supposed to, while protecting the visibility and integrity of data that may be private.
Salesforce is a nuanced machine for data security and sharing, offering admins granular control over who can see and do what. Let’s break down the platform’s security and sharing architecture across four key levels:
- Organization-level security: Defines who can access and interact with your Salesforce org. Salesforce orgs must be secured to only verified, credentialed users.
- Object-level access: Controls what data sets credentialed users can interact with.
- Record-level access: Controls which individual records credentialed users can interact with, protecting specific records from users who do not explicitly require access.
- Field-level access: Controls visibility of specific fields that may contain personally identifiable information (PII) or sensitive data, ensuring that only users who explicitly require access can see this data.
Remember that clearly documenting your security and sharing model is an important part of org transparency. Here, you can access a starter template to help you structure your security and sharing model.
Salesforce Tools and Products
Within each of these levels, Salesforce has a number of tools to enable the configuration of data sharing and visibility rules. Let’s take a look at some of the most important tools for admins to be aware of:
| Level | Tool |
|---|---|
| Organization |
|
| Object |
|
| Record |
|
| Field |
|
*Please note that it is now considered best practice to provision object-level permissions via Permission Sets instead of Profiles.
Salesforce provides a suite of additional products and tools to support data and org security, including the safeguarding of PII and sensitive data. Some important tools to be aware of include:
- Salesforce Shield: Helps to monitor, encrypt, and classify constituent data.
- Security Center: Simplify how you view, analyze, and manage org security in one unified place.
- Privacy Center: Streamline constituent consent to support effective data management and compliance.
- Data Mask & Seed: Protect sensitive data in sandboxes to ensure security throughout your release pipeline
- Backup & Recover: Protect data with automated backup, data loss and corruption notifications, and intuitive restoration.
Data Security Methodologies
Architecting a coherent and comprehensive security and sharing model that meets the needs of the business is not a simple task; however, there are some important, industry-standard methodologies that architects and admins can use to help construct their data protection protocols.
Shared Responsibility Model
With trust as one of Salesforce’s five key values, the platform seeks to provide a secure and reliable infrastructure for clients and their constituent data. Underneath the platform layer, it is still the organization’s responsibility to enforce a comprehensive data security protocol. This is what Salesforce refers to as their “Shared Responsibility Model” – the shared responsibility between Salesforce and clients to jointly protect constituent data.
You can think of the “Shared Responsibility Model” as securing a house. Salesforce is responsible for building a secure house with doors that lock and a sophisticated alarm system. The homeowner, however, is responsible for locking those doors, safely storing the key, and using the alarm system.
Principle of Least Privilege
The Principle of Least Privilege (PoLP) is a decision-making heuristic that should help establish the required level of access for certain users to constituent data. The PoLP suggests that only users who explicitly require access to data should be able to access it, and to the lowest level of privilege possible. Put another way, a security and sharing model should only be as permissive as it needs to be, and no more.
When thinking about the design of a Salesforce security and sharing model, PoLP should prompt questions like:
- Does this user absolutely require this/this level of permission to do their job?
- Can I further limit or reduce permissions in any way?
- Can I further restrict the permissions by time/session?
- Will they still be able to do their job if it’s further limited?
Zero Trust
Salesforce’s Zero Trust policy follows the ethos of the PoLP, specifying that users should have only minimum viable access. With Zero Trust, “a user only has access to specific things applications, services, etc.) through a predefined pathway, thus preventing a hacker from doing a lot of damage in the unlikely event they are even able to gain access.”
Multi-Factor Authentication (MFA) is a key example of Zero Trust in action. Additional Zero Trust best practices include:
- All connections use strong, approved encryption.
- Connections are monitored and closed if they exceed authorization.
- Location is not used as a proxy for device, or used as a sole authorizing attribute.
You can learn more about Salesforce’s Security Best Practices on the security website.
Monitoring Your Data
Continuous monitoring of your Salesforce org and data constitutes an important aspect of your data protection protocol. Monitoring your org ensures vulnerabilities are recognized early and risks are mitigated before they become problems to solve.
Some important ways that admins can monitor the security of their orgs include:
- Running the Health Check: Identifies, prioritizes, and estimates the level of effort to resolve key security risks in your Salesforce org.
- Event monitoring: Ensures that high-risk events are caught early and often.
- Setup Audit Trail: Provides a history of metadata changes to the org.
- Field history tracking: Logs field-level changes to data, creating an auditable trail.
Data archival, scheduled deletion, and backup also form an important part of a secure data management process. While the tools leveraged to ensure data is secure throughout its lifecycle are wide-ranging (from leveraging custom automation to installing third-party tools and applications), your organization’s policy for managing the data lifecycle should be clear.
When building your data protection protocols, ensure that a robust org and data monitoring process is established, and the relevant team members are clear on the cadence of monitoring activities.
Final Thoughts
Safeguarding your constituent data on Salesforce is a top priority for organizations. Salesforce offers a robust set of native and third-party tools to support data security requirements. However, developing a robust data protection protocol is a shared responsibility between the platform and organizations that manage constituent data.
By understanding and effectively classifying your constituent data and understanding the regulatory frameworks that impact how you manage that data, your team can begin to build a compliant and ethical data management framework. Once the data security requirements are clear, admins can protect constituent data by developing a security and sharing model that follows best practice – ensuring that data is safe from cyberattack and accessible only to authorized users who explicitly require access to it. Monitoring org security and data integrity throughout the data lifecycle ensures that security risks are mitigated early and often.
