Role Redesign… Don’t forget SU24 optimisation!

Updating SU24 is one of the single most important preparatory tasks before you start an SAP role redesign. It determines which authorisation checks are proposed when creating or generating roles and therefore directly shapes the baseline for every role, every profile and every downstream risk or licence calculation. Skip it and you’ll carry legacy noise, false positives and broken access logic straight into your redesign — which turns a rational exercise into a firefight.

What SU24 actually controls

• Proposal of authorisation values when you generate or change roles. SU24 stores the recommended authorisation objects and default field values for transactions, programs and function modules.
• Consistency between transactions and authorisation objects. Current SU24 entries tell the system which objects to check for which programs, T-codes and Fiori tiles.
• Baseline for automation and audits. Role generation tools and manual role-builders rely on SU24 to avoid missing required checks or adding irrelevant ones.

Why support packs and custom programs matter

With each Support Pack you apply, subtle changes to programs and libraries can alter authority checks. New code paths, updated APIs, or restructured function modules may add or remove checks that SU24 must reflect. Treat each support-pack cycle as an opportunity to verify and, where necessary, adjust SU24.

Custom Z programs are a frequent source of gaps. If a Z program contains authority checks but those checks are not mapped in SU24, role generation and automated tools will not propose the correct objects and fields. That forces manual intervention during role builds or causes missing authorisations at runtime. Ensure all Z programs include proper authority checks and map those checks into SU24 so generation becomes reliable rather than guesswork.

A practical tool for discovery is STUSOBTRACE. It collects every authority check executed when transactions or programs run. Use its trace output to identify which objects and fields are actually being checked in production use and then update SU24 entries accordingly

IN DEVELOPMENT !!!

SAP RMS has the knowledge and tools to help automate SU24 verification and mapping work, ensuring changes from support packs and custom code are captured efficiently and reliably.

Risks of NOT updating SU24 first

• Propagating deprecated or incorrect checks into new roles, causing functional breaks at runtime.
• Bloated roles owing to obsolete or overly broad proposed values, increasing SoD and licence exposure.
• False positives in SoD and usage analyses because SU24 entries do not reflect technical reality.
• Wasted rework when you regenerate roles after fixing SU24 — doubling time and cost.
• Audit and compliance gaps because auditors expect SU24 to be maintained as part of the authorisation lifecycle.

Practical SU24 checklist for a role redesign project

1. Assign ownership and scope
   • Appoint an SU24 owner and define which modules and custom areas are in scope for the project.
2. Extract the current baseline
   • Export all SU24 entries from your development USOB*C tables. Keep a versioned export for traceability.
3. Run STUSOBTRACE and review results
   • Trace representative business transactions and custom Z programs to capture real authority checks.
4. Map custom checks
   • Ensure every Z program with authority checks has corresponding SU24 entries and sensible default field values.
5. Identify obsolete entries
   • Remove or flag SU24 mappings for retired T-codes, replaced programs or function modules.
6. Tighten default field values
   • Replace wildcards with specific values where business need permits (company code, plant, sales org).
7. Engage functional owners
   • Validate which proposed objects and field values are business-relevant and obtain sign-off.
8. Document changes with business rationale
   • Create transportable change requests with clear justification and owner sign-off for audit trails.
9. Implement changes in a sandbox
   • Apply SU24 changes in a non-production system first and attach them to a transport.
10. Generate trial roles and test
    • Create sample roles from the updated SU24 and execute end-to-end business tests using reference users.
11. Re-run SoD and licence exposure reports
    • Use the updated SU24 baseline to produce accurate risk and costing reports before mass generation.
12. Coordinate transports and deployment

• Move SU24 changes and role artefacts through QA to production with a controlled freeze-window to avoid conflicts.

Suggested sequence for your project plan

1. Planning and ownership confirmation
2. Baseline extraction and STUSOBTRACE exercises
3. Functional validation workshops by module
4. SU24 updates in sandbox and documentation of changes
5. Trial role generation and reference-user testing
6. Fix cycles and re-validation with functional owners
7. Transport to QA and repeat testing
8. Final sign-off, transport to production and go-live monitoring

Testing and validation tips

• Generate at least one sample role per business process and test it end-to-end with a reference user.
• Use STUSOBTRACE results to refine SU24 entries after initial tests; expect iterative tuning.
• Run SoD matrices and licence-exposure reports after SU24 updates to understand immediate impact.
• Schedule short freeze-windows during transports to avoid parallel manual edits overriding automated generation.

Final note for security leads

Treat SU24 updates as a design activity, not housekeeping. It requires technical review, functional sign-off, transport discipline and repeated validation. Doing SU24 properly up front reduces rework, avoids broken access in test or production, tightens licence exposure, and gives your role redesign a clean, auditable foundation.

If you’d like, I can produce a one-page SU24 change checklist formatted for inclusion in your project plan and transport requests.