We recently met with a few of our global customers as well as prospective clients, and we were able to gain a great deal of insight regarding one of the most talked about topics, segregation of duties. Some of the companies say that segregation of duties is only for the auditors, while some companies understand the importance of enforcing the rules over user authorizations. A few have taken it to the next level and expand it to other areas in order to create business continuity.
Whatever the company’s acceptance level is regarding segregation of duties, we find that many companies we encounter find this particular implementation project difficult and tedious and it is usually executed by hired consultants, who are less familiar with the company’s operations.
Occasionally, we will find one of the lucky few companies who have been able to implement their segregation of duties project smoothly within a one to two month period, sometimes even less, and it did not make employees want to jump off the roof. Over the past year, we have gathered and documented some of the key factors on how to successfully implement an effective segregation of duties project.
1. Despite popular beliefs implementing Segregation of Duties does not need to be a long project!
There ARE SoD projects that take between 1-2 months to implement and are successful. When we say implement SoD, this does not necessarily mean to implement a full GRC suite with workflows, process controls, risk assessments, etc. In most cases, all a company needs to do is to implement a good ruleset. This practice is acceptable in many cases by auditors because you can still enforce the ruleset on user authorizations, fix what is required or put controls into place to manage violations that are not fixable, and then set an effective alerting system; Ta-Da you are done and everyone is happy!
2. Start with the best practice that you get from your auditor
Don’t try to reinvent the wheel – SoD projects have been around for more than 10 years and the best practice rulesets were written and improved again and again over the years. So ask your auditors for a good ruleset, validate it first and then focus on implementing this ruleset. Your goal should be a quick win and gaining management’s support. Only after the project is successfully completed should you consider adding more customized rules to the ruleset.
3. If it has not been used – delete it! (Courage is required)
The simple rule should be – if a person has not used an authorization for over a year, it should be removed from his/her profile. Easily said, but not easily executed. First of all, from a technical point of view, in order to remove an authorization from a user you need to change their existing authorization roles and this is quite difficult to do manually. Second, strong support from management is needed in order to execute this policy as removing authorizations may anger employees, even if they were never using the permission to begin with! Therefore, if you want to proceed with this policy we recommend that you start slowly – begin with removing authorizations that create SoD conflicts, and then remove sensitive authorizations from people who do not use them. At this point you can consider if you want to continue or if you prefer to report back to your auditors that you narrowed down the SoD risks by about 70 percent, as this is the common percentage just from removing the unused authorizations from people.
4. Don’t just agree – ask why!
Over the years we have discovered that managers who want to understand the reasons behind an SoD ruleset help in making an organization successful. When they do not understand why a specific rule is relevant to their organization – they ask for an explanation. If they feel it is not necessary they then try to convince the auditors that it should be left out.
For example, some organizations have found issues with creating immediate alerts for SoD violations and have managed to convert these immediate alerts to be in a weekly or monthly report because this is what is good for their specific organization.
There is a benefit to understanding the cause of situations. For example, when you understand the reasoning behind a certain SoD rule or requirement from your auditors, you may be in a better position to suggest an improvement or a change in said rule so that it will fit your organization better. In one instance, we had a CIO that wanted the Firefighter process to avoid waiting for approvals in the middle of the night. This change ended up saving a lot of time and eventually money to the organization.