What breaks when custom SAP controls are left inside the digital core?

Why custom controls embedded in SAP become brittle

Custom controls inside the digital core usually start as a fast way to enforce business-specific access or workflow logic, but they also become part of the system's upgrade surface. Once they are woven into core configuration or code, every patch, support pack, transport, and authorization change has to preserve their assumptions. That is why embedded controls tend to age poorly compared with controls that sit in a layer designed for change.

The biggest issue is coupling. A control that depends on internal tables, custom exits, or bespoke checks can work perfectly in one release and fail quietly in the next if the underlying business object, role model, or audit event changes. In practice, the more the control relies on local knowledge instead of explicit design, the more likely it is to become fragile during ISO/IEC 27001:2022 Information Security Management driven change cycles and access reviews.

That brittleness matters because the control is often expected to prove something important, such as segregation of duties, logging, or approval enforcement. If the control is hidden inside the core, the technical implementation and the governance intent can drift apart. The result is not just maintenance overhead, but uncertainty about whether the control still expresses the policy it was meant to enforce.

What fails during upgrade and migration cycles

Upgrade and migration work tends to expose three failure modes at once: compatibility breaks, test coverage gaps, and undocumented dependencies. A custom control may still compile or deploy, but no longer fire at the right point in the transaction flow, or it may fire with incomplete context. That is especially dangerous when the control is used to support evidence for access restriction or logging, because silent failure can look like success.

Migration also changes the verification burden. Teams must prove that role checks, exception handling, and audit events still behave as intended after the move. If the control is entangled with core logic, that proof becomes harder because every change to configuration, master data, or transport sequencing can alter the control's outcome. This is where NIST SP 800-53 Rev 5 Security and Privacy Controls is useful, especially for access control, audit logging, and configuration management expectations.

Custom controls also create handover risk. New teams often inherit code that was built for a specific project, not for long-term maintainability. If the original design rationale is not documented, the control becomes difficult to retest, recertify, or retire, which is why hard-coded or deeply embedded logic is so often the first thing that breaks in an otherwise successful upgrade.

Why governance becomes harder to prove after the core changes

The governance problem is not only whether the control still runs, but whether you can demonstrate that it still means what auditors and risk owners think it means. Embedded custom logic can obscure the boundary between application behaviour and control evidence. When that happens, access rules, SoD checks, and logging may continue to exist technically, yet lose audit clarity because nobody can easily trace the policy to the execution path.

This is where control visibility starts to matter as much as control strength. A good control should be easy to inspect, test, and explain in business terms. When a rule lives inside the digital core without a clear ownership model, you often end up with a control that is effective only as long as the original experts remain available. That makes governance fragile even when the underlying technology is stable.

For many teams, the practical lesson is to treat custom core controls as temporary exceptions unless they are formally governed, fully tested, and explicitly documented. If the control is central to compliance evidence or access assurance, it needs an owner, a test method, and a retirement path, not just a transport record.

Risk and Threat Considerations

Custom controls buried in the core can create hidden exposure when they stop matching the current authorization model. The main risk is not only breakage, but false assurance, a rule may appear to be enforcing least privilege or segregation of duties while actually missing new transactions, new roles, or changed logging fields.

Failure mechanism: Core upgrades, role redesign, or migration steps alter dependencies the custom logic relied on, so the control either stops triggering or triggers on the wrong conditions. That can leave privileged actions insufficiently checked, or make audit evidence incomplete.

Impact: Access violations, SoD bypasses, and logging gaps become harder to detect and harder to defend during audit or incident review, especially when the control's intent is no longer transparent.

Practitioner Guidance

What to verify: Before each upgrade or migration, verify that the control still maps to the current business process, role model, and logging schema. If you cannot trace the rule from requirement to execution path to evidence, treat it as unproven rather than compliant.

Decision rule: If the custom logic directly affects access approval, SoD enforcement, or audit logging, prioritise revalidation or externalisation before the next core change. If it is only a convenience check, consider retiring it and moving the control to a layer where it is easier to test and govern.

What good looks like: The best outcome is a control that survives change because it is documented, testable, and owned, with clear evidence for what it enforces and how failures are detected. That is easier to achieve when the control is not dependent on opaque core internals.

Practitioner takeaway: The real breakage is usually not the code itself, but the loss of traceability between policy, implementation, and proof. If you cannot re-establish that chain after change, the control is no longer dependable enough to carry governance weight.

Related resources from NHI Mgmt Group

• What breaks when LLM routing, retries, and cost controls are left inside each application?
• What is the difference between human IAM controls and NHI governance?
• When should organizations review access controls?
• What breaks when SoD controls are tied to legacy SAP customisations?