When it comes to handling GRC conflicts, is it better to use an alerting tool or a simulation tool? They both manage conflicts, but one is predictive and the other happens after the fact. Well, there is no one solution; the key is to use them in combination to promise a peaceful process and clean GRC audit report.
The inception of GRC and SoD
When GRC and particularly Segregation of Duties regulations first arose, they were very simple to understand. There were rules about functions that couldn’t be executed by a single user because they would then create an “SoD Conflict.” For example, if you put “Create Purchase Order” and “Approve Purchase Order” together in a rule and use this rule to check for users that have both of these functions together, the results will be a list of users who violate this SoD rule and the situation should be resolved or explained (i.e. “mitigated”).
Authorizations are not static and neither are violations
Authorizations are not static, and as users progress or change positions within the organization, they are granted with more authorizations. This means that the violations aren’t static either. Organizations that check their SoD violations every six months or year are surprised to discover, audit after audit, that their inspection reports include new SoD violations.
So, people got smart. They created a tool that simulates granting authorizations to users. The tool includes all the SoD rules and inspects whether to grant users with specific authorizations before they are actually granted (the simulation). If the simulation results in a violation of one or more SoD rules, then the authorization will not be granted and the organization will stay clean from having more violations.
Now, why doesn’t this work? In many cases people ignore the simulation – either they don’t perform it or they just ignore the results. It’s just not dependable enough.
Defense and offense together
If the organization truly wants to defend itself, it must have something that constantly scans all existing authorizations and alerts about new SoD violations. This way, even if a user manages to bypass or ignore the simulation process, the system will alert about any newly created violation, and someone will have to be accountable for it.
The concept of “Stay Clean” or “Staying Clean” from SoD violations was embraced by many, including all of the Big Four consulting firms. Staying clean from SoD violations is achieved with a combination of predictive tools (i.e. simulation), alerting after tools (i.e. alerts), and conflict resolving.