- SAP Managed Tags:
Part #3/5: How to build a mitigating controls repository?
Building a repository of mitigating controls requires a good understanding of the access risk, the system, and, above all, the context, i.e. business processes (and not only) in which we embed these controls. If you already have this knowledge, read the article, in which you will learn how to create a repository of mitigating controls in practice and what it really means.
If you are still wondering if you need mitigation controls, I recommend the previous entry in this series (Mitigating Controls - Is this a cure for 'all evil'?), Which will tell you when to use them and when to rely on other mechanisms.
Risks and mitigating controls
Dealing with risk in the case of user access to systems is subject to similar rules as we apply to any other type of risk.
A bit of theory first - key risk response strategies include:
When speaking theoretically about mitigating (or compensating) controls, the risk usually refers to the first of these strategies. However, in the design approach it is a certain simplification because we refer to mitigating control as actions within each of these 4 strategies (I am aware of how this can offend purists of risk management theory). Of course, this is a simplification, but it is very useful and facilitates the later implementation of mitigating controls in GRC class solutions (this subject will be detailed in the next article).
Repository - the hardest to start ...
When creating a repository of mitigating controls, it is worth considering what we already have, and then how we can use and optimize it. Below are some of the practical approaches we encountered in our design practice. Let's start from the beginning, i.e. approaches that are fortunately less and less common on projects:
Tabula rasa….
Let us assume that we have identified risks related to access to systems or conflicts of separation (separation) of the so-called SoDs and we try to solve them and…. we hit the wall, i.e. we meet with business or other project shareholders and learn that:
- YES - of course, all SoD risks and conflicts should be addressed, but
- NO - we do not agree to changes, including restriction of access (or we can only guess in a few cases) and
- NO - we do not have any mitigating controls that you could use to address the risk
We call this business position the Bermuda Triangle, in which all access risks or segregation of duties conflicts disappear…. Until an auditor comes or fraud is committed, then they magically come back in time. As a result, it is necessary to dive inside the Triangle to bring out all the solutions that have been brought down
Below I will briefly present an approach that will allow us to avoid this trap and address the issue of risk in a structured way.
Step One – Recognition
If you work in an organization where an internal control system based on COSO, or ICFR has been implemented, you are subject to SOX, J-SOX, or other ICS regulations, then I invite you to the Second Step immediately.
For those who work in organizations where these practices have not yet been implemented, there are dedicated activities that have proven themselves well in our projects for many years.
What may seem surprising at first, but our practice shows that the best control identification mechanism that we use on projects is… conversation. Before you start implementing the so-called best practices in controlling whether you will bring benchmarks and standards for duplication into the business, start by talking to the owners and key users of business processes
The basic information that we want to gain during such a conversation is a good understanding of the business context in which the risk occurs, what element of the process it is, who performs it, what activities are carried out (in the system and outside the system), what other elements of the process are implemented (reporting, approval, etc.). If during these conversations (going through the processes you come across activities like control elements), it is worth describing them in detail (preferably following the 5W principle - frequently used systematics of control description).
The effects of such meetings are surprising, usually, more than half of the controls that we then use for mitigation are already carried out by the business and there is no need for any additional actions to address the risk or SoD conflict with them.
Step Two – Selection
Having a defined list of internal controls, regardless of the method of obtaining - whether through the diagnosis described above or based on the available documentation, we can proceed to filter which of these controls we can use to mitigate SoD conflicts.
First, let's establish the criteria that we will use when selecting mitigating controls.
Typically, at least the key aspects for creating a repository are considered:
Having the aspects of the analysis defined in this way, the selection criteria are self-evident - we choose only those controls that are adequate to the identified access risks or SoD conflicts.
Based on this initial selection, we will be able to determine whether we address the needs of all business areas or whether we need to add new controls that will allow for mitigation in the areas of "white spots". It is at this stage that we can use external sources, i.e. best practices.
Step Two '(Prim) - External Sources
The basic external sources for control are, of course, all types of standards, including COSO, CoCo, ICFR, IFC, ICS, CobIT, etc. If you are looking for information that is already processed for the needs of the SAP system, I encourage you to read the repository of processes that SAP provides for S / 4 - it is a mine of ideas for control and specific process settings.
For SAP systems, predefined automatic controls are also available, e.g. in the SAP Process Control solution, more widely described e.g. here (link)
Shortly, we plan to publish a series of articles on automatic controls in individual business processes that we can use to mitigate risks. We will provide a link to the materials as soon as they are updated.
Step Three – Repository
After collecting the information and making the initial selection, we can start building the control repository.
Depending on the needs and complexity of our environment, different criteria are adopted for the description of basic data, our practical experience shows that it is worth including at least the following information in the control repository:
Basic information:
User assignments:
Regardless of the criteria presented above, it is also necessary to store data on the attribution of mitigating checks to the actions of individual users. In this case, information that needs to be gathered and kept are:
Data on the assignment of control to users as transaction data should be placed in a separate repository (linked to the control repository).
Step Four - Update
Creating and managing a repository requires support in the form of a backup tool. Depending on the possibilities that our company has at its disposal, this may be the minimum version, i.e. using Excel sheets and making them available to interested entities, and then manually assigning them to access risks, SoD conflicts, and, consequently, to people for whom these risks occur (even when writing about it, I have the nightmare of people who will later have to manage this repository and manually track all assignments, their expiration ...).
There are, of course, several dedicated work automation products for SAP – e.g. SAP Access Control or SmartGRC. I will talk more about them in the next part of this series.
In summary, building a mitigating controls repository requires:
In the next, fourth part of the article, we analyze the topic of automation and implementation of control in GRC systems. We will discuss key functionalities that should be implemented to effectively support SoD risk analysis and management of mitigating controls. Join us and find out more in the upcoming article!
Please share feedback or thoughts in a comment section.
Read more on related topic in SAP Solutions for Governance, Risk, and Compliance Topic Page
Filip Nowak
Building a repository of mitigating controls requires a good understanding of the access risk, the system, and, above all, the context, i.e. business processes (and not only) in which we embed these controls. If you already have this knowledge, read the article, in which you will learn how to create a repository of mitigating controls in practice and what it really means.
If you are still wondering if you need mitigation controls, I recommend the previous entry in this series (Mitigating Controls - Is this a cure for 'all evil'?), Which will tell you when to use them and when to rely on other mechanisms.
Risks and mitigating controls
Dealing with risk in the case of user access to systems is subject to similar rules as we apply to any other type of risk.
A bit of theory first - key risk response strategies include:
- a) risk minimization (reduction) - activities aimed at reducing the negative effects of threats,
- b) risk transfer (transfer) - insurance, outsourcing,
- c) risk avoidance - eliminating threats, changing the scope of the project,
- d) risk acceptance - usually by the risk owner, process owner, or management.
When speaking theoretically about mitigating (or compensating) controls, the risk usually refers to the first of these strategies. However, in the design approach it is a certain simplification because we refer to mitigating control as actions within each of these 4 strategies (I am aware of how this can offend purists of risk management theory). Of course, this is a simplification, but it is very useful and facilitates the later implementation of mitigating controls in GRC class solutions (this subject will be detailed in the next article).
Repository - the hardest to start ...
When creating a repository of mitigating controls, it is worth considering what we already have, and then how we can use and optimize it. Below are some of the practical approaches we encountered in our design practice. Let's start from the beginning, i.e. approaches that are fortunately less and less common on projects:
Tabula rasa….
Let us assume that we have identified risks related to access to systems or conflicts of separation (separation) of the so-called SoDs and we try to solve them and…. we hit the wall, i.e. we meet with business or other project shareholders and learn that:
- YES - of course, all SoD risks and conflicts should be addressed, but
- NO - we do not agree to changes, including restriction of access (or we can only guess in a few cases) and
- NO - we do not have any mitigating controls that you could use to address the risk
We call this business position the Bermuda Triangle, in which all access risks or segregation of duties conflicts disappear…. Until an auditor comes or fraud is committed, then they magically come back in time. As a result, it is necessary to dive inside the Triangle to bring out all the solutions that have been brought down
Below I will briefly present an approach that will allow us to avoid this trap and address the issue of risk in a structured way.
Step One – Recognition
If you work in an organization where an internal control system based on COSO, or ICFR has been implemented, you are subject to SOX, J-SOX, or other ICS regulations, then I invite you to the Second Step immediately.
For those who work in organizations where these practices have not yet been implemented, there are dedicated activities that have proven themselves well in our projects for many years.
What may seem surprising at first, but our practice shows that the best control identification mechanism that we use on projects is… conversation. Before you start implementing the so-called best practices in controlling whether you will bring benchmarks and standards for duplication into the business, start by talking to the owners and key users of business processes
The basic information that we want to gain during such a conversation is a good understanding of the business context in which the risk occurs, what element of the process it is, who performs it, what activities are carried out (in the system and outside the system), what other elements of the process are implemented (reporting, approval, etc.). If during these conversations (going through the processes you come across activities like control elements), it is worth describing them in detail (preferably following the 5W principle - frequently used systematics of control description).
The effects of such meetings are surprising, usually, more than half of the controls that we then use for mitigation are already carried out by the business and there is no need for any additional actions to address the risk or SoD conflict with them.
Step Two – Selection
Having a defined list of internal controls, regardless of the method of obtaining - whether through the diagnosis described above or based on the available documentation, we can proceed to filter which of these controls we can use to mitigate SoD conflicts.
First, let's establish the criteria that we will use when selecting mitigating controls.
Typically, at least the key aspects for creating a repository are considered:
- the process in which the control occurs (whether in the scope of SoD analysis),
- organizational scope - which units are under control, whether they are SoD units,
- assertions like completeness and accuracy - whether all relevant transaction data is covered by control, whether we do not omit a significant part, e.g. we only considered a selected type of employment, specific orders, etc.,
- exceptions - exceptions handling method, complementary controls,
- actors - persons performing controls vs. people carrying out transactions, whether they are the same or different people,
- documentation - description of the control process, is it available or we can obtain it,
- control effectiveness - how will we make sure that a given control is performed and that it is effectively reducing risks?
Having the aspects of the analysis defined in this way, the selection criteria are self-evident - we choose only those controls that are adequate to the identified access risks or SoD conflicts.
Based on this initial selection, we will be able to determine whether we address the needs of all business areas or whether we need to add new controls that will allow for mitigation in the areas of "white spots". It is at this stage that we can use external sources, i.e. best practices.
Step Two '(Prim) - External Sources
The basic external sources for control are, of course, all types of standards, including COSO, CoCo, ICFR, IFC, ICS, CobIT, etc. If you are looking for information that is already processed for the needs of the SAP system, I encourage you to read the repository of processes that SAP provides for S / 4 - it is a mine of ideas for control and specific process settings.
For SAP systems, predefined automatic controls are also available, e.g. in the SAP Process Control solution, more widely described e.g. here (link)
Shortly, we plan to publish a series of articles on automatic controls in individual business processes that we can use to mitigate risks. We will provide a link to the materials as soon as they are updated.
Step Three – Repository
After collecting the information and making the initial selection, we can start building the control repository.
Depending on the needs and complexity of our environment, different criteria are adopted for the description of basic data, our practical experience shows that it is worth including at least the following information in the control repository:
Basic information:
- Control ID
- Description (preferably based on 5W)
- Type: preventive, detection, corrective
- Determining whether the control is event-related (event description) or periodic (defined period)
- Automation of the execution of control and testing (automated, semi-automated, manual)
- Business context
- Process / sub-process / business area
- Organizational unit (or range of units)
- The owner of controls in each unit, persons performing the controls
- Risk context
- Connected risks (i.e. which risks, and SoD conflicts can be mitigated using this control)
- Effectiveness of mitigation:
- Control effectiveness testing results (period/scope/result)
User assignments:
Regardless of the criteria presented above, it is also necessary to store data on the attribution of mitigating checks to the actions of individual users. In this case, information that needs to be gathered and kept are:
- SoD conflicts, access risks identified on users
- method of mitigation (ID of mitigating control)
- organizational scope (identifier of the unit for which the control was assigned)
- validity time of the assignment (the maximum period after which it is necessary to verify that the assignment is still valid and required)
Data on the assignment of control to users as transaction data should be placed in a separate repository (linked to the control repository).
Step Four - Update
Creating and managing a repository requires support in the form of a backup tool. Depending on the possibilities that our company has at its disposal, this may be the minimum version, i.e. using Excel sheets and making them available to interested entities, and then manually assigning them to access risks, SoD conflicts, and, consequently, to people for whom these risks occur (even when writing about it, I have the nightmare of people who will later have to manage this repository and manually track all assignments, their expiration ...).
There are, of course, several dedicated work automation products for SAP – e.g. SAP Access Control or SmartGRC. I will talk more about them in the next part of this series.
In summary, building a mitigating controls repository requires:
- Knowledge of the business context,
- Identification of control activities and proper selection for the purposes of mitigation,
- Documentation based on established criteria,
- Tool support for master data management and user assignment.
In the next, fourth part of the article, we analyze the topic of automation and implementation of control in GRC systems. We will discuss key functionalities that should be implemented to effectively support SoD risk analysis and management of mitigating controls. Join us and find out more in the upcoming article!
Please share feedback or thoughts in a comment section.
Read more on related topic in SAP Solutions for Governance, Risk, and Compliance Topic Page
- See our introductory post with link to other articles in this series prepared together with andrzejpartyka
- Ask questions about Governance, Risk, Compliance (GRC), and Cybersecurity and follow us
- Read other Governance, Risk, Compliance (GRC), and Cybersecurity and follow blog post
- Please follow us on and our profile for future posts fnowak and andrzejpartyka
Filip Nowak
