Why integrations need their own change control
Integrations sit between systems that already have change control of their own. An SAP S/4HANA system, a partner portal and a warehouse application may each have a disciplined release process. The integration between them often does not. A mapping edited in a hurry, a changed endpoint or a loosened API policy can stop order flow or expose data, and nobody notices until a business process fails.
The risk is easy to underestimate for three reasons:
- Integration content is quick to change. A small edit can be deployed in minutes.
- The impact crosses system boundaries, so no single application owner sees the full effect.
- Ownership is often unclear. The integration team builds it, the business depends on it, and the application teams assume someone else tests it.
This guide gives you a control model that is light enough to use daily and strict enough to satisfy an auditor. It has four parts: risk tiers, four-eyes approval, separation of duties, and emergency access. It applies to SAP Integration Suite, to SAP Process Orchestration 7.5 and to hybrid runtimes alike.
Scope: what counts as a production change
Decide first what the control covers. A narrow definition leaves gaps. Treat each of the following as a change to production:
- Deploying, redeploying or undeploying an integration flow in Cloud Integration.
- Changing an API proxy, product or policy in API Management, for example OAuth 2.0 verification, quota, spike arrest or threat protection.
- Changing credentials, certificates or connectivity settings, including destinations and Cloud Connector access rules to on-premise systems.
- Changing event topics, queues or subscriptions in advanced event mesh.
- Changing scenarios, mappings or channels in SAP Process Orchestration 7.5.
- Changing alert rules, because a muted alert is a control change.
Changing a log or trace level on a running integration flow is also a production action. It is usually low risk, but trace levels can expose payload data, so it belongs in the tier model rather than outside it.
Step 1: classify changes by risk
Approval effort should match impact. If every change needs the same heavy process, people will route around it. Define three tiers and publish them.
