SAP Security Blogs

Turnkey's team of expert consultants share their wealth of knowledge and in-depth insight into SAP security and controls in a series of blog posts.

Unlocking Management Information - Part 3

Monday, 15 December 2014

Posted by Tom Venables

Up to now, we have looked at understanding the purpose of an MI system and some options for transforming and securing sensitive data. In this piece, we will look at storing data in a way which supports compliance objectives.

The next principle to support the secure and compliant provisioning of data in BW is: store the data in a way which will support the authorisation design. 

It is very common to see datamodels in BW which have been structured entirely around delivering the functionality of the reports, withoutconsideration of the responsibility to secure data, or the engagement of the authorisation team to provide or restrict access to the data as appropriate. In any LSA (layered, scalable architecture) model, there are several layers in the BI environment which can be used to ensure that data is presented to the reports in a fashion which is functional, performs efficiently and is compliant.

In circumstances where there is no option but to import and present data which is sensitive, our next approach to ensure we can make this available to those users who require it, is to ensure it is stored in a location and a format which supports the correct use of authorisations on this data. Segregating sensitive data and ring-fencing it into limited-access infoareas within the data warehouse, will support such a design and ensure that roles and analysis authorisations can be structured in a way that provides differeing levels access.

One method which have proven particularly effective is to configure a virtualisation layer within the BW data warehouse to store multiproviders, which can be used to 'hang' the reports off. By using this method, it is possible for us to authorise end-users of reports on the multiproviders and infoareas on which the reports are built themselves, without the need to provide access to the detailed infoproviders in which the raw data may be stored.

Hanging the reports in this way, with ring-fenced authorisation on the infoareas (which may be aligned to roles) will allow the analysis authorisations, which support the reporting access, to be linked to the roles themselves. This should always be considered as best-practice, as it will allow for automated allocation of analysis authorisations to the users with minimal manual maintenance overheard.

Once your users have access to the data within the reports it is time to think about the final option we have for securing data, the presentation of reports to users, which we will cover in the next entry.

If you have any comments or questions, please feel free to use the comment submission below or email us at:




Make a Comment

Guest Blog | Richard Anderson | New guidance on Risk Management from Financial Reporting Council

Thursday, 18 September 2014

Posted by Richard Hunt

We're delighted to welcome Richard Anderson, our first guest blogger, to the Turnkey Consulting Key Insights blog.


New "Guidance on Risk Management, Internal Control and Related Financial and Business Reporting" from the Financial Reporting Council

After much turmoil in our economy, and many, many months, if not years of consultation, the long awaited guidance on risk management (and all the rest of the things included in its snappy title) from the FRC was published at midnight last night (16/17 September 2014). And – I never thought that I would write this – it was well worth the wait. This document is miles ahead of the former incarnations of the Rutteman Report (remember that?) and subsequently various versions of the Turnbull Report. At last we have something that really addresses the needs of companies, and boards in particular, to do something sensible about risk management.

Thankfully this guidance is also pulling together the various sources of guidance on risk including the former Sharman Report on addressing the knotty issues of reporting under the going concern principle. So this becomes a one-stop source of reference and guidance for boards.

Contextually, as the document says:

The Code defines the role of the board as being "to provide entrepreneurial leadership of the company within a framework of prudent and effective controls which enables risk to be assessed and managed". Effective development and delivery of a company’s strategic objectives, its ability to seize new opportunities and to ensure its longer term survival depend upon its identification, understanding of, and response to, the risks it faces.

At last we are looking at risk management in the context where it belongs: the entrepreneurial leadership of the board, seizing new opportunities and long term survival. In other words this is not a mere governance issue: it is about the creation and protection of value. It goes on to say that the “Company’s approach to risk [needs to be] properly considered in setting the company’s strategy”. In other words risk and its proper management is a strategic issue – as I have been arguing for a very long time. Of course this is divergent with the common practice in many companies today where it is largely a compliance issue dealing with operational matters. 

The responsibilities of the board are set out in Section 2 of the guidance and are comprehensive. I have summarised them below:

  • Design and implementation of appropriate risk and control systems and robust assessment of principal risks;
  • Determining risk appetite;
  • Ensuring appropriate culture and reward systems are embedded;
  • Agreeing on the approach to managing principal risks;
  • Monitoring and reviewing risk management; and
  • Ensuring sound information on risk management is published

There is also more material on the board’s responsibility for the Going Concern principle, which I will deal with in a subsequent note. Interestingly, references in earlier drafts to stress testing appear to have been relegated to Appendix B where the approach to longer term viability is discussed. With that exception, the list of responsibilities includes three comparatively recent additions to directors’ responsibilities: namely risk appetite, risk culture and ensuring that sound information is published on risk matters. While risk appetite appeared in the UK Corporate Governance Code a few years ago by inference, it is here explicitly (albeit in brackets!) 

My personal take on this is that directors who take this list of responsibilities seriously (and who wouldn’t given the potential impact of failing to do so) will have some considerable work on their hands to address the first two of these issues: namely risk appetite and risk culture. The more fundamentalist members of the ISO31000 community will likely have a collective frenzy of horror at the “Risk Appetite” phrase creeping in – I on the contrary am delighted to see it appearing, because I believe it to be the cornerstone of an effective risk management approach, especially in the strategic domain. At a recent Internal Audit conference I asked how many internal auditors were reviewing their corporate risk culture in anticipation of these changes (they have been well trailed). The response was that depressingly low numbers are doing so and even fewer could articulate their approach to risk appetite.

Section 3 of the guidance advises boards on the exercise of their responsibilities. Five key areas strike me as being particularly relevant and they include:

  • Having the board ensure that the "appropriate culture is on place". Indeed the guidance goes on to say that "it is not sufficient for the board to set the desired values." 
  • Ensuring that there is adequate discussion at the board: this is a far cry from the comments made by Nigel Turnbull after his Report was published when he said to the effect that it was sufficient for the board to have a chat once or twice a year. The guidance now says that "the board needs to ensure that it engages in informed debate and constructive challenge and keeps under review the effectiveness of its decision-making processes."
  • Considering whether the board and any committees and management groups have the "necessary skills, knowledge, experience, authority and support to enable it to assess the risks the company faces and exercise its responsibilities effectively". For some time now, I have predicted that this is an area where boards are going to need help. There is far more to the style of risk management that is being asked for here than was implied under the previous guidance. My take on this is that we will see more boards looking for a risk specialist on their team of non-executives, and quite probably seeking board advice specifically about these areas, rather than the broader advice that might be offered to management more generally on the topic.
  • Specifying and then monitoring the information that it requires to discharge its risk responsibilities, and in particular that "it is of sufficient quality to allow effective decision-making". Much of what currently passes for risk management is a data-free zone. This will have to change as boards demand better quality information over which appropriate governance procedures are exercised, more akin to the disciplines over accounting data.
  • Identifying and seeking assurance on risk matters, including from "compliance, risk management, internal control and internal audit functions within the company, the external auditor’s communications to the audit committee … and other internal and external sources of information or assurance." The guidance goes on to say that "the board should satisfy itself that these sources of assurance have sufficient authority, independence and expertise to enable them to provide objective advice and information to the board." Expertise is written in my italics: it ought not to be good enough for anyone to hold themselves out as a professional risk practitioner without having appropriate credentials. In my view appropriate credentials are rarely provided solely by dint of a qualification in another professional area.

Section 4 of the guidance provides some thought on the establishment of risk management and internal control systems. There is comparatively little that is new or innovative in this regard in this document. Section 5 addresses the requirements to monitor and review risk management and internal control systems. Most important in this section are the recommendations as to what an annual review of effectiveness should address. These include:

  • Risk appetite
  • The operation of the risk and control systems;
  • The integration of risk and control with considerations of strategy and business model;
  • Changes in risks and the ability to change in response to the external environment;
  • Risk communications
  • Issues dealt with by the board during the year; and
  • The effectiveness of the reporting process to the public.

It will be up to the board to determine how this review is carried out. No doubt internal audit will often be the default choice. I would merely caution the board to consider the relevant domain qualifications, skills and expertise resident in their internal audit departments. Some will have it, others definitely will not and the board will have to satisfy itself that the right people are conducting the review.

Section 6 of the guidance addresses specific reporting requirements, which I do not propose to cover here, apart from the “Safe Harbour Provision in relation to the Strategic Report, Directors’ Report and the Directors’ Remuneration Report”. Directors will benefit from some protection from making misleading statements in these areas provided that they did not know that the statements were untrue or misleading and did not know that the omission was a dishonest concealment of a material fact. Again, this suggests to me that directors may well wish to engage with professional advisors to assist in the preparation of relevant information being provided to shareholders (and others) in these various reports.

Appendices A and B deal with Going Concern and the Longer Term Viability Statement respectively. I will address these in a subsequent note.

Appendix C provides some useful questions for the board to consider, and Appendix D sets out the relevant sections of the UK Corporate Governance Code and other regulatory provisions.


This document is far reaching in how it addresses risk management. Many companies are going to struggle to articulate their risk appetite or understand their risk culture with sufficient depth to make the concepts meaningful. I anticipate that boards will start to recruit “risk” non executives to their cadre and that we will see more risk board advisors emerging. 

My key recommendation is that all boards should consider the content of this guidance carefully and take steps sooner rather than later to address any shortcomings in their current procedures.

Richard Anderson is the Chairman of the Institute of Risk Management and was the principal author of their guidance on risk appetite and tolerance. He is the principal at AndersonRisk and works with a number of UK and overseas Boards on governance and risk management matters.

If you'd like to get in touch with Richard, please contact us at with your questions or comments.

Make a Comment

Unlocking Management Information - Part 2

Friday, 29 August 2014

Posted by Tom Venables

In the previous instalment, I described the need to clearly understand the purpose of a Business Intelligence (BI) platform used for management information and to manage the expectations placed on the system. It is important to remember that your BI system should be providing targeted, business-led reporting and not simply used as a data-dump tool. In this continuation of the series, I would like to talk about the options we have to secure the stored data for targeted reporting which can bring the business requirements and compliance together.

The first principle is: do not import sensitive data unless absolutely required.

It may seem obvious, but many organisations miss this key opportunity to ensure that sensitive data cannot be accessed in the BI platforms; it really can be as simple as ensuring the data is not there in the first place. As discussed last time, with a clear understanding of the report requirements it may be possible to include only a level of information which is not considered sensitive and therefore does not require the same level of control as that of the source system. 

By working closely with the extraction and transformation specialists from the BW build team, it is possible to ensure that these sensitive characteristics are then stored in a format which presents minimal risk of access to the data, such as aggregated information. Logical separation of the data, such as storing in dedicated infoproviders can further help to ensure that even users with the ability to create reports cannot access the sensitive data.  This is particularly relevant in systems where you must consider Data Privacy and commercially sensitive or confidential data.

Challenging the need to import data is one of the most straightforward ways in which we can assist users at all levels of the business in thinking about the need to include information in the BW systems. ETL (extraction and transformation) layers of the datamodel encompass not only the direct extraction of data from source systems, but also have the capability to transform data. Transformation provides an up-front mechanism to identify sensitive data that may be required and to manipulate it into formats which do not present the same degree of risk to an organisation, for example aggregation, which allows data to be displayed for a team, rather than identifiably linked to individuals.

Many organisations have used BI systems merely as a replacement for table queries from their SAP systems; importing all data and providing it in a format which is difficult to secure and which does not intelligently present the data in a manner which supports business processes. Ensuring that reports are process-driven will permit authorisation teams to work with management information functions and provide compliant, business-led reporting.

Once your data is extracted from source and transformed into a form which is delivering the needs of the reports, in a more compliant format, you can think about the next principles for securing reporting data, which I will cover in the next session.

If you have any comments or questions, please feel free to use the comment submission below

Make a Comment

Security Engagement

Monday, 18 August 2014

Posted by Tom Venables

When should security get involved in a project?

The short answer to this is; as early in the project as possible!

One of the most challenging aspects of security for SAP projects is often seen when security teams are engaged late in the project lifecycle, when a project is already deep into the build phase of whatever development is taking place and the need to achieve functionality in a controlled, compliant manner is raised only after the requirements have been gathered. Often we see security as an afterthought to functionality and this presents a number of challenges for successful delivery.

These challenges  come about because there has been no opportunity for security to share in the design decisions, to understand the requirements from the point of view of an end-user, or to sit with process and risk owners to understand the control objectives of the organisation. 

Often, development teams proceed with creating new functionality, whether it be a portal application, a new transaction, program, or even a new report, they migrate it through a landscape and sometimes all the way to production before finding out that no-one can access their shiny new functionality. At this point, the security for the development is then handled as part of an incident management process, rather than being scoped as part of the project itself. This places pressure on security teams in terms of cost, time and results in a negative perception of the security function.

A lack of involvement from the security & authorisations function early in a project lifecycle means that important risk control objectives are often not incorporated in requirements and this can snowball and impact all phases of the project:

Design phase:

Without clear definition of the functional requirements of developments, the scope for security changes is not confirmed and it is extremely difficult to achieve a technical design which meets the requirements. Understanding the control objectives, risks which must be addressed and the technical architecture involved is essential. 

Without a clear set of requirements for both the business functionality and security, it can be particularly challenging to come up with a design for your roles which supports the needs of your organisation. In addition, security design is more effective when the needs of the business are understood by the security administrators. 

Build phase:

So, you have little or no functional / technical design documents on which to base your build of the authorisation components, but still a requirement to have roles in place to support the project. Without knowing what authorisations to grant, or restrict, the roles themselves may have insufficient authorisation (which will impact testing experience), or excessive authorisations, which will be highlighted by auditors. 


Say you have managed, by virtue of a lot of effort in your build phase, to get roles built, the roles are handed over to UAT execution and at this point, the testers identify defects in the roles. Perhaps they permit access to some sensitive data or fail in the testing of some critical activity. These issues are then raised as defects in the role, rather than changes to the scope of the roles. Without a design, how do you know that the build fits that design?


If the testing phase of the project is signed off, despite (IN SPITE OF LINGERING) some lingering issues with the security, you now have to handle issues in the production system. Forcing changes through a business as usual process, you’ve got to deal with a negative perception of security, face time pressures on getting functionality working in production or may face the prospect of failed audits. At this point, your management now have to decide if they’re going to create a remediation project purely for the authorisations. This is one common justification for the creation of GRC projects, to identify issues and remediate.

How do you get early engagement?

It’s not an easy thing to change the way an organisation engages with the security teams, but one thing which I have seen work well lies in educating project and change managers about their responsibilities to include security in all phases of the project. An element of this can include stage gate approvals from security to exit each phase of the project. Using your existing change control processes, it should be possible to include a review step in the design phase and as part of stakeholder engagement to ensure that changes cannot progress until the security impacts have been assessed.

To summarise, if security is involved in sap projects from the outset, not only will it be more liekly to work, the organisation will also save time and resources it would have deployed later in the process to fix the problems.

If you have any comments or questions, please feel free to use the comment submission below

Make a Comment

SAP GRC 2014, Orlando

Friday, 4 April 2014

Posted by Richard Hunt

Last week I attended the US based SAP GRC conference for the eighth year in a row and this year it was back to where it all started for us, Orlando Florida.

It was a great opportunity to catch up with our US based SAP colleagues and customers and I was joined by three members of our US team and a couple of our team in the UK who were speaking at the conference. The team at SAP Insider put on another well organised event and co-hosting it with the SAP Financials event, I felt, worked really well as everybody had an interest of some sort in GRC.

The event was again well attended and it was a fantastic opportunity to hear from US customers how they are leveraging their SAP GRC tools.

The highlights for us this year were:

1. The official launch of SAP GRC Audit Management on HANA.

Audit Management is the latest addition to SAP’s GRC focused solutions. The solution is focused on helping companies manage the audit cycle. The solution is still evolving and with a HANA backend its future roadmap is sure to include some very interesting audit analytics capabilities.

Here’s an overview diagram of the new product:

Audit Management Overview












2. More customers leveraging Process Controls.

At this year’s event we noted more customers with experience of SAP GRC Process Controls in their environments. This led to a lot more detailed discussions around the capabilities and potential use cases of the product and it was great to explore ideas with these customers.

It was encouraging to hear that our customers are still at the leading edge in terms of getting benefits from process controls.

3. Increased uptake of HANA in the US customer base.

We noted that the take up of HANA was significantly more prevalent amongst US based customers than we have found to be the case in Europe to date. This is a very positive development as it indicates a shift towards this technology amongst the SAP customer base generally.

HANA offers a lot of exciting possibilities in the GRC space and we are looking forward to helping more customers to harness this technology.

4. Increasing interest in SAP GRC Risk Management.

Having successfully implemented Access and Process Controls we are finding more and more customers turning to the Risk management module. This is an area we have put significant focus on over the past two years having developed a Rapid Deployment Solution (RDS) with significant enhancements over and above the SAP standard solution.

We met with a number of customers on this topic in Orlando and are looking forward to helping more customers to utilise this product.

5. Increased product integration across AC, PC and RM.

Many customers we spoke to at the event were interested in how they can make their usage of GRC more efficient and improve their GRC processes by further integrating the GRC components. We had several discussions around options for sharing risks across AC, PC and RM and around how best to integrate the products to take a more holistic approach.

This is something that we have been seeing more in our own customer base and its encouraging to see other SAP GRC users looking to maximise the return on their GRC investment.

It was great to be back in Orlando and we are already looking ahead to next year which may well be back in Vegas (TBC). For those who were not able to join us at the US conference the good news is that this year's European event is only a few weeks away and will be held at a new venue in Nice, France. We will be there again, with our speakers repeating their sessions in addition to some other content we have been asked to provide. If you’re interested in attending the Nice event please let us know – as exhibitors we are able to offer you a customer discount.

Hopefully we will see you there!

Make a Comment