RISE With SAP Moves the Core — But Access Governance Can't Stay Behind

One of the quieter failures in RISE With SAP migrations is when the access governance scoring breaks — and nobody catches it until audit season.

The Setup

You've done the technical migration. The S/4HANA system is running in the cloud. Basis is happy, the project team is celebrating go-live, and then someone runs a compliance report — and the risk scores are wrong, incomplete, or simply not firing at all.

This isn't a fringe scenario. It's a predictable consequence of treating access governance as a background task during a RISE migration instead of a parallel workstream. I came across this piece on SAP Insider about access governance in RISE projects that articulates the structural problem clearly — and it's worth understanding why this keeps happening.

What Changes Under RISE That Breaks Governance

When a company moves to RISE With SAP, the managed cloud environment introduces new constraints around infrastructure access, system configuration, and tooling. The problem is that many organisations still run their identity and access governance layer — tools like SAP Access Control (GRC AC) — in a model designed for on-premise.

A few things that can quietly break:

• Connector configuration between GRC and S/4 changes. RFC connections and background job scheduling behave differently in a managed environment. If your risk analysis connectors aren't recertified and tested post-migration, you get silent failures — jobs run, nothing errors out, but the scoring isn't actually pulling current data.
• Role data in the central system goes stale. If your SUIM or access risk analysis runs on a snapshot that hasn't been refreshed correctly from the new cloud system, you're scoring against old role assignments.
• The cloud operating model adds new privileged access paths. SAP Basis tasks in RISE may be handled by SAP itself, but your custom admin roles, Fiori launchpad configurations, and S/4 business roles still need to be governed. The line between "SAP manages it" and "you own it" is blurrier than the sales material suggests.

None of this is unsolvable. But it doesn't solve itself — and it doesn't get discovered until someone looks.

Why Scoring Fails Specifically

Risk scoring in GRC Access Control depends on a chain working end to end: the role data has to be current, the ruleset has to be maintained, and the background synchronisation jobs have to be running and completing successfully.

In a RISE migration project, that chain breaks most often at the synchronisation layer. The GRAC_REPOSITORY_SYNC and related jobs need to be reconfigured to point at the new system landscape. If they're not explicitly part of the migration cutover checklist — and in many projects they aren't — they either don't run, or they run against the old system ID.

When the scoring job then executes, it pulls stale or empty data and produces a result that looks valid but isn't. No error message. Just a wrong number, or no number at all.

The governance team sees green. The auditor sees a gap.

What This Actually Requires

This isn't about buying a new tool. Most of what you need is already in your landscape. What's required is treating access governance as a migration dependency, not a post-go-live cleanup item.

Concretely:

1. Map your GRC connectors before cutover. Know exactly which RFC destinations, background jobs, and sync schedules are in scope, and validate them in the target landscape during the parallel run phase.
2. Rerun your ruleset validation post-migration. Role structures sometimes shift during S/4 conversion. A ruleset that was well-maintained on ECC may have gaps when applied to S/4 role concepts.
3. Document the new privileged access model explicitly. In RISE, SAP holds some system access you previously controlled. Get clarity on what SAP can access, under what conditions, and how that's auditable. This should come from your contract and SAP's cloud security documentation — not assumptions.
4. Run a post-go-live access risk analysis with human review. Don't trust the automated score alone in the first 60 days. Have someone actually look at the output and verify it reflects reality in the new system.

Key Takeaways

• RISE migrations don't automatically carry over working access governance — the synchronisation layer needs explicit re-validation.
• Scoring failures are often silent: jobs complete, numbers appear, but the data underneath is stale or wrong.
• Treat GRC connector reconfiguration as a cutover task, not a post-go-live cleanup item.

---

The SAP Insider article linked above is worth reading if you're planning a RISE project and access governance is on your radar. The structural argument it makes — that governance tooling has to migrate alongside the core — is correct, and it's one that gets underweighted in project scoping conversations.

If you've run into this on a project, or you're currently trying to figure out where your scoring is actually failing, I'd be curious to hear what the sticking point was. You can find me at markus-mildner.com or just leave a comment below.