Most SAP configuration drift is not caused by unauthorized access. It is caused by authorized users making changes for legitimate reasons that are imperfectly documented and never reversed. A Basis engineer who increases the dialog work process count in RZ10 during an incident and solves the problem. A consultant who unlocks the production client to apply an urgent correction and forgets to re-lock it. An authorization admin who adds a temporary role to a user during month-end close and removes the task from the backlog three weeks later when the urgency has passed.
Each of these is a real event with a real justification. None of them are unauthorized. All of them leave the production system in a different state than the documented baseline. That gap between the documented state and the actual state is configuration drift. It is also the gap that contains the explanations for incidents that appear to have no obvious cause.
Why configuration drift is distinct from a change management failure
Change management in SAP, meaning the STMS transport system and associated approval workflows, catches changes that travel through the formal transport landscape: ABAP code, configuration transported from development through quality to production. Configuration drift lives in the space that transport management does not cover.
Direct table modifications via SM30 or SE16N in production. Profile parameter adjustments made directly in RZ10. HANA configuration changes made through HANA Studio or SQL without going through a configuration management tool. RFC destination modifications that do not generate a transport. User master record changes that bypass the role-based provisioning workflow. These are all technically possible, often necessary in urgent situations, and systematically outside the transport log.
The post-incident investigation that concludes “we don’t know when this changed” is almost always referring to one of these categories. The STMS shows nothing because nothing was transported. The change is real. The record of when it happened and who made it is in the SAP change documents, but only if those documents were configured to capture the relevant table, and only if someone knows to look there.
The three configuration layers that drift independently
Authorization and user master drift
Authorization configuration in SAP changes through multiple channels. Role changes transported via STMS are visible. Direct user master changes via SU01, role assignments via PFCG, and authorization buffer rebuilds are not transport-visible. They generate change documents in the USR* table change history, but those documents are only reviewed when someone explicitly opens SCU3 and queries for changes to user administration tables.
The drift pattern that causes incidents most often in this layer is a temporary access grant that was not time-limited and was never revoked. A user who received a sensitive authorization for a project three months ago still has it. A service account that was given broad access for a migration activity was never cleaned up after the migration completed. An authorization admin who added a role assignment “just to test” and considered reverting it later, then forgot.
The monitoring question is not whether these changes were authorized at the time they were made. It is whether the current state of the authorization landscape reflects what should be in place today, and when any deviation from the expected state was introduced.
System and instance configuration drift
Profile parameters in RZ10 define how the SAP application server behaves: number of work processes, memory allocations, buffer sizes, timeout values. Changes to these parameters require a restart to take effect and are, in theory, controlled events. In practice, they are made under incident pressure with imperfect documentation and are sometimes not rolled back when the original problem is resolved.
SCC4 client settings are a specific high-risk area. The setting “No changes allowed” in a production client enforces that customizing changes require a transport. If this setting is temporarily changed to allow direct customizing for an urgent correction, and then not reset, the production client is open to direct customizing from any user with table maintenance access. This is a configuration that can stay in a degraded state for months without any operational consequence, until an auditor checks it or a developer starts making direct production changes because they can.
HANA configuration parameters changed via HANA Studio or via ALTER SYSTEM SET commands are the least visible category. They do not generate ABAP change documents. They are recorded in HANA’s own configuration history, visible through M_INIFILE_CONTENT_HISTORY, but they are not part of any SAP transport or ABAP change document framework. A HANA parameter change that improves performance in one area and degrades it in another, made six weeks ago and forgotten, may be invisible to the Basis team investigating the current degradation.
Integration and interface configuration drift
RFC destinations defined in SM59, logical system definitions, IDoc partner profiles in WE20, and ALE distribution model settings are integration configuration objects that do not typically travel via transport in established landscapes. They are created and modified directly in the target system.
The specific drift scenario that causes integration failures is an RFC destination that was modified to point to a different system for testing purposes and was not reverted. Or a partner profile where an outbound parameter was changed during a project and the production system now sends IDocs with the wrong message type. These changes exist in the SAP change documents for the relevant tables, but nobody has configured monitoring to surface them.
Where the change records live and what they miss
SAP maintains change documents for tables where change document logging is configured. SCU3 (table change log) shows which tables were changed, when, and by whom, but only for tables with change document logging enabled, which is a subset of all tables and not uniformly configured across implementations.
SM20 (security audit log) records events including user administration changes, authorization failures, and system client changes, but its coverage depends on how the audit log was configured: which event classes are active, which clients are audited, and whether all users are captured or only a defined subset.
STMS and SE01 show what traveled through the transport system. They show nothing about changes made outside the transport landscape, which is exactly where the most operationally significant drift originates.
The gap between the change that happened and the change record that can be found after an incident is the primary reason post-incident reviews produce conclusions like “we believe this changed approximately three weeks ago but cannot confirm the exact date or the specific change made.”
| Watch out: In many SAP implementations, change document logging is enabled for some tables during the initial implementation and then never reviewed as the landscape evolves. Tables that were not considered sensitive at go-live may now contain critical configuration. Verify which tables have change document logging enabled (check the table properties in SE11) and compare that list against the tables most relevant to your highest-risk configuration areas. |
What configuration drift monitoring requires
Baseline snapshots at known-good states
Drift is only detectable relative to a defined baseline. The baseline is the configuration state that has been reviewed, approved, and documented as correct. Without it, any current configuration state is equally valid because there is nothing to compare it against.
Practical baselines for configuration drift monitoring include: the authorization role assignments and user profile assignments at the end of each quarter after access reviews are completed, the RZ10 profile parameter values after each maintenance window, the RFC destination list after each integration project completes, and the SCC4 client settings at each system health review. These are point-in-time snapshots that capture the intended state and become the reference for subsequent comparison.
Events that warrant immediate alerting
Not all configuration changes require the same response speed. Some represent urgent risks that should produce an alert within minutes of occurring. The SCC4 setting changing from “No changes allowed” to any other value in a production client is one. Any direct change to USR02 (user master records) outside of normal business hours is another. Changes to SM59 RFC destinations that point to critical system connections, and changes to the HANA global.ini configuration file, both fall into this category. These are configuration changes that, if unintended, can create security or operational exposure immediately.
Changes to review on a daily basis
A larger set of configuration changes are worth reviewing daily without requiring an immediate alert. Changes to AGR_USERS (role assignments), modifications to TVARVC (report variants used in background jobs), changes to background job schedule definitions in SM36, and modifications to partner profiles in WE20 all fall into this category. None of these require waking someone up at 03:00, but all of them should be reviewed before they have been in place for 24 hours to confirm they were intentional and appropriately documented.
| In practice: A simple daily drift review takes fifteen minutes if the monitoring output is well-structured: a list of configuration changes in the past 24 hours, grouped by category, with the user and timestamp for each. Most SAP teams do not have this list produced automatically. They have access to the individual transaction logs (SCU3, SM20, STMS) but no aggregated view. Building a scheduled report or monitoring alert that produces this list daily is lower-effort than it appears and higher-value than it seems until the first time it catches something. |
The incident the drift monitoring prevents
Configuration drift becomes visible in post-incident reviews in a predictable way. The system behaved unexpectedly. The team investigates. They find a configuration that differs from what the documentation says. They check when it was changed. The change log either has no record or has a record from six weeks ago that nobody can connect to any documented change request.
The investigation takes hours or days. The remediation adds more time. And at the end of it, the root cause is documented as “unauthorized configuration change” when the accurate description is “authorized configuration change that was not tracked, documented, or monitored.”
Configuration drift monitoring does not prevent authorized users from making changes. It makes those changes visible at the time they occur, while the person who made them can still explain the reason, and while reverting them is a minor operation rather than a production incident investigation. That visibility, delivered consistently and without requiring manual effort, is the difference between configuration management that works and configuration management that exists on paper.
Redpeaks monitors SAP configuration change events including authorization changes, profile parameter modifications, and client setting changes, with daily drift summaries and immediate alerts for high-risk configuration events. See the configuration monitoring features.
