Lesson 4 of 5
Control and audit
14 min
The fear about continuous delivery in regulated SAP environments is that automation erodes control. Done well, it does the opposite. Manual processes depend on people remembering to check, sign and file. Automated promotion checks the same things every time and records the result. What changes is where the control lives: less in individual approvals, more in the pipeline, the gate rules and the people who control them.
The controls do not change
Auditors still ask the same questions as before: was the change authorized, tested, approved before production, were duties separated, and were urgent changes reviewed? Continuous delivery must answer each one, with evidence, for any sampled change. The answers just come from different places.
| Control | Manual release model | Train with automated gates |
|---|---|---|
| Authorized | Signed request form | Approved requirement linked to the feature in Cloud ALM |
| Tested | Test lead’s sign-off sheet | Gate results (ATC, ABAP Unit, regression) linked to the feature and release |
| Approved before production | Change board minutes | Ready for Production set by the Change Manager; release decision recorded |
| Segregation of duties | Different people sign forms | Developers cannot approve or deploy; pipeline and deploy users are separate and controlled |
| Urgent changes reviewed | Review meeting | Urgent features tagged, reviewed and recorded on the feature |
Segregation of duties in a pipeline
In a manual model, separation means the developer does not import into production. In a pipeline, it means more: the developer cannot change the gate rules, cannot approve their own feature, and cannot use the technical user that deploys to production. At Contoso, Kenji's developers can push commits and release transports; only Luis can set Ready for Production; only the pipeline's deployment user, owned by Sam and locked from interactive logon, can import into CMP; and changes to pipeline configuration go through a feature like any other change.
Approvals in an automated flow
Automation changes what a human approves. Instead of approving each transport, the Change Manager approves the train based on the gate summary and the exceptions. Low-risk changes that pass every gate can be treated as standard changes, pre-approved by the change board as a category, provided the gates are the documented control. Higher-risk changes still need named approvals. Write this down: which categories are pre-approved by passing gates, and which need a person.
| Change category | Promotion rule | Human approval |
|---|---|---|
| Configuration or code inside an existing extension, all gates green | Promoted with the train | Train-level approval by Luis |
| New integration or interface change | Promoted with the train after partner test | Feature-level approval by Luis and the process owner |
| Change to financial postings, pricing or tax | Promoted with the train after process owner sign-off | Dan or Maria, plus Luis |
| Change to gate rules or pipeline | Separate feature, reviewed by someone other than the author | Luis and Sam |
Which changes ride on gates and which still need a named approver.
Urgent changes and emergency access
Automation must not create a back door. If the only way to fix production at night is a developer with emergency access changing objects directly, every control above is undermined. Keep the urgent path inside the same flow: an urgent feature, a hotfix branch or transport, the commit-level gates (ATC and ABAP Unit run in minutes), a focused test, Luis's approval and deployment by the controlled user. Emergency access for direct production changes should be rare, time-limited, logged and reviewed by someone other than the user, and every use should become a finding in the next post-release review.
- IncidentPriority 1 incident in CMP; urgent feature created and tagged
- FixHotfix transport or branch; ATC and ABAP Unit gates run in minutes
- Focused testFix and surrounding process tested in CMQ
- ApproveLuis and the process owner approve on the feature
- Deploy and reviewControlled deployment user imports; review within five working days
Evidence retention
- Gate results are attached to or linked from the feature, not left only in CI server logs that expire.
- Commit IDs or transport numbers are recorded on the feature, so production state traces back to source.
- Pipeline configuration history is kept in Git, showing who changed which rule and when.
- Retention periods for logs match audit requirements; check what your CI server deletes by default.
What would you do?
An external auditor samples a pricing change that went to production automatically on the monthly train. There is no signature from a person on that specific transport. How should Luis respond?
- The audit questions stay the same; continuous delivery answers them from different evidence.
- Separate build, gate rules, deployment and approval; developers cannot change gates or deploy to production.
- Pre-approve low-risk categories that pass gates; keep named approvals for high-risk changes.
- Treat the pipeline as a privileged system and keep its evidence for the audit retention period.
Check your understanding · not graded
Lesson check
1. Automated promotion still requires which control in regulated environments?
2. Who should be able to change automated gate rules?
3. Why record commit IDs or transport numbers on the feature?