Application Segregation of Duties

Your company may be going through the SOX blues when you consider application segregation of duties (SOD). What are your challenges? Defining the potential SOD conflicts? Reviewing which potential SOD conflicts need to be remedied? Figuring out how to document the mitigating controls? Implementing the changes requested by your reviewers? Do you know if all the requested changes were completed?

SOD isn't a fun topic for many large companies to address. The SOD topic has certainly caught a lot of attention for those companies having to comply with Sarbanes-Oxley section 404. But even, if your company isn't obligated to do so, there are principled reasons for your organization to consider the consequences of not monitoring segregation of duties.

Segregation of duties is a fundamental element of internal control and information security. Generally, we think of the physical segregation methods - different groups handling specific processes and separating the activities so that they are handled in a manner that will discourage fraudulent behavior. This is especially true in today's computing environment.

At the turn of the 20th century, it was commonplace for groups of employees to be physically separated from one another. Due to the manual nature of the work and number of employees, the boundaries of what was proper protocol were generally transparent. Manual effort was necssary whether it required brains or braun. At the turn of the 21st century, the advent of computer business applications being fused together as modules of a larger Enterprise Resource Planning systems with complex business rules, numerous security groups, and custom roles obscured a level of protocol that was once very visible. For some, it's not an ERP package; rather it is an extensively used general ledger package.

Many organizations struggle with a spectrum of security configurations. Some are too complex they force the administrator to create a security monster so rigid that they fear it may break the will of the users' to do their jobs. Others are are too simple they compromise application data integrity. In the wake of many these implementations are application security configurations "simplified" for administration purposes that leave organizations open to inadvertent processing errors, breaches of privacy, or clandestine data modifications.

Few applications have addressed SOD conflict management as a product feature. There are a few application vendors and third-party providers that have collaborated on the matter and provisioned bolt-on tools to facilitate the process. But if your organization isn't running SAP or Oracle applications, chances are you're going to have to figure out how to face the SOD issue from the ground up.

You may need to do a SOD analysis for any financially significant application in your organization or potentially for any applications that have "need to know" sensitive data. As you consider the effort, consider Comstock's Theorem of SOD Need, which states: "Applications that drive transaction processing which have diverse user groups, with varying roles, and multiple levels of security architecture will generally be the highest priority for SOD review and maintenance." You won't find that anywhere else but here, because I just made it up. That said it is an observation that resonates with me each time I assess an application that fits the profile. While there are many tasks and people necessary to implement and manage application SOD, my colleagues at GCRM have identified four major efforts necessary to manage the SOD process.

1. Develop a SOD Conflict Matrix by engendering cross-departmental
   collaboration. A SOD Conflict Matrix defines the institutional understanding of
   how a company's employees work with an application and expresses the perceived
   and actual taboos. The conflict matrix should be granular enough to determine
   application activities that should not be performed by individuals
   defined by security or user groups necessary for their job function.
   
2. Circulate a SOD conflict report to the departmental managers
   responsible for the oversight and design of effective SOD controls for their
   area so they may identify necessary changes or mitigating controls (risk
   acceptance).
   
3. Capture the manager defined changes for future review and signoff.
   Your SOD administrator should periodically circulate SOD conflict reports to
   management to evaluate new conflicts that may need to be resolved, as well as
   confirm that the circumstances for conflict acceptance (mitigating controls)
   continue to persist. If you can put the acknowledgements in a database table, it
   would make future review more efficient, providing an effective way of creating
   exception reports to facilitate the efforts in item 2 above.
   
4. Have your security administrator positively confirm all change
   requests, user id termination, privileges granted or revoked, etc. back to the
   management team in order to close the feedback loop and ensure that the
   audit trail for the change activity is well documented.

In closing, let me remind you that this effort is a process. As long as you add, change, or delete user access and their respective application rights, the SOD conflict map will need to be re-evaluated at least annually. If this control is not reflected in your IT policies and procedures, you should punch up that document to communicate the policy, risks, and necessary procedures that the application user community must understand. The first full pass at application SOD may take a Herculean effort. With regular review and periodic monitoring, the exception based SOD conflict reporting and positive confirmation for change requests should taper off to a very manageable workload for all involved.