Supporting internal and external audits is sometimes seen as a requirement that does not result in revenue generation. Therefore, these necessary tasks often do not receive the required attention and resources. As a result, time, money, and resources are lost in ineffective processes. Before the release of version 10.0 of SAP Access Control and SAP Process Control, you had no option other than to create separate master data. Their integration was limited and time-consuming. Version 10.0 of SAP Access Control and SAP Process Control combined these two applications in the same ABAP stack. This integration of technology and common master data results in a significant reduction of the implementation cost.

SAP Access Control and SAP Process Control configuration and customizing are transported using the standard ABAP transport system. You can activate the SAP Access Control, SAP Process Control, and Risk Management modules in the same system and share common master data elements between them to produce a much more tightly integrated solution.

After you install the GRCFND_A_add-on in the SAP system, you can activate SAP Access Control, SAP Process Control, and Risk Management. To access the Active Applications In Client screen, follow menu path IMG > Governance, Risk and Compliance > General Settings > Activate Applications in Client. To activate an application, select the check boxes in the Active column shown in Figure 1. Click the save icon to save your selections.

Figure 1

The Active Applications In Client screen

In Figure 1:

• GRC-AC refers to SAP Access Control
• GRC-PC refers to SAP Process Control
• GRC-RM refers to Risk Management

SAP Access Control and SAP Process Control 10.0 provide the option of sharing master data across capabilities. This unified platform has common integrators in the form of key master data elements that can be shared across the SAP Access Control and SAP Process Control components. I focus on two key integrators: organizations and controls.

Overview of an Organization and Its Attributes

A good organizational structure helps businesses perform impact analyses and also makes sure that reporting is organized. The organization can be based on:

• Geographical entities
• Functional entities
• Business entities
• Stores
• Business units
• Plants
• Legal entities

After activating SAP Access Control and SAP Process Control in the GRC system, you need to create a corporate level organization (root node or top node in the hierarchy) and one child organization for this corporate level organization. You can execute the Create Root Organizations program in the SAP GRC 10.0 system with any of these options (each option displays the screen shown in Figure 2):

• Use transaction code GRFN_CREATE_ROOT
• Use transaction code SE38 and execute the program name GRFN_CREATE_ROOT_ORGUNIT
• Follow menu path IMG > Governance, Risk and Compliance > Shared Master Data Settings > Create Root Organization Hierarchy

Figure 2

Create a root organization

Note
The value 002 is the default hierarchy provided for SAP Access Control and SAP Process Control. Alternatively you can also customize your own hierarchy by following menu path IMG > Governance, Risk and Compliance > Shared Master Data Settings > Maintain Organization Views. Double-click Maintain Organization Views Configurations. In the screen that displays (not shown) click the New Entries button. You then click the IMG activity documentation icon at the Maintain Organization Views link for more detail on this topic.

In Figure 2, select the boxes as shown and enter a date in the Valid From field. Click the execute iicon. This action displays the screen shown in Figure 3.

Figure 3

Enter organization details

In Figure 3, you can select the Organization View using value help. To complete this step, position your cursor in the Select the Organization View field and click the value help icon or press F4. This action provides you with a list of values for available organization views in the system, such as the ones shown in Table 1.

Enter the Select the Organization View as 002 (Standard Hierarchy(PC+AC)) and then enter the name of the Root Organizational Unit and Child Organizational Unit in their respective fields.

After entering the required fields, press the F8 button or click the execute icon. This action creates the Root Organization unit and its first child organization unit in the system. For verification you can open Figure 4 by following these steps:

1. Execute transaction code NWBC.
2. Click the appropriate role link in the Launch NetWeaver Business Client page.

Figure 4

SAP GRC 10.0 Launchpad

SAP GRC 10.0 is pre-delivered with many tabs, such as My Home, Setup, Access Management, Reports and Analytics, Master Data, Rule Setup, and Assessments. These tabs are part of the work center (Launchpad). Each tab contains different sets of predefined links.

For more information on the work center (Launchpad) use these external links:

• Role and Work Center Concept (SAP Help Link)
• NWBC screen layout options for GRC (SCN Document)

In Figure 4, click the Master Data link and then navigate to Organizations. Click the Organizations link. This action opens a screen that shows the organization hierarchy (Figure 5).

Figure 5

Organization hierarchy

In Figure 5, you can add the child organizations of the root organizational unit. To do this step, expand the name of a root organizational unit (e.g., BJ_PORG) and click the Add button. This action displays the screen shown in Figure 6.

Figure 6

The Create Organization screen

A user with both SAP Access Control and SAP Process Control roles sees the tabs (General, Subprocess, Indirect Entity-Level Controls, Regulations, Policies, Users, Owners, AC Roles, Assignments, Roles, and Attachment and Links) displayed in Figure 6. I describe the functionality of these tabs:

• General: This tab defines attributes of new organizations such as Organization Name, Valid From, Valid To, Shared Service Provider (SAP Process Control Attribute), Currency, and Country. The General tab is common for both SAP Access Control and SAP Process Control users. However, some attributes of the General tab may vary between SAP Access Control and SAP Process Control users. For example, a user with only SAP Access Control authorization in a system in which only the SAP Access Control application is activated sees the following attributes: Name, Description, Country, and State as shown in Figure 7.

Figure 7

Create an Organization view for an SAP Access Control user

Figure 7 is displayed when you click the Create Organization link (not shown) in the system in which only the SAP Access Control application is activated. To access this screen go to the Work Center and click the Setup link. Under Organizations click the Organizations link.

Attributes such as Shared Service Provider, Org Level System Parameter, and various Review Settings check boxes are only displayed to a user with SAP Process Control roles when the SAP Process Control application is activated in the GRC system.

• Subprocess: This tab is only visible to users with SAP Process Control roles. Assignment of subprocesses to an organization is a key step in defining the compliance structure.  Assignment of subprocesses and controls can be made either by reference or by copy. If you assign subprocess by reference, the subprocess and control definition are driven exclusively from the central subprocess and controls. Any changes to the central subprocess and controls are automatically reflected in the referenced subprocess and control. If you assign subprocess by copy, then there is a separate copy that is created in the system that is attached to that organization. After assignment, the user can also modify the subprocess and control definition.
• Indirect Entity-Level Controls: This tab is only visible to users with SAP Process Control roles. Indirect Entity-Level Controls can be created at any time and assigned to the organization.
• Regulations: This tab is only visible to users with SAP Process Control roles.
• Policies: This tab is only visible to users with SAP Process Control roles.
• Users: This tab (Figure 8) is visible to users with SAP Access Control roles. SAP Access Control users can be added to the organization through this tab. Once a user is saved in one of the organizations, it cannot be added in any other organization. To perform access risk analysis for these users who are added in the organization, click the Add button (Figure 8) and then access the Risk Analysis: User Level screen (Figure 9) by clicking the work center Access Management link and following menu path Access Risk Analysis > User Level.

To open the Search Org Unit pop-up screen shown in Figure 9 click the object value selection (OVS) icon or press F4 for the Org Unit analysis criteria.

Figure 8

Add users to the organization

Figure 9

Analyzing Access Risk Analysis for the users added in the organization

• Owners: This tab is visible to users with SAP Access Control roles. You can maintain the SAP Access Control owners via work center menu path ‘Setup’ > Access Owners > Access Control Owners > Create. This action opens the screen shown in Figure 10.

Figure 10

SAP Access Control owner assignments

In this screen you can identify users or user groups who should be mitigation monitors and approvers or any other type of owners with specific roles in SAP Access Control. In the Owners tab of the Organization screen (Figure 11), you can add the SAP Access Control owners that you created in Figure 10.

Figure 11

Add an Access Control owner

In the Owners tab, you can assign the appropriate owners to the organization unit by clicking the Add Row button. The list of owners available is based on the owners identified in Figure 10. These owners can then be defined as mitigation approvers and mitigation monitors to the control.

A mitigation approver is the user who owns the Mitigation Control Maintenance. This user also approves mitigation maintenance workflows and receives the mitigation control alerts. The mitigation approver gives notice of the decision to the internal audit team, security colleagues, and other business process owners about the control and monitoring person. This is the user who is responsible for the assignment of a mitigation control to any User/Role/Profile as per the business configuration.

A mitigation monitor is designated for monitoring users who are mitigated for the associated access risk ID. The monitor also checks what activity mitigated users have done in the plug-in system. The monitor does this by running the report or transaction code maintained under the Reports tab in the Mitigation Control definition. The monitor ensures mitigated user IDs are doing jobs as per the business requirement and should report any fraudulent activity if found to the approver and business owner.

• AC Roles: This tab is visible to users with SAP Access Control roles. SAP Access Control roles can be added to the organization through this tab (Figure 12).

Figure 12

Add Access Control roles

You can perform access risk analysis for these roles that are added in the organization via the AC Roles tab. For this you have to execute a Role Risk Analysis report for the field Org Unit.

To complete this step, click the work center Access Management link (Figure 4) and follow menu path Access Risk Analysis > Role Level > Open the OVS Help for Org Unit. This action opens the Risk Analysis: Role Level screen (Figure 13).

Figure 13

Analyze Access Risk Analysis for the roles added in the organization

You can execute a role level risk analysis report for these organizations.

• Roles: The Roles tab is visible to users with SAP Process Control authorizations. In this tab, you can assign process control roles to any user.

For example in Figure 14, I assigned Jitan Batra as an organization owner role for this Org Unit. To complete this step, select a role and click the Assign button. Find the user in the Select Users browse and select screen. Click the OK button in the Select Users browse and select screen. Save this assignment.

Figure 14

Roles tab

• Attachment and Links: This tab is visible to both SAP Access Control and SAP Process Control users and is used to add a file or link for more information on the Org Unit.

Overview of Control and Its Technical Details

In SAP Access Control 5.3 and in older traditional releases, mitigation control data was stored in SAP Access Control application tables. However, in the SAP solutions for GRC 10.x releases, mitigation control data is stored in HR tables. SAP Access Control mitigation control and local control in SAP Process Control are stored in the application tables with the same object type: P2. Table 2 lists the major technical object types that are relevant to this article.

There are three database tables (HRP1000, HRP1001, and HRP5354) that contain mitigation control information. These tables are part of the HR framework and are specific to SAP Process Control. Readers who have worked in release 5.3 of SAP Access Control find it difficult to trace the mitigation control database tables for SAP Access Control 10.0.

The Table HRP1000: Selection Screen (Figure 15) contains the Mitigation Control ID with a technical object ID. You can easily find the number of local controls (which includes SAP Access Control mitigation controls and local SAP Process Control controls) through this table. To open the screen shown in Figure 15 execute transaction code SE16.  In the Data Browser: Initial Screen (not shown), enter the table name as HRP1000. Press F7 or click the table contents icon .

Figure 15

Database table HRP1000

To check the total number of local controls, enter P2 (local control) in the OTYPE (object type) field and click the Number of Entries button. Alternatively, press the shortcut key (Ctrl + F7). The total number of controls is displayed in the pop-up screen shown in Figure 15.

If for maintenance purposes you want to know the technical object ID of the Mitigation Control ID, enter P2 in the OTYPE field and JITANMIT1 in the STEXT field as shown in Figure 16. Click the execute icon or alternatively press the shortcut key F8.

Figure 16

Finding the object ID of the SAP Access Control Mitigation Control ID

This takes you to Figure 17 in which you can find the technical object ID of the mitigation control through field OBJID.

Figure 17

Details of SAP Access Control Mitigation Control ID in HRP1000

HRP1001 contains the relationship information of the control and local subprocess. To obtain the technical object ID of the local subprocess, you can use the technical object ID of the mitigation control from Figure 17.

Now execute transaction code SE16 (object browser). In the Data Browser: initial screen (not shown), enter the table name as HRP1001. Press F7 or click the table contents icon. In the screen that appears (Figure 18) enter the technical object ID of the mitigation control in the OBJID field and P2 in the OTYPE field. Click the execute icon or press the F8 key.

Figure 18

Find a relationship of SAP Access Control Mitigation Control ID by providing a technical object ID

This action opens to the screen shown in Figure 19 in which the relationships of the control ID are displayed. In this case the relationship of control ID (P2) is displayed with the local subprocess. P1 appears in the SCLAS field, and the local subprocess technical ID is appears in the OTJID field.

Figure 19

Details of the relationships of SAP Access Control Mitigation Control ID

Note that the OTYPE of the subprocess is P1. You can see this value in the SCLAS column of Figure 19. This value means local subprocess. Database table HRP5354 is the field extension table that contains SAP Access Control extension information, such as the business process ID and business subprocess ID.

How to Retrieve Mitigation Controls If Their Relationship Is Broken

In this section you see how GRC administrators and experts can retrieve the mitigation controls if their relationship with the local subprocess is broken.

Being part of a development organization, I have seen multiple incidents in which mitigation controls exist in the database, but were not visible in the Mitigating Controls screen (Figure 20). To access the Mitigating Controls screen, click the Work Center Master Data link (Figure 4) and navigate to Mitigation Controls. Click the Mitigation Controls link.

Figure 20

Mitigating control personalized object work list (POWL)

This scenario can happen when a local subprocess is removed from the database or its validity has been reduced from the back-end system. This removal or validity reduction could be because a user has changed the master data through transaction code GRFN_STR_CHANGE. Note that GRFN_STR_CHANGE is the transaction code given only for administrative purposes, and one should pay the utmost caution while changing any data through it. It should only be given to power users.

The below steps walk you through how to retrieve these missing controls. In this scenario all the missing controls belong to a single organization <OUNIT> for simplification. (If the missing controls do not belong to a single organization you can follow the same steps for multiple organizations.)

Step 1. Find the list of mitigation controls that are missing. (As an example you can take the list of mitigation controls from the old exported file from Mitigation Control POWL.)

Step 2. Find the technical object ID (OBJID) for these mitigation controls and note them down. You can retrieve the technical object ID by using database table HRP5354. Refer to Figure 21, which shows various fields of database table HRP5354. To open Figure 21 execute transaction code SE16. In the Data Browser: Initial Screen (not shown), enter the table name as HRP5354. Press F7 or click the table contents icon.

Figure 21

Database table HRP5354

Take one mitigation control ID. For example, in the OTYPE (object type) field, enter P2 and enter the mitigation control ID: JITANMIT1 in the SHORT_KEY1 field. Click the execute icon, or alternatively, press the shortcut key F8, which takes you to Figure 22.

Figure 22

Details of a single mitigation control technical object ID in table HRP5354

Note down the technical object ID from field OBJID. This is the technical ID for the mitigation control ID. You can input multiple mitigation control names in the SHORT_KEY1 field to retrieve technical object IDs of the missing mitigation controls.

Step 3. Retrieve the mitigation control details. Use the technical object ID (OBJID) and check if there is any entry existing in database table HRP1001. To complete this step, execute transaction code SE16. In the Data Browser: Initial Screen (not shown) enters the table name as HRP1001. Press F7 or click the table contents icon. This action opens the screen shown in Figure 23.

Figure 23

Find the object ID in HRP1001 in this database table that stores relationships between various object IDs

In this case there should not be an entry for a missing control in HRP1001. As you see in Figure 23 when you try to find the object ID and click the execute icon, you see the message No table entries found for specified key at the bottom of the screen.

Now using the OBJID (50000953) that you retrieved in Figure 22 and OTYPE (P2), retrieve the BEGDA (begin date) and ENDDA (end date) by searching through database table HRP1000. After entering the OBJID and OTYPE, click the execute icon. This search takes you to Figure 24.

Figure 24

Details of the object ID in HRP1000

Note down the BEGDA and ENDDA retrieved from the fields BEGDA and ENDA.

Step 4. Retrieve the Mitigation Control. Execute transaction code PP01. In the Maintain object screen (Figure 25) enter the following details:

• Plan version: Current Plan
• Object Type: Local Subprocess
• Object ID: 50005673 (This is the technical object ID for BSPDUMMY, which is a local subprocess that is linked to organization <OUNIT> and is associated with the missing mitigation control). This subprocess BSPDUMMY is just an example. It could be any of the subprocesses linked to organization <OUNIT>. You can find the subprocess through table HRP1001 or through GRFN_STR_CHANGE transaction. Press Enter.

Figure 25

The initial Maintain object screen

In the Infotype Name section, select Relationships and click the create icon or press F5 (Figure 26). This action opens the screen shown in Figure 27.

Figure 26

Create relationships

In Figure 27, enter the following details that are extracted from previous steps:

• In the Validity field: BEGDA and ENDDA taken from step 3
• Type of related object: Local Control
• ID of the related object: 0000953 taken from step 2
• Relationship type/relationship: B 970 (Incorporates)

Figure 27

Maintenance of the relationship entry

After you enter all the above details, the screen looks like Figure 28.

Figure 28

Save the relationship

Click the save icon or press (Ctrl+S) to go to Figure 29.

Figure 29

Relationship saved

The missing relationship is created between the subprocess and the mitigation control. The application shows the success message Record Created as shown in Figure 29.

Check the Effectiveness of the Control Before Consuming It

An increased focus toward governance, risk management, and compliance has led many businesses to implement compliance processes to monitor the identification of issues and remediation of these issues.

Self-assessments of controls can be instrumental in establishing and maintaining a full proof compliance process, which also provides management with the real time necessary information to focus on identifying actual issues and remediation on those issues. Also the self-assessment of these controls raises accountability of control owners, and places overall responsibility of the controls in their hands. Control owners can quickly develop remediation plans for these issues, which also allow internal and external audit teams to do their work in less time. Assessment of Mitigation Controls using the same master data is only possible because the control is shared between SAP Access Control and SAP Process Control.

You can schedule these assessments through the Planner screen. Figure 30 is displayed by following menu path Work Center Assessments > Assessment Planning > Planner. Click the Create button in the Planner screen. In the Plan Activity field of the pop-up screen that appears, select Perform Control Design Assessment from the pull-down list of options.

Figure 30

The Planner screen

You can schedule the Perform Control Design Assessments for the local control through the Create Planner screen. This screen schedules the assessment workflow, which goes to the control owner. The control owner then performs the required steps and the assessment is completed. If the control owner finds an issue related to the controls, an issue is created and remediated accordingly and then assessment is completed.

As these assessments are completed, the business is reassured that these controls will be effective once they are deployed for access risks in Access Control application.  Such checks help in more effective internal and external audits and also improve daily operations.

Tip: You should perform these assessments in a time frame older than when these controls need to be deployed in SAP Access Control. For example, if controls need to be used for the year 2015 onward, then assessment of these controls needs to be completed by 2014. When an issue is created, respective owners are assigned to address it. Case management functionality in a process control provides an environment for tracking the work done on a case and supporting other forms of collaboration. If any issue exists for these controls, you are not able to change any attribute of that control in the SAP Process Control application. In such scenarios, the system throws an error message: Change of validity not possible because case exists or in a policy.

Jitan Batra

Jitan Batra is a senior developer for SAP Access Control and is currently working in SAP Labs India Pvt. Ltd. in development support for SAP Process Control. He has different certifications, including SAP Access Control 10.0, ISEB, and ISTQB. He was the development implementation partner for GRC Access Control 10.0 at Daimler APAC, which was the first deployment of the product in APJ and globally. He has also conducted public batch trainings for the SAP Access Control 10.0 course.

You may contact the author at jitan.batra@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.