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

Why do we need a tool

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

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 a 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 3 requirements effectively and efficiently without any kind of 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 huge, 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 basically 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 simply 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/or 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 any sort of software automation, the process of remediating risk can itself be a complex 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 basically means you need to look at ways to reduce the risk while not fully removing it.

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

A good 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 any sort of 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 normal 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 on a periodic basis. 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 the 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
CaoSys
info@caosys.com
No Comments

Post A Comment

Call
Email

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.