Do You Really Want to Make Me Cry?

Do You Really Want to Make Me Cry?

I’m sure you heard this kind of dialog before:

“We need to remove one of your authorizations immediately”

“Why?!”

“Because it violates a segregation of duties rule”

“Which rule???”

“Something to do with the financial auditors”

“But you can’t, I need it to do my job!”

“I can’t do anything about it, sorry. It’s a requirement coming from management”

 

 

Sounds familiar..? This type of conversation often takes place following a major SOX/SoD (segregation of duties) project, in which an organization is required to solve various SoD conflicts. What this means is that during the SoD project all authorizations in the company are examined through a set of rules (for example: the same user can’t create a vendor and issue an order for that vendor). After initial inspection, all users that violate SoD rules are pinpointed. And then the fun begins…

In most enterprises a meeting is scheduled with each of the relevant users (this is the point when conversations like this take place). In reality, I’ve never seen a user that simply agrees to let go of any of their authorizations; this is also why such meetings end up taking such a long time.
Download_The_Complete_Authorization_Review_eBook.png
Isn’t there any other way?

Let me suggest two alternatives:

Alternative 1: Compensating Control

Leave the violating authorization in place. Don’t panic, I’ll explain: There are cases where companies must enable a violation in order to ensure smooth business processes (such as when the same employee is in charge of several functions in the organization). When choosing to leave a violating authorization, a company is forced to find a way to supervise the potential violation (in GRC terms, implement a compensating control). For example, John can open new vendor accounts and also issue orders for these vendor accounts. In this case a compensating control needs to be implemented, which can include a periodical review of all vendors and orders that were created or changed by John. A compensating control has a termination date (usually after one year) so the necessity of the control is re-examined with each renewal.

Although listed as alternative #1, this is not the first option I recommend. Why? Simply because it requires a lot of resources. Just imagine implementing 1000 compensating controls (the average number needed); many managers would spend their time reviewing reports on compensating controls instead of doing their actual work.

Alternative 2: ERP Usage Inspection

Listed second yet recommended first is the option to remove any authorizations that violate SoD rules. How do you avoid the above conversation, you ask? ERP usage inspection is the answer. Let’s say John can open new vendor accounts and also issue orders for these vendor accounts – this creates the SoD conflict. However, when looking back (via ERP usage inspection), you can see that John has never opened a new vendor’s account. Therefore, this authorization can be removed without even wasting valuable time to meet John and discuss this. In fact from our experience 95% of users, which “lose” authorizations they don’t actually use, are not even aware of the fact that various authorizations were removed. For the 5% chance that a user suddenly needs an authorization that was removed, an automated authorization request process is available.

ERP usage inspection basically means knowing exactly which authorizations are used de facto (and not only which authorizations are theoretically needed). This is what paves the way to managing user authorizations smartly and effectively, and finally successfully maintaining a GRC-compliant working environment. By using ERP usage inspection together with business profiling you can complete a successful GRC project in time and within budget.

Yoav Michaeli

Yoav Michaeli joined Xpandion in 2008 as a team leader, and in 2010 Mr. Michaeli began managing the entire Research & Development group of the company. Prior to joining Xpandion, Mr. Michaeli served in an elite technological unit of the Israeli Defense Forces as a team leader for various key military projects. Among other achievements, he was instrumental in pioneering the use of advanced .NET technologies for large scale distributed systems. Mr. Michaeli is an expert in programming, agile development, application security and specialized programming techniques.