What actually reached production, and who said it could.
Auditing SAP change management means answering four questions for every change. Was it requested? Was it approved by someone eligible? Does what was deployed match what was approved? And did it touch anything financially relevant? Most audit approaches check documents. The reliable approach correlates systems, because the documents are written by the people being audited.
The evidence triangle.
Three independent record systems describe every SAP change. The transport log shows what objects actually moved into production, when, and released by whom. The ticketing system, whether Jira, ServiceNow or ChaRM, shows what was requested and approved. The version control and deployment trail, including the deployment logs on your servers, shows what the developer actually built and shipped. Each of these can be massaged individually. Their intersection is where truth lives. An audit that reads only the ticket audits the paperwork. An audit that correlates all three audits the change.
The four findings that recur everywhere.
- Scope creep. The transport contains more objects than the ticket approved. The extra objects are where the interesting changes hide.
- Self-dealing. The developer requested, approved or released their own change. Segregation of duties applies to the change process, not just to postings.
- Eligibility drift. The approval is formally present, but the approver gained approval rights days before, on an expedited request. Check the change history of the approver list itself.
- Orphan changes. Production changes with no ticket at all, typically via emergency procedures whose promised retrospective documentation never arrived.
Financial relevance is a property, not a guess.
Not every transport matters to the financial statements. Whether one does is determinable: which objects does it touch, do those objects sit in posting, valuation or reporting paths, and which company codes are affected. Categorising changes by financial impact lets a lean audit function spend its attention where misstatement risk actually lives, and gives the external auditor a defensible scoping rationale.
Doing this continuously.
The correlation described here is mechanical. Match transport IDs, ticket references, commit metadata and approver lists. Flag the four patterns. Attribute every data point to its source system. Mechanical means automatable, which is how RiskForge runs it: continuously, across SAP, Jira, ServiceNow, SAP GRC and server deployment logs, with every verdict carrying its sources. The method stands on its own, though. Even performed quarterly by hand, correlating the triangle beats reading tickets.
See RiskForge on your own processes.
A 30-minute walkthrough against realistic SAP scenarios: payment runs, journal entries, transports. No slides, just the actual product.