Leveraging SAP GRC in the Fight Against Corruption and Fraud

2.2 The main features of an anti-corruption framework

2.2.1 Content focus: ICS integration

When looking at the content structure of an anti-corruption framework, we have to consider the developments presented below.

In the GRC world, recent years have been marked by an integrated approach. Amongst other things, this means that the boundaries between an ICS and risk management—from both a content and process perspective—have become increasingly less significant. Where necessary, today, risks at the operational level can be integrated seamlessly into an ICS.

To achieve a framework structure that is as generic to all industries as possible, we will take the well-known COSO-based structure as a basis (see Figure 2.4 as part of Figure 2.2). To do this, we should look at a further development: the multiple compliance framework approach. The idea behind this is that you can manage multiple dimensions or views at compliance level simultaneously.

Figure 2.4: Framework contents: the basic structure

What main features do we expect from a framework that should increasingly accommodate anti-corruption elements beyond the usual ICS objectives?

• Controls at company level, also referred to as entity-level controls (ELCs), are vitally important in an anti-corruption framework. For the usual ICS purposes, self-assessments and tests would be sufficient; beyond this, however, in an anti-corruption context, we would expect GRC software to be able to automate some of the underlying processes for the controls.
• In an anti-corruption environment, ELCs also contain specific activities and measures referred to as collective action.

Beyond ELCs, we would expect the following supporting focuses in an ICS area based on business processes:

• Business process controls with an anti-fraud focus are being initiated increasingly in an anti-corruption framework. Amongst other things, it is a matter of observing the principle of dual control, whereby achieving a segregation of duties (with a focus on prevention) is a must in business applications—by means of application controls, roles designed to be free of SoD conflicts, or corresponding manual (compensating) controls where there is no other alternative from an organizational or technical perspective.
• In addition to preventive controls, detective controls can also be used. In ERP-supported business processes in particular, this inevitably also involves topics such as data analytics and CCM (continuous control monitoring).
• SoD conflict-free role design reaches into the next ICS level which we are familiar with from the ICS world shaped by COSO/COBIT: IT General Controls [ITGC]. In the area of security, we would expect an SoD- and ICS-conform user and authorization management.
• Beyond the authorizations in the application layer, there are also further important security topics which, depending on the risk potential specific to the company, would be relevant for fighting corruption. These topics can be grouped under the fashionable phrase cyber security (see Section 1.2.7).

Prevention and timely detection of intentional impairments of IT systems are particularly relevant for achieving anti-corruption objectives in IT.

Due to the special importance attached to the content in GRC, in Chapter 3 I will address the internal design of an anti-corruption framework in more detail—including some industry-specific and process-specific examples.

2.2.2 Process focus in an anti-corruption framework

In this section, I will explain the process side of an anti-corruption initiative. The standards already mentioned (World Bank Institute, UN Global Compact, Transparency International, etc.) describe four main processes in an initiative for preventing and detecting corruption. This initiative is based on principles in the well-known COSO model, supplemented by an additional feedback component, and then grouped into six components.

These COSO-oriented components (see Figure 2.5) unite basic principles that can be found in all processes.

Figure 2.5: The process side in an anti-corruption framework

What do the individual elements of our so far rather abstract construct contain? In the following, I will address the individual main processes and in particular, the objectives they contain:

Even though by far not all conflicts of interest are facilitated by a dangerous accumulation of access authorizations to business applications (SoD (segregation of duties) conflicts), it is important to deal with critical SoD conflicts in application authorizations. For other conflicts of interest that cannot be uncovered using information technology, it is a matter of recording corresponding risks and evaluating them.

As you will already have noticed, risk management is very important in an anti-corruption framework. In 2004, there was an addition to the original COSO model (COSO II): the COSO ERM – Enterprise Risk Management framework was published. COSO ERM inserts additional components and thus takes account of the growing need for and the increasing importance of the integration of the ICS with risk management. For example, the Risk Assessment component shown in Figure 2.5 was split into the following components in COSO ERM:

• 1. Event identification
• 2. Risk assessment
• 3. Risk response

As features of main processes, these additional components are also relevant for our anti-cube model. For example, during the evaluation of risks (first main process), it is important to analyze the events (incidents, losses, etc.) recorded as part of the detective processes (third main process). The accumulation of such events in a certain risk category or a business process can, for example, be an indication that there are still some blank spaces in the map of corruption risks.

Even if we cannot stress often enough how important “tone setting from the top” and a systematic education for the purpose of ensuring a healthy compliance culture in a company are, a compliance initiative without detection would be incomplete:

I will address the role of the external auditor and widespread misunderstandings in this context in Section 3.1.3.

A systematic recording of all risk events, in particular an intuitively performed and well-known (in the company) opportunity to report these events (both internally and externally) has proven its worth in practice. Corruption-relevant incidents can be recorded in tools based on case management, such as:

• Whistleblower input
• Compliance incidents or risk events reported by employees using online options
• Centralized recording of qualified incidents by the helpline or compliance team
• Complaints from customers/business partners
• Audit findings (internal and external audit)

The ideal status of a case management system would be a system integrated with GRC initiatives. Event types related to GRC would be, for example, security incidents (within the scope of Information Security Risk Management), ICS issues (ineffective or unsuitably designed process controls), and incidents. You will learn how these cases are supported by SAP GRC in Section 2.6.2 and Section 2.6.3.

The order of the main processes from 1 to 4 is merely to provide a better overview; their order is not set in stone in practice: for example, preventive risk countermeasures (risk response—see process group 4) can be set up at the same time as risk assessment (process group 1). The (residual) risk evaluation can take place simultaneously with a status follow-up of the relevant action plan. What is important is that all objectives addressed in anti-corruption and compliance processes are achieved. The last process group, reaction, therefore, is concerned with taking a critical look back at what has happened and defining suitable measures for the future.

Another important principle you should consider in an anti-corruption initiative is the feedback principle. This can be explained from the following three perspectives:

• On the one hand, this principle is concerned with giving employees the opportunity to express their own opinion from the bottom of the company up about GRC-relevant facts on an ad-hoc basis (process group 3, helpline).
• On the other hand, transparent accountability over the progress (budget, completion, etc.) of critical projects, services, or over the clarification of incidents on a “top-down” basis must be guaranteed.
• Gathering opinion “systematically” via surveys is part of this process and is seen as part of the evaluations (first main process).

Employees can express opinions on their own initiative via the above-mentioned helpline (online or through contact with the compliance department) or anonymously via the whistleblower function.

We have now completed the software-independent description of the main processes in a company-wide anti-corruption framework. To build a bridge from the abstract theory to practice, in the next section I will present SAP GRC-specific examples of the implementation of the main processes.