Integrated Risk Management
Through the application of technology and automation, we'll help you manage your risks efficiently and effectively across the entire enterprise.
Identity and Access Management
We'll help you ensure everybody within your organisation has access to the right systems and data, for the right reasons, and at the right time.
Cyber & Application Security
Our experts will uncover security weaknesses within your security design and business-critical applications. Helping you protect your organisation from both internal and external threats.
Bedrock Managed Service
Scalable support and on-demand expertise that seamlessly integrates with your existing operations.
About us
A group of passionate individuals with a shared purpose to help the world's leading companies embrace best practices for GRC and risk management.
Partners
Turnkey's strategic partner network consists of selected organisations that complement our capabilities.
Corporate Social ResponsibilityCSR
We are committed to being agents for change through our Climate Action Plan, championing diversity in our workplaces, and more.
Get in touch
We have operations in all corners of the globe, so see which office is nearest to you and connect with them.
Careers
We have operations in all corners of the globe, so see which office is nearest to you and connect with them.
Webinars & eBooks
All of Turnkey's webinars, guides and other insights available in one place.
Blogs
Read the latest insights from our experts on GRC and risk management, covering the latest industry topics.
Press Coverage
See all the publications where Turnkey, our experts and our successes have been noted.
Key events
See the key industry conferences on GRC, SAP security and risk management which we are attending.
Case Studies
Client satisfaction is of the utmost importance to us, and we strive to constantly deliver above expectations, going the extra mile at every opportunity.
2 August 2012

An Integrated Approach To SAP GRC Access Controls (Part 1)

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:

  1. In response to an audit report recommending improved controls.
  2. 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 cut over 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.

Conclusion

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?