This is a guide to provide compatibility between GRC components in all GRC systems. As there are many questions raised regarding compatibility of GRC with plug-ins, SAP_BASIS versions and enhancement packages, I decided to put this information all together in one single guide. Starting from Virsa to GRC 10.1.

Virsa 4.0

This version of virsa is out of maintainance since 15.03.2014.

Access the Migration Guide if you want further instructions on how to move from 4.0 to 10.0.

If you want to know what will be migrated:

Access Control 4.0 Migration to v10.0 - Governance, Risk and Compliance - SCN Wiki

Compatibility of Virsa 4.0 with Netweaver Releases:

• 2072255 - Is VIRSA 4.0 Supported on EHP 7?

Virsa 5.3

Compatibility of Java Packages and VIRSA components:

AC 5.3 Java SP15-SP21 can be used with VIRSANH SP16 to 22 (SP10-16 for 710/730) for those customers that are not able to upgrade both Java and ABAP stacks simultaneously.

Compatibility of Virsa 5.3 with Netweaver Releases:

• Is Virsa 5.3 compatible with Netweaver 7.4 (SAP_BASIS 740)?
  • Implement the following SAP note to make 5.3 compatible with NW 740:
    • 1918850 - GRC AC5.3 plug-in Compatabile for SAP_BASIS 740 release

• VIRSAHR and VIRSANH is compatible with NW 730 from SP17 onwards.
• VIRSANH and VIRSAHR is compatible with NW 711 after implementation of 1675165 note.

Be aware that Virsa 5.3 will be out of maintenance from 31.12.2015.

From 5.3 to 10.0:

If you are migrating from Virsa 5.3 to GRC 10.0 you need to know that:

• GRC 10.0 does not work with front-end Java anymore. The new GRC model is all based in ABAP and ABAP webdynpro
• A new model concept was adopted (Foundation system and plug-ins systems). The foundation centralizes the master data.

To those who use Virsa 5.3 and are migrating to a new GRC version (10.0 or 10.1), the following guides and KBAs can be used during the migration:

• Guide to migrate from 5.3 to 10.0
  • You can also find in this guide, information on how to export data from 5.3 Risk Analysis and Remediation and Superuser Priviledge Management to GRC 10.0.

If you still need to use Java front-end and have installed GRCPINW in the back-end system, you will see that:

• GRCPINW overwrittes VIRSANH
• GRCPIERP overwrittes VIRSAHR

After support package 04 of GRCPINW, the 5.3 function modules are included (support package 04 of GRCPINW and GRCPÍERP is equivalent to VIRSANH Support package 16 and VIRSAHR Support package 14 respectively. As the front-end is still based on Java, the minimum SP level required for the front-end system is 15.

From 5.3 to 10.1:

All GRC 10.1 Support packages have 5.3 code included.

• Guide to migrate from 5.3 to 10.1

This is stated in the following KBA:

• 1590030 - GRC 10.0, 10.1 Plug-in & AC 5.3 VIRSA (RTA) Co-Existence

Access Control 10.1 plugins are also supported with an Access Control 5.3 Java front end. You must be at minimum AC 5.3 SP22 for the front end and 10.1 SP07 for the plugin in order for this scenario to be supported.

Access Control 10.0

Below, you can find the most current support packages for GRC 10.0 (from SP 11 to SP 19) and their compatibility with components on the very left column.

PS: The support packages highlighted in green are relevant to GRCFND_A V1000.

* Prior to GRCFND_A SP10, the GRC system and all plug-in systems must be on the same support pack level. As of GRCFND_A SP10, backward compatibility has been introduced. Please refer to SAP Note 1821368  for more details.

Compatibility of GRCFND_A V1000 with Netweaver Releases:

• GRC foundation is compatible with Netweaver 702 Support package 06 onwards;
• GRC foundation is also compatible with Netweaver 731 since GRCFND_A is on Support package 08;
• GRCPINW and GRCPIERP is compatible with NW 730 from SP05 onwards.

Click Here to check what's new in GRC 10.0.

Access Control 10.1

The below tables shows the Compatibility Matrix in GRC 10.1.

PS: The support packages highlighted in green are relevant to GRCFND_A V1100.

For GRC 10.1 Foundation and GRC 10.1 Plugin systems, it is recommended to have both systems at the same level, however GRCFND_A 10.1 will be compatible with all 10.1 plugins as long as the plugin SP level is equal to or lower than the Foundation. (ex: GRCFND_A cannot be on SP02 while the plugin is on SP04).

Compatibility of GRCFND_A V1100 with Netweaver Releases:

Access Control 10.1 GRCFND_A needs to be installed on NW740 (at least Support package level 02) and it is compatible with GRCPINW (700, 710, 730, 731).

Click Here to know what's new in GRC 10.1.

References:

The tables information was taken from:

• 1352498 - Support Pack Numbering - GRC Access Control

The Netweaver compatibility was taken from:

• 1680268 - Compatibility of Access Control Packages

The documenation was taken from:

• 1243085 - Available Documentation for GRC Access Control

The co-existance of components (5.3 and 10.0 or 10.1) was taken from:

• 1662113 - Using Access Control 5.3 with your 10.0 and 10.1 plug-in systems

Dear all,

I referred some SAP notes,KBA's,threads which are answered by Alessandro Banzer and Madhu Babu,found some standard behavior(As we know) of GRC access controls product.

Thought to share with you all,hope its helpful.

1.Transaction description is not available in consolidated log report in EAM.

Ans: The transaction description is not available in the consolidated report due to performance issue. As in 10.0 there are multiple systems and logs come from multiple systems of different basis release. Now for showing transaction description RFC calls have to be made for each system. So it was found that fetching the transaction description for each system is degrading the performance of the log report, hence the per the design the transaction description has not been supported in EAM reports

2. Results mismatch in risk analysis in Reports and Analytics and risk analysis in Access Management

Ans: 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.

The risk analysis in Access Management is real time analysis.

Both the results are same only when the batch risk analysis ran and completed successfully.

3.If any role from the User Account has been rejected or removed, UAR notifications are not sent to the User for whom the access review.

Ans: As per the standard functionality, notifications to users are not supported

If you want to send notification to user, then go for customization

Note: 2138427

4.Removal of direct and indirect role assignments using User Access review

Ans: 1.An indirectly assigned role, particularly through HR, (Position based), cannot be removed from SU01 directly.

         2.GRC requires a system call from HR trigger, (Position change), to remove the indirectly assigned roles.

          (Indirect role can be removed from PO13,but cannot be removed in SU01.)

         3.From GRC product functionality, a UAR request will only remove the direct assignments

Note: 2066401

5.We cannot use functional area as attribute for role in BRF+ rule,as Functional area is a table.  It is possible to maintain multiple

functional areas in roles,so it is not possible to directly use functional area as attribute for roles in decision table.

     Instead we can use business process or create a table operation to read functional area of the roles using BRF+ procedure.

Note: 1890452

6.While updating the user assignment from Business Role Management (BRM), the change document in plugin system shows that the updated user-id is,the user who executed the update assignment from BRM and not SM59 user.

The change document in plugin system would show that the updated user as logged in user, who executed the update assignment and not SM59 user-id.

This is to track that who actually executed the provisioning.

7.Change log reports does not give any results for user id search

The User ID filter in the Change Log Report is intended to search for the changes made by the specific user in the USER ID field,on any particular

object within GRC NWBC.

     The Audit logs shown for the Access Request would not be captured in this report.

This is only intended to capture the changes made to the objects within GRC. Check for the Configuration Settings in IMG for Access Control, it contains the parameters to enable the logging for various GRC objects like Risks/Functions (within ARA functionality), Roles (from within BRM) and similar.Objects under Param Group "Change Log" in GRC are under the scope of this report. (Available in IMG - Maintain Configuration Settings for Access Control).

8.Changing Mitigation control ID for an assignment, creates a duplicate mitigation assignment rather than updating old assignment.

It is a standard behavior of system to create a new assignment based on control ID entered. If any change is done to control ID, it will trigger a new assignment. We can do a mass change with the help of program GRAC_UPLOAD_MIT_ASSIGNMENTS and GRAC_DOWNLOAD_MIT_ASSIGNMENTS.

Note: 2026425

9.An error message 'Mitigating ID is not unique' appears when the approver tries to approve the control id workflow request second time wherein Control Id is same as in the first workflow.
 

If the workflow is ENABLED - the error happens only while approving the work item.If the workflow is NOT enabled - the error is shown at the time of creation, when you press SAVE.

This is as per the Mitigation Control Workflow functionality - it allows to submit 2 Control IDs with same name,

but does not allow approval. (This scenario can be very business specific, should avoid creating controls with same name/IDs).

We cannot show any error message during control creation in case of workflow, because Control Id will not be generated till the time it is completed.

Once the workflow for Mitigation Control has been initiated and sent to the Approver's Inbox, it will not show this error message until

this first workflow is completed and Control Id is created.
     

When the two Mitigation Control Workflows are created and sent to the same approver, the approver will be able approve only one workflow. Second  time, when he will attempt to approve the second workflow which has same control name, it will display the error message saying 'Mitigating ID is not unique', because there is already a Control Id with same name existing in the system.

IMPORTANT: If the control is created WITHOUT WORKFLOW, this error message appears at very beginning and therefore, system will restrict the duplicate, the second time.

Note: 2130931

10.Mitigation Controls change History

Mitigation controls are integrated with Process Control, and whenever a new mitigation control is created, the entry is saved in tables starting with HRP*,example:      HRP1000 holds the mitigation control object ids.

These object ids are converted from Process Control ID to Access Control ID, to be displayed in the Access Control screens.

There is no change history available for it.

Mitigation control changes can be tracked by having the "Mitigation Assignment" and "Mitigating Control Maintenance" workflow requests.

In order to have the control changes and assignments to generate workflow requests, configuration parameters 1061 and 1062 should be set to YES.

     Mitigation assignments for Roles and Users are stored in below tables

     User: GRACMITUSER
      Role: GRACMITROLE
      Profile: GRACMITPROF
      User Org: GRACMITUSERORG
      Role Org: GRACMITUSERORG

Note: 2027376

11.When a user request is created for a user who already has mitigation control assigned, the SOD detour path does not get initiated.

As per the design, if a mitigation control is assigned to a risk then the SOD detour is not initiated.

If a user access is altered and new risks arise then detour would be initiated.

But for existing risks where the Mitigation control is already assigned, the request will not take the SOD detour.

Note: 2073883

12.Difference in the results displayed for "Access Risk Analysis" and "Access Risk Assessment".

Check the "Permission Level" check box before running the "Access risk Analysis".This is required because "Access Risk Assessment" always runs at Permission Level by default and to keep the results in sync with "Access Risk Analysis", it should also be run at "Permission Level".

Note: 1689067

13.HR Triggers not works multiple positions for an employee.

HR Triggers functionality currently does not support fetching roles for multiple positions.

SAP HR storing only one position in PA0001, the GRC code is prepared to receive only one job position from this table.This means there is not such a LOOP to go through the found entries in PA0001, the code only reads from it expecting only one entry.

Note: 1990364

14.Behavior of user sync if two different systems are having same User ID with different user name

     As per Application behavior, user sync depends on the User Data Source

CASE 1:

Say you are having 2 systems X and system Y. If none of them are listed in the user data source then the latest

connector sync will have the data in  GRACUSER table.

System X: User ID ABC: User Name: ABCX

System Y: User ID ABC: User Name: ABCY.

Run user sync for system X.

ABCX gets updated in GRACUSER table.

Run user sync for system Y

ABCY gets updated in GRACUSER table. In this case, the older value ABCX would be overwritten by ABCY as none of the system is

listed as a Detail Data Source.

CASE 2:

If connector X is maintained in detail data source connector.

Then on running user sync for connector X, ABCX will be updated in GRCAUSER table

On running user sync for Y, ABCX will remain as it is as its connector X is maintained as a User detail data source in IMG.

Note: 2041653

Looking forward to add more into this page so that its easy to refer and helpful for others.feel free to add if you have any such information.

Regards

Baithi

This is a continuation of the troubleshoot guide for planner. Click Here to access the part I of the guide.

Reporting an issue:

Issue is created as I set the test to fail status:

The Owner of the issue is I827528.

Just the Control Owner or the ICMAN have authorizations to Receive an Issue:

This user must have power user roles or must be the control owner (in this case, as I am working with SOX regulation, the user must be a SOX control owner).

The business event responsible to deliver this task is:

• 0PC_RECE_ISSUE

Accessing the task to remediate the issue:

This information can be seen in table GRPCCASEIS.

Creating a Remediation Plan:

When you assign a remediation plan, you set the user you want to be the owner during creation:

In CONTROL_OWN’s inbox, there is a new task:

Test was set to complete. You can also check this information in table GRPCCASEPL.

We can see the progress of the workflow in SWIA:

The yellow highlights are the tasks which were completed.

If you need further information about the step you are in, you can access the task information in the container of the work item ID.

if you have some doubts on the workflow information, you can start debugging sessions based on the Task information:

Example:

Upon clicking on the highlighted task TS75900020, I can see the following screen:

We know Class and Method that are used when this event is triggered. Setting a breakpoint at this point allows users to debug this event.

Going back to the Close issue activity:

After pressing submit button within the work item, the status of the work items goes to Reserved

The status reserved will continue there until the remediation is not closed by the owner.

After completing the test, the evaluation is sent back to the SOX Control Tester for a Re-Evaluation.

If approved, the process is closed.  The test result is set to Pass.

Process is completed in Planner Monitor.

If you check SWIA after performing all these steps, the whole workflow is completed.

More information will be added upon contribution.

For the tips described below, I used a Process Control testing case.

A Control Test of Effectiveness was planned in my fresh GRC sandbox.

Note: These tips can be used in most of activities in GRC which use Extended Workflows.

System details:

GRCFND_A V1100 Support Package 06

GRCPINW V1100_731 Support Package 06

The objective is to check all the possible errors during the creation of a Control Test of Effectiveness.I am planning the task and correcting the issues as it comes.

First step is to create the central structure in NWBC -> Business Processes.

After the central structure is created, the following must also be created:

• Organization
• Local Subprocess
• Local Control

As soon as I created the objects, I try to open the local control and I receive an ASSERT_CONDITION VIOLATED.

Illegal case type – Case customizing was not configured in the system

Checking in table SCMGCASETYPE, the case types are not in the system.

This check is performed in Class and Method below:

This happened because I did not configured Case Management from client 000 into the copied client.

So it is mandatory after the client copy is performed to perform the Case Customizing.

To execute this task, the following KBA can be followed:

• 2107509 - Transfer client-specific Customizing

How case customizing should look like:

Now, we can create and display organization and local objects:

Control tester is assigned:

It is very important to compare the HR role assignments in table HRP1852 with SPRO -> 'Maintain Regulation Role Assignment':

I am working with SAP standard roles, however if customized roles are used, these configurations can lead to confusion.

As shown above, I have assigned my user CONTROL_OWN as the control tester.

SAP_GRC_SPC_SOX_PRC_TESTER is assigned to SOX regulation.

Checking this role in HRP1852, I can see my users there:

CONTROL_OWN has 2 entries as it is assigned to 2 different objects.

With authorizations set, it is time to schedule the plan.

Creating Plan in Planner Screen

First Step:Plan Activity: Test Control Effectiveness

Second Step: Choosing Regulation:

Note that there is no Regulation shown in the Drop Down list

Checks to know whether this is not a configuration issue:

• Is Regulation created?

If not created, it must be added

Relate regulation to Plan usage in SPRO must be configured. Test Control of Effectiveness is configured to both regulations:

If not created, it must be added

Check whether ‘Need Regulation’ is selected in Plan activity for Process Control

If not created, it must be added

If all these steps were followed then, the following SAP note must be implemented:

• 2072420- Regulation is missing while creating test control effectiveness in the Planner Note After processing with these steps, the regulation is there:

Note After processing with these steps, the regulation is there:

Third Step:

The organization, which the plan will be triggered, needs to be selected.

Fourth Step:

The local object will appear for selection, unless you have already scheduled a plan for the same organization in the same time frame.

Fifth Step:

Checking recipients:

If the recipients column is empty, the work items will be addressed to the fallback receiver.

The fallback receiver will start to receive the notifications for three reasons:

1. If the user is not assigned to a role in HRP1852
2. If the role is not mapped in SPRO -> Maintain Regulation Role Assignment (when using role regulation specific)
3. If the user does not exist anymore in the system

If you have users assigned in HRP1852 and not in Maintain Regulation Role assignment, it means that you are working with Cross Regulation roles.

There is one issue, which was introduced in Support Package 18 of GRC 10.0.

All the work items are forwarded to the fallback receiver when customer is using cross regulation roles.

This issue is corrected by the following SAP note:

• 2154060 - CCM Owners not receiving Issues created by Automated Monitor

Plan Activation and Completion:

If you want to debug the activate Plan button, set a breakpoint in the following Webdynpro Component, View and Handler:

After job activation, the planner monitor shows the jobs status as "With Exceptions":

This is because the workflow was not triggered.

If you check, no workflow items were created in transaction SWIA for the time frame the plan was activated:

Configuring workflows according to SAP note 1621649:

• Automatic workflow customizing
• Perform Task-Specific Customizing

In my system, the task specific customizing was not configured. After configuring it:

Event Linkage also needs to be performed:

The following objects must have the event linkage as well as event queue

• CL_GRPC_WF_ASSESSMENT
• CL_GRPC_WF_TESTING
• GRPC_CASED
• GRPC_CASES

If the event queue is activated, the event queue job must be enabled to handle situations where large events are triggered at the same time.

One good tip is to enable the workflow trace through transaction SWELS

The workflow trace can be seen through transaction SWEL.

Triggering the workflow again:

The logs can be seen because SWELS is activated:

In transaction SWIA, all the workflows steps and workflow logs are available:

• Workflow started – Plan was activated and workflow created
• Workflow completed – background job GRFN_BP_SCHEDULER is completed
• Sub Workflow handler started – WS75900005
• READY – A task of the sub workflow that requires a dialog user to perform an activity

If you press shift + F8 on this screen, you can see workflow logs that present the historical path of the plan. In the workflow log, you can see the agents that are waiting for the work item:

Clicking on the agents button, you can see:

The symbol at the side of the user’s name means that the work intebox is going to the user’s inbox.

By pressing Shift + F9, you can access the workflow list with technical details

Checking agent's work inbox:

When logging with the agent and accessing his/her work inbox, the work item is there waiting for actions:

The case is available also in table GRPCCASETL

The case reached user's inbox as the Agent is correctly assigned in SPRO -> Governance, Risk and Compliance -> General Settings -> Workflow -> Maintain Custom Agent Determination Rules:

If you pass the evaluation, you can check the table mentioned above to see detail (GRPCCASETL).

To be continued ...

CLICK HERE for the Part II***

Purpose

The core functionality in SAP GRC is Risk and Impact Analysis which will help the organizations to achieve their motto "GET CLEAN and STAY CLEAN". During one of the implementations I am working for we noticed lot of issues/bugs with the risk analysis functionality and based on our findings decided to write a blog which can be useful for others to consider below scenarios during implementation

Mitigation Policy Configuration - To restrict approvers from approving requests with Unmitigated Risks

First enable configuration parameter 1072 - Mitigation of critical risk required before approving the request as YES. This is applicable for both Critical Action and Critical Permission Risks.

Mitigation Policy can be configured using BRF+ to enforce the approvers to mitigate the risks before approving an access request. Under the Application Mapping, there is the Application ID: 'Request Mitigation Policy'. The BRF+ Function for this App ID is maintained by default. The BRF+ rule is created to identify which risk requires mitigation and which risk does not require. If there is no BRF+ Rule created for Mitigation Policy, then please remove the entry from IMG.

Once this entry is deleted, kindly execute the scenario again. Now the Approver cannot approve the request if risks are not mitigated. This was the purpose of un-checking the Task Setting 'Approve Despite Risks', so that risks that are not mitigated, do not get approved.

Note: If maintaining the BRF+ Rules then it is necessary to maintain the entry in SPRO.

If you want to make use of BRF+ mitigation policy with corresponding decision table and it works as below

Reference SAP Notes

1614290 - Risk Analysis Mandatory for Access Request

Locked and Expired Users

When a user account is locked or expired and when the same user try to create an access request then Risk Analysis/Impact Analysis will not return any results and this is as per design.

We identified few issues where users already have some roles assigned to their user accounts and now when they raise new requests with the roles which conflict with the existing roles or the roles requested in the request itself have violations but since users are LOCKED or EXPIRED risk analysis didn't return any violations.

We identified during our weekly risk analysis report that few users have SOD conflicts with the roles assigned to them and up on investigation this is the issue with LOCKED or EXPIRED users.

We enabled the below configuration to fix our issue

One User Request Per System

Risk analysis functionality has one limitation in access requests but SAP addressed it with One User Request Per System functionality.

Eg: Approve Purchase Request(PR) and Release Blocked Invoices

Now we have defined a rule in the system that "Approve Purchase Request and Release Blocked Invoices" as a HIGH SOD risk violation. But a smart user can raise two GRC access requests as below:

Request 1 - With Approve Purchase Request Role - Individually this request is clean and has "No Risk Violations"

Request 2 - Release Invoices Role - Individually this request is clean and has "No Risk Violations"

But once both the requests get approved, user will get access to the roles which have HIGH risk violations. This issue can be addressed in different ways:

1. Role Owners should take the responsibility when approving the roles to verify whether user really require access to that role,but system wise it will not stop them from approving these requests.

2. Enabling the risk analysis as MANDATORY before approving the request at last stage of approval so that if one request is first approved and user got the role 1, at least request 2 now shows the violations when risk analysis is run again before approving, but still if both the requests approved at the same time then still this option will not stop the user getting access to these conflicting roles.

To address this issue, SAP has given an option in the configuration which allows the users to raise ONE USER REQUEST PER SYSTEM at a given time. So, the users cannot raise a second request when there is a pending request for the same system which will help to address the issue mentioned above.

Since these days most of the customers of GRC having business roles we have identified this configuration having issues with the way it is working for business roles. We are able to get it fixed by SAP and enabled the below configuration in our system which has helped to address kind of issues discussed above

In EUP configuration, you can enable below option as One User per Request per System is part of the end-user personalization customizing so it is mainly based on the screen elements on the request.

Also implement below note to fix One User per Request per System EUP configuration issue with Business Roles.

2168444UAM: One request per system not working correctly with business role and for IDM

Simulation Button in ARQ Request/Approval Screen

There is a button called SIMULATION in access request creation/approval screen. Actually risk analysis in ARQ will perform both Risk Analysis and Impact Analysis for the user and SIMULATION button also gives the same option.

We have noticed few issues in the way SIMULATION button is working and how using this button approver/risk reviewer can wipe out risk violations in access request though the roles selected in the request have violations

Steps to Replicate lssue with SIMULATION button:

1. Create a access request which has RISK VIOLATIONS.

2. At approval stage you can see the risk violations under RISK VIOLATIONS tab

3. Now change the approval status for the role causing violations to REJECT and then click on SIMULATION button and run risk analysis and click on APPLY button in Simulation screen.

4. Now all violations will be removed from the request. Now again change back the role approval status to APPROVE and then click on SIMULATION button and without running risk analysis and click on APPLY button from SIMULATION screen.

5. System doesn't prompt to run risk analysis and violations are wiped out

We haven't reported this issue to SAP but since this button access can be controlled using risk analysis authorization objects, we have removed this button access to our Users and Approvers from Request Submission and Request Approval Screens.

In order to hide the SIMULATION button from the Access Request creation screen, remove the following permission from the role:

Authorization Object: GRAC_RA

ACTVT:  70 (Administer)

Risk Analysis behavior during business role removal

We have identified a different risk analysis behavior during business role removal.

Below are the sequence of events:

1. User has already been assigned with a Business role. This business role has a composite role which actually caused Critical Action risk violations for the user.
2. To remediate this, requester raised an access request for Business role removal so that as part of removal the role causing violation also gets removed.
3. Since the role which is creating violations is being removed via business role removal, ideally the risk analysis shouldn't show any violations in the request. But request still shows risk violations with the same role which is being removed from the user.
4. To validate the behavior, we have created another request for removing composite role creating violations directly than through the business role and now request shows NO VIOLATIONS.

With the above steps we confirmed that during business role removal risk analysis behavior is incorrect. We have raised this to SAP and working with SAP to get it fixed. I will update this blog with the fix details once we get it

Risk Violations bypassed at Approver Stage

We have setup the configuration in such a way that no unmitigated access can be provision to the user in our production system.

All seems to be working fine however we found one scenario where approvers managed to bypass the risk violations and managed to approve the requests despite having violations in the request.

This is a product bug where if you close the browser it doesn't save the approval status change however save the risk analysis result based on the approval status. SAP has acknowledged this issue as bug and are providing the fix I will update this blog with the fix details once we get it

BRM Impact Analysis - Behavior

BRM Role change process involves Risk Analysis and Impact Analysis

1. Risk Analysis - To make sure that the role being created/modified don't have any SOD violations.

2. Impact Analysis - To make sure that the role being created/modified doesn't create any SOD violations for the users already assigned to it or the Composite/Business roles using it.

Issue:

BRM User Impact analysis report shows the user level violations even though the assigned role validity is expired for the user.

Eg: User A has ROLE B. In BRM I am modifying role B and the changes being made will create SOD violations for user A with other roles assigned to user A. Then Impact analysis report should show those violations in the Impact analysis report which is the intended behavior.

But Role B assigned to user A is already expired validity. Even then Impact analysis shows that user will get violations with the role which is already expired.

In general, Risk/Impact analysis doesn't consider validity dates of the roles, but if Impact Analysis report gives the report with expired roles for the user then they are FALSE POSITIVES.

Raising this issue to SAP to understand from them the behavior as well Will update the blog with the details given by SAP

BRM Role Change and ARQ Request at the same time

This issue is one of the product limitation So, I wanted to understand from other consultants as well on how they are handling this scenario

1. Role Management Team is modifying a role using BRM in Development. As part of BRM process role changes are made and Risk/Impact analysis is done.

2. Risk analysis is done against the contents of the role in BRM and Impact analysis is done for Users assigned to this role and Roles (Composite or Business) using this role and Risk/Impact analysis shows no Violations (assume)

3. Now assume that there is a pending Access Request for the same role being modified through BRM and the user in the access request will get SOD violations because of  BRM role change but since the request is not yet completed and role is not yet assigned user will not be shown in Impact analysis report.

4. After Risk/Impact analysis phase in BRM there is certain time gap to finish approval and transport process and if the pending access requests with that role are approved during this time users will get that role but users will be shown in Risk analysis report after transporting the role modified through BRM.

So, there is a chance for risk violations to pass through because of this BRM role change and ARQ pending requests for the same role during that time.

Can the members of the community share their views on this scenario and how they are handling it as this is product limitation

Looking forward for all your inputs in improving this blog with all other additional details

Thanks for reading.

Best Regards,

Madhu Babu Sai

Workflow configuration

1.Perform automatic workflow customization

SPRO->Governance, Risk and Compliance->General Settings->Workflow->Perform Automatic Workflow Customization

Select the node Maintain Runtime Environment and click on F9 as below

2.SPRO->Governance, Risk and Compliance->General Settings->workflow->Perform Task-Specific Customization

Expand the GRC PC component and make sure you define General/Background task for entries as below through 'Attributes' button.The workflow item will not be received if the task is not maintained.

The final screen will look like:

3.Activate the Event Linkage

Make sure all the relevant events are activated under GRC and GRC PC folder as below

4.Maintain the Event Queue

This is an optional setting. But its recommended to maintain , so the workflow run smoothly

SPRO->Governance, Risk and Compliance->General Settings->Workflow-> Maintain the event queue settings

Select the 'Switch on Event Queue' and click on Event Linkage as above

Verify the below events have 'Enable event linkage' selected. If any of the events have to be enabled, go to details button and enable the same

5. SPRO->Governance,Risk and Compliance->General Settings->Workflow->Maintain the event queue settings-> Click on Background job tab->Click on Schedule background job-> make sure the job is in Released status

6.Enable event Trace- this is an optional setting but it is highly recommended to activate

Go to Transaction SWELS

Select Switch on

Workflow Troubleshoot tips:

1. Check the Planner log

Transaction SLG1

Object : GRPC

Subobject : PLANNER and enter the planner ID, in the external Id field along with the timeframe

The mesage associated with the log can give more information

2.Event Trace

From the Event Trace , you can determine if the workflow is triggered successfully or not

Transaction-  SWEL

Input the Case ID into the Creator Object instance (Get the case ID from the Planner log)

This will help to verify the receipt of the work item

3. In addition to these, make sure the relevant agent determination is in place

SPRO->Governance, Risk and compliance->General Settings->Workflow->Maintain Custom-Agent Determination Rules

4. Based on the Agent determination rules, check role assignment

5. Maintain the fallback receiver using

SPRO->Governance, Risk and Compliance->General Settings->Workflow->Maintain Fallback Receiver

If this is maintained, the workflow will get notified to the fallback user, making someone aware of these tasks

6.If there is an issue where there is no recipient for the task when the fallback receiver is not setup. In that case, the user can go to transaction SWPR

Based on the data, fix the role assignment

Dear all,

The overview of this document is creation of risk in risk management with basics.

Hope it is helpful for others.

The prerequisites to create a risk we need to create required organization units and relevant risk categories

The organization units and Risk categories as created in master data work center

Risk can be created in Assessment work center.

Click on Risk and Opportunities

Click on Create to select type of risk

Where we can create different types of risks (Operational/Corporate) and Opportunity

We need to provide the risk name, select organization unit, risk category and select drivers and impacts for risk

To select the risk category from list we need to create required risk categories in master data work centers under

Risk and Responses at Risk Catalog

In master data work center we can create Risk Category and Risk Template, after creating, reflects under the classification hierarchy node and Risk Templates are created under risk category.

After providing required values we need to select Allow assignment is YES, then only we can select risk category while creating risk.

Now select the risk category for risk.

Now select, add the Impacts and Drivers

Drivers are nothing but events that could cause the risk to occur

Impacts are nothing but consequences if the risk event were to occur

We need to define Impacts and Drivers in SPRO:SPRO>GRC>Shared Master data Settings

Select Impacts and click on ADD

It will show the category and description which we maintained in SPRO

Repeat the same for drivers also.

We can assign multi drivers and impacts for Risk.

Now go to Roles tab in Risk

Initially roles tab does not show anything in role column to assign the owners

To assign role owner for risk in roles tab we need to maintain role assignment for entity in SPRO

SPRO>GRC>General Settings>Authorizations>Maintain entity role assignment

Click on Maintain entity role assignment, select the required entity with role

Now these role assignments will appear under roles tab of Risk

Now select the role and click on assign button to assign owners (we can assign single owners or multi owners also)

Now we can submit the risk

Once we click on Submit button then Risk status will be changed to active.

Regards

Baithi

Hello together,

we´re working with GRC Access Control 10.1 (SP9) and are connected to an CUA to read the user data.

And we got the programm error, that GRC writes the second surname in the request field "First Name" at the first request.

At the second request, the second surname in the CUA will writes the second ones in the GRC Field "First Name".

Duplicates. More and more and more.

I opended a message at SAP, takes a lot of weeks.

Now I´ve got the 2200123, implemented it, and it works now wonderful.

If you have the same problem, implement it or contact me.

I think, this is an importand message for you all.

Thanks and have a nice day.

Best regards

René

Hello folks,

You may have the requirement in your company, that you only want to create new hires/terminations from HR Triggers for users that belong to a certain Company Code (BUKRS).

How can you do that?

My suggestion is to create a Procedure Call that executes a function module to get the user BUKRS. Then you add BUKRS to the condition columns of your Decision Table, and it is done!

Okay, you will ask me.. why not use a DBLookup instead of a Procedure Call? Answer is, BUKRS field is stored in HR System table PA0001. If I was wanting to retrieve field value from any table sititng in the GRC Foundation system itself, I could have used a DBLookup - no problem. But the table I need to access is on another system, the HR System. Therefore, by using a Function Module tied to a BRF+ Procedure Call expression, I can make use of SAP Standard Function Module RFC_READ_TABLE to complete this task.

Below are the steps suggested to achieve it.

CREATE a FUNCTION MODULE in the GRC FOUNDATION system

Code for the Function Module:

NOTE: this code is a sample, and IS NOT standard application code. It is merely a suggestion on how to create the Z Function Module in order to get Company Code (BUKRS) for the PERNR user triggered by HR Triggers.

NOTE2: I made this sample in the most basic form, you will need to add treatment for Exceptions, etc.

IMPORT parameter:

EXPORT parameter:

My FM is called "Z_HR_TRIGGER_GET_BUKRS", and you may call it whatever you like.

Also you may use it for any other HR info type information that you would want to add to your Decision Table. In this scenario, the data I want is BUKRS, but you may want to use WERKS, Personnel Area, etc. As long as the data is stored in a HR Table related to the employee PERNR number, you can map it following this blog.

The suggested code is:

FUNCTION Z_HR_TRIGGER_GET_BUKRS.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IT_HR_DATA) TYPE  GRAC_T_HR_TRIGGER_BRFP
*"  EXPORTING
*"     VALUE(ET_BUKRS) TYPE  BUKRS
*"----------------------------------------------------------------------

  DATA:   lv_pernr      TYPE string,

          ls_hr_data    TYPE GRAC_S_HR_TRIGGER_BRFP,

          lv_connector  TYPE GRFN_CONNECTORID.



  DATA:   lv_data       TYPE string,

          lt_data       TYPE STANDARD TABLE OF tab512,

          lv_table      TYPE TABNAME,

          lv_fields     TYPE string,

          lt_fields     TYPE STANDARD TABLE OF rfc_db_fld,

          lv_options    TYPE string,

          lt_options    TYPE STANDARD TABLE OF rfc_db_opt.



  FIELD-SYMBOLS <fs_hr_data> LIKE LINE OF it_hr_data.

  FIELD-SYMBOLS <fs_lt_data> LIKE LINE OF lt_data.





  CLEAR lv_connector.

  CLEAR lv_pernr.





  LOOP AT it_hr_data INTO ls_hr_data WHERE field_name = 'PERNR'.



    lv_connector = ls_hr_data-CONNECTOR.

    lv_pernr = ls_hr_data-NEW_FIELD_VALUE.



    EXIT.



  ENDLOOP.



  IF lv_connector IS NOT INITIAL AND lv_pernr IS NOT INITIAL.



    CLEAR lt_data.

    CLEAR lv_options.

    CLEAR lt_options.

    CLEAR lt_fields.



    lv_fields = 'BUKRS'.

    APPEND lv_fields TO lt_fields.



    CONCATENATE 'PERNR EQ' lv_pernr 'AND ENDDA GE "' sy-datum '"' INTO lv_options SEPARATED BY ' '.



    REPLACE ALL OCCURENCES OF '"' IN lv_options WITH ''''.



    APPEND lv_options TO lt_options.

    WRITE: lv_options.



    lv_table = 'PA0001'.



    CALL FUNCTION 'RFC_READ_TABLE'

      DESTINATION lv_connector

      EXPORTING

        query_table          = lv_table

        rowcount             = 1

      TABLES

        options              = lt_options

        fields               = lt_fields

        data                 = lt_data

      EXCEPTIONS

        table_not_available  = 1

        table_without_data   = 2

        option_not_valid     = 3

        field_not_valid      = 4

        not_authorized       = 5

        data_buffer_exceeded = 6

        OTHERS               = 7.



    CASE sy-subrc.

      WHEN 0.

        " fine, do nothing



      WHEN 1.

        "lv_msgno = '082'.



      WHEN 2.

        "lv_msgno = '083'.



      WHEN 3.

        "lv_msgno = '084'.



      WHEN 5.

        "lv_msgno = '085'.



      WHEN 6.

        "lv_msgno = '086'.



      WHEN OTHERS.

        "lv_msgno = '087'.



    ENDCASE.



    "Only one line must be in lt_data, only one Active BUKRS per PERNR is expected in PA0001.

    IF lines( lt_data ) = 1.

      READ TABLE lt_data ASSIGNING <fs_lt_data> INDEX 1.

      lv_data = <fs_lt_data>.

      MOVE lv_data TO et_bukrs.

      WRITE: lv_data.

    ELSE.

      CLEAR lv_data.

      "WRITE: 'Error'.

    ENDIF.



  ENDIF.




ENDFUNCTION.

BRFPlus APPLICATION changes

Assuming your BRFPlus HR Triggers rule is created according to blog:

Creating your first HR Triggers BRFPlus - BASIC

we will make the below modifications:

1) Create two Data Elements. Type: TEXT, Length: 4

- BUKRS

- DT_BUKRS

2) Add the newly created Element "DT_BUKRS" to the Function context:

3) Create an Expression of type "Procedure Call", I am calling it "GET_BUKRS".

In my sample, I have created a Function Module in the GRC Foundation system, called Z_HR_TRIGGER_GET_BUKRS.

Below I mapped the FM parameters for Import and Export.

4) Create an Expression of type "Formula". I called it "FORMULA".

Assign "Result Data Object" to Element "DT_BUKRS".

To add the GET_BUKRS to the formula, right-click anywhere in the formula area (white box), choose "Insert Expression" and select the existing "GET_BUKRS".

5) Now go to Rule 1 (if you have named them differently, go to the Rule that has the LOOP.

Add below expression and make it the first expression (1).

6) Open Decision Table, and add DT_BUKRS to the "Condition Columns"

SIMULATE

Lets simulate the scenario.

1) In my test HR system called GH7CLNT600, I have PERNR 3, with BUKRS "US01".

Note that there are two rows for the PERNR 3, the Function Module must take the valid entry, and ignore the expired entries.

2) My decision table has below conditions, for New Hire (0105 0001):

3) Simulating the FUNCTION:

Click Start Simulation.

I have entered two lines in my simulation.

The first line is to match the New Hire condition.

The second entry  always comes within HR Trigger data from HR system, which is the PERNR number.

If PERNR is not coming, it will fail. In real scenario, it will always come along with the changed info types.

What must happen: in Rule 1, the BUKRS will be collected for the PERNR 3, and my New HIre condition will meet only if all columns are matched, including DT_BUKRS.

Other HR Trigger documents and on WIKIS

Dear all,

We are using GRC system as central system for access request to users from different entities with different composite roles (The roles are created based on Business process and entity)

Approvals based on Functional area, Business Process and Company

Access request type: New

FI (Business Process) - XXXXXXXXXXXXXX (Composite role)-ABC Specific to Company/Entity-Approver A

FI (Business Process) - XXXXXXXXXXXXXX (Composite role)-DEF Specific to Company/Entity-Approver B

Approver Agent rule is based on business process, Functional area and Company in access request

Execute

Go to BRF+, select the application click on Activate button

Now close the BRF+

Go back to Generate MSMP Rule for process screen and re execute the same.

Now open tcode BRF+

Select the application, right click on it and select COPY

Click on COPY

Now Application ZAPPROVER_BP_FA101232 is available for us to use which is in inactive status

Now create decision table from application by right click on application

Click on create and Navigate to object

Now select the Result data object as GRFN_MW_T_AGENT_ID

Where T indicates for table

Now go to Condition columns select from context data objects from insert columns

Select Functional area,Business Process and Company

Click on OK

Click on Insert row   to provide values for table contents

Select Direct Input value for Function Area

Select the value from F4 (It will show the values which are maintained in SPRO)

SPRO>GRC>Access Controls>Role Management>Maintain Functional Areas

Function are can be anything it is just for identification of role in BRF+

We can define the companies in SPRO

SPRO>GRC>Access Controls>Role Management>Define Companies

Now the maintained functional areas will be appear in BRF+ to provide direct value input for functional area.

Select the functional area, relevant business process and company with required approver in USER ID field

Now check, Save and activate the decision table.

Now go to Function and select the decision table in Top Expression

Now check, Save and Activate the Function.

Function rule id will used in MSMP for agent rule to approve

  Rule ID: 40A8F0333BE91ED58F82621E018D40D7

Now approval will be triggered based selection of Business Process, Functional area and company (under user details) in access request

Hope this is useful if anyone has same/Similar kind of requirement.

Regards

Baithi

Dear All,

With continuous to how to create a risk in risk management Creation of Risk in Risk Management GRC V10.0

This document will gives you how to create/use key risk indicators tab in Risk

We can create two types of KRI

Standard KRI Instance

Manuel KRI Instance

Click in create standard KRI instance

It will ask for KRI instance Name and KRI Implementation

How to create KRI Implementations

KRI implementations can be created under Key Risk Indicators link

Click on KRI Implementations to create

To create KRI Implementation we need KRI template

How to create KRI template

Click on create button to create KRI template

Provide the KRI template name and select Value type from drop down

To select other details like system, Business process and Component

We need to go back to SPRO for maintenance

SPRO>GRC>Risk Management>Key Risk Indicators

Click Save to create KRI Template

Now created KRI template will be available in KRI template catalog like below

Now we can select the KRI template in creation KRI implementation

Provide KRI Implementation Name and select the created KRI template from F4

Select the connector type from drop down

Connector types are configured and maintained in SPRO

Maintain the connector names with system in Maintain Connectors and select connector type

Maintain the script for SAP table, where we need to provide the SAP table name.

Once we select the connector type, then connector and script field will be populated

Don’t save now, it will give error

Now go to Implementation details tab

In this tab we can select required fields for output value with options

Now Save

The created KRI implementation will be available in KRI Implementation catalog

Now we can use the created KRI implementation in Risk at Key Risk Indicators tab

Provide KRI Instance name and select the KRI implementation from F4 list

Select monitoring frequency, time frame then only Test Instance button will be enabled.

Now you can Activate KRI Instance, it will be available in Key Risk Indicators tab of Risk

We can create business rules for created KRI instance.

If you click on request localization of KRI instance then we cannot create business rules.

Status will become Localization Requested and Create button will be disabled.

Select the KRI Instance and Open

Click on Complete

Now status will change to Localized

Again Select the KRI Instance and Open

Click on Confirm

Now status will change to Active

Regards

Baithi

Troubleshoot your issue at your own! - Try Component Specific Questions (CSQ) for faster resolution.

CSQs are the set of suggestions which put forward the latest KBA,Notes,WIKI docs, blogs and videos to serve you a quick resolution for the customer. The CSQ section appears right after business Impact section while creating the Incident with the heading 'Questions Specific to the selected application area'.
See below:

When the customer attempts to create an incident at SAP Service Market Place or via Solman and selecting a component, a set of customized recommendations and specific questions are prompted. With this, you will be immediately led towards a potential solution without sending an incident to SAP Support. This way, it helps you finding the resolution of your issues faster minimizing the overall time and effort for both the parties. Therefore, we always encourage customers to ensure that they are mentioning the correct component to get with the right set of CSQs for the specific issue area, else you will not get appropriate results for resolution. These CSQs are specific to each GRC component and their sub-components i.e, Access Control CSQs are different from Process Control/Risk Management and so on, and further they are categorized by their sub-components – Access Request Creation(ARQ), Access

Risk Management(ARA), Business Role Management(BRM), Emergency Access Management(EAM).

It is a generic text which is displayed for a particular component. Now, it becomes the action item for the customer to look for the most appropriate answer as per the business requirement. For example, CSQs for ARQ- there are categories like Notifications, workflow, provisioning, Password self service, Model user, dumps etc. Therefore, customer will have to check the particular area their issue belongs to. If they find a relevant solution and it resolves the issue, they can skip creating the Incident further and leave Incident wizard without saving. Otherwise, please continue with Incident description and add other related things to complete the Incident helping our engineers understand your issue more effectively.

Similarly, there are CSQs for process Control, Risk Management and Sustainability Performance Management. Going forward, Audit Management/Fraud Management CSQs will also be updated in their Incidents.

These CSQs are updated every quarter consisting the details of latest code corrections/hot fixes via Notes/KBAs, WIKI documents, blogs at SCN forum and additional quick updates. This is a really easy and quick way of troubleshooting your issues at your own prior to sending the Incident to SAP Support. This helps finding the solution at a very short span of time.

Take a scenario: Where you have a requirement for

1) User Authentication data source is LDAP

2) User Details Data source is HR(for Manager)

3) SAP User ID is stored in physical attribute in LDAP.

4) HR system infotype 0105 subtype 0001 stores SAPID

5) HR system infotype 0105 subtype 9000 stores domain id

Whenever a user is authenticated in LDAP using SAMACCOUNTNAME the same is passed to HR for details data source information and it also gets validated against Infotype 0105 subtype 0001 to obtain manager and other details.

When SAMACCOUNT id is passed and SAP ID in infotype 0105 and subtype 0001 is stored, it will not match.

Hence a development on target system has to be made where it can validate against infotype 0105 subtype 0001 in /GRCPI/CL_GRIA_USR Method is GET_USR_DETAILS

Now the details can be fetched for access request.

Since the requirement is authentication data source is LDAP.

And SAP ID is stored in physical attribute and Manager should come from HR system.

You have to remove Manager mapping for LDAP in maintain mapping for connector and connector group.

And Enable below parameter.

Access request validations           5023            YES     Consider details from multiple data sources for missing user details in access request

In Data Source sequence for User details keep LDAP above HR.

It will fetch all details from LDAP and change the SAP User ID in Access Request form.

Fill other details from HR system including Manager.

Regards,

Prasant

Some little tips about Manual test Plans

There was a migration of info types during the transition of GRC support packages to enable multilingual test steps in the test plan.

I started the scenario using a system with the following configuration:

• GRC 10.1 SP level 06.

The test steps are stored in table HRP5327:

The manual test Plan is stored like any other object in HRP1000:

A system upgrade was performed. Now my system configuration is like below:

• GRC 10.1 SP level 09.

In NWBC, the test plan is created:

However, my test steps are not there anymore:

If I create manually a new test step, it will show up in the grid.

New test step added:

Checking again in table HRP5327, the object is not there. However, the object was stored in table HRP5355.

Do not add any new items manually before executing the program.

In this case, a copy from the old database must be performed to copy all existing test steps to the new database.

The program GRPC_UPLOAD_HRP5327_TO_HRP5355 must be executed.

The second step is to choose a language. You can run in simulation mode for the first time.

Execution was successful:

After the execution, the record was moved to table HRP5355.

The test steps are shown in the front-end again:

The steps mentioned above can be found in SAP note 1949265 - GRC PC: How to enable multilingual test steps in test plan.

Summary:

After the GRC 10.0 SP-14 / 10.1 SP-07 implementation, the program GRPC_UPLOAD_HRP5327_TO_HRP5355 must be executed only once to copy all existing test steps from old database table HRP5327 to new database table HRP5355.

MDUG is uploading the objects into table HRP5327.

To resolve it, implement the note below:

- 2124607 to use MDUG to upload test step data after 10.0 SP-14 / 10.1 SP-07 upgrade.

Scenario: all the workflow e-mail notifications should be sent in English, regardlless of the language of the users (approvers, requestors, etc).

If you have such requisite from your business, what is the easiest way to achieve it?

No, you do not need to translate each and every single document in SE63 to English to achieve it.

The easiest way is to customize one of the Enhancement Spot/BADis available for workflow notifications.

Steps:

1) Create Enhancement Spot/BADi per Notes 1589130 or per Note 1727135. You can also apply both Notes and merge the code.

2) Customize the method SEND_OVERRIDE by adding one line of code, demonstrated in the screen print below. In this example I am customizing the BADi for Delegees, but the customization can also be added to the BADi for Multiuser notification. If you have both BADIs created, you will customize the merged method SEND_OVERRIDE (which will have code for both BADis, merged).

Now, all the GRC Access Control workflow e-mail notifications will be sent in English, regardless of the language of approvers, requestors, users, etc.

Hope this is useful!

Scenario: HR Trigger requests make use of the same workflow notification as other Access Control requests. Customers may want to disable notifications when the request is created by HR Trigger, and all other requests should continue to generate notifications normally.

How can customers disable email notifications for HR Trigger requests only?

Solution: This can be achieved by following the steps below:

1) Create Enhancement Spot/BADi per Note 1589130 or per Note 1727135. You can also apply both notes and merge the code.

2) Thereafter, customized code can be done in method SEND_OVERRIDE of the BADi's implenting class. It is a stable solution and does not get overwritten by SP upgrades.

The customization code attached is a suggestion that has been tested in my internal system as works effectivelly.

In my sample code, I am suppressing e-mail notifications for HR Triggers that create request type 23.

Please note that you need to replace the request type 23 with your own number based on you HR actions maintained in SPRO.

Navigate to SPRO>...>Access Control>User Provisioning>Maintain Settings for HR Triggers,
.

If you would like to suppress e-mail for more than one action triggered by HR, then you need to slightly modify the sample code to achieve it.

Hope this is useful!

Hello GRC Community,

Some customers are facing a dump when trying to synchronize the authorizations between BRM and PFCG,

And if you check the st22 there is a dump like the one bellow:

----------------------------------------------------------------------------------------------------

Category                             ABAP Programming Error
Runtime Errors                   SAPSQL_ARRAY_INSERT_DUPREC
Except.                               CX_SY_OPEN_SQL_DB
Program ABAP                   CL_GRAC_MODEL_ROLE============CP
Application Component      GRC-AC
Date and Time                    XX.XX.XXXX XX:XX:XX
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
|Short Text                                                                                       |
|    The ABAP/4 Open SQL array insert results in duplicate database
records.

To solve this dumps please follow the steps:

• If you have GRC 10.1 SP09 or bellow - Implement SAP Note 2147479 - Duplicate TCodes after Authorization

• If you have GRC 10.0 SP 17 or bellow - Implement SAP Note 2057990 - Profile for derived role does not get generated in backend
  while creating or updating the derived role through mass role derivation or
  updation

Thanks and Regards,

Rafael Guimbala

SAP TechEd 2015 in Las Vegas is just two short weeks away. Have you created a personal agenda yet? Mine is still a work in progress, already jammed with double and triple- booked times, but there are some things that I can recommend with certainty. Most importantly, do create a personal agenda. No matter how busy you are, it is worth spending some time browsing the sessions both by the tracks and by some keyword searches. Every year I find some security-related  sessions in other tracks, so it is time well spent. It is also OK to double book your agenda, in case a session cancels or is not what you expected.

So what is in my personal agenda? First, let me back up to something not in my own agenda, but everyone should at least consider: the ASUG pre-conference sessions. Depending on the projects ahead at your organization, there could be something to give you a great deep-dive start to the week. Be sure to check them out in this post by Tammy Powlas :

Jump Start SAP TechEd Las Vegas with ASUG Pre-Conference Hands-on Sessions

OK, back to my own agenda. Here are some recommendations for you to consider adding to your own agenda:

1. GRC Access Control Sessions. I am so pleased to see such a variety of sessions on GRC Access Control at SAP TechEd this year. This has been a quest of mine for several years now, to get more content in this area into the program.  If Access Control is something you are implementing or already support, be sure to consider these presentations:

SEC110 - Upgrading SAP Access Control and other GRC solutions from 10.0 to 10.1. My organization has not yet upgraded to 10.1, so I am very much looking forward to the lessons learned and other content of this ASUG education session.

SEC208 - SAP Access Control Customer Connection: Co-Innovation for the Win. This is my own presentation, so of course I am excited about it. Come to this session to hear about the improvements to SAP Access Control,  some  already delivered and some still in progress, that came out of Customer Connection projects, and learn about what is ahead.

SEC160 Hands-On Lab: An Introduction to using Key Features of SAP Access Control. A hands-on session on GRC Access Control- woo hoo! I have been begging for this for years. Access Control 10 has so much functionality that you may not have implemented all of it yet. This is the perfect opportunity to get hands on-time in several areas. If you have not yet signed up for your Hands-On sessions, get going, they are filling up.

SEC807 Road Map Q&A SAP Access Control. This is our chance to hear about the road ahead for this solution and ask questions of the product owner.

2. Security sessions. The security track covers a lot of ground; depending on the solutions in use at your organization, some of these sessions are likely to be more applicable than others, so be sure to browse both sub tracks of the Security track. Some of the sessions in my agenda:

SEC107 "Access"ing Your SAP Security Data. This session includes an intro to SAP Security, so if you are just starting out in SAP security, this ASUG education session will be great for you. As for me, I am looking forward to hearing about using Microsoft Access to manage security data.

SEC206 Deploying SAP Fiori to meet the Needs of Your Current Security Model.  My organization is not yet using Fiori, but surely it is just a matter of time, so this is another ASUG education session on my list.

3. ASUG education sessions. The ASUG sessions already mentioned are just a sample of the TechEd content brought to you by ASUG's TechEd Design Team: Tammy Powlas, Kristen Dennis, Kevin Comegys, and me, along with our SAP Point of Contact Peter McNulty. We have been hard at work since before ASUG/ SAPPHIRE to bring you the best possible content from ASUG members. You can find it in the session catalogue under the Source filter. Some of the other ASUG sessions in my agenda are:

TEC122 Building the Business Case for SAP Business Suite powered by SAP HANA

INT110 Secure Integration to the Cloud: Connecting On-Prem and Cloud Applications

BA122 It Isn't Only Brain Surgery: SAP HANA and SAP BusinessObject BI Solutions.

4. Expert Networking sessions. These may be the hidden gems of SAP TechEd, your place to meet with SAP Mentors, presenters, product managers, and your peers.  I am hosting two Expert Networking sessions in the SAP Mentors Lounge, EXP 27263 on Tuesday at 1:30 PM, and EXP27262 on Thursday at 10:30 AM, and I hope to see a lot of the regulars from the GRC and Security spaces on SCN as well as ASUG members there. To find the Expert Networking sessions and add them to your personal agenda, do a search with a filter on Session Type> Networking session.

5. Evening Events. After a long day of lectures, labs, road maps, and chatting with the experts, it is great to kick back and network in a more informal way. Be sure to attend the Networking event on Wednesday, starting at 6:00 PM on the show floor. The SAP Fiori Jam Band will once again lead the way and rock out Las Vegas. Come and sing along with us! Photo courtesy of SAP photographers.

Hope to see you all there!

Dear all,

This document will give you overview of creation of regulations and how to assign to sub processes.

Regulations and Policies are provides visibility into your compliance framework and access to end-to-end policy management

Regulations are assigned to Sub process, controls, IELC (Indirect Entity-Level Controls), Policies and Ad-Hoc Issues, which are assigned to organizations.

Regulations will be part of master data

We can create Regulation group,Regulation and Regulation Requirement

Creation of Regulation Group

Provide the details and click on SAVE

Once regulation group has been created, then create Regulation

Select the regulation group and click on Regulation to create

Provide the regulation name, description and select the Assign regulation configuration from drop down.

Assign regulation configuration will be maintained in SPRO

SPRO>GRC>Process Controls>Multiple Compliance Framework>configure compliance Initiatives

Select the Assign regulation configuration from drop down, click on save

Now regulation will created under regulation group

Select the regulation and create regulation requirement

Provide the details and Save

Now select the sub process from Business Process to assign the created regulation

go  to regulations tab

click on Add to see and select the regulations and Save the sub process.

Regards

Baithi

Dear all,

This document will gives you overview about master data (ex:Controls) change workflow in GRC Process Controls

Central controls are created for sub processes under Business Processes

Once controls are created, if you open

If change master data workflow activated, SAVE button will disabled and Request change button will appear

SPRO configuration:

First activate master data object for which you required workflow

SPRO>GRC>Shared master data settings>Activate Workflow for Master Data Changes

If we do changes in central controls then workflow will trigger for change approval and notification

Now maintain Custom Agent Determination Rules for entity: XCONTROL

SPRO>GRC>General Settings>Workflow> maintain Custom Agent Determination Rules

NOTE: Correct role selection is very important for business event and map with correct entity id, select notification business event if notification required.

Now go and change for control in NWBC, once you click on Request Change button, you get error

Reason: Not maintained user in fallback receiver

SPRO>GRC>General Settings>Workflow> Maintain Fallback Receiver

Now try the same from NWBC

  Once you click on Request Change for control, it will ask for change request

Provide details and click OK, will get the below message.

Reference:Master Data Change Request Workflow - Governance, Risk and Compliance - SCN Wiki

pc:No Approver Found. Request Change is not possible.

Hope it helps for others.

Regards

Baithi