Organizational Rules in SAP GRC Access Control are specialized filters designed to eliminate false positive segregation of duties (SoD) violations in access risk analysis reports. These rules enable organizations to account for organizational-level restrictions when evaluating access risks, ensuring that conflicts are only reported when they occur within the same organizational boundary (such as company code, cost center, or plant)

Objective:

The primary objective is exception-based reporting to remove false positives that result from organizational-level segregation, where users may have conflicting transactions but are restricted by different organizational values

Scenario / Challenge:

An organization has implemented a shared services model where finance teams are segregated by company code. The current SoD analysis shows false positive conflicts when users have vendor invoice posting rights (FB60) for Company Code 1008 and vendor master data maintenance rights (FK02) for Company Code 1000. While these are conflicting functions, they pose no actual risk since they operate on different organizational entities.

Good Practices for Configuration:

Organizations should implement organizational rules exclusively for exception-based reporting and only after thorough analysis to ensure the situation warrants their use. Rules should not be instituted until the remediation phase of a GRC project, and only after identifying specific organizational rule scenarios.

Critical considerations include:

• Use organizational rules only when the company has made a conscious decision to segregate via organization levels

• Avoid using organizational rules for mass organizational level reporting due to performance impact

• Be cautious not to filter out too much, as it's better to over-report (false positives) than under-report (false negatives) from a control perspective

• After creating organizational rules, SoD rules must be regenerated using transaction GRAC_GENERATE_RULES

• Apply the “Consider Org rule” option during risk analysis execution to activate organizational rule filtering

Most companies control data access through role assignment rather than organizational rules, so this functionality should only be enabled for functions requiring specific organizational segregation

Implementation:

Step 1: Identify the specific SoD risk: “Vendor Master Maintenance vs. Process Vendor Invoices”

SOD Setup Diagram:

To keep it simple. I have created SOD Risk ‘ZP001_1’ containing two functions ‘ZAP02_1’and ‘ZPR01_1’.

Generate the Risk after creation or modification ( Tcode: GRAC_GENERATE_RULES )

Risk: ZP001_1

Function: ZAP02_1

Function: ZPR01_1

Note:

I have added permission which contains BUKRS field as we are considering implementing Organizational Rule for Company Code.

$BUKRS in SAP GRC ruleset permission files is a variable placeholder that represents the Company Code field (BUKRS) in SAP authorization objects

When the ruleset is evaluated, $BUKRS gets populated with actual company code values from the user's authorizations or role assignments

Role details:

Role 1: Z_TEST_ROLE_1008

Role 2: Z_TEST_ROLE_1000

Assign this to a test user and run the Repo sync job ( SA38 ->GRAC_REPOSITORY_OBJECT_SYNC )

Step 2: Setting up Organization Rule

From the SAP NetWeaver Business Client, navigate to

Step 3: Running Risk Analysis

From the SAP NetWeaver Business Client, navigate to

When we run Risk analysis without considering Org Rule, we see that the values are displayed as $BUKRS which leads to potential false positives

When we run Risk analysis considering Org Rule, we see that the values are displayed for BUKRS field which helps determine that this risk is clearly false positive and can be ignored.

Org Rule ID helps filter out these false positive results and focus on actual risks.

Conclusion:

Key Benefits

1. False Positive Elimination

• Filters out SoD conflicts that appear risky at the transaction level but are safe due to organizational restrictions

• Prevents reporting of violations when users have conflicting access across different organizational boundaries (e.g., different company codes)

• Provides unique identification for each organizational rule, enabling targeted application to specific risks

• Allows granular control over which SoD risks should consider organizational filtering

• Creates a clear reference system for documenting why certain risks were filtered out during analysis

• Supports regulatory compliance by providing justifiable reasons for risk exceptions based on organizational controls