Customizing your SoD rule set, what’s the big deal?

As I’m finishing up my research for the upcoming GRC 2010 Europe event in Barcelona this November, and just about to kick off the research for our GRC 2011 event next March, I’m noticing there seems to be a lot of buzz surrounding the importance in customizing your SoD rule set and questions on how to approach the project.

I wanted to take the opportunity to post some insights taken from a recent presentation given by Casey Davis of Protiviti at our GRC 2010 event in Orlando titled, “Technical Lessons for Including Custom Transactions in Your SoD Rule Set”.

Reasons for Rule Set Customization
The SoD rule set should be customized for your specific business

• The default rule set is too broad to cover multiple scenarios and industries
  • Organizations configure SAP differently to support their unique business processes
  • Risks may not be applicable to your organization
  • Important risks may not be included in the rule se
• Risks should be categorized to reflect the magnitude of each risk to your organization

Customize the rule set to ensure accurate reporting

• The default rule set does not include any custom transactions
• Certain SAP standard transactions included in the rule set may be irrelevant or display only based on your version of SAP
• Authorization checks do not include field level security or additional authorizations implemented to secure transactions

Your SoD analysis is only as relevant, accurate, and encompassing as your configured rule set

Importance of Including Custom Transactions
A standard transaction may be replaced by a custom transaction

• The default rule set reports on the standard transaction, which may not be assigned to users
  • This results in the rule set not identifying SoD conflicts that exist with the custom transaction

Custom transactions can be created to call standard SAP programs or custom ABAP programs

• Custom transactions can include data uploads, mass maintenance, and direct table maintenance, which can pose significant risk to your organization.

Custom transactions may bypass system controls or standard process controls further increasing the SoD risk over standard transactions

• Standard functionality controls, like Park and Post or Authorization Groups, for approval limits

Important SoD Risk Customization
Review SoD risks with key stakeholders (business process owners, internal audit, compliance, etc.)

• Disable risks not applicable to your organization
  • Do not delete the risk, so it is available for future use
• Add risks that are not included in the default rule set
  • Identify any potential SoDs that your organization considers a risk based on your business processes
• Classify or rank each risk
  • Identify agreed upon rankings and framework to consistently rank each risk
• Update risk descriptions to relate it to your business or clarify understanding