Part 2: Why do we need a tool to manage access related risk?

Why do we need a tool

access related risk tool

Why do we need a tool to manage access related risk?

This is a question we get a lot. If you have not yet read our previous article titled “Why managing SoD is such a BIG deal” then I recommend that you give it a quick read now. It discusses the main reason why a tool is needed to help manage SoD, but if you need more convincing that dealing with this issue without an access related risk tool is impossible, then read on.

From our experience of talking to organizations, the term “managing access related risk” really comes down to 3 separate requirements…

1. How can we identify the potential risks?
2. Once identified, what do we do about it?
3. How do we prevent new risks from being introduced?

The primary focus for many organizations is around identifying and understanding the risks. Some go on to do something about the risks and very few do much to try and prevent new risk from being introduced.

To be able to satisfy each of the three requirements effectively and efficiently without a software solution is very difficult at best and often impossible. Let’s take a quick look at why this is the case.

How can we identify the potential risks?

A tool is essential if you want to identify access related risk quickly and effectively. For many (in fact most) organizations, the volume of data involved is vast, so huge in fact that trying to do it manually without any software is utterly impossible. The task is so big that even a single pass of the system may never be completed (if done correctly) and so the only way to solve this particular requirement is to have software do it for you.

Once identified, what do we do about it?

Once the risks have been identified, there are 3 choices about what you do about them; these are…

1. Do nothing

Maybe you don’t need to do anything other than identify the risks.

2. Remediate the risk

To remediate the risk means to remove it; you can remove access in Oracle EBS in a number of ways…

  • Revoke access to the conflicting responsibility.
  • Create some function and menu exclusions for the conflicting responsibility.
  • Amend the conflicting menu.
  • Revoke access to the conflicting responsibility and replace with one less privileged.
  • Create a new responsibility and associated menu with the conflicting functions removed.

Without software automation, the process of remediating risk can itself be a complicated and very time-consuming process; not to mention the fact that you will likely not even know what to remediate.

We will be publishing an article later in this series that looks at risk remediation for Oracle EBS in a little more detail.

3. Mitigate the risk

Mitigating the risk means you need to look at ways to reduce the risk while not entirely removing it.

There are many things you can do to reduce the risk.

An excellent way to mitigate risk is to ensure accountability by implementing an audit trail. An example would be the creation of an audit trail of additions, deletions, and changes to suppliers since the system doesn’t have such an audit trail out of the box. Then someone separate from those doing the data entry would trace the actual changes back to supporting documentation to validate the completeness and accuracy of the data entry. This could be done via a complementary solution in our suite – CS*Audit.

Without software automation, your options for mitigating controls might be limited.

With a software solution in place, you can implement your mitigating controls (i.e., an audit trail or lookback analysis) and also use the software to help you create the required documentary evidence against the risks so that you need not repeat yourself each time you get a fresh list of risks to work through.

How do we prevent new risks from being introduced?

So, you have identified the risks and either remediated or mitigated them.

What now?

For most organizations, the process of managing SoD is a never-ending process that exists for the lifetime of the applications. This does not mean you have to repeat yourself over and over, but it does mean that managing SoD should be part of the typical day to day operational aspects of managing a large-scale ERP system.

With a software solution in place, new risk is managed as it is introduced with some risks re-visited periodically. A software solution such as CS*Comply can help you manage all of this. However, with the right solution in place, you can begin to take a more pro-active approach and, that is, to prevent some risks from ever being introduced.

This is achieved with preventive controls; this is where the software looks for risk in real-time when any new access to the system is being provisioned. When risk is detected, the system will prevent access from being granted (or allow it if approved).

We will be publishing an article later in this series that looks at preventive controls for Oracle EBS in a little more detail.

Want to find out how we can help you identify, remediate, and prevent access related risk in Oracle EBS? Get in touch today and ask us about CS*Comply.

Early Access – Newsletter

The next article in this series is “It’s all about the risk matrix“.

If you want to get access to these articles before anyone else, please subscribe to our newsletter.

Did you like this article? Follow us to receive all our blog updates

Subscribe to our newsletter
Craig O'Neill
No Comments

Post A Comment

thirteen − three =