Blogs

Apart from the introduction of our new US team the most exciting announcement at SAP GRC 2013 in Las Vegas this year was the launch of the new Fraud Management module!

Fraud Management is an exciting new addition to the SAP GRC family and adds a number of capabilities to the existing SAP GRC solution set. In this blog we explore some of these features and also discuss some of the possibilities that SAP GRC Fraud Management might open up for the future.

A HANA Backbone

The first thing to note about Fraud Management is that it is based on SAP HANA technology. We have been asked several times by customers about whether Fraud Management is available without HANA. The answer, unfortunately is no. HANA is a pre-requisite. That is not necessarily bad news though as the next release of SAP GRC, 10.1 - scheduled to enter ramp-up in June, will also be (optionally) available on HANA.

With HANA as the backend engine Fraud Management is able to offer some of the real-time transaction monitoring capabilities that were either difficult or in some cases impossible with SAP GRC Process Controls. The Fraud Management analytical engine also enables more effective management of alerts, suspected fraud cases, etc.

How it Works

Fraud Management is essentially an application or use-case of SAP HANA. Data relevant for Fraud analysis (from an SAP or non-SAP source) is extracted into the HANA database. This data is then interrogated using pre-defined fraud patterns and detection rules. The output is used to monitor and report on the likelihood of fraudulent activity through KPIs and KRIs and to trigger responses and/or alerts where appropriate.

Alerts can take the form of an RFC call to the backend ECC system, for example triggering a workflow or calling a BAPI to block a suspicious business transaction in real-time.

 An example might be the analysis of vendor payment transactions within a certain tolerance % of purchasing approval limits. E.g. if multiple payments of £19,950 were found to the same vendor authorised by an approver with an approval limit of £20,000 these payments might be blocked pending further investigation.

What Does the Future Hold?

Fraud Management can already be combined with SAP Predictive Analytics to perform more advanced pattern analysis of fraud relevant data and to explore more complex modelling scenarios. In addition to further enhancements of these capabilities we would hope to see standard BAPIs available to enable pre-configured responses to fraud incidents. Another key functionality gap that we would expect to be available in the next release is configuration wizards for the fraud detection rules, currently these are defined manually using SQL queries.

From a customer perspective I think that applications of Fraud Management could extend well beyond fraud analysis, leveraging the capabilities of the tool for continuous transaction monitoring scenarios. For example the capabilities of the tool might be used to optimise working capital by highlighting and postponing vendor payments that were made prior to payment terms.

Conclusion

Our initial assessment of the Fraud Management module is that the key to getting benefit from it is a strong understanding of the indicators of fraud in your environment. This will be a combination of three things:

1. An understanding of the key risk factors specific to your organisation
2. A knowledge of any past incidents or fraud exposures.
3. Content from your implementation partner.

To this aim we have been working with a well-known forensic accounting specialist, to develop content for our Fraud Management offering. We’ve also been exploring the technology in our own demo environment and are evaluating Fraud Management with several customers.

Real-time transaction analysis is a very welcome addition to the functionality available from SAP GRC solutions and significantly enhances the possibilities for continuous transaction monitoring as well as the obvious fraud management applications. Personally I am looking forwards to the prospect of exploring these possibilities further with our customers.

Last week we discussed lack of visibility of access risks for management and the issues this creates. In this blog, I discuss the fifth and final issue of time and cost of audit, when no automated tools are in place.

Excessive time and cost of audit

Even before an audit, preparing for an audit is time consuming and costly.

Some external auditors will bring their own SoD tools to perform an audit. They will generally charge the client for the use of the tool and the time to set it up. For example, one of our FMCG clients had received a number of negative access audits and was being charged an additional substantive audit fee because the auditors could not place reliance on access controls in the sys.

They recently decided to implement GRC AC to address the issue, and during preparation of the business case, they found the one-off cost of the software purchase will offset the cost of the substantive audit fee.

Our clients who use AC find their auditors are willing to place reliance on the tool and the results. Customers have consequently been able to negotiate reduced audit fees of up to 30%.

Rapid Deployment Solution for AC

Turnkey Consulting Australia are the first in the country to offer a Rapid Deployment Solution (RDS) for GRC Access Control

You can be up and running with Access Risk Analysis and Emergency User Access in as little as 6 weeks for a fixed fee.

For more details please contact Ed Davis at ed.davis@turnkeyconsulting.com or see our page on the SAP EcoHub;

http://ecohub.sap.com/store/rds/catalog#!solution:Turnkey-Australia-SAP-GRC-Access-Control  

Last time we looked at issues around managing access risk in a reactive and fragmented way. This week I discuss the fourth major concern around managing access risk which is lack of management visibility.

Lack of visibility for management

We all know that senior management hate surprises, even more so when it is delivered by an external party! It leaves them wondering what else is out there that they don’t know about!

By implementing a tool like Access Control, organisations are demonstrating that they are being proactive and keeping on the front foot with managing system risk. This will always be looked upon favorably by auditors and other stakeholders to the company.

Some of our clients, regularly report the status of the access risks to senior management using the dashboard we saw earlier. This gives a level of comfort to executives, to know that’s one less thing they need to be worrying about.

We find that customers love the drill down capabilities of the AC dashboard. They have the ability to see which business processes or users have the most issues, so that they can prioritise their remediation. They are able to clearly see and track the progress being made as risks are reduced over time.

Last week we looked at issues around managing emergency access to systems. This week I discuss the third major concern around managing access risk which is taking a piecemeal approach which does not address the ongoing risk.

Reactive and fragmented approach to managing risk resulting in recurring audit issues

Clients typically fall into 3 levels of maturity around managing access risk;

1. No process: The auditors will deliver their report and the client will address the issues which existed on that day which is only a short-term, band-aid fix. It is reactive and doesn’t constitute a process.

2. Manual process: Many companies manage their SoD’s by extracting data from SAP and manipulating it in spreadsheets. What’s wrong with doing this?

• As soon as it is extracted it is out of date
• It is subject to human intervention and is therefore error prone (or worse, manipulation)
• It is very time consuming and not easily repeatable! May not capture all risks.
• Auditors will not generally rely on this for the above reasons.
• Unless a process is able to be repeated continuously access issues will creep back into the system over time.

3. Automated process: By having a central repository of agreed access risk rules, management of these risks becomes transparent. This enhances the collaboration by providing a common language between the business (who typically do not have enough technical understanding) and IT (who often don’t understand the risks in a business context).

As part of my blog on the top five concerns around managing access risk, last week we looked at concerns around improper systems access leading to loss from fraud or error. This week I discuss how to best manage emergency access to systems.

Emergency access to systems, without the proper controls and auditability

Emergency access to production systems is a fact of life. For example, performance troubleshooting or configuring a setting which cannot be transported, such as number ranges, or debug access.

A requirement always exists to meet immediate business needs when a role cannot be developed in time.

GRC Emergency User Access provides a balance between business requirements and the need to exercise internal control. Typical emergency processes are frail and do not stand up to audit scrutiny (e.g. no audit trail, approval occurs after the fact). EUA enforces a robust and auditable emergency access process.

This is very quick to implement. We recently implemented Emergency Access at a client in two weeks. Feedback from client was: 

• One of the smoothest IT implementations they had seen
• Easy to use
• Will be of great benefit to the support team.