Six Steps to Establish a Security Governance Model

A robust governance model is key for preventing security breaches

Imagine you are the lead Salesforce Architect on a large transformation program. You are very excited about delivering new features that will provide value to your organization in no time. Yet, you also want to put in place robust security measures to prevent unwanted intrusions. Or, maybe you are the sole administrator for a fantastic nonprofit organization. You want to make sure that only authorized users can access the data stored on the platform. For this, you need to design a robust security model that follows the principle of least privilege.

In both cases, you are well aware of the rich security capabilities provided by the Salesforce platform. You keep the Well-Architected framework as a handy reference, and you have bookmarked its Secure topic for easy access to guidelines. But you’re not quite sure where to start…

This post guides you through establishing security governance for your Salesforce implementation. It covers:

• People — the individuals to involve and how they should work together
• Processes — the steps to be followed at each stage of the delivery lifecycle
• Technologies — supporting artifacts like templates and tools to automate processes

Salesforce implementations range from small to very large organizations. They all have different security needs and capabilities. The recommendations in this post come with a size indication (S/M/L) when applicable.

• Small implementations(S) typically have minimal customization or configurations. There are generally fewer than 100 internal users, fewer than 3 business personas, fewer than 10 integration points and comply with local privacy regulations.
• Medium implementations (M) usually involve small or medium sized projects that can be delivered in less than 12 months. There are generally fewer than 5000 internal users, up to 20 business personas, up to 50 integration points and comply with local and industry-specific privacy regulations.
• Large implementations (L) are multi-year programs with multiple streams of work. They typically involve more than 5000 internal users, more than 20 business personas and more than 50 integration points. These implementations tend to involve organizations in highly regulated industries with very low security risk tolerance.

Step 1. Identify your resources and structure

While it is true that security should be everyone’s responsibility and everyone’s top of mind as they work with Salesforce, a key success factor for robust security governance is to appoint one single person to own the end-to-end security of the platform: the Salesforce Security Architect. This person is in charge of the overall security of the platform on a day-to-day basis, and at every step of the delivery. Some of their responsibilities include:

Defining and implementing security related processes

• Chairing security-related governance meetings and forums
• Enforcing security standards at every step of delivery
• Coordinating security related activities such as monitoring processes, risk assessments, and security audits

Maintaining security-related artifacts

• Defining and maintaining Salesforce security guidelines, standards, and best practices. These should be aligned with your organization’s security standards but also follow Salesforce best practices and take into account new Salesforce security features as they are released.
• Keeping the security section of the technical debt register up-to-date based on findings and the organization’s risk tolerance.

Enabling and guiding the Salesforce technical community within the organization on security best practices.

Depending of the size of your implementation the Salesforce Security Architect role can be fulfilled by:

• A dedicated resource (L)
• The Platform Technical Owner (M/L) (This is the most common approach for organizations that are too small to have a dedicated person.)
• The Release Manager (M)
• The Business as Usual (BAU) Lead (S/M)
• And for small organizations (S), the Admin

The Security Architect is the go-to person for anything related to Salesforce security but they work hand-in-hand with stakeholders across all levels of the organization. They are closely aligned with other stakeholders:

• The Chief Information and Security Officer (CISO) ensures that the Salesforce security guidelines comply with your organization’s security strategy, as well as your industry’s regulations (M/L). CISO is also the Security Architect escalation path when there are deviations from security best practices. In smaller organizations, the CIO or CEO may cover these responsibilities.
  Note: It’s a good idea for CISOs to acquire a high-level understanding of Salesforce platform security capabilities.
• The Chief Privacy Officer (CPO) and Data Owners (M/L) provide guidelines on data sensitivity levels and associated data access. In smaller organizations, business owners are often the de facto Data Owners.
• Salesforce Business and Technical Owners work with the security architect to develop a clear understanding of the platform’s overall security health and any security risks as they define the business and architecture roadmap and make technical decisions.
• Salesforce Technical Leads and Technical Architects look after the next level of detail. They own the applications and are responsible for enforcing security best practices at the application level, designing and implementing security recommendations and defining lower level data access controls in line with the agreed standards.

In the end, everyone involved with the Salesforce platform is responsible for security. It is essential that every developer, business analyst, tester, project owner, and even business user feels empowered to reach out to the Salesforce Security Architect if they have concerns or questions.

Step 2. Establish a set of guiding principles

When you define the platform architecture, it is the right time to also detail your security strategy. This is where the Salesforce Security Architect develops the vision for all activities related to security. The security strategy is the North Star for all downstream processes.

As the owner of the security strategy, the Salesforce Security Architect works closely with the CISO, CPO, platform technical and business owners, and other key stakeholders to define security guidance, standards, and best practices. These need to be tailored to your organization, and take into account several factors:

• You might have industry regulations that need strong security guardrails
• You may need to store and manipulate sensitive data requiring special treatment
• Your Salesforce implementation may be open to users that are external to your organization, such as customers and partners

The best way to define your security strategy is to start with a risk-based approach:

• What are the non-negotiable capabilities?
• What mitigation options are available?
• What risks are you willing to accept?
• What is your risk tolerance? What is the budget, time, and effort your organization is ready to commit to secure the platform further?

Start from your organization-level security guidelines and security principles. These should be provided by your organization’s CISO (M/L). Then, employ Salesforce security best practices as detailed in Salesforce Well-Architected — Secure

• Organizational security and authentication: What are the access channels (UI and API)? What authentication methods do you want to use? What extra enforcements do you need (for example, MFA, SSO, IP restriction, certificates)?
• Data access controls: Work with your Privacy Officer and Data Owners to understand your organization’s data classification and data access guidelines (M/L). Then define how loose/strict your security model should be, based on the type of data and its sensitivity level. Keep in mind that the more locked down the security model is, the more complex it will be to set up and manage. Define an access strategy for your top 10–15 objects based on high-level use cases. The most common ones include Account, Contact, Opportunity, and Case. You may also have highly used custom objects that are specific to your business.
• Persona strategy: Think about what users can access in terms of personas, not individuals. What types of users will access your org? How granular should your business personas be? What level of complexity are you prepared to manage? Is there any specific care required for personas carrying higher risk (for example, personas with high privileges, external personas, unauthenticated access)?
• Secure integration: Work with your integration architect to define secure integration patterns. Check also the latest platform capabilities (for example, Integration User, OAuth Flows, and API Access Control).

And finally, develop tailored Salesforce coding standards and best practices that cover security for your organization. Several public lists are available to use as a starting point. For example, see Drive Consistency and Grow Developer Skills with a Developer Best Practices Checklist.

For more details and examples of content to be covered, see the Salesforce Well-Architected Security Policy Template.

Note: The above activities should be performed at the start of a project or program, before any implementation work. However, the Security Architect should update the security strategy on a regular basis as your Salesforce delivery practices become more mature. To be useful, your security strategy must always stay relevant. Therefore it should be reviewed before the start of any major piece of work or at a minimum annually.

Step 3. Document your processes and activities

Security should be taken into account way before writing the first line of code and long after the application is deployed in production. In fact, the earlier security is considered, the more cost-effective it is to deliver a secure application. There are security activities for every step of your project or program of work.

Organizations with strong security governance keep security in mind at every single step of delivery. It can even be weaved into the release management process, and that’s why we often talk about DevSecOps.

Your organization may have an Architecture Review Board (ARB) to discuss major architecture decisions. This forum is where architects validate that architecture designs are aligned with the organization’s security and privacy guidelines (M/L). Security Architects are usually key stakeholders of the ARB for anything related to security.

The Salesforce platform Technical Owner would usually host a Design Authority Forum every week (M/L) or every fortnight (S/M) to review and endorse design decisions. The Security Architect should assess and endorse all security-related design decisions. For larger programs (L), you might want to consider hosting a separate security governance forum.

Key areas to be covered are:

• Changes to data access controls. The most common ones are related to persona definitions and the impact on the security model.
• Decisions not aligned with the security strategy and its rationale. Sometimes there is a compelling reason for not following best practices. For example, there may be a need to meet a critical business deadline, and it is OK as long as the extra security risk is understood, accepted, and documented. In that case, make sure you record any deviation from the standards in the technical debt register along with the rationale. Sometimes the security strategy needs to be updated, and that’s fine as well. The Security Architect can organize a review at any time with the relevant stakeholders (see the secure architecture principles above).

Take some time to review this checklist for an example of security checks and this template for security design.

Step 4. Ensure that security is incorporated into your build, test, and deploy strategy

Once the design approach is agreed, developers and administrators build the components following the security standards and best practices as defined in the security strategy.

The Technical Lead for the team (S/M) or their delegate (M/L) are responsible for enforcing the standards and practices during the peer review process. This process helps identify defects, improve code quality, and ensure that the software meets the required standards before it is merged or deployed.

There are checks that can be easily automated to facilitate the peer review process and increase code quality (M/L): Use a static code analysis tool (SCA) such as Salesforce Code Analyzer to enforce coding best practices. SCA should be run before any commit and be part of the deployment processes.

• The Salesforce Security Architect usually works with the other technical stakeholders to define relevant security rules for your organization.
• There are some scenarios where it doesn’t make sense to follow these rules. In these cases, a violation exception should be implemented and documented in the code.

Secure Testing

Develop scripts that check specific changes when code is submitted to the source code repository. For example:

• Changes in security configuration such as default sharing settings, profiles, permission sets, sharing rules, and so on
• Code violation exceptions

These scripts can either send an alert, request additional approval, or block the change altogether. See the checklist for examples of other security checks for the build and deploy phase.

Testing is an essential step where you validate that the implementation is actually secure. Testing checks that the application meets business requirements, but it should also check that no unauthorized operation is allowed!
Security testing should be performed at several levels:

• Unit tests should cover both positive and negative tests, especially for custom components. Custom code/configuration should be thoroughly tested for any unauthorized operation.
• Client-side code is often overlooked, even though this area is among the most prone to security risks. Remember that end users have full control of anything that executes in the browser. They can manipulate client-side code in an attempt to gain access to more information and perform unauthorized operations. You can use testing tools like Jest framework for client-side unit test.
• Functional testing should cover both authorized and unauthorized personas. If Experience Cloud is in use, public access must be tested thoroughly to validate that guest users can perform only authorized operations. The Authenticated and Guest User Access Report is a good starting point.
• Penetration testing is also recommended before first go-live (M/L) and before any significant release (M/L). This is usually performed by third-party organizations. Check this page for the most common security questions related to security assessment. Note that customers are no longer required to obtain prior approval before performing security assessments for Salesforce products.

See the checklist for examples of other security checks for the test phase.

Step 5. Document your long-term maintenance activities

Now that your application is deployed, it needs to be maintained to the agreed level of security. Organizations usually have a BAU (Business as Usual) team responsible for all maintenance activities, and this includes security.

One of the usual activities is to manage user provisioning and de-provisioning, and users that change roles. A change of role often involves a change of persona, and access rights need to be modified accordingly. This includes adjusting profile and permission sets, but also updating record-level access to align with the principle of least privilege. For example, should the user still be the owner of the cases they had access to before? Should they still be part of the Account team? User management processes cover all three scenarios: provisioning, de-provisioning, and change of role. Depending on the size of your organization, these can be either manual (S/M) or automated (M/L) processes.

The BAU team would rely on clear guidelines and the personas defined in the Security Architecture design document that was created based on the Salesforce Well-Architected Security Policy Template to eliminate the guesswork when allocating new roles to users.

Other ongoing security maintenance activities include:

• Review Salesforce Critical Updates and apply them as required
• Rotate credentials, keys, certificates, and so on
• Review recently released Salesforce security features and plan implementation for relevant ones

See the checklist for other examples of security maintenance tasks.

Step 6. Establish auditing and monitoring processes

No solution is fully bulletproof, ever. There will always be risks of unauthorized access and missed vulnerabilities. You want to be proactive and identify these security risks as early as possible — and before they become a data breach!
You can identify vulnerabilities that may have been missed in delivery and ongoing maintenance with security audits.

• Strong security governance includes regular security audit routines that can be manual (S/M) or partially automated (L). There are many built-in tools that can be employed to help, but the tools themselves are of little use if there is no one to look at the reports. It is the responsibility of the Salesforce Security Architect to ensure the right processes are in place to take action on the audit findings.
• If you have applications that were built some time ago, or if your Salesforce platform has gone through significant changes since the last audit, you might also consider a full security audit to get a complete picture of risks and vulnerabilities. Smaller organizations may start with the Salesforce Optimizer report. These types of audits though — when performed with the right level of scrutiny — require specialized skills (M/L). The Salesforce Security Architect may need support from specialized third parties in the Salesforce ecosystem or from Salesforce Professional Services. As above, it doesn’t matter how comprehensive your security review is, if the report is used only to fix the leg of that wobbly table! Make sure you have the right processes in place to act on these findings.

For large organizations handling sensitive information and for some highly controlled industries, security threat detection needs to be taken to the next level with proactive monitoring.

• Before investing in expensive tooling, make sure you have a good understanding your attack surface. For example, consider the number of Salesforce orgs you have, third-party applications that connect to your orgs, Experiences sites, Web-to-Case and Web-to-Lead forms, email services, and so on. Develop a threat model that is adapted to your security needs, with the right resources and processes.
• Salesforce also offers a suite of tools as part of Salesforce Shield. There are two important ones among the many advanced security features that Salesforce Shield provides. With Shield Event Monitoring, you can get access to key activity information. You can use it as-is or integrate with third-party monitoring tools. But just enabling Salesforce Shield does not mean you are protected from intrusions! Shield Event Monitoring is useless if there isn’t anyone to look at the logs. Some organizations go one step further with Enhanced Transaction Security. Transaction security policies enable you to control user activity in a much more granular way and prevent operations like the full customer list export from a report.
• Another great way to identify vulnerabilities is to engage with ethical hacker services. Bug bounty programs are initiatives to encourage and reward individuals who identify and report security vulnerabilities or bugs in software. Their goal is to improve the security of your systems by making use of the collective intelligence, expertise, and specialized tools of external security researchers. Instead of relying solely on an internal security team, you can engage the global community to identify vulnerabilities that may have been overlooked.

See the checklist for examples of security audit routines and monitoring tasks.

On the importance of capturing security vulnerabilities and assessing their risk level

Having covered the main phases of the development lifecycle in the sections above, it’s fairly easy to see numerous areas in which new security vulnerabilities can be identified. For example:

• External constraints — such as delivery timelines, business priorities, and project funding — that come into play to justify tactical decisions.
• Misses during peer reviews
• Vulnerabilities that are found late in the process, during regular audits or penetration tests
• New ways of compromising an application that need to be mitigated

The Salesforce Security Architect is responsible for documenting these vulnerabilities as they are identified. One good place to list them is in the technical debt register under the Security category. You can then assess the criticality level following your organization’s risk assessment framework, similar to this one. Based on this, you can decide on the action to take: remediate fully or partially or accept the risk altogether. Don’t forget to assess any residual risk. Risks that need to be remediated can then be allocated the right level of funding and prioritized in the backlog based on the level of urgency.

Not knowing about your system vulnerabilities doesn’t make your platform any safer. All this takes time, but you still want to ensure that your Salesforce implementation meets your organization’s security requirements and industry regulations. And for this, you need to have as comprehensive view of those vulnerabilities as possible. It’s actually healthier to have a large list of well-documented security findings with a risk assessment and an agreed remediation path, than an empty technical register, hoping really hard that nothing bad is going to happen. Security-related technical debt can be tracked in the Technical Debt Register template.

Conclusion

Robust security governance for your Salesforce platform is essential, regardless of your organization’s size. With Salesforce built-in rich security features, you have all that you need to build the guardrails to protect your organization’s data. With this post, along with the Well-Architected framework, you are better equipped to confidently develop these measures by:

• Engaging in collaboration with key stakeholders
• Establishing well-defined processes
• Employing suitable technologies and tools

Supporting Templates

Below is a list of templates that you can use as starting points to put in place the processes detailed in this post.

• Salesforce Well-Architected Security Policy Template
• Design Template (Security Section)
• Definition of Done for Security
• Key Permissions to Watch for in Salesforce
• Security Maintenance Checklist
• Technical Debt Register

Additional information can be found in the Tools and Resources tables of Salesforce Well-Architected — Secure