Security and GRC Decisions You'll Make Three Times (Because Nobody Got It Right the First Time)

Every EWM rollout I've been part of eventually hits the same question: "Who actually approved this user role?" followed by "Wait, how did this get configured?"

Turns out we're not alone. SAP Insider recently reported that security, GRC, and cloud governance are among the biggest execution challenges enterprises face during SAP migrations. Not strategic challenges — execution challenges. As in, people know it matters, but they're still getting it wrong.

I'm watching this closely because I'm currently in automotive EWM implementations where security decisions made during the S/4HANA migration are now creating friction as we bring in BTP services. And I'm starting to see a pattern.

The Problem: You Make Security Decisions Three Times

First time: during the initial S/4HANA migration. You're focused on moving business processes, and security gets handled as "we'll mirror what we had in ECC" or "let's simplify the role structure this time." Someone builds a governance framework. It looks good in PowerPoint.

Second time: when you start adding SAP BTP services. Suddenly you've got a different identity provider, BTP-specific roles and scopes, and nobody's quite sure whether the old GRC tool even covers what's happening in the cloud subaccounts. You retrofit security decisions.

Third time: when you realize the security model you've been building doesn't actually scale across regions, doesn't map cleanly to how BTP handles authorization, and audit is asking questions about segregation of duties that your setup can't answer properly.

By the third iteration, you're not just fixing security — you're undoing decisions that seemed fine at the time but didn't account for what came next.

What This Looks Like in Practice

On our current rollout, we migrated warehouse operations to S/4HANA with a cleaned-up role structure. Roles were defined, GRC policies were documented, everything passed audit. Then we started integrating a BTP service for external logistics partners.

Problem: the BTP subaccount has its own role collections that don't map 1:1 to our S/4 authorization objects. We've got users who need specific EWM functions and visibility into BTP-managed workflows. The original role design didn't anticipate this.

Now we're building a parallel authorization layer — BTP role collections that reference S/4 user attributes — and trying to keep GRC policies consistent across both. It works, but it's more complex than it needed to be because we didn't design for cloud-native identity from the start.

Where BTP Changes the Conversation

If you're running pure S/4HANA on-premise, your GRC tooling probably covers you. The moment you add BTP services — whether it's integration flows, extension apps, or managed cloud services — you're dealing with:

• Different identity concepts: BTP uses OAuth 2.0, XSUAA, role collections. Your GRC tool might not have visibility into that.
• Distributed authorization: roles defined in both S/4 and BTP, sometimes referencing each other, sometimes not.
• Compliance gaps: your audit team wants a unified view of user access, but BTP and S/4 don't share a single source of truth by default.

This isn't theoretical. I've seen projects where security was "handled" during the S/4 migration, but nobody mapped out how BTP identity services would integrate. Six months later, someone's trying to bolt on Cloud Identity Services and align it with the existing GRC framework.

What I'd Do Differently (Next Time)

If I were starting an S/4 + EWM migration today, knowing what I know now:

Design for hybrid identity early. Don't assume S/4 roles will be enough. Map out how BTP subaccounts will handle authorization and whether you need Cloud Identity Services or Identity Authentication from day one.

Include BTP in your GRC scope. Even if you're not using BTP services yet, plan for it. Make sure your GRC tool or process can track role assignments across both platforms.

Test governance at scale. It's easy to set up roles for one site or one region. The real test is when you roll out to multiple sites with different user populations and localized compliance requirements.

Don't wait for audit to ask. If you can't clearly answer "who has access to what, and why" across your full landscape, someone will eventually ask. Better to figure that out proactively than during an audit.

Key Takeaway

Security and GRC aren't things you solve once during a migration. They're decisions you'll revisit every time your SAP landscape expands — especially as you move into BTP. The gap isn't usually knowledge; it's execution. Planning for it upfront saves you from fixing it twice.

I'm still figuring out the best way to handle this on our projects. If you've dealt with this on a larger scale or have a clean approach to unified GRC across S/4 and BTP, I'd be curious to hear how you structured it — reach out via markus-mildner.com.