<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

Building a Risk Framework for Your Microsoft Dynamics Environment

In the last article, we discussed the importance of risk management and how having a formalized approach can lead to more efficient and effective decision making.  Additionally, taking a risk based approach to auditing Microsoft Dynamics is not only best practice, but will save you a tremendous amount of time and money during internal and external audits.


The first step in building a successful risk management environment is building a risk framework. This article will discuss how to develop one at your organization.


A common challenge we see in many Microsoft Dynamics environments is difficulty identifying which risks are relevant to the company.   These companies end up implementing excessive controls or auditing excessive amounts of data because they do not understand where their risks truly exist. This has a major impact on productivity and costs.  To avoid these misdirected activities, companies need to implement effective risk management which begins with knowing thy corporate self.


Every company faces a unique set of risks based on industry, size, location, etc., and every company should conduct risk assessment workshops to identify the specific risks that they face.  To ensure a comprehensive evaluation of risk, the workshops should include key stakeholders and business process owners who have an in-depth understanding of each area of the business.  Separate workshops may be conducted for each business process but it is advisable to include business process owners from related areas like finance and IT in each session.  The output of these workshops will be a prioritized list of risks and the necessary mitigation strategies to minimize risk where it cannot be eliminated.


The first step in the workshop is brainstorming all of the risks that each area of the business may face.  No risk should be discounted at this point because risks that are seemingly insignificant can be found to have far reaching consequences across business processes.  Once the risks have been identified, they need to be scored based on probability and impact.  Probability is the likelihood that a situation will occur.  For a company based in Fargo, there is a very low probability of a hurricane but a very high probability of blizzard.  The exact opposite would be true for a company based in Florida.  For impact, a company needs to consider the consequences of the event.  Does a blizzard knock your Fargo data center offline for 10 minutes or does it destroy your Florida orange crop putting you out of business permanently?  


Once the risks have been identified and scored, a risk appetite or tolerance may be defined.   Something that has a high probability and high impact should be avoided/eliminated or minimized as much as possible with the appropriate mitigation.   Conversely, an event that scores low on both scales may be small enough that it is acceptable to the business and would only require periodic evaluation for change in threat level but no ongoing action.


Now that the risks have been identified and prioritized according to the risk appetite, each risk is assigned to a business process owner.  This individual is now responsible for developing a mitigation strategy for the risk.  The mitigation should be a component of the business process so that it has a minimal impact on productivity while minimizing both the probability that the risk would occur and its impact if it did. The best way to build this type of mitigation is to map it to the business process. The next article will discuss how to build process maps while considering risk and incorporating mitigations.