22 Mar 19 Part 9: It’s All About the Reporting of Risk
access related risk reporting
It’s All About the Reporting of Risk
So you’ve got your super new solution for managing access related risk (we will refer to this as your Segregation of Duties/SoD solution), you’ve got a risk matrix and you’ve identified the risks (conflicts); how do you now report on those risks?
Of course, it goes without saying that perhaps the most important report your SoD solution should include is a report that simply shows everything. This would give a row by row account for every single risk that has been identified.
Let’s assume now that the detailed risk report is the only report you have and walk through a few simple example scenarios…
Scenario 1 – Small
You have a modest user base of 100 Oracle EBS users.
You have a risk matrix consisting of 120 rules and your access control solution found 7,500 risks.
Can you now work through all 7,500 risks one at a time to deal with them?
Can you easily determine which are the most problematic areas to work on first?
Scenario 2 – Medium
You have 750 Oracle EBS users.
Your risk matrix consists of 350 rules and your access control solution found 45,000 risks.
Chances are that by now you wouldn’t even attempt to start working through the risks one by one because the process would simply take too long.
Scenario 3 – Large
You have 7,500 Oracle EBS users.
Your risk matrix consists of 1,000 rules and your access control solution found over a million risks.
Which one of the above scenarios is closest to your situation?
Chances are you are probably somewhere in between scenario 1 and scenario 2, although there are many organizations that would be closer to scenario 3 and some that are considerably larger (one of our customers has nearly 1 million Oracle EBS users).
Understanding and Interpreting the Risks
How you report on the risks is an essential part of helping you understand and interpret them; this is key to help you figure out how you will deal with the risks moving forward.
The goal of your SoD solution at this point is to help you formulate a plan of action as to how you will either remediate or mitigate the risks you have identified but if you just have a huge list of risks, where do you begin?
How do you recognize patterns in the risks that will allow you to deal with them both effectively and efficiently?
You Need More Reports
Besides the main detail report, what other types of reports do you need to help you manage access related risk?
Your SoD solution should allow you to report on the risks summarised at various levels…
- User – this allows you to focus in on the users with the most risk easily.
- Responsibility (Role) – this will help you determine if you have too many privileged responsibilities in the hands of too many users.
- Rule – this allows you to focus your attention on the rules that are being violated the most.
- Function/Concurrent Program – from this you can easily determine if too many users have access to high-risk functionality within Oracle EBS.
In addition to the above, you may find you need many other types of report. For example, it is useful to be able to summarise risk by responsibility and rule so you can see which rules are being violated the most within a given responsibility, this can go a long way to helping you with good role design and thus help reduce access related risk moving forward.
Comprehensive Summary Reporting
The reason that quality and comprehensive summary level reporting is important is because often you remediate or mitigate risk in “chunks” rather than by individual risk; to try to deal with it on a risk by risk basis is near impossible because of the effort required and so the best approach is to analyze the risks to look for patterns as to why a given set of risks exist.
For example, you may have identified that a particular function is generating a large number of risks and further analysis shows that the function is accessible via a particular submenu and the menu is used on dozens of responsibilities, thus potentially affecting dozens or even hundreds of users. The likely remediation, in this case, would be to simply remove the function from the menu and therefore clean-up all those risks in one go.
Often when remediating risks with EBS, you may come across opposition from users who insist they need access to something when in actual fact they don’t, they may only need a subset of the functionality on offer; without the proper tools in place it can be very difficult to determine what your users are actually using on a daily basis and so your access control solution should include some sort of activity monitoring reports; these will allow you to see what users have available to them vs. what they actually use.
Categorization of Risk
To help improve the reporting of risk, your risk matrix (rules) should allow you to categorize the risks by level of risk, i.e. critical, high, medium and low and then your reports should include this categorization thus allowing you to focus in on the areas at most risk as a priority.
Your SoD solution should probably also include some high-level summary analysis reports that are useful when demonstrating to management both the current position of the system in terms of access related risk as well as to show how effective your remediation efforts have been over time.
Our flagship SoD solution CS*Comply, includes all of the above reports and many more.
Want to find out how awesome our access related risk reporting is? Get in touch today and ask us about CS*Comply.
Next Week & Early Access
The final article in this series is “Exclusions, Exclusions, Exclusions“.
If you want to get access to these articles before anyone else, please subscribe to our newsletter.