Top 15 Hard SAP GRC Interview Questions: Practical
Scenario-Based Guide (2026)
Mastering SAP GRC (Governance, Risk, and Compliance) requires more than memorizing transaction codes; it demands a deep understanding of live production environments, risk mitigation, and automated workflows. In top multi-national corporations (MNCs), Level 2 technical and architectural interviews focus on practical scenarios, configuration logic, and system troubleshooting.
Section 1: Access Control (AC) - ARA & ARM Deep Dive
Q1: A user requires an emergency role that conflicts with
their daily functions, creating an unavoidable Segregation of Duties (SoD)
risk. How do you technically manage this within Access Risk Analysis (ARA)?
Answer: You must implement a Mitigating Control. The process
involves:
1. Identifying
the specific risk ID and conflicting functions in ARA.
2. Creating a
Mitigating Control ID via the NWBC (NetWeaver Business Client) frontend.
3. Assigning a
designated Control Monitor (approver/reviewer).
4. Mapping the
specific user and the conflicting role to the Mitigating Control ID with an
explicit validity period.
5. Ensuring
the control is actively monitored through periodic alert logs or manual usage
reviews.
Q2: During a risk analysis, you notice that a newly
customized transaction code (Z-transaction) is bypassing your SoD ruleset. What
are the exact steps to incorporate it?
Answer: Custom transactions must be manually integrated into
the GRC ruleset:
1. Go to NWBC ➔
Setup ➔ Access Risk Analysis ➔ Functions.
2. Open the
specific Function that corresponds to the business process of the Z-code.
3. Add the
Z-transaction code to the Actions tab.
4. Maintain
the corresponding authorization objects and field values under the Permissions
tab.
5. Save the
Function, generate the ruleset, and run an incremental synchronization job
(GRAC_REPOSITORY_OBJECT_SYNC) to update the global ruleset.
Q3: How does the "Impact Architecture" differ when
executing a Risk Analysis at the Action Level versus the Permission Level?
Answer:
• Action
Level Analysis: Looks only at the transaction codes (T-Codes) assigned to a
user or role. It triggers a risk if two conflicting T-Codes are present,
regardless of what the user can actually execute inside them.
• Permission
Level Analysis: Looks deeper into the underlying authorization objects, fields,
and values (S_TCODE, ACTVT). It only triggers a risk if the user has the
explicit authorization values to execute both conflicting halves of the risk,
making it far more accurate and reducing false positives.
Q4: Why is the Access Request Management (ARM) MSMP workflow
routing requests to the fallback stage instead of the designated path?
Answer: MSMP workflows route to the fallback stage when the
system evaluates a path but cannot find a valid agent or routing rule
condition. This typically happens if:
• The
dynamically evaluated agent (like a specific Role Owner or Manager) is missing
in the user master repository.
• The BRF+
rule returns a value or result string that is not mapped to a valid path inside
MSMP Step 5 (Maintain Paths) or Step 6 (Maintain Route Mapping).
Q5: Explain the technical difference between an Agent Rule
and a Routing Rule in MSMP configuration.
Answer:
• Agent
Rule: Determines who needs to approve the request at a specific stage (e.g.,
finding the Manager or the Risk Owner).
• Routing
Rule: Determines which path the request should take based on request attributes
(e.g., if the request contains a Critical Role, route through Path B; if it
contains standard roles, route through Path A).
Q6: How do you configure a multi-stage, multi-person (MSMP)
workflow to trigger a mandatory risk analysis before the Manager Approval
stage?
Answer: In MSMP configuration (GRFN_MSMP), go to Step 5
(Maintain Stages). Select your stage and locate the stage execution settings.
Enable the check box for "Risk Analysis Mandatory." Additionally,
configure the global ARM configuration parameters (Parameter 2024 and Parameter
2025) in transaction IMG to enforce risk analysis execution during submission
and approval.
Q7: A background risk analysis job is taking too long and
failing with short dumps. How do you troubleshoot and optimize this
performance?
Answer: Optimize by following these actions:
1. Ensure
tables are updated by running statistics on GRAC* tables via database
administration tools.
2. Check for
missing indexes on heavy transaction tables like GRACUSERROLE or GRACMOBJLIST.
3. Split the
global analysis job into smaller, modular batch inputs (e.g., running it per
specific connector or specific user groups rather than the entire landscape).
4. Increase
the timeout limit parameters in profile parameter rdisp/max_wprun_time if
resources allow.
Q8: What is the exact function of the
GRAC_REPOSITORY_OBJECT_SYNC program, and what happens if the Profile Sync fails
while the Role Sync succeeds?
Answer: The program synchronizes Master Data (Users, Roles,
Profiles) from the target plug-in backend systems into the GRC repository
tables. If the Profile Sync fails while the Role Sync succeeds, the GRC system
will know the roles exist, but any risk analysis executed will be incomplete
because it cannot verify the underlying profiles or authorizations attached to
those roles.
Q9: How do you technically enforce "Prerequisite
Roles" in ARM so a user cannot request an advanced role without holding a
baseline role?
Answer: Prerequisite roles are configured in NWBC under Role
Management. Open the target role definition, navigate to the Prerequisites tab,
and define the mandatory baseline role. When a user creates an ARM request for
the target role, the MSMP validation engine checks the repository; if the
baseline role is missing from both the request and the user’s current
inventory, it blocks submission.
Q10: How do you handle User ID mapping in a cross-system
environment where a user has ID "JSMITH" in ECC but
"SMITHJ" in S/4HANA?
Answer: You must configure Global User ID Mapping. In GRC system parameters, map the primary data source to an identity management system (like SAP IDM or LDAP) or maintain the User Mapping table (GRACUSERMAP) where the distinct backend connector names are explicitly linked to a single, unified Global User ID string.
Section 2: Emergency Access Management (EAM) - Firefighter
Scenarios
Q11: Explain the detailed technical lifecycle of a
Firefighter Session using the ID-Based approach versus the Role-Based approach.
Answer:
• ID-Based
EAM: A dedicated service user master record (type Service) is created directly
in the backend target system. The user logs into GRC, runs transaction
GRAC_SPM, and checks out the ID. A remote logon session opens.
• Role-Based
EAM: No unique service user exists. The user logs into their regular backend
account and executes GRAC_SPM. The system dynamically assigns the Firefighter
Role to their active user master record for the duration of the approved
session and strips it when they close the session.
Q12: A Firefighter log report is completely blank even
though the user executed several configuration transactions (SPRO). Why is this
happening?
Answer: A blank report occurs due to three primary
configuration oversights:
1. The
transaction logging parameter (rec/client) is turned off in the backend system
profile parameters, preventing table logs from writing.
2. The
synchronization job GRAC_SPM_LOG_SYNC has not run or failed in the background.
3. The
specific transaction codes executed do not generate change documents or
standard transaction logs (ST03N / SM20 logs) monitored by EAM tracking
frameworks.
Q13: How do you configure EAM to automatically send
Firefighter log review workflows directly to a user's functional Manager if the
primary Controller is absent?
Answer: In MSMP Stage configuration for the EAM log
workflow, you must maintain a backup path or use an Agent Rule defined with an
alternative fallback entity. Alternatively, implement a BRF+ rule that reads
the HR organizational hierarchy table (PA0001 / HRP1001) to automatically
select the functional manager if the primary controller field returns an
inactive or out-of-office status.
Q14: How do you isolate Firefighter ID access across
different company codes so a finance controller in Company A cannot check out a
Firefighter ID meant for Company B?
Answer: Isolate access by utilizing Firefighter Attributes.
In NWBC ➔ Emergency Access Management, maintain Firefighter
IDs with specific Controller and Owner mappings, and restrict authorization
object I_V_GRAC_FF in the user's base GRC security profile by filtering on the
explicit Functional Area or target Connector values matching Company B.
Q15: What is the purpose of Parameter 4010 and Parameter
4015 in EAM configuration?
Answer:
• Parameter
4010 (Firefighter ID Role): Specifies the structural security role that
identifies a Firefighter ID profile within the backend connector system.
• Parameter
4015 (Send Firefighter Login Notification): Dictates whether the system sends
an immediate automated email or alert notification to the controller the
absolute second a Firefighter session is initiated.