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.

John Scaramucci

Associate Director
Enterprise Application Solutions

Subscribe to Topics

Learn how to implement effective machine identity management to help your organization prepare for the growing risks emerging from a decentralized, hybrid workforce. #ProtivitiTech #IAM #Cybersecurity

Connect with Protiviti at the SailPoint Navigate: Identity Security Conference, where we’ll attend to gain insights into accelerated innovation and enterprise identity security.

#ProtivitiTech #IdentitySecurity #Navigate #Conference

Delve deep into the world of #5G with Protiviti’s latest whitepaper. Discover key insights on 5G's evolving landscape, successes, challenges, and adoption trends in this comprehensive report. Read more: #ProtivitiTech #Telecom #Wireless

Protiviti’s Chris Katz will present “D365 Security — Common Mistakes and How to Avoid Them” at the Community Summit in Charlotte, NC, Thursday, October 19 from 4:15-5:15 pm EST. #ProtivitiTech #Microsoft #CommunitySummit

Protiviti’s Nicholas You will present “Automating Privacy Teams INTO Operations” alongside two other speakers during this in-person Privacy Connect Session hosted by @OneTrust in San Diego, CA, on October 4, 2023. Learn More: #ProtivitiTech

Load More