Security & GRCadvanced

Access Risk Analysis Rule Sets: Functions, Risks, Actions and Permissions (Part 3)

Key takeaway

Build and govern an Access Risk Analysis rule set by modeling business functions from executable actions and permissions, then defining SoD or critical-access risks between those functions with clear business ownership.

Explanation

📌 KEY POINTS
✅ A rule set translates business-control risk into technical access patterns — its quality caps the quality of every analysis run on top of it.
⚠️ A function too broad flags almost everyone; too narrow misses alternate ways of doing the same risky thing.
💡 A "red result" from the tool isn't the finish line — someone must decide remediate, redesign, or mitigate.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE HIERARCHY

Actions and permissions — what a user can execute, under which authorization-field values
Business functions — grouped actions (Create Vendor, Maintain Bank Details, Approve Purchase Order...)
Risks — problematic combinations of functions, or critical standalone functions

━━━━━━━━━━━━━━━━━━━━
⚠️ 2. GETTING FUNCTION SCOPE RIGHT

Too broad → flags almost everyone; too narrow → misses alternate paths to the same risk
T-codes alone are often insufficient — authorization-field values can determine whether access truly conflicts
Consider alternate apps, Fiori services, and technical execution paths in the actual landscape

━━━━━━━━━━━━━━━━━━━━
▶ 3. AFTER THE RESULT COMES BACK

Define severity, business process, and owners so findings can be triaged
A red result is not the finish line — someone decides remediate, redesign, or apply a documented mitigating control

━━━━━━━━━━━━━━━━━━━━
▶ 4. KEEP THE RULE SET CURRENT

S/4HANA/Fiori/custom transaction changes should trigger rule-set review
A static ECC-era rule set produces both false positives and false negatives after transformation

✅ CHECKPOINT: explain why transaction codes alone are often insufficient to define a risky function.

Real project scenario

An SoD rule treated any user with one transaction as able to maintain all supplier data. In S/4HANA, authorization-field restrictions separated general supplier maintenance from bank-detail maintenance, but the rule ignored those values. The company had thousands of false positives. The rule set was redesigned around actual authorization permissions and business functions, making analysis actionable.

Common mistakes

Building rules from transaction-code pairs only.
Creating overly broad functions.
Failing to include Fiori/new execution paths after S/4 migration.
Assigning risk severity with no business owner.
Never retesting the rule set after role redesign.

Best practices

Model business capability, not just transaction names.
Include authorization values where they affect risk.
Maintain risk owners and severity rationale.
Regression-test rules after S/4/Fiori changes.
Track false positives as rule-set quality metrics.

Interview angle

Explain the hierarchy from technical actions/permissions to business functions to risks. A strong answer discusses authorization-field values, alternate access paths and rule-set lifecycle governance rather than simply saying "GRC checks conflicting tcodes."

Practice this lesson

Quick check

1. Scenario — An SoD rule treated any user with one transaction as able to maintain all supplier data. For the lesson "Access Risk Analysis Rule Sets: Functions, Risks, Actions and Permissions", which response shows the strongest architecture and production judgment?

2. Which statement correctly describes the hierarchical relationship among the building blocks used to define access risks within a GRC Access Control rule set?

3. In SAP GRC Access Control's Access Risk Analysis, what does a 'critical action' risk represent?

Interview questions

1. You are the senior consultant/architect responsible for Access Risk Analysis Rule Sets: Functions, Risks, Actions and Permissions. The project situation is: An SoD rule treated any user with one transaction as able to maintain all supplier data. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?

Answer it in your own words first, then compare.

2. You are the senior consultant/architect responsible for SAP GRC Access Control Architecture: ARA, ARM, BRM and EAM. The project situation is: A company implemented ARM but skipped rule-set cleanup and repository synchronization. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.