Audit-ready access at go-live

Go-live is when the new access design meets real work and, a few months later, the auditors. "Audit-ready" means two things on day one: every user has access that was designed, tested, approved and can be explained; and the evidence for all of that is collected and findable. The weekend itself has security tasks that belong in the cutover plan, and the weeks after need controls that keep the design from eroding.

Security in the cutover plan

Luis's cutover plan for the 60-hour window from Friday 18:00 to Monday 06:00 includes security tasks with owners and timings, rehearsed in the dress rehearsal like every other step.

Emergency access that auditors accept

Hypercare always needs some elevated access, and that is where audit findings are born. SAP Access Control's emergency access management provides controlled, temporary elevated access (often called firefighter access) with planning and monitoring. Contoso's rules: emergency access only through named firefighter IDs with an owner and a controller; a reason recorded for every session; session logs reviewed by the controller within a set number of days; and a weekly report to Nadia during hypercare. Shared logins and permanent broad access for the support team are not allowed, even in the first week.

The evidence pack

Logging and responsibilities under RISE

Audit trails depend on logging being configured and kept. In the private edition, SAP's roles and responsibilities document lists providing audit log information as a task excluded from SAP's services: customers manage and archive their logs. Where the security audit log is recorded (file, database or both) is a profile setting, so the architect confirms the target and retention with SAP ECS rather than assuming a default. User and role administration are Packaged Services (formerly SAP Cloud Application Services, CAS) that Contoso did not buy, so Nadia's team performs them. The architect should check these lines in the customer's own contract and RISE Roles & Responsibilities document, because they decide who produces each piece of evidence.

Getting ready for Wave 2

Wave 2 adds company code 1910 and plant 1910 Monterrey for Alternadores del Norte. Because Contoso's architecture sets organizational values only in derived roles, most of the work is creating 1910 derivations of existing task roles, not new designs. The Monterrey team is small, so Nadia expects more combined jobs and plans their mitigating controls with Dan before the mock loads, not after. Users from the acquired company come from a non-SAP legacy ERP, so there is no usage history to propose a mapping from; managers build the mapping from job descriptions instead, and UAT with real mapping covers every Monterrey user rather than a sample.

The first ninety days

• Close emergency access requested for hypercare; report every session reviewed.
• Run the first user-level risk analysis after go-live and compare it with the go-live baseline.
• Review access requests raised in hypercare: were they design gaps (fix the role) or mapping errors (fix the assignment)?
• Retire the legacy firefighter IDs and any cutover technical users.
• Schedule the first periodic user access review with managers, using the new business roles.
• Feed findings back into the design authority before Wave 2 adds company code 1910.
• Put the GRC platform itself on the roadmap: Access Control 12.0 leaves mainstream maintenance at the end of 2027, and SAP GRC for SAP HANA, its successor release (generally available since 31 July 2026), needs the GRC system on SAP HANA. Treat the upgrade like any release: retest the rule set, workflows, emergency access and connectors before it governs CMP.