Risks:

Risks are the core objects that identify the potential access issues which your enterprise may encounter. The elements that make up a risk are its attributes. Risk management uses the attribute descriptions to generate rules. Risk management is the set of processes through which management identifies, analyzes, and, where necessary, responds appropriately by mitigation or remediation to risks that might adversely affect realization of the organization's business objectives. The response to risks typically depends on their perceived gravity, and involves controlling, avoiding, accepting or transferring them to a third party. Whereas organizations routinely manage a wide range of risks (e.g. technological risks, commercial/financial risks, information security risks etc.), external legal and regulatory compliance risks are arguably the key issue in GRC.

Critical Permission Risk:

Defining a critical permission risk ensures that risk analysis identifies any employee who has been assigned a potentially risky permission. You can use this feature if the permission has been enabled but has no actions. This risk can have only one function.

SAP delivered SoD doesn't contain any Critical Risk ID specific to Critical actions or Critical permissions. So, if you run the access risk violation reports either at user or role level and if you select any option among Action level, Permission level, Critical action level et al. but Critical Permission level, you would see the risk reports as expected out of the selected rule sets. But once you select only Critical Permission level, you wouldn't see any violations. Reason being is that SAP standard SoD doesn’t contain any critical risk ID either at action or permission levels.

So, in order to customize the rule set and to create Critical risk at permission level, first we need to create a Function ID which would contain the permission (authorization object) and no action (transaction code) in it.

// Verion of GRC used: GRC AC 10.1 and SP 06 //

Go to create Functions as per the path defined below and don't add any action in this function.

Now, we will go to Permission tab to enter the required permission to be treated as Critical Permission.

Now, this Function ID (CF01) has to be added to a new Risk ID (CR02), map this risk ID with the Rule set and assign the risk owner as below:

Then generate this newly created Risk ID; either via NWBC or via SPRO (IMG -->GRC --> Access control --> Access risk analysis --> SoD rules --> Generate SoD rules; and mention the lately created Risk ID and execute).

We would see the risk violations at critical permission as below:

Your inputs/suggestions are always welcome

Courtesy & Regards,

Ameet kumar& Fernando Bassuino

Maintenance of User Type as Default entry:

I was having a bit of hard time in maintaining and getting user type synchronized across configurations done in EUP (SPRO) and Access request.

In EUP (SPRO --> GRC --> Access Control --> User Provisioning --> Maintain End-User Personalization), we have a field to maintain the “User Type” with default entry (if required), so as per my customer requirements, We had to go with “Dialog” so I got it maintained with default value as DIALOG in EUP in GRC-development and captured in TR (workbench) and transported across the follow-on systems. But there we started encountering an issue with this String “Dialog”. Access request for create or change account were not getting provisioned and when I looked for the Audit log, I saw the request is getting triggered to the escape route as GRC was not able to recognize the entry for User type as Dialog. It said: “Invalid user type D”. Even in the access request form also, user type was displaying just “D” but I thought GRC might have shorten the word to just a letter but it was kind of ignorance

Then I realized that GRC can’t recognize this user defined key-words but R3 defined key-words and then thought of utilizing R3 skills. In R3 we have user types as below:

A: Dialog

B: System

C: Communication

S: Service and

R: Reference

And then I entered just the key word, like “A” for dialog type and Yahoo!!, it worked

So, with the maintenance in EUP as below:

I can see user type coming up correctly in Access request forms as below:

Thought to share across to help others to overcome such issues.

Cheers,

Ameet

More and more organizations are adopting Enterprise Risk Management (ERM) frameworks to respond to regulatory pressures.  And with good reason.

In their 2014 Report on the Current State of Enterprise Risk Management researchers Mark Beasley, Bruce Branson, and Bonnie Hancock found that nearly two-thirds of organizations surveyed admitted they were caught off guard by an operational surprise “somewhat” to “extensively” in the preceding five years. And in a 2014 survey of nearly 300 insurance organizations by Wolters Kluwer Financial, two-thirds of the respondents rated "maintaining compliance with changing regulations" as one of their most pressing regulatory and risk management concerns.

It's the battle we're all in - the need to mitigate risk and maintain profitable growth in the face of regulatory changes. Maybe you're facing a steady stream of new rules. For example, the US Securities and Exchange Commission issued 20 final rules in 2013 alone.  Or perhaps you're preparing for a larger change, such as complying with the Solvency II insurance regulation directives in the EU, or the Affordable Care Act in the US.

Amongst the myriad challenges facing an organization (assessing risk culture, integrating technology systems, aligning and integrating risk management into strategic planning), there lies "the human element".  In the end, the success or failure of a risk management framework, like any business transformation, comes down to people.

If you have new processes to adopt, you need a workforce that can adapt - - a workforce that makes informed decisions, has the right information in the right format at the right time, and then absorbs and acts upon urgent information.

SAP's solutions for access control, process control, and fraud management provide an excellent framework for successful risk management.  And SAP has recently introduced SAP Communication Center by Ancile (SCC) as one way to address the human element.  When used in combination with SAP's risk management solutions, SCC enables you to align your workforce and your ecosystem in a single compliance-driven framework.

SAP Communication Center provides urgent information to employees via mini-lessons that focus on one or two key concepts.  Each message you deliver to your team with SCC includes critical information along with a quick knowledge check to ensure the recipient understands the information. 

For example, consider banks who want to comply with the latest global regulatory standard Basel III.  To meet this standard, banks must comply with specific monitoring and public disclosure standards. On the ecosystem side, the real-time, high-speed reporting and risk management is available from SAP's Liquidity Risk Management (LRM) Architecture.   But, in addition to the LRM application framework, you'll also need a workforce that's ready to implement the Basel III disclosure requirements. 

By creating a simple mini-lesson using SAP Communication Center, a risk manager can quickly share just enough information to the right people to ensure that they know what to do.  Each team member receives the message in their desktop or mobile browser, or via the SCC iPhone app.

SAP Communication Center also includes reports that give the risk manager much-needed visibility into how well their team is absorbing the information.

Given the pace and complexity of regulatory changes and the need for an effective enterprise-wide approach to risk oversight, learning snacks may be exactly what workers and business leaders need in order to adapt.  Beasley, Branson, and Hancock found that most organizations haven't provided training and guidance on risk management in the past two years for senior executives or key business unit leaders.

How do you deal with the human element in your ERM approach?  Do your workers know what the organization expects of them regarding risk activities? What support and incentives do you provide to enable and encourage the desired behaviors needed for effective risk management?

I encourage you to share your experiences, views, and insights by replying to my blog post here on SCN.

GRC 10.x being based on ABAP, we know that a lot of configuration can be built in the development GRC box and then moved along through the GRC landscape.

Lets take a typical landscape comprising of three GRC systems; development, quality and production. Usually, the quality and production boxes are closed for changes on them. During GRC AC implementation's realization phases, all configuration of GRC AC is done on the GRC development box and all changes are then moved to quality and production.

Following are the basic requirements for the configuration of access control:

1. RFC connections to backend systems done by basis.

2. These RFCs to be used then into configuration settings; like: user defaults, PSS, BRF plus rules, etc.

Considering that a lot of configuration is attached to RFC names there needs to be a way to be able to efficiently manage the changes through the landscape.

For example in user defaults, we tag the defaults to an RFC name and a default ID is assigned to this record automatically. Which is then in-turn used in the BRF plus user default rule.

Now lets consider the following options for change management, each has its pros-cons. I would really like to get feedback and better understand which one is better considered across implementations. Or if there is much better alternative to balance efficiency and trace-ability.

OPTION 1:

Here we have the RFC named as per regular conventions <SID>CLNT<Client#>; example - ECDCLNT100. So, here we have the following connections:

Each RFC from the GRC box to its ECC counterpart is named per its SID and client number.

Now in development GRC we build the user default configuration with ECDCLNT100 and tag different defaults to it. Everything works fine.

Then post-unit testing we move the configurations to Quality GRC box. Here in the Quality box, the config entry comes through the transport and is maintained as ECDCLNT100. Which is not present in the GRC quality! also the quality ECC is on a different RFC.

Thus, the user defaults does not work in Quality box. To fix it, the quality box is to be opened by basis and the entry fixed manually directly in the QA box. Now think of the effort of manual fix multiplied by the number of clients + exposure and risk of opening the clients for every little change related to RFC names.

The only seeming benefit here is that you get to use the regular RFCs and they are of standard naming convention that can/might be helpful for basis team members to track the RFCs by name.

OPTION 2:

Here we have GRC specific RFCs with same names across the landscape. The would ofcourse connect to the respective ECC client but their names would be same.

ECC_GRC is the RFC for connecting GRC box to ECC box. This ECC_GRC sitting on GRC Development connects to ECC development, ECC_GRC sitting on GRC Quality connects to ECC quality and so on. The exact target entity can always be mentioned in the description of the RFC.

Now coming back to the user default configuration, in this option we tag the defaults to "ECC_GRC" in development system. And transport it to Quality box. And it works! No manual changes needed.

The only catch here is that the set of RFCs to backend systems needs to be created by basis on GRC development, quality and production boxes, which is a one time activity.

CONCLUSION:

I have personally liked the option 2, since it brings down the change and maintenance efforts to minimum and eliminates client opening risks for small regular changes.

As a closure to this blog I request experts to share experiences and design of change management of configuration across the GRC landscape. If there are other options to use, if these options can be bettered?

Thanks!!

Sammukh

When an employee joins the company he requires SAP Access. The general process I the manager or supervisor of the employees sends an email to the SAP Security with the required roles and the user is provisioned in the required backend systems. This process does works but everything is manual and there is no clear audit trail. There is also no guarantee that the roles were properly assigned.

This is where the SAP GRC 10.0 User Provisioning tool can help. The key engine which drives this process of the approval workflow is called MSMP - Multi Step Multi Process. This will automate the process. Let us understand the MSMP from high level so beginner can understand the configuration

Step 1 ( Process Global Settings) - Execute MSMP Configuration from the SPRO menu to come to MSMP main screen. Here you need to note the process ID which is SAP_GRAC_ACCESS_REQUEST and it is liked to GRAC_AR_INITIATOR. Only one initiator can be linked to the process id.

Step 2:  (Maintain rules) - In this step we are going to look at the result value of the GRAC_AR_INITIATOR which drives the path of the work flow. Here the GRAC_DEFAULT_RESULT is the result value. This value will be used to find out how the request is going to flow when you create a request

Step 6 (Maintain Route Mapping) – In this step we look for the GRAC_DEFAULT_RESULT and see which path it is mapped to GRAC_DEFAULT_PATH

Step 5 Maintain Path – In this setting we look for the GRAC_DEFAULT_PATH and identify the Stage in the Path. This shows that there are two stages which are manager and Security. Now we need to understand how the approvers are assigned to the stages. The approvers assigned to the stage are ZGRC_MANAGER and ZGRC_SECURITY

Step 3 Maintain Agents – In this step we are looking are defining the agents and linking them to the PFCG role. The users assigned to this role will be the approvers of the request coming to this stage

Now when you create a request the following high lighted request which are mapped to Process id SAP_GRAC_ACCESS_REQUEST will follow these two steps and get provisionined into the system

Hope this help. Give your feed back and comments

Transport BRF+ Application from $Temp packge

I am not sure if you have already come across the phase associate with Copy the BRF+ application from $Temp package in order to make it transportable.

At the start of my implementaion project on GRC V:11 and SAP:04, I had created one BRF+ application and saved it to a $Temp package so as to avoid to capture it into a Transport Request, as I had to do some more configurations with the never ending requirements. So, when I completed all the configurations, I tried to put into TR which But couldn't fo that as I had saved it into $Temp so, got stucked.

So; to make an application transportable you have to follow these below steps:

1) Copy the application from $Temp package to SAP Development package

Execute BRF+ transaction code --> Navigate to the application which is saved into $Temp package

2) Right click on the application --> Copy

3) On the new screen, enter the New-Application name (target application name), description and short text.

You need to make sure to uncheck the box for "Create Local Application". Missing in doing it, you would agai end up copying the targer application into $Temp package.

If you have created a package specifically for BRF+ then you can mention the package name under "Development package" . If not, then you can create with transaction code: SE21 as below:

Fill in all the required details and confirm.

Now, after putting the development package, mention the Softwarre component and make sure to confirm the check box for "include contained objects". Click Copy.

It will ask to enter the TR, but you would see the error screen as below:

This is due to a bug within the GRC V:11 which would get resolved after implementin SAP Note# 2029700 http://service.sap.com/sap/support/notes/2029700

Thanks to SAP to provide this note, and now I am able to copy the application from $Temp package to SAP Development package to make it Transportable.

Thought of to share this experience with SCN-Community members to help them if they came across with this issue.

Cheers!!

Ameet

Purpose

In MSMP, Access Controls 10.0 and 10.1 provides extremely flexible and powerful tool to configure workflows. In this document we will see how to create BRF+ (NOT line item by line item) MSMP agent rule by taking example of real business case in context of Access Request.

Overview

In GRC 10/10.1 SAP has provided different ways for determining agents for a stage in access request. This scenario is more to determine the Role Owner for a role using Custom BRF+ application based on Functional Area field.

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 BRF+ decision table. Hence, this blog has been created which will be helpful for the consultants who have the requirement to use Functional Area as an attribute in determining the agent for roles. The below mentioned BRF+ agent rule is developed assuming each role will have a unique functional area

Ref SAP Note:1890452 - Functional area attribute for role is not picked up by BRF+ rule

Ref Discussion on SCN:http://scn.sap.com/thread/3661923

Steps to build the BRF Rule:

Creating BRF+ Rule for determining Agent based on Functional Area

You have to generate the BRF Rule via Transaction SPRO in GRC system. Follow the below steps in your GRC system.

Run the transaction SPRO, Go to IMG => Governance, Risk and Compliance =>Access Control =>Workflow for Access Control  => Define Workflow related MSMP rules.

Or

Directly execute Tcode GRFNMW_DEV_RULES

• Fill generation criteria (Process ID, Rule type, etc.)
• Specify Generation options
• Generate rule shell (Execute button)

Click Execute or Press F8. This now generates a successful message for BRFPlus Rule with name and ID. You can run BRF+ Tcode and can check the newly created BRF+ application there.

Now you can see the created BRF+ application as shown below.

Functions Signature Update

In BRF+ function, change the mode to “Event Mode” and activate the function as shown below

• Since Function mode has been changed to “Event mode,” the result data object has changed automatically, so it has to be reset manually
• In “Signature” tab of BRF Function, change the result data object to GRFN_MW_T_AGENT_ID

Create Ruleset in BRF+ Application

Create Ruleset in your BRF+ application by clicking on “Create Ruleset” button under “ASSIGNED RULESETS” tab of function. Ruleset is a combination of business rules that can only be assigned to a function in the BRFPlus framework.

Enter any name for the Ruleset and click on “Create and Navigate to object” as shown below

Ruleset will be created and you will be shown a success message as shown below

Create Rule within Ruleset - Create Expression of Type “Loop”

1. Click on “Insert Rule” button to create new rule
2. From within rule, click on “Add” -> “Process Expression” -> “Create” to create a new expression
3. Create expression of type “Loop” and provide suitable name and description

Loop gets created as shown below. Processing Mode and Loop Mode maintain as mentioned below.

Create Rules within Loop Expression

First Rule

Create expression of type “Table Operation” and provide suitable name and description. In this Table Operation, we will fetch the Functional area value from Functional area table and return the result in to Functional Area field which is part of structure GRAC_S_API_ROLE_FUNC_AREA

Second Rule

Create an expression of type DECISION TABLE as shown below and create a rule change agent ID in agent ID structure after processing each entry in Decision table.

Third Rule

Third rule is used to assign value to context as shown below. This rule will be included in your loop for inserting the values into Agent ID table after processing each LineItem.

The Public Company Accounting Oversight Board, established by Congress as part of the Sarbanes-Oxley Act, has responsibility to oversee audits by public companies. Since 2012, the PCAOB has been particularly active, and in September of 2014 the PCAOB announced significant changes to auditing standards have been released and take effect for companies with a fiscal year starting December 15^th, 2014 or afterwards - less than two weeks from the time of this writing.

In addition to changes and proposed changes to accounting standards, the PCAOB has been actively releasing staff guidance in the form of practice alerts, directing additional validation of source reporting assumptions, ensuring that system-generated reports are complete and accurate, and verifying top-down risk assessments are conducted (one auditor acquaintance of mine recently termed the current PCAOB validation process “brutal”).

So What Does this Mean for Me?

Practically speaking, SAP customers publicly traded in the U.S. have been seeing and will continue to see increased scrutiny from their external auditors. So what does this mean for SAP customers with U.S. Sarbanes-Oxley obligations? And in particular, what does this mean for SAP customers with SAP Access Control/GRC in place to monitor separation of duties and automate security design and role assignment?

Canned Access Control/GRC reports and rule sets are relatively easy to verify assumptions around completeness and accuracy. That said, the SAP-delivered  rule set is not one size fits all – some high risks for certain industries will be medium risks for others, and vice-versa. For those of you who like to spend this time of year planning strategy for the coming year, I recommend considering the following questions when planning your FY 2015 audit report improvements to stay ahead of trends in SOX reporting requirements:

• Have we conducted a top-down risk assessment with high, medium and low SOD risks in our AC/GRC rule set(s) in scope, and have the results been verified and signed off on by senior management? And are we able to trace rule set changes to findings in this risk assessment?
• Mitigating controls are, by design, limited to being effective for one year. Still, many SAP customers will re-apply them for another year without giving a whole lot of thought to the underlying assumptions. Did your risk assessment ensure that the residual risk after mitigating controls is in effect is acceptable? And is there traceability of these management signoffs to your mitigating controls?
• Are my technical controls for my GRC landscape adequately defined and documented? Have we spent time adequately negative testing GRC roles (for example, can mitigating controls owners approve firefighter requests?)
• Have my risk owners been adequately defined by senior management and adequately documented?
• Have my BPOs been adequately defined by senior management?

Final Thoughts

The PCAOB practice and standards changes have had and will continue to have an impact; the full extent of that impact has yet to be determined. That said, early compliance will have significantly less organizational impact than mid-year remediation.  It never hurts to plan ahead!

Related Reading

http://www.natlawreview.com/article/public-company-accounting-oversight-board-pcaob-selected-auditing-developments

http://pcaobus.org/Standards/QandA/10-24-2013_SAPA_11.pdf

http://pcaobus.org/Rules/Rulemaking/Docket038/Release_2014_002_Related_Parties.pdf

Purpose

I am currently working on GRC 10.1 SP05. I could see lot of customers also working on same SP or upgraded to same SP. There are lot of issues in GRC 10.1 SP05 which we came across. I am just updating the issues with relevant SAP notes here just to make it easy for the guys who come across the issues just like mine. Also I am requesting others to contribute by adding in the details which we might had missed out.

There are still lot of issues which we are working on and will update this blog regularly based on our issues and fixes.

NOTE: There can be few SAP notes which SAP might have released specific to us, but if the issue is relevant in your system you can request the same from SAP

Access Request Module (ARQ)

Issue 1

Work Inbox – Simplified Not Working

When launching the Work Inbox - Simplified from IE8, it generate the following error messages and it will only display the "Work Inbox" header but the rest of the body are blank.

The following are the error messages:

1. Error

2. ExceptionTypeError: Access is denied.

Replicate the Scenario using below steps

1. From GRC, execute Tcode NWBC. It will launch IE8 to display Business Client for HTML.
2. From the Work Inbox section click on Work Inbox - Simplified link. It will launch another IE8 browser for Work Inbox.

Related SAP Note for fix

UI5 libraries which were used for Simplified Access Request have recommendations for IE9 and above, hence it don’t work properly in IE8, so customers using this functionality should upgrade to IE9 and above.

1974672 - Keyword Search in simplified access request/ Approver in Box not opening

Issue 2

We are getting the error "Text 265 Not Found" every time we click the "View Provisioning Logs".

In ST22, it shows some ABAP dump. I have attached the ABAP dump for your analysis.

Steps for Reconstruction 

NWBC->My Home->My Profile->Request Status-> Select a Request -> click on View Provisioning Logs

Related fix

You have missed some Text elements in your system due to which this error is being thrown. For the resolution of this issue, kindly follow the steps mentioned below:

a. Go to Transaction SE24.

b. Enter CL_GRAC_UIBB_ACCESS_REQ_ASSIST and click on display.

c. Click on Goto and select Text elements.

d. Click on edit icon (Ctrl+F1).

e. Enter '265' in Sym and 'Request Key' in Text field.

f. Save and Activate.

Issue 3

This is more of a query. We are trying to configure the system that it automatically perform the risk analysis while submitting an access request. We have configure this and this with config parameter 1071. We found that this functionality is running risk analysis only for one type of risks (Action level, Permission, Critical Action or Critical Permission) based on config parameter 1023, which means it shows incomplete risk analysis results. We want to configure it to run risk analysis for all type of risks.

Related Solution

In that case, you can either remove 1023 parameter from Configuration Parameter list (as mentioned in SAP Note 1733984).

OR

You can maintain multiple values under 1023 parameter (as mentioned in SAP Note 1776542).

This would resolve the issue.

Issue 4

The ABAP program GRAC_REPOSITORY_OBJECT_SYNC didn’t sync the data properly of an EP Connector (X PORTAL). It only properly sync the roles but it didn’t sync the users properly.

It work for other EP Connector (Y PORTAL). They belong to the same connector group (PORTAL_GRP).

The X_PORTAL is a SAP NW 7.4 Portal while Y PORTAL is an SAP NW 7.0 Portal.

We have configured our EP Connector using the instruction in SAP Note 1977781 - GRC 10.1 Enterprise Portal Configuration

We have also applied the instruction in SAP Note 1647157 - How to Setup Access to the SPML Service on AS Java

Replicate the Scenario using below steps

Tcode SE38

Program Name: GRAC_REPOSITORY_OBJECT_SYNC

Select Profile, Role, User and Role Search check box.

Connector: <Portal Connector>

Run it in foreground.

Related fix

1889792 - UAM: Portal sync results in time out/ Portal Object not getting synched

2008685 - Portal sync in GRC 10.0 is not working

1940769 - Timeout problem in GRAC_REP_OBJ_SYNC

Issue 5

We are always getting ABAP dump every time we run the program GRAC_REPOSITORY_OBJECT_SYNC.

We are consistently getting the error 'SQL error "SQL code: 3135" occurred while accessing table "GRACRLCONN"

Related fix

Jobs are terminated because of the huge Database space Usage and that’s why it is giving dump. So we advised you to schedule a job by selecting option which is really required. If the requirement is related to user only then you should select only user option rest you can uncheck. In this way, you can execute parallel jobs as much as you can. But if you really want to schedule a batch job with all the options then you should schedule one at a time. This is not the application issue it’s all because database usage.

This is a known limitation of any database that can't handle big SQL statements and you can experiment the same issue when you select the data for a particular table in standard ABAP transaction SE11/SE16.

Ex:  Table USR02 and you can put high volume of users into the selection criteria and you will see the same issue.

You may also check Note - 1847034 - Runtime error for very large OpenSQL statements, for additional details.

Issue 6

Currently the GRC system allows all kinds of file types to be attached in the GRC system (Eg. on the BRM and ARQ screens). These file types includes .html or .exe which could contain malicious scripts. If the system is able to prevent certain file types from being uploaded, then the risk is minimized.

Please refer to SAP note 1232736 for the same functionality in SAP GRC Access Control 5.3.

Since it was there in 5.3 our customer is expecting the same in latest version as well

Related fix

Please implement note 2058231 (manual and automatic corrections) in your system. After implementing this note you will have to implement a BADI as shown in the document attached to the note. Then you can maintain configuration parameter 2401 in IMG for the allowed types of files.

Issue 7

We have enabled mitigation control assignment workflow based on the client’s requirement. Workflow is configured to have first level of approver by supervisor who will perform risk analysis and mitigate the risk at this stage.

Based on the GRC 10.1 behavior we have noted below shortfalls:

1. On request level, access request approver in this case supervisor does not get confirmation on the mitigation control approval submission. There is a submit button and after clicking that the request does not show the mitigation control workflow number.
2. Mitigation Control assignment number does not match with the access request number and hence the mitigation control approver have no idea about which access request is this approval for. This is major short fall for client which are expected to have high volume of mitigation control assignments.

Related SAP Suggestion

Request number of Control Assignment workflow is generated separately and it would be considered as a separate workflow. Normal Access Request workflow has different request number and flow and control assignment workflow has different request number and flow. These cannot be merged.

However, as far as the linkage is concerned, you can submit this idea on SAP Idea Place and let our Product Management team consider based upon the feedback/voting from the globe or if possible.

Issue 8

We have configured stage level approval and rejection level to "Request" which mean the approver on the stage allowed to approve the whole request or reject whole request. In the above configuration we should not be shown approve and reject button at line item level near user access tab. We have observed that approve and Reject button are still visible and they are non-functional.

Related SAP Fix

2057413 - UAM: Approve/Reject button at Line Item Level not working according to stage level setting

Fix for visibility of reject button under other options after fixing the issue of APPROVE/REJECT buttons at Line Item Level

2066115 - UAM: Reject option not displayed while request approval

Issue 9

For Screens like Model User, Existing Assignment and My Profile there was not feature to filter the records in the upper table

Related SAP Fix

1984995 - Missing Filter for Model User, Existing Assignment and My Profile

Issue 10

We want to achieve that user can only select role from his business process in access request.

The business process field is getting populated from LDAP. We have configured the role selection that business process field is mandatory and non-editable in role selection screen. This works fine that user can only select role from his business process.

We noticed that user cannot edit the auto populated business process field but he can add another business process field on role selection screen and the role search works as 'OR' between both of the business process. This means user can select the roles from both business processes. This system behavior defeats the purpose of having a field as mandatory and Non-Editable in role search. This is a product bug.

Related SAP Fix

2068938   UAM: Duplicate actions shown in the ACTION OVS in access request role search and role search restriction not working in access request

Issue 11

There is no authorization control available to control user as such that they can administer their own jobs. The users should not be allowed to view, delete the result of background job scheduled by other users.

We have run the trace for the back ground jobs and found it doesn't check any authorization object so we can control. This is very basic behavior which should be implemented.

No authorization control for the user to view and adminster his own’s job

The role only has object GRAC_BGJOB with 70. The users will need to adminster their own job and not others job.

Based on the trace enabled only GRAC_BGJOB

User able to delete and administer all jobs in GRC system

Related SAP Fix

Need to put this in GRC Ideas place

Issue 12

We are facing an issue while searching for users from LDAP. If we type a user ID and press ENTER then User details are populated correctly from LDAP. However if we click on button to search user from pop-up screen then system doesn't shows any search result from LDAP.

This was working fine before we implemented a SAP Note 1982896. This functionality is broken by this note.

Related SAP Fix

Kindly implement the note 2025895 after implementing the note 1982896 to resolve the issue

1982896 - UAM: Fuzzy Search is not working on User ID and copy request is not copying line items.

2025895 - UAM: Users not searched from HR/LDAP connectors if Realtime search parameter 2050 is YES

Issue 13

We are facing issue while downloading the default role template to upload default roles. Once we click on default role template button there is no action from system.

Related SAP Fix

2044932 - FPM Search GUIBB: dump or empty screen

2018804 - UAM: Dump in default roles while clicking the Import from file button

2067320 - Default role file import does not support connector group with space

Issue 14

We noticed that in unlock account users are able to add role via existing account option. This should be not allowed. We have given only existing "Unlock Account" action to the unlock request type. This is a bug in system functionality.

Related SAP Fix

2101596 - UAM: In Existing assignment, systems are selectable though request doesn't have any system action.

2048988 - System are selectable in existing assignments for Assign ob

Remarks

After applying the above notes everything was working fine and then we found out that Business roles are being added from existing assignments when creating unlock account request. Waiting for update from SAP for this issue

Issue 15

We have mapped the business role as default role in our configuration with other single and composite roles. If a user submit the request and this request fulfills the default role criteria, however only single and composite roles are auto populated in request. The configured business roles are not populated in request.

We have already implemented SAP Note “2030797 - Default role is not getting populated in Access Request in case of Business Role”

Related SAP Fix

2077121 - UAM: Business Role as default role is not working for Request level

Issue 16

We are using this GRC End User Login services for all new users to request access to the SAP system. The new users have an LDAP account. We are using SiteMinder to authenticate the user to its LDAP before calling the SAP Webdynpro application. We have enabled the parameter SAP SSO parameter login/accept_sso2_ticket=1 to accept an SSO ticket.

We are having problem on the GRC End User Logon services (Webdynpro application grac_uibb_end_user_login) to authenticate from SiteMinder. The Webdynpro application doesn’t recognize that the user have already been authenticated by SiteMinder. It still show the screen asking for UserId and password.

Is there a configuration that we need to do for the Webdynpro application to authenticate to it?

Related SAP Suggestion

SiteMinder validation is not supported in GRC End user login. Kindly refer the note 1575897 and create an enhancement request in the Idea Place

1575897 - Logging Enhancement Request - Business Objects Access Control

Issue 17

While raising the access request the user selects business role and its validity date for business role is not set automatically. Valid to date is cleared in case of Business Roles. Business Roles doesn’t have validity date.

Related SAP Fix

2095046 - UAM: Business Role Valid to date is blank

Issue 18

We noticed that the drop downs on access request page are not sorted based on description. For Example while selecting the roles the dropdown for Functional Area, Business Process, and Company. These drop downs are not sorted based on the description. These are sorted based on ID which is not visible to the user in drop down. This causes a confusion to the user as they need to browse through the whole list which may go up to 100 line items.

Related SAP Fix

2061817 - UAM: Access Request field values are not sorted with short description

Issue 19

We have configured our LDAP server as a user data source. Our LDAP server has 2 fields (Mail, Mid Mail) which stores the Email ID. System is able to pull the mail information correctly if it is available in any of these fields.

The issue happens when we try to search for users by using Email ID. The search with email ID doesn't work. It simply doesn't return the result.

Related SAP Fix

2102827 - Search LDAP User Using ID and Email Address

Issue 21

We have created an ABAP Webdynpro iView for the GRC application grac_oif_request_approval. This is to ensure that the link will use SSO automatically when clicked inside an email. Everything is working fine except when the user start clicking any link inside the ABAP Webdynpro application. All of the sudden, the link being generated is using a Portal NavigationTarget instead of the usual link generated when launch from SAP ABAP ICM. Because it generated a different link, it doesn't call the correct ABAP service to display the content.

May we know how to force the Portal to use the link generated will follow the link when it is being launch from SAP ABAP ICM.

Related SAP Fix

Waiting for SAP to help with this issue

Issue 22

Every time the user is creating an access request to lock a user in Portal, the following message are generated in the access request log:
Could not update user Attribute "lockreason" on namespace "com.sap.security.core.usermanagement" of principal "UACC.R3.DATASOURCE.S8".
Object class name does not exist in IDM.
By the way, our Portal UME is using a Backend SAP ABAP.

Related SAP Fix

Waiting for SAP to help with this issue

Issue 23

The default role upload is not working if we include business roles as part of default role. It checks for the system of the role however the system is not applicable in case of business role. This is causing the issue.

We compared the behavior by leaving the system field blank and found that in back-end it stores as "ALL SYSTEM", however if set the business role manually(Without upload) it stores as "BUSINESS_ROLE". Could you check this functionality and provide a fix for us.

Related SAP Fix

2084889 - Default role file import is not working for business role

Issue 24

We noticed that if an Approver (A) delegate his rights to another approver (B). The approver (B) gets the request in their work inbox however they don't get the notification. This cause that delegated approver (B) will not be aware of any new access request routed for his approval.

Related SAP Fix

1589130 - GRC AC 10.0 - MSMP Notification Override BADi - Enabling

1734548 - Delegated Approver is not receiving the Email

2028411 - Workflow delegation BADI not executed during delegation in Access Controls

Business Role Management (BRM)

Issue 1

When risk analysis is performed at the Critical permission level for certain roles with inactive Authorization objects through BRM, the risk is flagged by the system. However, this behavior is not consistent for all roles. In some cases, the roles with the same inactive authorization objects are not flagged.

Related SAP Fix

2036645 - Role Risk Analysis shows inactive authorization objects

Issue 2

We found that Role Search while creating an access request is not correct. The search result is impacted by parameter max no. of result row. It seems system is considering the parameter

"Max no. of result row" to look into the list of role.

For example:

If this parameter is set to 100 then system look for roles only in first 100 roles and shows only 3 roles as result.

If we set this parameter to 50 then system look only in first 50 roles and returns only 2 roles.

Related SAP Fix

2059283 - Role Search is not accurate

Issue 3

Unable to search Business role based on action maintained in single role on role search screen when business role having composite role and that composite role having single role.

Related SAP Fix

2093026 - Unable to search Business role based on action maintained in single role on role search screen

Issue 4

We are facing an issue while importing Composite roles in BRM. System does not import any of composite roles in BRM. We are trying to import the roles from back-end and selecting the role parameters during import process. With the same steps we managed to import all the single roles however not able to import any of the composite role. We have already run authority sync and repository sync job. We have also imported all the single roles associated with composite role.

Related SAP Fix

2027477 - Composite role import is not working

Issue 5

The issue is that when role owner is approving the role changes then he should be aware what all mitigation controls are applied to the role. This can only be possible if include mitigated risk is by default checked while system auto trigger the risk analysis before generating the role.

Risks were not displayed in the Analyze Risks - Role Generation Phase even though risks were displayed in Risk Analysis Phase

Our methodology is as follow:

Define --> Maintain Authorization --> Risk Analysis --> Generate --> Maintain test case --> Approval --> Complete

Related SAP Fix

2075894 - BRM: Risks are not displayed in the Role Generation Phase

Issue 6

We are facing issue in role certification. When user click on the link from role certification. The user is able to view the define tab of role in display mode however if he try to navigate to maintain authorization or risk analysis process step. System gives a dump "Assert Condition violated"

The role owner is not able to see the list of approvers and company mapped with the role. This information is required to certify the role. This information should be available to the role owner in display mode.

Related SAP Fix

2061588 - Assertion failed dump with no edit authorization in role methodology

Issue 7

We found that role prerequisites are not available in Role Parameter import template. These are also a role parameter same like functional area, Company, Business Process. Please rectify the problem and provide a fix to us. We need to upload prerequisite for 6000+ roles. This parameter should be part of Role Import Template.

Related SAP Fix

SAP has provided a Z program and related step by step document. Anyone has the same requirement let us know, I can share the program details here

Issue 8

We found that Role Owner search under "Define Role" Methodology step is working correctly. There are 2 fields (Owner & User ID) to search. If we put user ID (S80*) in user ID field it gives no result. However if we put user ID (S80*) in Owner field we get the search result. If we put user name (MADHU) in Owner field then there is no result and if we put user name in User ID then we can get the result.

The search is not working correctly as per the parameter provided. If we provide Owner it looks in User ID and if we provide User ID it looks into role owner name.

Related SAP Fix

2092209 - Text for user name in approver search help during role definition is ambiguous

Access Risk Analysis (ARA)

Issue 1

We are trying to transport the ruleset from SPRO but it gives error.

Related SAP Fix

1968082 - Not able to create transport for SoD Rules after upgrading to NW 740 SP04

Emergency Access Management (EAM)

Issue 1

We have noticed that some Notification variable for Firefighter log review doesn't get filled in the notification template. Following are the parameters which are nor working.

LINK_WORKITEM

Related SAP Fix

1983997 - LINK_WORKITEM variable not filled for FF Log Review Report Workflow

Issue 2

We noticed that the FF Log Review report doesn't have any option to relate the logs with the Original Access Request. We want to see this mapping in log review request so that reviewers will be able to match the request justification raised by firefighter and match the activities performed by him.

As we understand this is not available in standard product but this is very critical requirement for Log Review. Could you please let us know any possible workaround to achieve this requirement.

Related SAP Fix

Waiting for SAP update

Issue 3

We are running the GRAC_SPM_LOG_SYNC_UPDATE as a background job in our GRC system to extract GRC SPM log from our ECC Production system. We noticed that we need to increase the parameter rdisp/max_wprun_time considerably high (around 43200 secs) in the ECC system, otherwise the background job will fail in GRC. Our policy is that that the rdisp/max_wprun_time should only be set to 3600 secs (1 hour). This is to ensure that the work process are not block which will lead to system standstill.

If we reset the rdisp/max_wprun_time to 3600 secs, the GRAC_SPM_LOG_SYNC_UPDATE job will fail and the SPM logs that is not sync will also grow, which will make the job runtime even longer.

Is there a way to optimize the GRAC_SPM_LOG_SYNC_UPDATE job performance so that it will fit in the rdisp/max_wprun_time of 3600 secs? Can it have the same behaviour as BW extraction job which is not affected by the parameter rdisp/max_wprun_time even though it runs longer than 3600 secs?

Related SAP Fix

Please check this Notes. It describes the ways of optimizing the performance of EAM sync job.

1617529 - Best Practices For Improving Performance of EAM Log Sync job

1741151 - GRC 10.0 Indexing on CDHDR table in case of time out issue due to huge data

2047097 - Communication failure with remote system (SAP Query)

Reports and Analytics

Issue 1

The access rule library auto pop out once the group rule level is changed.

Please follow flowing steps for reproduction and refer to the attached screenshot.

1. Click on the “Reports and Analytics”

2. Click on Dashboard report “Access Rule Library”

3. Click on the pie chart with high violations and close the window

4. Now change the group level to “Critical Permission”

5. The window is auto populated without users actions

This behavior is an irritant and need to be resolved as this is bug.

Related SAP Fix

2061888 - In Access Rule library report, popup gets open without user action

Issue 2

The report "User to Role relationship" is not working as expected. If there is a role which doesn't have a profile then this report doesn't pick the role in output.

The expected output for this report is to include all the roles which are assigned to the user irrespective of profile of the role as this report is to show the relation between role and user instead of user and profile.

Related SAP Fix

2093024 - User to Role Relationship report not showing roles that does not have any profile generated

2107567 - User to role relationship shows empty profile even for generated roles

Issue 3

Change log report does not show results when the search criteria is in lower case. The report does not have option to save the file in excel.

Reports and Analytics -> Audit Reports -> Change Log Report

Related SAP Fix

2061392 - Role name is case sensitive while executing the change log report

Issue 4

As a part of the UAT phase following issue was noticed in the GRC 10.1 with SP Level 5. The role library dashboard does not have export option in the drill down list.

Related SAP Fix

2062839 - Export option not visible in the drill down of role library report

Issue 5

We noticed that that some reports are giving results in foreground mode however if we schedule the same job in background then it doesn't give any result.

List of Reports which are failing.

1. Role Relationship with User Group (No Output)

Related SAP Fix

2073736 - Role Relationship with user/user group is not working in background option

Issue 6

We have seen incorrect data being populated in the SAP standard dashboard report “Access Requests”. The numbers shown in access request pie chart and shown in request by types for similar period and similar filter criteria are not shown correctly.

Related SAP Fix

2064801 - UAM: Incorrect values displayed in access request report and drill down doesn't display data in provisioning report

Issue 7

We noticed that that some reports are giving results in foreground mode however if we schedule the same job in background then it doesn't give any result.

List of Reports which are failing.

Approver Delegation (Dump)

Related SAP Fix

2083663 - UAM: Approver Delegation report is generating short dump when it is run in background

Issue 8

We noticed that user group filter for the report (List Expired and Expiring roles) is not working. The User group is a very good criteria to list out the appropriate report to consume by user administrator.

Related SAP Fix

2066074 - List Expired and Expiring Roles for Users Report not working

*** Anyone interested to collaborate with the details which can add more value to this blog post, please let me know ***

A commencement of a new year always promises new abundance and happiness.But sometimes we may meet pitfalls on the way.
As the new year starts let us ask for god's blessings to safely navigate through this year.As we bid goodbye to the old year and tired 2014 we are left with the memories of the year that was.

We now joyfully welcome the brand new year 2015 as we look forward to an even better year full of promises.

Never step back & always have courage,to accept new challenges. Wish you all SCN member's a happy and successfull new year.

Thanks

KH

Surely 2014 was the year of simplicity with SAP's emphasis on simplification, simplicity, "Run simpler," or any of the variations on that theme trumpeted loudly and clearly at every SAP event and opportunity. This new emphasis seemed to be well received by customers, and why not? Who *wouldn't* want their SAP landscape to be simpler and easier to support and sustain? Security is no exception: doing more with less, squeezing a lean team harder to support more projects, more systems, and more users is just the given these days. Assuming that we start with at least a minimum number of well trained and competent SAP security staff, what does it take to simplify security to make it sustainable and bring about sustainable compliance? Here are some suggestions for your consideration.

Consistent security design

In my experience, there is not a "one size fits all" of security design except to say that sustainable results are more likely to be achieved with a consistent design. Are your security roles built using the derived role functionality, the enabler role model, or a haphazard mix of both? Is the design task-based, job-role based, or not clearly one or the other? If Business Role Management (BRM) is in use, is the model easy for the business users to understand? Is it your organization's practice that security roles have standalone integrity, or do some unknown number of them not fully functional unless some other functional role is assigned, which is not documented but "everyone in the plants knows that?" Are end user roles restricted from assignment to the SAP support team, or are exceptions frequent? Whatever approach the organization takes, taking it consistently and documenting it thoroughly will make your security much more sustainable in the long run, reducing the confusion among the people requesting access and the demands on the security resources to maintain and explain it.

Security design aligned with the business model

Whatever the basis of your security role designs, aligning the designs with the business is imperative for simplification. Otherwise, the requesters and role approvers will find themselves in an endless cycle of submitting requests to the security team for adding and removing roles from the users, and adding/ removing access from roles,  in frustrating attempts to get the access levels just right. But what if the jobs are not defined in a consistent manner? Then there is really very little the security team can do until the HR function works with the business to review the job  and task descriptions to improve the consistency.

Organizational standards

In my experience and observation, it is often the case that the organization's management wishes to have users' access restricted organizationally, often for compliance reasons. Whether the division is geographically based, product/service line based, data sensitivity based, or some other reason, sustainable security and compliance is much easier to achieve when the rules are documented, applied consistently, and enforced via automation. There is not much point in stating that users with access to one business unit should not have access to data of another business unit, when one functional area has a different idea from another of what organizational values represent each business unit, and end users are frequently granted roles from more than one functional area.

Furthermore, when the rules must be enforced manually, and approved exceptions are kept in a spreadsheet or file drawer instead of in a GRC toolset, compliance is anything but sustainable.

Governance model

So how does an organization that is lacking in any of these areas bring about the changes that are needed for sustainable security and compliance? In my experience, governance is the key. Role designs should not only be required to meet a documented standard, they should also be subject to periodic governance review. If role designs are any which way that the role owner and/or his/her business lead wish, if organizational standards are only a suggestion instead of a policy, if exceptions are numerous and monitored manually,  the security team will find themselves in an endless cycle of role and user modifications, which can take so much time and effort that value-added proactive initiatives, such as automating the user access review or some of that manual monitoring, are forever on the back burner. Without a governance model that has teeth, the security team may find themselves the scapegoats for the breaches and non compliance that are almost inevitable.

I hope that some of these suggestions spark improvement ideas that help bring about simpler and more sustainable security and compliance in your SAP landscape. Are any such initiatives already in the works for 2015 at your organization or among your clients? I welcome your comments and observations. What did I miss that you have found to be key to sustainable security and compliance?

Predicate and Propositional logic was the only subject in university that I failed (if only partial points were awarded for partial proofs!). Yet, I find myself applying this form of mathematics all the time in work as part of troubleshooting and problem solving. I must admit also, I can barely do the proofs anymore (goes to show what happens when you stop practising). However, the parts of this maths discipline is around reasoning and logical deductions - the type of mathematics we all use daily without realising. Yep – problem solving! By understanding logic and the concepts, it has helped me to troubleshoot and simply requirements. And in some cases, it has help me provide solutions to questions asked in this space.

So what has this really go to do with GRC? A tad random for me to be writing about something with no direct connection to GRC. Then again, the thought for this blog came to me after assisting a few recent questions relating to MSMP and BRF+ Decision tables. Members of this community were not asking how to resolve an error (that is, they knew how to configure workflow) but more around their design of their workflow and decision table entries (they didn't know what values to specify for the steps). Logically, it became evident that logic was missing.

I won’t attempt to provide a lesson in this mathematics (I couldn't imagine anyone willing to learn from a self-proclaimed failure). However, I thought I might share a slither of my thought process and approach to designing the decision table rules in hope it can help you to determine yours.

I have used this recent question from GRC space as an example of breaking it down - GRC 10.0 BRM : Issue with Decision Table. My workings this blog are not 100% the same as to the answer I gave as I have separated the steps out. However, the answer I provided would also have covered the requirement.

Step 1 – Gather and Record your Requirements

This step does not require changes to your system. Hold back on configuring your system until your think your requirements through. Therefore, you’re working with pen and paper and figuring out your design.

Requirements gathering in its simplest form involves obtaining business statements of what is needed. In this step, avoid the use of technical jargon and write your requirements out in simple English (or whatever your native language is).

You can ask yourself questions such as:

• Do I have different workflow scenarios depending on the request?
• What sort of scenarios are they?
• Will these scenarios require different approval steps?
• Who are my different approvers (agents)?

In this example, the requirements were already provided (off to a good start to designing the table)

If I select Composite Role it has to go Approver 1 irrespective of any criticality of the role whereas for Single Role if the role criticality is HIGH it has to go to Approver 2 and If the role criticality is MEDIUM and LOW it has to go Approver 3.

Step 2 – Identity your Inputs attributes

By the time you get to step 2 you should have written down all of the scenarios that you can think off for your requirements. The next stage is to go through and find the condition values (attributes) that you can use to configure your rules.

My approach on this one is to go through your statements with a highlighter and colour the attributes that you can see exist for the request type. Depending on how visual you and are how complex your requirement, you might want to use different colours to group the attributes.

For later use (in step 3) you can also highlight the output paths. In this case, these output paths are the identified Approver groups (return results).

Once you have gone through and found your condition values, you can then group them together as to identify the attributes:

• Role Type (e.g. Composite Role, Single Role)
• Criticality Level (e.g. High, Medium, Low, Any) – in BRF+ it will display as “Crit. Lvl”

At the end of this analysis, you now know that you have two input attributes to use. You can now build the structure of your decision table (you know the inputs from this analysis and you have the outputs due to the rule type – initiator).

Step 3 – Sequence and Simplify your conditions

As entry to this step, you know you the attributes to enter as the column headings. In this stage, you need to return the original business requirements and rewrite them as a pseudo-logic format based on your inputs and outputs.

Now an example of where Logic comes in (allows you to build a logically equivalent rule) and shows an example between how I wrote suggested the solution versus how it was built is Rule 1.

A Logical equivalent of this rule would be replacing the criticality is asterisk with the use of an OR operator and listing out ALL POSSIBLE VALUES for Criticality level

The risk of switching to the OR operator is if new Criticality Levels are built, then you have not factored them into this scenario. You then have to update the decision table. For this reason, when you requirement does not require the use of the attribute, I would specify the asterisks. However, the two rules above will return the same result (so long as there are only those 3 criticality levels).

You could approach this sequencing and simplification by drawing a decision tree. If you have completed business process flows, you may not even need to go through this process as the steps are already defined for you. Example of the decision tree, provides a visual flow of your rules which may help you validate them later when you test the rules. It is also a useful approach to use when you are analysing gaps in your requirements.

When breaking this one down, as it was a simply scenario, I realised immediately that 3 lines were needed for the different scenarios. However, where it becomes more complex, you might need to work through a decision flow and refine it until you can see all of the scenarios.

Step 4 – Add your catch-all

Depending on how thorough your rules are, you may have no rules left to capture. This step is important to analyse the business rules that you have devised to make sure you did not miss any possible combinations. If you miss a scenario then your end user will receive an “on submission” of the workflow error.

In this step, you need to look at your business rules and compare to your IMG configuration to determine if there are any possible inputs not yet catered for. In some cases you may be able to simplify your rules by changing the OPERATOR. In other scenarios, you may need to add additional rules (another line item).

As an example, ROLE TYPE is a potential gap. The original requirements only considered two roles types – Single and Composite. However, there are other roles types to choose from (profile, derived, composite, etc). It is hard to know if this is an oversight as part of it comes back to IMG configuration for choosing which role types are in scope. For the purposes of this blog, let’s assume that all role types are required.

The second potential is PRIORITY. If you only list the explicit values – LOW, MEDIUM and HIGH – you risk missing any other configured values. You also risk future IMG configuration requiring creation of a new criticality but the BRF+ decision table is forgotten. For example, there might be a value call CRITICAL.

There are a few ways to add the catch-all

Option 1 Rewrite your rules to cater for them

In the case of the first attempt – you can go through your rules and incorporate it. The risk of this path is that you implicitly include it in an Approver Path instead of going back to your business requirements and confirming them. This option really depends on how well you captures you business requirements in the first place.

For example, in rule 2 and 3 change it to Role Type <> Composite instead of Role Type = Single. For rule 3, change the criticality to not equal high. You have now removed the gap for Role Type and Criticality.

Your risk is whether you have interpreted the requirement correctly in simplifying. For example, what if Non-Composite Roles that have Criticality level of Critical need to go to a different approver (approver4)? This rule will not provide that option. Therefore, your simplification becomes invalid.

Option 2 Add entries to the bottom for each scenario

For each gap, you need to define the requirement and capture it. For example, you have determined that there are only two role types (Single and Composite) but there is another Criticality level – Critical – and you want to route to Approver2.

If you have a decision flow diagram, then you would need to update it to reflect the new rule. For each scenario, you would add a new rule to your table.

Option 3 Edit your Existing Rules to Expand

An alternative to Option 2 could involve editing the existing rules to include the missed scenarios. This would depend on the missing gap. Using the same requirement Options 2 (criticality of critical for single roles should go to Approver2) would result in editing rule 2.

Option 4 Wildcard catch all at the very end

If your decision table properties has been configured to only return a single result (which is the first rule evaluated) then you can add a wildcard catch all to the very end. This rule will only be evaluated if all other rules have failed. In this case, would configure an Approver_X (unknown) and consider routing it in MSMP to an Administrator to investigate.

Step 5 – Build and Test your decision table

Finally, you’re at the stage where you have translated your business requirements into business rules. Time to hope into BRF+ and create the decision table. Once you have completed, activate the decision table, functional and application. Finally, you can simulate your rules to verify that you receive the expected result based on your inputs (your decision tree might even help you with your test scenarios).

Note: configuration screen shot taken from the original thread referenced at the top

Hope this helps you think through your rules and apply a little logic. If you happen to be interested in logic as a topic (and succeed where I failed), this site is useful http://www.logicmatters.net/tyl/ and includes a Teach Yourself Logic Guide.

What is your approach to breaking down BRF+ rules? Do you take a similar approach or do something different altogether? I would love to hear your thoughts in the comments below.

Regards

Colleen

Is it 2015 already!?! Wow, how time flies. The SAP governance, risk, and compliance (GRC) team is already off to a fast start for 2015. Given this, I thought I’d use this week’s GRC Tuesday blog to reflect on 2014 as well as look forward into 2015.

2014 New Products

2014 was both a busy and successful year for those of us who watch over GRC here at SAP. I hope the same was true for you and your organization. One measure that I use to rate how busy we’ve been is the number ofnew productswe’ve launched. In 2014, we made five entirely new products available to you, our customers, for use when dealing with a number of specific risk and compliance challenges. I invite you to learn more about each of these solutions:

• SAP Audit Management
• SAP Global Trade Services for Processing Trade in China
• SAP Regulation Management by Greenlight
• SAP Access Violation Management by Greenlight
• SAP Fraud Management for Banking

2014 Awards and Recognitions

I can also measure our success by looking at theawards and other recognitionthat our solutions have garnered. In the last year, our GRC solutions have been rated and recognized as world-class more than a few times. One example is that Ventana honored us with theirOverall Business Technology Innovation Awardfor our SAP Audit Management and SAP Fraud Management solutions. This award and others like it help you to understand the capabilities we’ve included, as well as just how successful our customers have been through their use.

2014 Customer Successes

But I’m even more proud of the accomplishments that our customers made using our solutions and technologies as a cornerstone of their GRC programs. Ourcustomers’ successis the greatest measure of our own.GRC 20/20 recognized Exxaro, its implementation partner CQS, and SAP with a 2014 GRC Value Award in the domain of Internal Control Management. Exxaro is one of South Africa’s largest mining and materials companies. This award recognizes the efficiency, effectiveness, and agility of Exxaro’s controls program. Read thiscase studyfor more information. Way to go Saret and team!

2014 Internal SAP Implementation

Asecond 2014 GRC Value Award was given by GRC 20/20 to SAPfor its implementation of an integrated GRC architecture and use of technology to support and enable a global risk assessed internal control monitoring and assurance program. Yes, of course, we use our own products, but this is not the typical “drink your own champagne” use of one’s own software products. SAP’s own risk, compliance, controls, and policy teams are world-class. These teams impressivelysupport all of SAP’s GRC requirementsand this award is proof. In fact, some that know our GRC programs well have indicated that this is the most comprehensive, successful, and global implementation of GRC in the world. Congrats to the SAP’s own GRC team!

And now some predictions for 2015…

Uh oh! They tell me that I’ve run out of time and space here. Tune in next time for my thoughts on the GRC market in 2015 and how SAP will help your organization meet its risk and compliance requirements.

Originally posted to the SAP Analytics blog

Hello GRC Community-

Every month, GRC Product Support together with our Development team will share with you information proactively to help keep you up to speed on important news. The Newsletter will be uploaded to KBA 2123844 . This is our first edition and would like to hear from you any ideas that you think will help to make the newsletter more valuable. Please contact me directly (email in my profile) and we will work to incorporate your ideas into future editions.

Thank you everyone, hope you find some of this information useful.

Ramelyn Paredes
Director and Global Functional Manager (GRC and EPM)
SAP Active Global Support

The Dotcom boom of late 90’s, also saw some major corporate scams like Worldcom, Enron & Adelphi.  Some national headlines in US media (“Data theft at nuclear plant went unnoticed for six months” – June 10 , 2006 New York Times, XYZ Manufacturer violates EU pollution laws” – July 06 2006 CIO Tech Informer “US imposes record $100 Million penalty for export control violations” – March 27, 2007 Washington Post, etc.) would accentuate the changed milieu.  This necessitated a major emphasis on data security & vigorous audits (financial / system audits).  Sarbanes-Oxley (commonly called as SOX) act came into existence.  (The sections of the bill cover responsibilities of a public corporation's board of directors, adds criminal penalties for certain misconduct, and requires the Securities and Exchange Commission to create regulations to define how public corporations are to comply with the law).  There was a growing need of more transparent corporate governance, a well-designed whistle-blower policy framework & detail audit log (of who did what & when).

IT firms took these challenges into cognisance & turned it into opportunity to come up with security solutions, seamlessly integrated with organizations’ ERP softwares. ERP players like SAP acted upon it swiftly & integrated security solutions into SAP under a growing niche product suite called GRC (Governance, Risk & Compliance). SAP’s GRC 10.1 suite handles it through 3 sub-modules of 

Access Control, Process Control & Risk Management.

• Access Control– It involves managing user roles, who will (& who can) do what in the systems. The principle of Segregation of Duties (SoD) needs be considered while providing access. A simple example of SoD is, never to provide the same user access of creating new vendors as well as issuing/printing cheques. Giving too little access to user hinders work, whereas giving too much access attracts risk, so due care needs to be taken while designing access control. It also involves super user management & emergency access management.
• Process Control– This involves checks and balances built into the business processes to avoid/minimize occurrences of fraudulent activities. There are three different types of controls need to be designed: Preventive Controls, Detective Controls & Corrective Controls. The other way to look at building a healthy internal control environment is, following below 5 steps.  1. Documentation 2. Testing 3. Remediation 4. Analysis 5. Optimization.  (The details under each will be covered in a separate article)
• Risk Management– It helps reduce the risk of failing to comply with the regulations for financial reporting, trade regulations, factory act/s & environmental protection. At a very high level, Risk Management involves:  Identify the risks, analyse the risks, identify risk owners & coordinate responses.

Considering the growing need of ERP-agnostic solutions, many IT consulting companies (like Infor Approva, Greenlight Corp etc) came up with GRC solutions which complement the ERP software (like SAP, Oracle, Microsoft Dynamics) or seamlessly integrate with it. 

If we talk of India, the Indian corporate world was shaken by Satyam scam, Reebok India & a recent case in India’s top IT firm. In India, Clause 49 came into existence from 31st Dec 2005, for the improvement of corporate governance of all listed companies. (Which entails - It would be necessary for Chief Executives and Chief Financial Officers to establish and maintain internal controls and implement remediation and risk mitigation towards deficiencies in internal controls, among others)

In short, the question ‘Do-I-need-to-implement-GRC’ is no more relevant. Instead it should be, “What are we going to implement under GRC and when?”

     I am striking a discussion away from the technical aspects of GRC. The reason being, it is interesting to know how all the technical build-up and maintenance actually helps the organizations. I have a very basic and limited understanding in this area, that I have put across here and would really like to get more information to understand the overall picture.

     From the purpose of SAP GRC, it is clear that it caters to regulatory compliance based on certain legal acts / laws. These are specific to industries and geographies. We usually implement SAP GRC Access Control with majorly separation / segregation of duties in mind. This primarily in turn caters to help comply with certain regulatory laws. For example, the major one we hear of - SOX (Sarbanes-Oxley) Act.

     Now, SOX Act consists of over 50 legal sections. Most of which are not specifically IT related. SAP GRC Access Control's Separation of duties caters to the SOX Act's Section 404, which deals with Internal controls. This requires the management of an organization to have enough internal controls to assess risks and prevent frauds. Similarly, having approval logs, audit logs as part of SAP GRC features caters to the SOX Act's section 802, which deals with altering documents. This requires that no documents is altered in the due course of business in an organization.

     I, having worked specifically on Access Control part of SAP GRC, usually get to only look at the side of the separation of duty policies heavily. I know that Process Control does cater to specific regulatory compliance much more than what Access Control does, that being its purpose.

     So, please share your experiences, regarding how you have used SAP GRC Access Control or Process Control to cater to which regulatory compliance and how.

Thanks

Sammukh

Hi GRC Community

Do you get frustrated by functionality that it lacking? Do you see something in the solution and consider it an incident but are then told it’s by design? Are you creative and love to continually improve this product? Are you stuck in a situation where you have to minimise custom developments for the GRC system? Are you nodding your head in agreement? Are you the type of person who strives for continual improvement? Is that a Yes?

Then time to take a journey to the SAP ideas Place for the GRC Products. This is your opportunity to have your voice heard and get the support of the community. It is a direct connection to the SAP GRC Product Owners – a great opportunity that can be hard to come by.

Here’s the Ideas Places for GRC component:

SAP Access Control: Home

SAP Process Control: Home

SAP Risk Management: Home

Create Your Idea

• You will need to register your account if you have not done so already
• Assumption you have searched to make sure there is not duplicate idea
• Make sure you create it under the appropriate category
• Take your time to provide as much information as possible
  • Did the idea come about from a SCN thread?
  • Did you get requested to raise it in response to being told it’s not an Incident in Marketplace?
  • Do you have screen shots or uploads to better explain your example
• Let your network know about your idea and get their support

Vote and Comment

But hey, if you’re not an Ideas person then you get still join in. If anything, you are integral to an idea being considered. Vote in Support. Vote in Disagreement (some times the ideas have flaws). Just Vote! Add your feedback in comments.

SAP GRC team will only review ideas that have at least 10 votes.

GRC Product Team Listens and Reviews

The regularly review the Ideas Space and their next review is February 20 2014 – less than 10 days away. They will only review suggestions with more than 10 votes – Ideas cost money to develop. They will not consider ideas without customer support.

GRC Product team will add comments, request further feedback or review the idea in conjunction with their road map. You might find your idea accepted and scheduled for delivery (what an achievement) or you might find the idea is dismissed if it doesn’t fit the product road map. But hey, if it's dismissed at least you'll know why.

Get involved

So dear community, we have an opportunity to provide improvement suggestions to improve GRC. It may not help you today but with a strong voice and support of the community, your idea could be there to help you next time.

There are lot of ideas created in the past two years that are still valid. They have less than 10 votes and aren’t getting considered due to lack of support. Someone may have a proposed a solution to your current challenge but their voice is not loud enough to be heard. Time to shine some light on the ideas and get behind them.

And remember to check back regularly for new ideas!

Vote on! The count down is on!

Regards

Colleen

Here I am writing this blog about the solution we had implemented named as Audit Management. The purpose of writing this blog is to share my experience with all of you, the hurdles that we faced while this journey and how we came out, also to help developers who are going to implement this solution, this blog might become the shows stopper for them instead of find exploring various links and gather information they can find all information here at one place.

Introduction:

SAP Audit Management is part of SAP Assurance and Compliance Software

This solution provides an end to end audit management solution. The audit department can use it to build audit plans, prepare audits, analyse relevant information, document result, form an audit opinion, communicate result, and monitor progress.

The key features of SAP Audit Management includes:

• Fully mobile enabled and easy to access on multiple devices and platforms
• Full Coverage of audit roadmap, including planning, preparation, execution, report and follow-up
• Risk based audit planning with risks pulled from SAP Risk Management system
• 
  

What made us to implement Audit Management?

Many departments in organization conduct regular internal audits and inspections as part of performance improvement and internal benchmarking exercise. Initially, department used to maintain the details of audit plans, audit, its observation and recommendation in either worksheets or in word documents. As time progressed, they started getting lost in the maintenance of a centralized document for action tracking and recommendation closure. They tend to maintain various versions of the same information and hence confusion prevailed. This impacted the timely implementation of many recommendations.

Case Study:

When Risk Assurance department explained their business pains; requirement for an IT solution was felt. But, we were not sure of the platform and solution. We explored SAP solution offerings to find that SAP central component has solution called ‘Audit Management’. Subsequently, we could assess that this solution is quite flexible to not only plan and schedule audits and inspections, whether internal or external, but also has very robust mechanism of action tracking & reporting. The flexible hierarchy levels of audit objects allowed us to map all different type of auditing and inspection requirements.

Objective:

So after understanding business pain, we set our objective is to provide them a solution that not only ease them in data maintenance, but to provide them a fully-fledged solution that could help them for data management in required format, tracking for responsibilities assigned to users, calculation age to assigned activity after getting logged, send reminder to users for intimation as well as giving them a provision to navigate SAP, through outlook only.

Challenges:

Data Migration:

Before proceeding for the new entries of audit in SAP system, business wants all historical data to be in system first, so we had to explore some functionality in SAP for Batch input something like BDC but unfortunately due to dynamic behaviour of data it didn’t work and finally we came to a conclusion with ALE/IDOC.

Linear Reporting:

We were asked to generate on-demand reporting mechanism in the same format. The challenge with the format was that it has linear reporting of audit objects i.e. in the same row; it contained the details of audit, its observations, then recommendations and finally action. Further to that, it had many additional details of ageing and business defined statuses.

Reminders/Integration of SAP Objects with Outlook:

We got a requirement to integrate SAP objects with outlook, so that user didn’t need to navigate SAP transaction and they could directly access the SAP objects through outlook reminder mails only

Change Management:

So the change management was a big challenge for our functional consultant, to convince them of using SAP audit management module and get migrated from legacy environment to SAP environment.

Let’s move to developments part where I will share all the development objects that we had created for implementing this solution in details, which will help most of the developers to take a straightforward approach for implementing audit management module instead of exploring the technical feasibility of the objects.

Developments:

1^st development: Linear Reporting

First requirement which we asked is to build report with information containing Audit, observation, recommendation, and action in a single line.

We had no advanced technical details available with us, which we could use to achieve business requirement, After long time spending in exploration we came to conclusion to achieve this through BAPI (Business Application Programming interface), and with all logical operations on BAPI data, we developed report with single line information.

BAPI that we had used to achieve this has mentioned below:

      BAPI_BUS20370_GET_DETAIL

2^nd Development: Reminder mail & Integration SAP Objects with Outlook

Second requirement we got from business is to send reminder mail for Audits and their relevant actions, for that SAP has provided one program named as PLM_AUDIT_REMINDER_01.

You can create customize program by copying above mentioned program to change the contents of mail accordingly.

To change the content of Program you need to create a dialogue text using tcode SE61, and use that name in the selection screen of program created to send reminder as highlighted in below mentioned screen shot:

When you will execute the program, above mentioned screen will get appear; in the standard text field type the name of the dialogue text created for mail content.

As you can see in above screen shot there is one section ‘Restrict the Analysis Period’, in that section Planned Start Date field directly have a relationship with To be completed by date at various levels of audit management. This program will send mail for all objects which falls under Planned Start Date field range.

To attach work item in outlook mail so that user can directly access SAP objects through outlook only by clicking on attachment, instead of navigating through SAP tcode, there is standard SAP function module named as SWN_CREATE_SHORTCUT.

Function Module to attach work item in mail: SWN_CREATE_SHORTCUT

3^rd Development: BI/BW Extractor

Our next requirement is to design a BI/BW report which would track how many actions has been logged in which department, out of which how many has resolved, how many has got overdue, and how many are pending which could get identified by calculating their ageing with the completion by date.

BAPI’s that we used for building this extractor are as below:

PLM_AUDIT_ACTION_PREFETCH_M_DB

BAPI_BUS20350_GET_DETAIL: Action Details

BAPI_BUS20360_GET_DETAIL: Question List Details

BAPI_BUS20370_GET_DETAIL: Audit Detail

After all such developments it went through unit testing, user testing after getting green signal, we organized GO-Live event for Audit Management.

Roll Out:

Before getting it rolled out in all departments, it was necessary to have users review about the solution, whether it is working properly and in a manner the way business wants. Some cosmetic changes came which got concluded and it took us almost one month to get the solution stabilize.

Once we came to know we have developed a deliverable solution, it was the time to Roll out this solution in rest of the departments like Legal department, Safety department, PSM department etc.

Business Benefits:

• A centralized and yet simple solution for recording all the different Audit Plans, Audits, Inspections, Observations, Recommendations & Actions.
• All scheduled audits can be planned, approved in system now and auditors/participant will get system reminders beforehand.
• A single source of truth for all our Audit data, which otherwise was getting unmanageable from different excel sheets, word files, mails and MOMs.
• Uniformity in the capturing the Audit recommendations, observations & related nomenclatures, which otherwise were inconsistent in our records.
• All documents which are relevant for an audit can be attached for reference.
• Availability of Department / Unit/ Audit Area - wise action tracking reports for pending, due and overdue action counts, thereby enabling closed-loop action tracking mechanism
• Automated system reminders for action completion to the person responsible. Also, escalation mechanism for overdue actions to reporting manager and Auditors.
• Excel- downloadable reporting features which serves as ready-made reports for further analysis and dissemination.

I hope you will like this blog and expecting this blog will help developers which keen to implementing this solution in their organization.

Thankss….    

There are frequent questions why "Custom Field" option is disables when the Details are not saved while creating an Role via BRM application.

• The Details (First Phase) are becoming mandatory because the Role ID is required to initiated the BADI IF_GRFN_API_CUSTOMFIELD_BADI, then BADI can become active on the Fields that are desired by Custom Fields.

• Logically the Post Exit method POPULATE_ROLE_ATT in ZFILL_ROLERELAT_CUSTFIELDS is not called when creating a role in BRM application. Because the Role ID is required for the second phase.

• The functionality flows, first phase the basic attributes of the Role eg Role Name has to be defined and in second phase enhanced attributes would be defined like Owners/Approvers then BADI for Customer Fields is called.

From my experience, in many companies country risk is treated separately to risks registered in their Enterprise Risk Management (ERM) framework and reported independently to the Board - most often by using political risk maps.

To me, this is an error as country risk has a direct impact on operational risks and this impact should be materialized so that the correct mitigation strategy can be decided and applied.

First, let me define what I mean by country risk. To me, it is the potential negative events arising from political, economic and societal uncertainty in a given country.

Many equate country risk to political risk but as you can see in my definition, I believe that political risk is only a component of country risk - albeit an important constituent - it does not cover its complete scope.

This concept is very mature within investment companies as it is usually one of the criteria applied when deciding whether to invest in one country or another but I think it applies more widely.

All companies face a country risk, some with a higher level than others but all companies operate at least in one country. So, even if this country is rather “stable” today, this risk should still be recorded, assessed and monitored as situations can evolve sometimes more rapidly than expected.

Direct links with your ERM framework

Consider the following situations:

• Do you have operations? If yes, then regulatory changes decided by a government can affect you directly and subject you to new regulatory obligations;
• Do you have production facilities? If yes, in extreme cases, you may be facing unilaterally decided nationalizations;
• Do you have sales activities? If yes, then these can be significantly impacted by the national economic climate, especially if you are in a B2C business;
• Do you have employees? If yes, then these can be at risk if there is a sudden outburst of unrest. On a less drastic scale, a change in labour laws can also directly influence your HR organization and even decrease your profitability;
• Do you invest in innovation? If yes, you may have to agree to technological or knowledge transfer to be able to supply the local market with your products, increasing your competitive risk.

In another post (The Critical Role of Marketing Executives in the Risk Management Process) I had discussed the fact that reputational risk is a direct result from other risks. Well, I believe that country risk is at the opposite side of the spectrum and can be a trigger for many operational risks.

As such, even in low risk profile countries, assessing and regularly reviewing the risk level is part of a sound risk management practice.

How to assess country risk?

There isn't one common agreed measure to assess this risk category but I would like to try to suggest a simple method:

• Likelihood of occurrence: here would be assessed the combined probability of potential evolution of the political, economic and societal conditions. Some countries have a stable political environment either because it appropriately represents the opinion of the population or because the government secures its re-elections by different means. Nevertheless, this does not mean that societal conditions can’t evolve rapidly, as precisely illustrated during the Arab Spring. Taking into account these three criteria will therefore result in a more truthful probability of occurrence;
• Impact: here would be documented the potential direct impact of a country risk for your company and its different activities carried out in the country: manufacturing, sales, R&D, etc.;
• Speed of Onset: here would be assessed the velocity with which the risk can occur. For instance, in countries where political representation effectively embodies public opinion, a change in the political landscape can be rather long compared to personalized regimes where a change in leader can bring a system down rapidly. This is likely to be the most difficult criteria to assess, but publicly available geopolitical analyses can be a good starting point.

Then what?

Here is why I believe political risk maps can’t be used as is by companies as country risks: not all companies will be affected in the same way by changing events. Integrating this risk category in your ERM framework means that you can not only assess a macro-impact at your company level, but that you can also document the influence of this country risks on your objectives and on other risks in the ERM framework: potential effects on your supply chain, manufacturing activities, sales process, etc.

From there, appropriate mitigation strategies for these operational risks can be defined and implemented.

The intent of this post is certainly not to say that all countries are at risk, far from it, but that internal and external influences can lead to a rapid change in the rules of the game for your organization and its activities and that this should be monitored so as to avoid being taken off guard.

What about you, do you monitor country risk?