Tuesday, 21 May 2013
Posted by Richard Hunt
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.
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:
- An understanding of the key risk factors specific to your organisation
- A knowledge of any past incidents or fraud exposures.
- 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.
Friday, 14 December 2012
Posted by Richard Hunt
With the New Year approaching I thought it might be a good time to reflect on my observations for the SAP GRC and security market in 2012 and think about what 2013 might have in store for us.
Observations from 2012
With the release of SAP GRC 10.0 in late 2011 this year was always going to be an exciting one in the SAP GRC space. As expected, we’ve seen a lot of customers migrating from older versions of GRC into the new, ABAP based, application. Many have taken the opportunity to revisit their business case for GRC and consider how they could take advantage of what the new software has to offer. This has led to a significant increase in the deployment of process controls and risk management in 2012. We have also seen customers using their migration or upgrade project as an opportunity to re-evaluate automated access provisioning and as a result are seeing more projects in this area.
Whilst perhaps not as high profile we have also seen interesting developments in the SAP security space. The new authorisation concept in SAP HANA together with SAP’s push into mobility and cloud computing solutions have given our SAP security team a number of new technical challenges to solve. They have found it interesting to be at the cutting edge on this area and it’s been a great way to apply their existing SAP security knowledge.
In conclusion, a year of consolidation and expanded reach for SAP GRC with a number of interesting developments in the SAP security space.
Looking forwards to 2013
So what does 2013 have in store in the SAP Security and GRC space?
If our recent survey is anything to go by then automated controls are going to be a big topic in 2013. With over 63% of respondents intending to invest in this area in the next 12 months next year looks set to be an important year for SAP GRC Process Controls. This product is maturing fast and it's flexibility means that customers are putting it to a number of innovative uses. For me, this will be the biggest growth area in 2013 in terms of GRC but I also think we will continue to see an increase in access controls automation initiatives with further migrations/upgrades and more customers maturing in their usage of the access controls 10.0 products.
Continuous transaction monitoring and proactive fraud prevention continue to gather interest and we can expect new products from SAP to address this growing market. Demand for these products will also be fuelled by the increased interest in process controls and I think we can expect to see deeper integration with SAP process controls from vendors like Oversight and Greenlight.
HANA and mobility will remain strong focus areas for SAP in 2013 and this will drive a need for security solutions to address the new business risks that these solutions create. This was again borne out by our survey results which found that 48% of respondents planning to invest in mobility solutions together with additional security and 26% with similar plans around HANA.
All in all, I think 2013 has a positive outlook in terms of opportunities for those with SAP security and GRC experience. With continued ‘doom and gloom’ in the overall economy those working in the IT security and GRC space are fortunate to see a continued increase in the demand for their skills. The challenge, as it has been this year, is to align our efforts and solutions with the overall economic climate – a continued focus on return on investment and delivering cost savings is crucial in achieving this goal.
Wednesday, 14 November 2012
Posted by Richard Hunt
In this blog I would like to follow up on my earlier entry around the benefits of including GRC in a greenfield implementation. Previously we explored this area in the context of access controls. We now look at the benefits of implementing Process Controls at the outset of your SAP journey.
Integrated Control Framework
An SAP control framework is something that will be developed over time by most organisations. Typically Internal Audit will have a control framework against which they test the company's existing controls. This will be updated by IA either during the initial SAP implementation or, more commonly, at the first audit cycle post go-live. The inclusion of process controls at the outset of the project enables an organisation to focus resource towards the adaptation of the control framework to suit the SAP environment. It also gives the opportunity to ensure that these controls are designed efficiently for SAP.
Automated Process Controls
With or without GRC technologies in place your SAP implementation will need to define business process controls to ensure the control and smooth running of your business processes. The inclusion of GRC technologies in your initial implementation scope will enable these controls to be defined and developed in the most efficient way possible, taking advantage of the latest controls automation technology to drive down the costs associated with operating and testing these controls post go-live.
Internal Audit Efficiencies
Testing an SAP environment can be a very labour intensive and inefficient process from an audit perspective. Investing effort to understand where these inefficiencies occur during the initial implementation will help to reduce these inefficiencies, ensuring that duplication of testing is minimised and control testing is automated wherever possible.
Familiarity with the SAP Environment
Ensuring that IA are familiar with controls in the SAP environment from the outset of the project is an important but difficult challenge. Without focused effort from IA to get up to speed on the various complexities of auditing an SAP environment they could find themselves playing catch up post go-live. The inclusion of PC in the implementation scope of GRC will give your audit team a natural 'home' on the project and enable them to develop the skills they need to audit the new SAP environment over the course of the project.
Maturity in the GRC market and in the GRC applications available from SAP means that these solutions should be a consideration for any greenfield SAP implementation. Whilst it may not be in every project scope from the outset customers should consider the benefits of addressing some of the problems that GRC solves during their initial implementation. As we have seen in this blog entry, taking a proactive approach has a number of benefits and tackling your GRC challenges early will surely result in a stronger and more efficient control environment.
Wednesday, 24 October 2012
Posted by Richard Hunt
Typically GRC deployments have focused initially on Access Controls, maybe followed by Process Controls and then possibly Risk Management. In this blog entry I want to challenge the status quo and think about the most approproate way to deploy the SAP GRC toolset as an integrated Enterprise Risk Management solution.
One of my colleagues, Marc Jackson, recently delivered a session at the SAP Insider GRC conference titled 'a Risk Based Approach to Security Audits using SAP Solutions'. The session outlined the way that the Big Four take a 'top down' approach to auditing SAP systems, focusing on the corporate objectives, the risks to the achievement of these objectives and the derivation of the controls required to mitigate those risks.
This got me thinking about the way that most companies approach their SAP GRC implementations. Typically a company will start their SAP GRC journey with an Access Controls implementation to address audit issues or regulatory concerns such as Sarbanes Oxley. This is partly due to these tools being the first to market and partly due to the resolution of those issues being the highest profile/priority. Many companies are now looking to build on this with improvements and automation of business process controls through the SAP GRC Process Controls solution. A few have deployed Risk Management, perhaps alongside PC or as a stand alone implementation.
Taking a step back, the overall objective of the SAP GRC solutions is improved risk management and internal controls. If we consider the risk based approach advocated by the Big Four audit firms and many professional bodies (e.g.PCAOB, IIA, and ISACA) then it would follow that a more logical sequence to implement the SAP GRC toolset might actually be the inverse of today's scenario. This question is particularly relevant with v10.0 as the three solutions now offer much better integration.
Starting with the implementation of the Risk Management tool has several advantages. Firstly this solution is targeted at C-Level and Snr Management users. Therefore it should follow that the project has senior level sponsorship from the outset, a key success factor for any GRC initiative. Furthermore the subsequent implementation of Process Controls will inherently align controls with corporate objectives and the risks to the achievement of those objectives since all controls will be derive from those risks identified by management and the board. While Access Controls are often some of the most robust control options available they are only one control option in the overall control environment. It therefore follows that these should be derived from the control framework defined in SAP GRC Process Controls.
Taking a risk based approach is not going to work for everyone. Many companies look to SAP GRC as a spot solution to specific challenges and they may not have the appetite for an Enterprise GRC Solution. However, for those that do it may be worth rethinking the standard deployment strategy for SAP GRC solutions with a little more focus on the overall objective, Risk Management.
Thursday, 2 August 2012
Posted by Richard Hunt
Many Greenfield SAP implementations will exclude SAP GRC from scope, treating it as an optional module that can easily be implemented post go-live. In this two part blog entry we explore how the deployment of the SAP GRC toolset at the outset of a Greenfield implementation can improve the effectiveness of internal controls in the long-run.
A conversation with one of our customers recently got me thinking about the way that most GRC projects are commissioned, and about how things could be different if a slightly more forward thinking approach was taken. This blog will explore, in two parts, how the deployment of the SAP GRC toolset at the outset of a Greenfield implementation can offer a significantly more effective implementation in the long-run. We start with SAP GRC Access Controls.
A GRC Access Controls project will typically be initiated for one of two reasons:
- In response to an audit report recommending improved controls.
- As a result of a process improvement initiative.
Unfortunately we still rarely see GRC as part of a Greenfield SAP deployment. GRC will often either be overlooked in scoping or become a casualty of tightening budgets at some stage of the project. This is a shame as there are a number of reasons why implementing GRC Access Controls at the outset of a project can be hugely beneficial.
A Compliant Role Design
Any implementation of SAP will require the implementation of SAP roles to support access control requirements and facilitate segregation of duties (SoD). Whilst SAP roles are often designed and built without a segregation of duties tool this approach will inevitably lead to some form of role remediation to align the SAP roles with an SoD ruleset. Even if SoD rules are not defined during the initial implementation a subsequent audit will almost always necessitate some form of remediation activity to achieve this.
By implementing the SoD monitoring tool (Access Risk Analysis) at the same time as the SAP roles it is possible to develop a role design that aligns with the SoD ruleset from the outset, avoiding this subsequent re-work and the associated costs and disruption to the business. This approach is also likely to result in a role design that is easier to maintain as, in the absence of a complete re-design, most post go-live role remediation projects will necessitate some compromise in role design.
A Complete Audit Trail from Day One
Although not widely used in pre-production systems the Emergency Access Management (EAM) module comes into it’s own in a project environment. There are a number of scenarios during a project where elevated access needs to be allocated in a controlled way and EAM is the ideal tool to achieve this. For example, during cutover it will often be necessary for project team members to execute business transactions as part of a data load. Similarly, fire fighting during the hypercare period immediately after go-live will often necessitate higher access privileges than a ‘normal’ business as usual support environment. Making the EAM module available to the project team is an excellent way to provision this elevated access in a controlled way and it will also ensure that an audit trail of high privileged access is available from day one.
Modern Access Control Processes
A Greenfield SAP implementation will most likely require some changes to the IT support model in order to provide an adequate run and maintain environment post go-live. User Access Management processes will vary significantly if an SoD tool is in scope as these processes will need to incorporate SoD analysis. Today’s GRC applications also enable automated provisioning which will further change the UAM process. By deploying these tools into the Greenfield implementation it is possible to design UAM processes that incorporate the most effective use of the GRC tools available from the outset. This will not only save money but will also avoid some of the challenges that many GRC implementations face in failing to secure sufficient business engagement to make best use of the GRC tools.
Many Greenfield SAP implementations will exclude SAP GRC from scope, treating it as an optional module that can easily be implemented post go-live. Clearly this over simplifies things. My hope is that readers of this blog entry will challenge the assertion that the deployment is of GRC is not part of the initial project scope and will argue that GRC should be treated as part of the core solution infrastructure in a similar way to solution manager. After all, why wait until your first audit to be told that you should have included it?