Evaluate Integrations with a Risk Assessment Framework
Integrations are an integral part of Salesforce implementations. However, each integration adds complexity to the system, and as a result, new areas for potential system or business risks. As an architect, understanding these risks is important to maintaining system integrity and security.
While this might seem straightforward on the surface, consistently evaluating integrations and communicating the results with the business can prove difficult in practice without an established process.
Establishing a risk assessment framework and using it to assess new (and existing!) integrations can help guide your evaluation process and create a common language between development teams and the business. In addition, documenting mitigation steps for higher severity risks can provide an accountability structure for ensuring that these risks do not go unaddressed.
This post covers the creation of a risk assessment framework and the application of the framework to some example integration risks. It also covers common use cases where a risk assessment framework can be applied.
But before getting started, let’s consider a fundamental question.
What do we mean by risk?
All of us have some intuition for what we mean when we think of risk, but to create a common language for evaluating and discussing risk, architects need something more concrete.
The widely accepted technical definition of risk is:
Risk Severity = (Likelihood) x (Impact)
Or in other words: Given a possible negative event, the severity of the risk associated with the event is determined by combining the likelihood that the event will happen with the impact of the event if it does happen.
While this definition is a good start, as an architect, you need a way to document the impact, likelihood, and ultimately risk severity in an understandable and consistent way. One way to do this is to assign simple text labels (Low, Medium, High) for likelihood and impact and fill out a matrix that maps out the overall severity of the risk. The row and column headers of the matrix represent likelihood and impact respectively. The risk severity is defined at each intersection.
Alternatively, you might prefer to use a more quantitative approach and assign numeric values to both likelihood and impact. This approach results in risk severity values that are numeric multiples of the likelihood and impact values, for example:
- Likelihood = 9
- Impact = 5
- Risk = 5x9 = 45
The key is clarity and consistency. The numbers or levels are more or less arbitrary; it’s the ability to compare risks relative to each other that is important. Think about how you would like to present information relating to risk and who your audience will be. Then choose a consistent methodology and stick to it.
Establish a risk assessment framework
Now that you have a clearer definition of risk, the next step is to develop a framework that can be used for assessing risks. Again, the key here is to define a process that you can repeat consistently (in this case, for all integrations). Luckily, risk assessments are a standard tool used in many roles across multiple industries and ample material exists for reference. For starters, the NIST Guide for Conducting Risk Assessments is an excellent reference to understanding risk assessment strategies in detail. A more implementation-focused resource is the OWASP Risk Rating Methodology, a risk assessment framework used for evaluating web and software vulnerabilities. The steps outlined in this post are derived from this methodology, but I recommend conducting your own research to align — and refine — your risk assessment based on your specific goals.
To see how such a framework works in practice, let’s go through some sample steps that are commonly included in a risk assessment using real-world risk scenarios that you might encounter when evaluating an integration. I follow these steps in the risk assessment framework that I use for my org.
1. Identify potential risks
The first step of any risk assessment is to identify potential risks. In this case, that means evaluating an integration from a technical and business perspective to determine the potential for any negative impacts. Let’s say for example, you discover that the way in which the integration stores or transfers data poses a risk of exposing customer data. In addition, the integration may require some amount of maintenance, posing a risk to your team’s capacity. Keep a list of each risk you discover:
- Customer data exposure
- Increased team maintenance load
2. Determine the severity of each risk
Next, evaluate the impact and likelihood of each risk in order to establish the severity.
When determining impact, think about all of the possible consequences if the risk is realized. Remember to consider factors both internal and external to Salesforce! As you go through this evaluation process, document all of the factors that contribute to your assessment of the impact.
In this example, which uses the Low, Medium, High approach for documenting impact and severity, the impact of customer data loss is High based on the potential consequences. Likewise, the impact of increased team maintenance load is Low given the small impact to capacity:
Customer Data Exposure
Impact: HIGH
Impact Factors: Loss of customer trust, Potential financial loss
Increased Team Maintenance Load
Impact: LOW
Impact Factors: Small loss of capacity for other initiatives
Next, determine likelihood. When evaluating likelihood, it is helpful to think through specific scenarios that might cause the risk to be realized in addition to specific factors that may increase or decrease the likelihood. Document these factors and scenarios that contribute to your assessment of the likelihood. The likelihood values and factors for this example are:
Customer Data Exposure
Likelihood: MEDIUM
Likelihood Factors:
- Data is encrypted in transit and visibility can be restricted using settings in the package
- By default, all internal users have access to the integration settings controlling data visibility and could make changes
Increased Team Maintenance Load
Likelihood: HIGH
Likelihood Factors: Certain data mapping settings will need to be changed frequently but are only accessible to admin users
Once you have determined the impact and likelihood for each risk, combine them to assign a severity to each risk. Since this example uses the Low, Medium, High approach to documenting risk, the severity is determined using the criteria shown above:
Customer Data Exposure
Severity: HIGH
Increased Team Maintenance Load
Severity: MEDIUM
Here, the Customer Data Exposure risk is High despite having only a Medium likelihood of actually happening. This reflects the severe impact of exposure, however likely. Likewise, the risk of Increased Team Maintenance Load is Medium despite the Low impact since the likelihood of it occurring is High. Accurately evaluating both impact and likelihood is key to a solid understanding of risk severity.
3. Determine the overall risk of the integration
Once you have determined the severity of each risk, you can evaluate the overall risk of the integration. In general, the rule I use is simply to set the risk of the integration to be equal to the highest severity risk identified. In this example, this means that the overall integration risk is High. Assigning an overall risk is useful in situations where you are evaluating a new integration or performing a comparative analysis between solutions; in some situations, however, you may find it unnecessary. Alternatively, the above approach may be too simplistic and you might find that establishing a more rigorous process for determining the overall risk is needed. Keep the context in which you are performing your risk assessment in mind when deciding if or how to determine the overall risk of an integration.
4. Define mitigation steps for each risk as necessary
Defining mitigation steps is arguably the most important aspect of a risk assessment. There’s no use identifying risks if you don’t plan to do anything about them. If any high severity risks (or risks that you or the business are uncomfortable moving forward without addressing) are identified as part of the assessment it will be necessary to determine mitigation steps before proceeding with the integration. These steps should be targeted at reducing either the impact or likelihood of the risk (or both). In this example, after identifying the risk severity of Customer Data Exposure as High, the following mitigation steps are defined:
Customer Data Exposure
Severity: HIGH
Mitigation Owner: Margaret Smith
Mitigation Steps: Update permissions to integration settings to limit access to a selected group of users
In this example, the mitigation step is straightforward, but this is frequently not the case. Mitigation steps might include significant changes to the integration strategy, continuous monitoring, or other actions that require a high level of effort. In these situations, assigning a mitigation owner is an important step to maintain accountability. In general, the owner should be the individual who will perform the mitigation steps.
5. Document results and communicate
In this step, you combine all of the above information for each risk in a single document. Normally, you’d do this as you go through each assessment step. You may want to include a template as part of your framework to help with this step. Here is the template I use in assessments:
Risk: <description of risk>
Impact: <Level or Score>
- Impact factor 1
- Impact factor 2
Likelihood: <Level or Score>
- Likelihood factor 1
- Likelihood factor 2
Severity: <Level or Score>
Mitigation Owner: <Owner>
Mitigation Steps:
- Mitigation Step 1
- Mitigation Step 2
How you format your document will vary depending on the goals for your risk assessment and your audience. For example, if you are using the assessment to provide a recommendation on whether or not to proceed with integration, you might want to focus on only the most severe risks and potential mitigation steps for discussion with business stakeholders. I have found that in addition to the detailed analysis for each risk as seen above, it is useful to create a summary of the assessment to communicate the key information to stakeholders. You can use this template based on the format I use to get started. For this example, the summary might look something like:
Business Owner: Betty Jones
Overall Risk: HIGH
Approved: No — 07/07/2022
Last Assessment Date: 07/07/2022
Overall Integration Risk
Given the assessed severity of the following identified risks:
- Customer Data Exposure HIGH
- Increased Salesforce Team Maintenance Load MEDIUM
The overall integration risk has been deemed to be HIGH and the integration cannot proceed without completing the following mitigation steps:
- Update integration settings to limit access to a selected group of users (Owner: Margaret Smith)
Store the complete outputs of your assessment in a location that is easily accessible for your team as well as your business stakeholders.
6. Rinse and repeat!
Salesforce orgs are ever-changing, and in many cases risks that were once associated with an integration may no longer exist, or more importantly, new risks may exist that didn’t at the time of the original evaluation. It is a good practice to routinely re-evaluate integrations to maintain an up-to-date picture of your integration risk landscape.
Common use cases
Let’s look at a few key scenarios in which integration risk assessments add value.
Comparing integration tools and strategies
When comparing managed packages, evaluating middleware tools, or scoping custom integrations, risk assessment can be a useful tool for comparison. The same identified risk can be evaluated for each of a set of options and the results can be compared to determine the best approach. In addition, considering the overall number and severity of risks associated with each different solution can help determine the best approach. For example, integration tools use and store data from Salesforce in different ways. Evaluating the severity of the risk of unexpected data exposure in light of these differences can help determine which tool is best suited for your use case. Using risk assessment in this way leads to a higher degree of confidence when making recommendations and decisions regarding integrations.
Surfacing risks with requested integrations
When a business unit requests a new integration with an external tool, it can be difficult to effectively communicate risks that might require additional investigation or mitigation to stakeholders. It can be particularly difficult if there is a business urgency or cost associated with delaying an integration project. For example, you may discover an unexpected risk only after a considerable amount of the integration work or testing has been completed. Including a risk assessment as a prerequisite for integration projects as part of your routine architecture process can provide a more consistent and timely way to communicate risks.
Evaluating existing integrations and re-evaluating integrations over time
As your org evolves, the risks associated with an integration can increase or decrease in severity, new risks can be identified, and others can cease to exist. For example, you may discover that an update to a package significantly increases its API consumption putting you at risk of hitting your API limits. Performing a risk assessment routinely on existing integrations can help you uncover previously unidentified risks, divert resources from mitigation efforts that are no longer needed, and increase overall system integrity.
Conclusion
Maintaining system integrity is a key responsibility of every Salesforce architect. By creating a risk assessment framework and applying it to new and existing integrations you can stay ahead of unexpected system or business impacts related to your integrations and ensure they are properly addressed. Next time you are evaluating a new or existing integration with Salesforce, consider running a risk assessment as part of your process. Start with the general steps outlined above and then expand or iterate to fit the specifics of your org and process. You can use this template based on the format I use to get started. Remember, the primary value is in the practice of evaluating risks and addressing them, not in the specifics of how you categorize and label them, so try different approaches until you land on what makes the most sense for you!
