After Security Remediation and Redesign: What’s Next?

Tackling Segregation of Duties Risk with Quantitative Analytics

Recent regulatory changes have shifted many conversations this year to topics such as lease accounting and data privacy, and SAPInsider’s 2018 GRC/Financials Conference was no exception. One of the most compelling topics at this year’s conference centered on the fact that, in addition to the added stress of ensuring compliance with these new policies, companies still face the ever-present challenge of limiting user access to segregation-of-duties (SOD) conflicts within their enterprise resource planning (ERP) applications.

The level of scrutiny around security and controls by compliance and audit organizations only continues to increase, and even within organizations that have prioritized optimization efforts for their security environments, a multitude of common issues still exist, such as the following:

• A significant number of SOD violations remain after initial SOD projects involving remediation and redesign are completed.
• Controls applied to mitigate the SOD risks do not address the true nature of the risk or are not performed effectively enough to pass compliance testing.
• Emergency-access functionalities, such as firefighter accounts, are used excessively as a cure-all for SOD issues, generating unmanageable amounts of system logs to review.
• Remediation efforts are costly but ultimately insufficient, as subsequent audits uncover new SOD and sensitive-access concerns.

Assessing Financial-Risk Exposure Resulting from SOD Access

Due to these concerns, assessing the true financial-risk exposure resulting from SOD access can become a difficult task. Most companies define a ruleset of SOD risks made up of conflicting business functions, then perform an analysis to identify which users can execute those risks. From an access perspective, most companies have several users with conflicts across their ruleset, which represents a total count of SOD conflicts. Remediation efforts such as role redesign or business transformation can be taken to reduce this number, but a group of conflicts usually remain.

Many companies provide mitigation over SOD by embedding control activities within the business process or across the enterprise using system configuration. While mitigating controls can provide comfort over SOD, they can also cause inefficiencies in the business or create complexities during efforts to verify their performance. In addition to the risk of operational deficiencies or unreasonable testing efforts, documented controls may cover only a subset of users or risks, which could leave some SOD access unmitigated. Considering that usually an even smaller set of these users are truly processing violations, testing for exceptions is not only a huge undertaking, it is also often like trying to find a needle in a haystack.

Defining a Meaningful SOD Ruleset

It is critical to define what the actual violations are for each risk, which encourages meaningful conversations about its criticality and how to test for exceptions. Criticality, or risk level, should be determined based on the ability for a user with access to the SOD to commit fraud or cause financial impact to the business (i.e., affecting financial reporting or getting money or product out the door). Additionally, existing mitigations should not be considered when defining the level or relevance of a risk, since controls are subject to ineffectiveness and a gap in definitions can result in unidentified conflicts.

The same discussions that help the ruleset take shape can also cover what constitutes an actual violation of the risk, since a well-defined risk means considering the actions a user can take with the SOD access to impact the company. For example, a common SOD risk states that a user should not have access to both create and pay vendors. If an organization were to test for access to this risk, it may find that hundreds or thousands of users have access to perform maintenance on vendor master records and to process payment transactions.

If we think through an actual violation scenario, which could be that a user creates a fictitious vendor and pays himself or herself with it, the user would have to had maintained and paid the same vendor record. If we test for this risk based on these defined scenarios, we may find that only a small number of users (or no users) have performed an actual exception. This concept of “did-do” testing for materialized SOD violations is the foundation for what we call SOD quantification.

Quantifying Real Exceptions to Determine SOD Financial Impact

SOD quantification is an analysis that queries transactional data in an application based on the defined risk criteria (e.g., create vendor and pay that same vendor) to obtain the relevant details and sums up the total dollar amounts. The objective is to identify real instances of SOD usage in the system and provide visibility to, and mitigation over, the financial risk exposure resulting from these transactions.

The detailed line-item results from an SOD quantification analysis can be used to review and mitigate instances as required with business-process owners, supervisors or the end users themselves. Summarizing results by user or organization can help management distinguish between potential areas of risk, which would require additional follow-up, and areas of no concern, alleviating the need for further mitigation efforts.

Since it is so difficult to determine, using standard audit methods, whether SAP users who have been granted SOD access performed actual improper system activity, this analysis can assist in substantive testing as well as provide visibility and control of risk exposure for SOD user activity. Since many access conflicts may remain after remediation efforts, it can also help focus mitigation activities on truly material risk areas so that business resources’ time can be leveraged elsewhere.

The results of this analysis can be quite illuminating. Statistics based on user access often misrepresent the actual occurrences of SOD exceptions, which can be far below what may be expected. Conversely, even low amounts of SOD access violations can have a significant number of quantified SOD transactions, especially where a single employee or a small team is responsible for an end-to-end business process. Addressing violations with users or their supervisors can also help facilitate those often-difficult conversations about process improvements, controls effectiveness and potentially handling fraudulent actions.

Start Focusing on Actual Violations Now

Despite the new financial reporting and data privacy regulations entering the landscape, expectations around SOD compliance have still never been more demanding. SOD quantification can give significantly better visibility to the financial exposure resulting from access risk, as it is based on recognizing that there is a significant difference between potential access violations and real financial impact. This type of automated process for SOD monitoring and substantiating activity can also alleviate management pressure to remove all SODs during a security-remediation or security-redesign project. More important, monitoring of known risks can start immediately to reduce risk and prove compliance with leading-practice standards around SOD and security.

Visit our Security and Segregation of Duties site to learn more about how Protiviti can help secure and manage your SAP application risks, as well as to hear stories from our clients’ past and ongoing success.