Who is accountable for access control readiness when SAP migrations go live?

Why This Matters for Security Teams

SAP go-live is not just a technology milestone. It is the point where access assumptions become audit evidence, and any mismatch between business duties and technical roles can turn into segregation-of-duties failures, emergency access sprawl, or blocked operations. Accountability sits with the teams that own the access model, because cutover dates do not validate roles, approvals, or exceptions. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a reminder that access readiness is often weaker than migration plans suggest.

For SAP programs, the real risk is that production access gets justified as temporary and then becomes the default operating model. That creates a control gap between what the migration team promises and what the business can actually support after go-live. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both points toward documented ownership, least privilege, and provable review. In practice, many security teams encounter access-control failures only after users are already in production and auditors start asking who approved what.

How It Works in Practice

Readiness starts before the final cutover window. The business process owner defines what each SAP role must do, security validates that the role design matches those duties, and the migration team proves that technical provisioning can implement those decisions without creating excess access. The account owners remain responsible for the decision, while the migration workstream is responsible for execution evidence. That distinction matters because audit teams look for accountable ownership, not just a successful deployment ticket.

A workable control pattern usually includes:

• role-to-duty mapping for finance, procurement, HR, and basis functions
• testing of privileged roles, emergency access, and segregation-of-duties conflicts before go-live
• documented approval for any exception, including time limit and compensating control
• evidence that access was validated in the target production-like environment, not only in a test tenant
• post-cutover review to remove temporary access and confirm ownership of ongoing access recertification

This is consistent with the control themes in the Ultimate Guide to NHIs — Key Challenges and Risks and the operational emphasis in SAP Breach, where weak identity governance can amplify access errors into broader exposure. SAP migrations often expose the same governance flaw seen in other identity-heavy environments: role design is treated as a project deliverable instead of a living control. These controls tend to break down when emergency access is left open across a month-end or hypercare period because no single owner is tasked with revocation.

Common Variations and Edge Cases

Tighter access control often increases cutover effort, requiring organisations to balance launch speed against auditability and business continuity. That tradeoff becomes sharper when legacy roles do not map cleanly into the new SAP design, when business units share duties, or when third-party support teams need temporary access during stabilisation. Best practice is evolving, but there is no universal standard for this yet: some organisations allow short-lived elevated access with daily review, while others require full pre-approval and no production exception at all.

The edge cases that create the most trouble are usually predictable. Concurrent projects can make it unclear whether the ERP owner, the business process owner, or the IAM team signs off on access readiness. Shared service centres can blur accountability across regions. And in merger or carve-in scenarios, inherited SAP roles often arrive with undocumented access paths. For these cases, the safest approach is to assign a named business owner, a named security approver, and a named operations owner for each critical role family, then retain evidence of validation and rollback criteria. The broader control objective aligns with CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management. When organisations cannot name a single accountable owner for access exceptions, the governance model is already failing before auditors arrive.

Related resources from NHI Mgmt Group

• Who is accountable when SAP access risks are not governed consistently across cloud and on premises systems?
• Who is accountable when SAP access, code changes, or transports create compliance failures?
• Who is accountable for controlling access to export controlled information in SAP and similar ERP systems?
• How should organisations design emergency access for SAP and ERP incidents without losing control or auditability?