Sep 5
GRC SAP

This document elaborates the SoD Management Process that is a key part to reduce Segregation of Duty (SoD) conflicts in a company. In fact SoD is a key contributor for fraud activities within an organization and hence to achieve seamless compliance (e.g. SOX) it is absolutely necessary to follow a straight process.

 

The SoD Management Process has six single steps that need to be completed one after one. Each step has its own outcome that you have to achieve before proceeding with the next.

 

Steps Description
step1.png

Gather a list of applicable SOD conflicts that allow fraud or generate significant errors. The outcome of this step is that your business has determined what is an unacceptable risk that they want to report on and manage via remediation or mitigation.

 

Helpful documents:

Risk Lifecycle

step2.png

Build the rule set based on the recognized risks from step 1. The outcome of this step is the technical rule set to analyze the user and/or role assignments.

 

Helpful documents:

Business Risks / Rule Set

Rule set - Rules & Rule Types

step3.png

Analyze the SoD output. This can be performed with the help of SAP GRC Access Control. In case of manual analysis, for each user, analyze if he/she has the access to perform any of the conflicting functions defined in step 1. The outcome is basically to provide the business insight to alternatives for correcting or eliminating discovered risks.

 

Helpful documents:

Online vs. Offline Risk Analysis

step4.png

In this step, evaluate if the conflicting tasks can be performed by an alternate person. If so, role changes and/or user reassignments can be performed to segregate duties properly. The outcome must be a very low number of remaining risks that need mitigation.

 

Helpful documents:

Remediating Access Control SoD Risks

step5.png

If it would not be possible to remediate the existing conflicts, consider formulating an appropriate control to mitigate the risk. This would typically entail working with the business to setup additional monitoring procedures that ensure to compensate the risk. The outcome must be no remaining risks.

 

Helpful documents:

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

Creation of Mitigation Controls in GRC 10.0

Mitigating Control Lifecycle

step6.png

Finally, establish a new continuous process wherein every access request is reviewed against the SoD conflict matrix prior to provisioning on the system. Also make sure that all role changes must be analyzed and remediated before implementing. The outcome, and also final result, your system remains clean.


Helpful documents:

Approve/Reject Own Requests

Risk Terminator - GRC 10


Best regards,
Alessandro 

Posted by Alessandro Banzer

Twitter Facebook
Aug 25
GRC

GRC's Access Risk Analysis is a tool within Access Controls to enable you to define user access risk (via way of a rule set); execute risk analysis to identify access risk (or simulate for potential risk); and then provide you with system functionality to remediate the risk or mitigate via assignment of a control. As this is an approach, it can apply to any version of GRC (of course the system screen shots are in 10.x version).

Like any other risk process the reviewer is has four options: accept; transfer; mitigate or remediate. This document details our strategy and approach to risk remediation. Our position is that you should always attempt to remediate a risk before your mitigate. Remediation removes the risk (or the residual level is acceptable) from the system and does not rely on the use of compensating control (typically manual control that requires a person to take regular action and can be subjected to human error). Accepting and transferring of risk are last resorts. Of-course the your decision would involve a cost-benefit analysis. It makes not sense to spend more on the control than the true cost of the risk (financial, reputation, legal and compliance, etc).

When a risk has been identified (violation, issue, etc.) someone has to take action to resolve it. Depending on your master data setup, GRC automatically displays the risk definition, including who is responsible (risk owner); the respective business process; as well as mitigation owners/monitors. This information is important to enable your to know who to contact to discuss the risk and receive advise (and some of this interaction will occur off system).


Risk Violation Count is Massive (Why?)


Be aware that the first time you run a risk analysis it is likely that the number of violations will be very high. Users may have access creep due to change in job function and retained old access. Roles may have been built with too much access. At the time, the business did not have adequate tools to identify these risks. Many organisations undergo a security redesign project once they have implemented GRC due to the number of inherent conflicts in their roles. In the end they find it easier to completely rebuild security (get it right and clean first time) than try to unpick the issues and clean the existing roles. In some cases, companies are aware of the issues but mistakenly believe implementing GRC will fix it: all GRC will do is give you the number of violations and will not help you if you do not go down the path of remediation and mitigation.


For example, in the screen shot below there are over 200,000 conflicts (more if we scrolled down). This number is large - huge - and probably daunting when it comes to fixing it. After all where would you start? Remember a risk violation is one rule in the risk definition being met. Therefore, if a risk has two functions and both functions have two actions you then have 4 rule violations. If a user happens to have all four actions they too have 4 violations. If there are 50 derived roles, you will see the violation count increase to 200 (4 x 200). In the screen shot below, on further analysis (not visible in this screen shot) the bulk of the issues are caused by derived roles. By cleaning the imparting roles the number of violations will reduce substantially (also, you cannot clean a derived role without using PFCG incorrectly or actually fixing the imparting role).

Risk_Analysis.png

Where to start for Remediation (Still overwhelmed by so many violations)?

Your security role design as well as access provisioning strategies will impact how you approach remediation. This diagram below assumed position-based security is used in your organisation. Depending on the authorisation concept and access management in your system, the number of circles will vary. For example, you may not user business roles or composite roles.

object sequence for remediation pbs.jpg

When approaching risk remediation, use the diagram below as a reference and work your way from the inside out.

    1. Single Roles: focus on remediating conflict in your imparting roles and other non-derived single roles. You will fix the derived roles when you distribute the change from the imparting (assuming you have followed SAP standard security rules and not added additional authorisations to your derived). Single role clean up will involved removal of transactions and other authorisations.
    2. Composite Roles: by this stage you expect that none of the single roles have inherent conflict. You cannot remediate risk in a composite role if the single role has conflict. Your choice to remediate at this point is to remove roles assigned to the composite (possible replace with a different version). Another option is to remove access from the single (it may not cause an inherent conflict in the single) if the access is not required and it is contributing to the violation.
    3. Business Roles: this assumes you have built business roles via GRC Business Role Management for provisioning. Same principal applies as composite.
    4. Positions: if you are using position based security then you can consider removing roles (single, derived, composite, etc) from the position.
    5. Users: finally you have removed all inherited risk. The only unmitigated risk violations against the user is due to the combination of access. At this stage you can then remove roles.

Note: Remediating inherent role conflict will take time. You will need to work with the business process owners (the business) to determine the appropriate solution. Once you identify the permissions to removal from a role you will then need to follow your companies change management process to schedule the change and arrange a transport to Production. As an interim measure, you may need to implement a mitigating control.

Who should I engage with? What should I say?


This will depend on your company's organisational model and approach to risk management. However, regardless of approach it is still a business decision. You will need to consider meeting with the business process owners, line managers, etc.


In starting the conversation with these stakeholders you need to outline and explain what the risk is and why it needs to be remediated. In some cases the conversation may be as simple as 'Is this access really required'. You may discover over time that access creep has cause the conflict and requires clean-up. Where a user is concerned, the question may be 'Does this user really need both access'. The stakeholders identify non-compliance in a job duties or that there is an alternative person to take on part of the function. Again, it will all depend on the business so get out there and talk to the stakeholders!

For some more ideas refer to Reviewing of Risks in the: Risk Lifecycle


How can I decide remediation approach?


The diagram below has been devised to visually represent the process to deciding how to remediate the access. You may devise a similar approach and change the sequence of options depending on your organisation's policy.

decision flow.jpg

Is it a Risk?: Before investing work effort into remediation you need to verify that violation is actually a risk and not a false positive.You may have executed the report at Action level only but if you re-ran at permission the violation is not longer there. Alternatively, you may look at the violation and question why it is a risk in the first place. If you realise the risk definition is incorrect then you need to change it. The rule-set is not static and must be reviewed regularly.

Does the object need both functions?

The violation is a risk and you need to take action. Does the object (role, position, etc) require both actions? To assist in this decision you could look at action usage reports in GRC. If it appears one of the functions is not used, then remove it. For roles this will be a change request and users/positions it will be an Access Request. Approval from the business will be required regardless.


Is there Alternative Access?

You determined the both functions were used but could you assign a different transaction or authorisation combination to restrict. For example, the user might have XK01/02 transactions for Vendors but does not need all views - such as payments details. Instead they only need FK01/02 which does not include the payment details.  By changing the transaction over the user can still perform their job function via a different transaction.

Is there a System Control - Can system controls via IMG configuration, workflow and ABAP development be implemented to remove the risk? Alternatively, can the business process be changed to include a new step. For example, add vendor confirmation via FK08/FL09 for sensitive fields to force a second pair of eyes to review the change.


Unable to Remediate -  By this stage you have exhausted all possibilities to remediate the access and must investigate mitigation as an option.As already mentioned many times on SCN, always try to find a way to remediate a risk instead of defining compensating controls. Mitigation, whether it be with the help of spot checks, reviewing postings, etc. is always a reactive way and fraudulent actions might be done in the mean time. Still there needs to be a balance between managing risk and allowing the business to function. If you cannot remediate, refer to the document for further details on defining mitigating controls: Defining Mitigating Controls / Compensating Controls



Analyse Again (or verify your Remediation via Simulation)


Once you have remediated your risk we recommend you re-execute your risks analysis. You need to ensure that by remediating the list violations you did not introduce a new one. The good news with GRC is the ability to simulate access risk. Before going to the effort of role change or access change you can execute a risk simulation to test removing of the conflicting function and replacing with the alternative. This will provide you with confidence to remediate and avoid introduction of new risk. Using simulation will also reduce rework through continual rebuild or access change.


Finally I'm Finished - the system is clean...

Sorry to break it to you bust risk identification and analysis is continual. You must regularly plan to review your rule set to ensure the risks are valid (support packs, enhancement packs, custom development, changes to configuration, changes to the business, etc) as the system and business is in a constant state of change. In addition, when security role changes are migrated to production then user may now have risks.


Keep on top of the review so you only ever have a small number of violations to respond to. Scheduling Role Re-certification in BRM, SoD and UAR Review workflow will help manage this regular review.


Does your organisation approach remediation in GRC differently? We would love to hear your feedback in the comments below.


Best regards,

Alessandro Banzer & Colleen Lee

See the original version of the document: http://scn.sap.com/docs/DOC-57447

Posted by Alessandro Banzer

Twitter Facebook
Jul 16
GRC

This document describes the difference between Online and Offline Risk Analysis in SAP GRC Access Control based on several SAP Notes.

In order to be able to run offline analysis at all, the configuration option "Enable Offline Risk Analysis" must be set to YES (Parameter 1027) in Access Control configuration settings in SPRO. 


This configuration option is now selectable in the Risk Analysis > Additional Criteria. 


Offline analysis is not real-time data but is dependent on the date of the last Batch Risk Analysis. The Batch Risk Analysis is run as background job in GRC by using program GRAC_BATCH_RA. This is the same batch risk analysis that is run to update the management reports and companies should be running this on a frequent basis to ensure their management reports are accurate. Running the Offline analysis is the same as drilling down via the Management View.

The benefits using offline analysis is mostly in response time. By using offline analysis, Risk Analysis and Remediation does not have to make as many calls into the connected systems so the analysis will return much faster than using online analysis. However, please keep in mind that offline analysis is not real-time and will not take into account any changes made since the last Batch Risk Analysis.

Also, it's important to understand that even when you run offline analysis it will have to make a call to the back-end system to obtain composite role names. Therefore, if the back-end system is down, offline analysis will not work.

Using offline analysis, you can obtain both summary and detail reports. The one exception is that if you run Report types Critical Action or Critical Permission, you will not be able to see the detail report, only the summary report. Please note that this is only for Critical Action and Critical Permission. Report types of Permission level and Action level can go down to the detail level in offline mode.

Please keep in mind that how you have the Batch Risk Analysis set up for defaults will impact the data you have to run offline analysis on. For example, in Configuration under Risk Analysis  you have the option "Exclude Locked Users". If this is set to YES, when running the batch risk analysis, it will not evaluate locked users which means the tables holding the conflicts will not include any data for locked users.

When you run Risk Analysis, you have the option to change Ignored Users field to something other than what is set up in the Configuration. However, if you change this to NOT ignore locked users and run in offline mode, you will not receive any conflicts because no locked users were evaluated during the batch risk analysis. Running this report in online mode may turn up conflicts with locked users.

Impacts on Workflows

The following listing shows the impact on each workflow which uses date from the risk analysis.

Segregation of Duty (SoD) Review

The system uses Offline Risk Analysis data to update management graphics and to generate SoD Review workflow requests. When the system detects SoD violations, it automatically sends reports to managers so that they can take actions to either remove user access or to mitigate the SoD risks.

User Access Review

The system uses Offline Risk Analysis data to update and generate UAR Review workflow requests.

Access Request Submission

The application automatically performs an online risk analysis when the requestor submits the request. This behaviour can be configured in parameter 1071 (Enable risk analysis on form submission). Note: The risk analysis results are intended for the approver. Therefore, the risk analysis results appear on the approver’s screens but not on the requestor’s screens. SoD violations for access requestes are stored in table GRACSODREPDATA.

Role Approval Workflow

In Business Role Management (BRM), some customers may have a business requirement that once a role is sent for approval to Role Approval workflow, the role owner(s) must re-run the risk analysis and mitigate a risk before approval. The risk analysis has to be performed during Analyze Access Risk methodology step and is always performed as Online Risk Analysis.

Impact on Reports

The following listing shows the impact on Reports which uses data from the risk analysis.

Risk Analyisis in Access Management

The risk analysis results in Access Management, like User Level, Role Level, Profile Level or HR Objects, are based on real-time risk analysis. Also simulation uses real-time risk analysis data.

Risk Analysis in Reports and Analytics

The risk analysis in Reports and Analytics tab is always offline analysis and hence you should have run the Batch Risk Analysis to populate the violations data.

Regards,
Alessandro

See the document also in SAP GRC Community: http://scn.sap.com/docs/DOC-56653

Posted by Alessandro Banzer

Twitter Facebook
Jul 6
GRC

In regard to my document about Rule Set / Business Risks I would like to give some detailed information about rules and rule types. As we learned rules (or risk rules) are possible combinations of transactions and permissions for a business risk.

Rules must be generated when ever risk contents change. This can be done in SPRO (GRC > Access Control > Access Risk Analysis > SOD Rules > Generate SoD Rules). Generally rules are combinations of actions and aren't maintained manually (done automatically by the program).

The number of rules defined from a risk is determined by 

  • the number of action combinations, and
  • permission/field value combinations contained in each function of the risk.

The following graphic shows the rule structure in more detail:


Now let me give you a short overview of the different types of rules considered by GRC.

Transaction Rules

Rule components are as follows:
  • System
  • Conflicting Actions
  • Rule ID
  • Risk Level
  • Status
Example (from the graphic above):

F001001: Maintain fictitious GL account & hide activitiy via postings
F001001 - Risk ID
F001001 - Action code combination number (represents Conflicting Actions)

Permission Rules

Rule components are as follows:
  • System
  • Object
  • Field
  • Rule ID
  • Risk Level
  • Status
Example (from the grapic above):

F00100101: Maintain fictitious GL account & hide activity via postings
F00100101 - Risk ID
F00100101 - Action code combination number
F00100101 - Object combination number

Critical Action

List of actions considered critical. Option to run at both Action and/or Permission level. Critical Actions are created same way as Segregation of Duty risks, exept Risk Type = Critical Action, and can contain only 1 function (as shown above with SCC4).

Critical Permission

List of objects/permission considered critical. Created same way as Segregation of Duty Risks, exept Risk Type = Critical Permission, can contain only 1 function, and function cannot contain actions.

Critical Roles and Profiles

Roles and profiles considered critical. Critical roles and profiles will be excluded from analysis if the configuration parameter 1031 (Ignore Critical Roles & Profiles) is set to YES.

Organizational

Used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organziational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies are controlling what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.

Supplementary

Additional security parameters other than authorizations a user must have to enable access. First checks to see if the user exists in the supplementary table, then checks if conditions are met. Based on exclusion setting, it will include or exclude the user in the risk analysis.

Please share and contribute in this document to make it better. See also my document on SAP SCN GRC community: http://scn.sap.com/docs/DOC-54530

Regards, Alessandro

Posted by Alessandro Banzer

Twitter Facebook
Jun 18
GRC

With respect to my document Rule set - Rules & Rule Types and as I've got some requests to discuss the org rules in more detail I would like to share some more information about organizational rules.

Organizational rules in GRC Access Control are used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organizational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies control what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.

Basically organizational rules allow you to filter false positives from the risks analysis. What does that mean? If you have a role concept where you derive roles from master roles, for example the leading organizational level is the company code, the risk analysis might show a risk which is due to the limitation of the authorization based on the organizational level no risk. Let me give you an example:

Role A: Z_ROLE_A_1000 for company code 1000 with action FB60

Role B: Z_ROLE_B_2000 for company code 2000 with action FK02


Role A contains transaction FB60 (posting of vendor invoices) for company code 1000, whereas Role B contains transaction FK02 (changing vendor master data) for company code 2000.

The combination of FK02 and FB60 is a SOD risk, as posting of vendor invoices and changing of vendor master data shouldn’t be performed by the same person. A user who gets the two roles would have both transactions assigned hence the risk analysis shows a risk. Actually this isn’t a risk, but as the organizational values are not considered it shows as a risk. This behavior is false positive as the user cannot execute FB60 and FK02 for the same company code. To filter these false positives you can utilize organizational rules.

While running a regular risk analysis, the user would show up with a SOD conflict, as he has both conflicting transactions assigned.  To find out if the risk exists for the same company code you can use the organizational rule. Therefore create an organizational rule hat filters the company code 1000 and apply this org rule to the risk analysis. After adding the org rule to the analysis the user won’t show up with the risk. Please be aware that after creating org rules the SOD rules must be regenerated (GRAC_GENERATE_RULES).

In most of the cases org rules are created for designated risks. Alternatively it is also possible to define org rules for all possible false positives by using wildcards (e.g. XGPR*).

Looking forward to your input.

Best regards,
Alessandro

See also on SAP SCN: http://scn.sap.com/docs/DOC-55986

Posted by Alessandro Banzer

Twitter Facebook
Apr 22
GRC

To get a better understanding how a business risk occur, we have to understand the process how GRC identifies a risk and its key terms which are used. One or more business risks can be covered in a rule set which is also shown below. Let’s start with the key terms which are used by specialist to talk about GRC.

Business Process – used to classify risk, rules and rule sets by business functions. E.g. Order to Cash, Purchase to Pay, etc. are all types of Business Processes. All risks and functions are assigned to business processes.

Business Risk – identify potential problems your enterprise may encounter, which could cause error or irregularities within the system.

Business Function – identifies the tasks an employee performs to accomplish a specific portion of their job responsibilities. This can be analogous to a role, but more often a role comprises multiple functions.

Actions – known as transactions in SAP. To perform a function, more than one transaction may be required to be performed.

Permissions – authorization object in SAP, which form as part of transactions.

Risk Rule - possible combinations of transactions and permissions for a business risk.

Rule set – categorize and aggregate the rules generated from a risk. When you define a risk, you attribute one or more rule sets to that risk. Similar to business processes.

Belows graphic shows the architecture of a Business Risk. Basically two business functions, for example accounts payable payments and vendor master maintenance, are defined as a business risk. The business risk is called “SOD required between accounts payable payments and vendor master maintenance” and says that this two functions should be segregated properly. The business risk, technically named XGPR0005 in my example, is assigned to a rule set. While analyzing the user, GRC compares the rule set with the actual authorization in SAP. Technically GRC compares the given authorization by the rule set and the actual authorization in SAP on permission level and reports if there is a match which should be segregated.


To make it more clear another graphic specifically designed for the above mentioned SOD conflict „SOD required between accounts payable payments and vendor master data maintenance“.


As seen above business risks are a combination of two business functions which shouldn't be performed by one single person. One or more business risks can be categorized in a rule set which is required to run the risk analysis. Another example, based on the architecture shown above, shows a typicall example of a rule set.


This example also shows that a business function (here Business Function 2) can conflict with one or more other business functions. Let's say Business Function 2 is "Accounts payable payments" which is conflicting with "Vendor masterdata maintenance" (shown as Business Function 1) and as well with "Bank Reconciliation" (shown as Business Function 3). Hence it might be possible to have a business function assigned in two or more business risks.

I hope this document helps to understand the concept of a rule set and how a rule set works from its architectural point of view.

This article is also online on the SAP SCN GRC community: http://scn.sap.com/docs/DOC-54434

Please do not hesitate to collaborate and share your knowledge.

Regards, Alessandro 

Posted by Alessandro Banzer

Twitter Facebook
Mar 3
GRC

A high amount of time during a SAP GRC project will be spent on defining processes and responsibilities. My suggestion is to think in lifecycles for getting a better understanding of the processes and who is taking over the responsibilty.

In this post I would like to clarify the lifecycle of Firefighter IDs. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

On request I have additionally added the RACI matrix to see who is Responsible, Accountable, Consulted and Informed for each step. Please be aware that this is very much depending on the point of view and can be different in your organization. My considerations are commonsense and pretty much of thinking in smooth processes throughout a global enterprise.

Creation of Firefighter ID

Tasks

  • Define the necessary access rights of the FFID
  • Define the responsibilities (Ownership, Controller)
  • Create Firefighter ID

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

Changing of Firefighter ID

Tasks

  • Define the necessary changes in access rights
  • Define changes in resonsibilities (Ownership, Controller)
  • Define changes of Firefighter ID (e.g. validity)

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner


Deletion of Firefighter ID

Tasks

  • Delete the Firefighter ID
  • Document the decision of the deletion
  • Archive belonging firefighter logfiles

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible


Reviewing of Firefighter ID 

Tasks

  • Review validity
  • Review rirefighter ownership and controller
  • Check proper access rights

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

Please also see my blog post on SAP SCN: http://scn.sap.com/community/grc/blog/2014/03/03/firefighter-id-lifecycle

If you want to have further information or contribute in this blog post do not hesitate to contact me or reply to this post directly.

Posted by Alessandro Banzer

Twitter Facebook
Feb 23
GRC
A high amount of time during a SAP GRC project will be spent on defining processes and responsibilities. My suggestion is to think in lifecycles for getting a better understanding of the processes and who is taking over the responsibilty.

In this post I would like to clarify the lifecycle of Risks. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.


Creation of Risks

Tasks

  • Define the SoD risk on business level (e.g. with internal auditors)
  • Evaluate the necessary transactions to execute the SoD conflict (transaction and authorization)
  • Implement the risk within SAP GRC AC
  • Validate the risk analysis results

Involved functions

  • Risk owner
  • Process owner
  • ICS responsible
  • SAP GRC responsible

Changing of Risks

Tasks

  • Define the changes within the SoD risk on business level (e.g. with internal auditors)
  • Evaluate the necessary transactions to execute the SoD conflict (transaction and authorization)
  • Change the risk within SAP GRC AC
  • Validate the risk analysis results

Involved functions

  • Risk owner
  • Process owner
  • ICS responsible
  • SAP GRC responsible


Deletion of Mitigation Controls

Tasks

  • Delete risks within SAP GRC AC which are not valid anylonger
  • Document the deletion of the risk and especially the decision to delete the risk

Involved functions

  • Risk owner
  • ICS responsible
  • SAP GRC responsible

Reviewing of Risks

Tasks

  • Analyse if maintained risks within SAP GRC are still valid
  • Define actions to take because of:
    • New business processes
    • Changes in the IT system
    • Changes in the Internal Control System

Involved functions

  • Risk owner
  • Process owner
  • ICS responsible
  • SAP GRC responsible

If you want to have further information or contribute in this post do not hesitate to contact me directly.

SAP SCN Blog Post: http://scn.sap.com/community/grc/blog/2014/02/23/risk-lifecycle

Posted by Alessandro Banzer

Twitter Facebook
Feb 23
GRC

A high amount of time during a SAP GRC project will be spent on defining processes and responsibilities. My suggestion is to think in lifecycles for getting a better understanding of the processes and who is taking over the responsibilty.

In this post I would like to clarify the lifecycle of Mitigating Controls. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

Creation of Mitigating Controls

Tasks

Define the control including:

  • Control description
  • Control execution
  • Control approver and control monitor
  • Documentation of control execution
  • Templates used to monitor the risk

Involved functions

  • Control Owner
  • ICS responsible
  • SAP GRC responsible

Changing of Mitigating Controls

Tasks

Change the control for example:

  • Control description
  • Control execution
  • Control approver and control monitor
  • Documentation of control execution
  • Templates used to monitor the risk

Involved functions

  • Control owner
  • ICS responsible
  • SAP GRC responsible

Deletion of Mitigation Controls

Tasks

  • Delete the mitigating control within SAP GRC AC
  • Document the decision of deletion of the mitigating control

Involved functions

  • Control Owner
  • ICS responsible
  • SAP GRC responsible

Reviewing of Mitigating Controls

Tasks

  • Analyse if maintained controls within SAP GRC are still valid
  • Analyse if the mitigating controls are covering the risk fully
  • Test the effectiveness of the mitigating controls

Involved functions

  • Control owner
  • ICS responsible
  • SAP GRC responsible

If you want to have further information or contribute in this blog post do not hesitate to contact me or reply to this post directly.

SAP SCN Blog Post: http://scn.sap.com/community/grc/blog/2014/02/23/mitigating-control-lifecycle

Posted by Alessandro Banzer

Twitter Facebook
Feb 10
GRC

In this article I would like to show you the structure of a rule set in GRC. To understand all the termininology used a short introduction to all terms.

Rule Set - Is a collection of risks. A group of rules is configured in ARA (Access Risk Analysis) to identify all risks within a specific regulation. In a later stage it is possible to run a risk analysis against a rule set to get all conflicts which are covered in the selected rule set. 

Business Process -  Categories  used to classify/group risks (e.g. Finance, Basis, HR, etc.)

Risk - Compination of Functions

Action - Transaction in SAP

Permission - Authorization objects that limit the kind of access within a transaction such as create, change or display.

Rule - Combination of the actions/permissions within a risk.

Rule Set Structure 

Example with a Risk 

If you need more information about the possibilities of firefighting with SAP GRC do not hesitate to contact me directly by leaving a comment or sending an email. 

Posted by Alessandro Banzer

Twitter Facebook