Organizing Security to Get Ahead of the Audit Game

Sarbanes-Oxley (or SOX) has been around for so long now that you’d expect everyone to have their internal controls for section 404 in pretty good shape.

Not necessarily so!

The definition of what constitutes a successful audit lies firmly within the control of the audit companies, but we frequently talk to organizations who don’t have the kind of client/auditor relationship that enables them to establish prior to the audit what controls will be tested. They know that they will be expected to demonstrate satisfactory Segregation of Duties (SoD), but are given little guidance as to what SoD Rules should be

And it’s not just about SOX; many companies have nagging doubts about the effectiveness of their controls and would like to safeguard against the risk of fraud – wouldn’t you like to know who is in a position to run off with the company’s money?

Something is changing though. This year we’ve heard more conversations about restructuring security than ever before. What’s driving this? Getting proactive with security means that customers can demonstrate good controls based on their own interpretations of the risks that affect their business. It’s taken some time, but it seems that organizations have had enough of playing catch up and now they want to get ahead of the audit game.

So right now we’re working with many customers to incorporate this kind of risk management into their security. Some of them have decided that the easiest way to achieve this is to completely restructure their security, which has led them to think about ways to make it easier to demonstrate compliance as well to manage ongoing security, for example:

• The need to reduce the number of Roles per User

This is often identified as a major requirement. The fact is that the sequencing issues caused by Users having many Roles are highly problematic when you are trying to demonstrate effective controls to your auditor.

• The need for a PROACTIVE process to test security changes against policies such as SoD

The ability to identify potential SoD conflicts that would result from proposed changes to security enables you to avoid them altogether – reducing risk and keeping access in line with your SoD Rules.

Getting business users on board is critical to the success of this process. One great thing about embarking on this journey is that you can engage the ‘Business’ more and possibly even hand security over to them – after all it is their Application!

Before Roles are reorganized, you need to consider how to ensure that IT and Business Analysts can work together effectively to implement security and we find that Menus/Tasks are often a good starting point for this – many people express the desire to create a Security Model that mirrors the Menus in JD Edwards (plus all the hidden bits like Exits and UBE’s).

If this strikes a chord with you, perhaps it’s time to ask yourself whether the easiest way to tackle ‘the elephant in the room’ is to start with those Menus and see if they give IT and the ‘Business’ common ground to work from.