Security & GRCadvanced

Access Request Management: Workflow, Risk Analysis and Provisioning (Part 4)

Key takeaway

Design Access Request Management as a governed access lifecycle: requester justification, identity and role selection, risk analysis, business/security approvals, provisioning, failure handling and auditable evidence.

Explanation

📌 KEY POINTS
✅ ARM must ensure access is justified, risk-checked, approved, AND provisioned — approval alone isn't enough.
⚠️ A workflow can be fully approved while provisioning still fails — track both states separately.
💡 Mitigation should never be silently attached just to make a request pass — it needs an owner, monitor, validity, and evidence.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE REQUEST

Starts with a clear business purpose and the exact user/system/access requested
Workflow routing: manager, role owner, risk owner, security — per policy
Risk analysis should run BEFORE final approval so approvers see new SoD/critical-access exposure

━━━━━━━━━━━━━━━━━━━━
⚠️ 2. APPROVAL ≠ PROVISIONING

A request can be fully approved while provisioning fails (connector, target-system user, role validity, repository, authorization issues)
Support must track both states independently

━━━━━━━━━━━━━━━━━━━━
▶ 3. MITIGATION DISCIPLINE

Never silently attach mitigation just to pass a request
A real mitigating control needs an owner, monitor, validity period, and evidence

━━━━━━━━━━━━━━━━━━━━
▶ 4. THE FULL LIFECYCLE

Removal and change are part of the same lifecycle — transfers/terminations should trigger deprovisioning or revalidation, not indefinite leftover access
Business roles and clear descriptions improve request quality over hundreds of cryptic technical role names

✅ CHECKPOINT: explain why "request approved" and "access provisioned" must be tracked as two separate states.

Real project scenario

An access request showed status "Approved," but the user still had no role in S/4HANA. The help desk repeatedly resubmitted it. GRC provisioning logs showed the target connector could not find the user because the identity had not been created in that system. Fixing identity provisioning resolved the issue; workflow approval had never been the problem.

Common mistakes

Equating workflow approval with successful provisioning.
Letting requesters choose cryptic technical roles with no business meaning.
Applying mitigation automatically to pass risk analysis.
Omitting access-removal lifecycle.
Resubmitting failed requests without diagnosing connector/provisioning status.

Best practices

Require meaningful business justification.
Show risk results to the right approvers.
Track provisioning separately from approval.
Verify target access after completion.
Integrate joiner/mover/leaver governance.

Interview angle

Walk through request -> risk analysis -> approvals -> provisioning -> verification. Strong answers separate workflow from target-system provisioning and discuss mitigation, role ownership and deprovisioning.

Practice this lesson

Quick check

1. Scenario — An access request showed status "Approved," but the user still had no role in S/4HANA. For the lesson "Access Request Management: Workflow, Risk Analysis and Provisioning", which response shows the strongest architecture and production judgment?

2. What is the purpose of the 'role import' functionality in Business Role Management (BRM) within GRC Access Control?

3. When an access request in GRC Access Control is configured for automatic provisioning, what occurs immediately after the request receives final approval?

Interview questions

1. You are the senior consultant/architect responsible for Access Request Management: Workflow, Risk Analysis and Provisioning. The project situation is: An access request showed status "Approved," but the user still had no role in S/4HANA. 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 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.

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.