Part 10: Exclusions, Exclusions, Exclusions

Exclusions, Exclusions, Exclusions

Exclusions, Exclusions, Exclusions

If you have been following our series of articles about managing access related risk for Oracle EBS then you should have a good understanding of why access related risk is such a big deal, why and how a tool can help, what to look for in a risk matrix as well as other things such as collusion related risk, preventive controls, false positives, remediation and reporting.

In this final article in the series, we introduce you to another important aspect of a good SoD solution and that is “exclusions”.

What is an Exclusion?

So what do I mean when I say “exclusions”?

In the context of access related risk, I simply mean a risk that you want to exclude from the results.

Why Exclude a Risk

There are a number of reasons for wanting to exclude risks from the results but most of the time it comes down to one of the following…

  • You have mitigated the risk
  • You have accepted the risk

If a risk has been mitigated or you have just accepted it, then you may not need to be told about it each time you scan the system.

Being Effective While Still Being Efficient

One of the key aspects of being able to manage access related risk effectively and efficiently is to ensure the volume of risks is as low as possible. You should be looking for ways to reduce the number of risks being reported on. Obviously, as you remediate risk, the risk count will reduce but what about when you mitigate a risk?

Mitigation will not reduce the risk count since the risk still exists post-mitigation. You need a means of documenting the fact that you have a mitigating control in place and at the same time you no longer want to see the risks you have just mitigated; this is achieved by creating exclusions.

More Reasons for Excluding a Risk

Consider a few more scenarios where you no longer want to see risks being reported…

  • After some consideration, you decide you no longer need to see risks being reported for your IT users and consultants; mainly because they will always show a lot of risks that cannot be remediated. In this case, you would want to create exclusions for specific users perhaps and document why they have been excluded.
  • There are some functions that are inquiry only when used via a specific responsibility (perhaps due to a personalization). You want to document this and also stop the risks from showing.
  • You have some closely guarded responsibilities that are considered to be “superuser” responsibilities. In the hands of certain users, they will always generate a lot of risks. You decide you no longer need to see these risks because they will always be present. You don’t want to fully exclude the users or fully exclude the responsibilities; in this case, you need a more fine-grained type of exclusion where you can exclude a responsibility but only for certain users.

There could be several other reasons for wanting to exclude risks from the results.

Making Access Related Risk Management Easier

As you remediate, mitigate and exclude risks, the risk count will be going down.

You will likely never reduce your risk count to zero, but the lower the number of risks, the easier it will become to manage the remaining risks.

Our flagship SoD solution includes the ability to create several different types of exclusion with supporting documentary evidence to make access related risk management easier and more efficient.

Want to find out what types of exclusions we support? Get in touch today and ask us about CS*Comply.

Next Week & Early Access

This is the final article in this series and so we will take a break for a week or two but watch this space for the next series which is all about Oracle EBS and why a good audit trail is so important.

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