Enterprise SU24 Governance: Mass Maintenance, Custom Transactions, and Cross-Landscape Consistency

Explanation

In enterprise landscapes with hundreds or thousands of custom transactions and years of accumulated role history, SU24 maintenance stops being a one-off activity and becomes an ongoing governance discipline. At this level, the concern shifts from 'how do I add an object to SU24' to 'how do we ensure SU24 data stays accurate, consistent, and auditable across a multi-system landscape over the life of the SAP implementation.' A primary driver of SU24 decay is custom development. Every time a developer creates a new Z-transaction, especially one that wraps standard function modules or BAPIs containing embedded AUTHORITY-CHECK statements, that transaction needs corresponding SU24 entries or the security team will discover missing authorization objects only when users hit failures in production. Mature organizations embed an SU24 registration step into their custom development lifecycle: developers or a designated security liaison must document every AUTHORITY-CHECK call in new or modified code, and a security architect reviews and maintains the corresponding SU24 entries before the transport is released to QA. Skipping this step is one of the most common root causes of authorization firefighting after go-live. Mass maintenance situations arise during major upgrades, ECC-to-S/4HANA conversions, or SAP support pack applications that ship revised SU24 default data (SAP periodically updates its delivered USOBX/USOBT content). When SAP delivers new default data, organizations must decide whether to accept SAP's new proposals wholesale or preserve customer-specific overrides. This is typically handled through the SU25 upgrade/comparison process (a related transaction used specifically for handling SAP's delivered SU24 data changes during upgrades), which lets you compare delivered defaults against your customer table entries and selectively merge changes. Blindly accepting all SAP-delivered changes can silently alter check indicators across thousands of transactions, some of which may re-enable checks that were deliberately suppressed for legitimate business reasons, or vice versa - so this comparison must be reviewed by security architects, not applied automatically. Cross-landscape consistency is another architect-level concern. In a three-system landscape (development, quality, production), SU24 entries are transportable customizing objects, so consultants must ensure changes flow through the transport chain in the same sequence as the corresponding role and code changes, never made directly in production. Divergence between systems - for example, an SU24 default value present in development but never transported to production - creates a dangerous inconsistency where role builds tested in development behave differently once promoted, because production PFCG proposals differ from what was validated. Governance processes should include periodic reconciliation checks comparing SU24 tables across landscape tiers, especially after any manual production fix (which should be exceptional and always backfilled to development). In S/4HANA and hybrid landscapes, an added governance dimension is the coexistence of classic transaction-based roles and Fiori catalog/business role assignments. SU24 remains relevant for the transactional backend layer (including transactions still called via Fiori apps that route to classic ABAP programs), but architects must maintain a clear map of which authorization decisions are governed by SU24-driven PFCG proposals versus which are governed by Fiori launchpad catalog/group assignments and their own authorization defaults, since these are maintained through different mechanisms and a gap in either can cause access issues that look similar to end users but require entirely different remediation. Governance documentation should explicitly state, per application, which mechanism controls its default authorization proposals. Finally, auditability requires that SU24 change history be traceable: which transaction codes had check indicators changed, when, by whom, and under what change request or business justification, ideally correlated with the transport number that carried the change. Without this traceability, an external audit reviewing why a sensitive authorization check was disabled for a transaction has no way to confirm the change was authorized and appropriate, which becomes a control deficiency finding.

Code example

* Governance checklist artifact used during SU24 review meetings (not executable code,* but a representative structure security architects maintain, often in a spreadsheet* or GRC tool, correlated with transport numbers): * Transaction | Object | Old Check Ind | New Check Ind | Justification | Transport | Approved By | Date* ZMM_GR_POST | M_MSEG_WMB | Unmaintained | Check | Missing check found via SU53 trace after go-live | DEVK900123 | J.Smith (Security Architect) | 2024-03-11* ZSD_ORDER_CHG | V_VBAK_VKO | Check | Do Not Check | Legacy interface bypasses sales org check by design, compensating control via interface user restriction | DEVK900456 | R.Nguyen (Security Architect) | 2024-04-02 * Illustrative pseudo-process for SU25-driven upgrade reconciliation (conceptual, not* actual system syntax):* 1. Run comparison of SAP-delivered SU24 data vs customer SU24 table (USOBX_C/USOBT_C)* 2. For each delta: flag as (a) accept SAP default, (b) keep customer override, (c) needs review* 3. Route 'needs review' items to security architect sign-off before merge* 4. Transport merged result through DEV -> QA -> PROD in the standard sequence* 5. Re-run PFCG authorization update on affected roles in each tier after transport import

Real project scenario

During an S/4HANA conversion project, the security architecture team discovers that hundreds of custom Z-transactions accumulated over 12 years on ECC have inconsistent or missing SU24 entries. Before the conversion, they run a project to inventory every custom transaction, cross-reference embedded AUTHORITY-CHECK statements in the underlying code with existing SU24 entries, and build a remediation backlog. They also establish a governance rule going forward: no custom transaction can be transported to QA without an accompanying SU24 registration reviewed by the security team. During the technical conversion, they use the SU25 comparison step to review SAP's updated delivered SU24 content, deliberately preserving several customer overrides that were tied to documented compensating controls, and transport the merged results through the landscape with sign-off recorded in the project's change management tool.

Common mistakes

• Allowing custom transactions to go live without a mandatory SU24 registration and review step in the development lifecycle • Blindly accepting all SAP-delivered SU24 changes during an upgrade or conversion without architect review, silently altering check enforcement across many transactions • Making SU24 changes directly in production instead of transporting them through development and quality first, causing landscape divergence • Lacking a documented change history correlating SU24 modifications with business justification, approver, and transport number, creating audit findings • Assuming SU24 governs Fiori app authorization defaults the same way it governs classic transaction-based PFCG proposals, missing that catalog/tile assignments follow separate mechanisms

Best practices

• Embed SU24 review as a mandatory gate in the custom development lifecycle for any new AUTHORITY-CHECK-containing transaction • Use SU25 comparison deliberately during upgrades and conversions, routing every delta through architect review rather than bulk-accepting SAP defaults • Maintain a documented, timestamped change history for SU24 modifications correlated with transport numbers and business approval • Never modify SU24 directly in production; always transport through development and quality tiers first • Maintain explicit documentation distinguishing which applications are governed by SU24-driven PFCG proposals versus Fiori catalog/tile authorization mechanisms

Interview angle

At advanced/architect level, interviewers look for evidence of governance thinking beyond single-transaction fixes: knowledge of SU25 as the upgrade reconciliation counterpart to SU24, the risks of mass-accepting SAP-delivered changes, transport discipline across landscape tiers, and the ability to explain why Fiori authorization gaps cannot always be fixed through SU24 alone. Strong candidates discuss embedding SU24 review into the SDLC for custom development.