Lesson 4 of 5
Audit trail
10 min
Sooner or later someone asks: "Show me how this change got into production." It may be an internal auditor testing IT general controls, an external auditor, or Dan asking why a posting rule changed. The test of your change control is how quickly and completely you can answer.
What auditors usually test
IT general controls over change management usually come down to a few questions for a sample of production changes. Was the change authorized? Was it tested? Was it approved before it reached production? Were the people who developed it different from those who moved it? Were urgent changes reviewed afterwards? Your audit trail must answer each one for any change in the sample.
| Auditor question | Answer in Cloud ALM | Supporting record |
|---|---|---|
| Was it authorized? | Approved requirement linked to the feature | Requirement approval history |
| Was it tested? | Test runs linked to the feature, with results and evidence | Test execution records in the quality system |
| Was it approved before production? | Ready for Production set before the import date | Feature history (who, when) and import log date |
| Were duties separated? | Different users built, approved and imported | Transport owner, feature history, import user |
| Was the urgent change reviewed? | Review recorded on the urgent feature | Feature notes or linked task |
Assembling the trail for one change
- Start from the transportThe auditor gives a transport number from the CMP import log
- Find the featureFeature Traceability or the transport section shows the one feature it belongs to
- Read the historyFeature history: status changes, approver, timestamps
- Open the requirementApproval and business owner
- Open the test runsResults, testers, dates, evidence
- Compare datesApproval timestamp precedes production import
Because each transport belongs to only one feature, the path from a transport in production back to its approval is unambiguous. That is one of the most useful properties of the feature model; protect it by never importing transports into production outside Cloud ALM's deployment. If Basis imports a transport by hand, the history in Cloud ALM no longer matches the import log, and you have an audit finding to explain.
Keep the trail complete
- All production imports go through feature deployment, never directly in the managed system.
- Feature descriptions state what changed and why in plain language; screenshots are fine.
- Status changes are made by the person accountable, not by an administrator on their behalf.
- Open defects accepted at approval are recorded with the accepting process owner’s name.
- Exported feature lists (the Features app can export to a spreadsheet) are archived per release for long-term retention.
- Historic ChaRM records remain accessible until the retention period ends.
Test your own trail before the auditor does
Do not wait for the annual audit to find gaps. Once a month, Luis picks five production transports at random and walks each one back to its approval using the six steps above. Anything that takes more than ten minutes, or that needs someone's memory, becomes an action. Over a year this small habit turns the audit from an event into a formality.
What would you do?
An auditor finds a transport in CMP's import log that has no feature in Cloud ALM. Sam says he imported it by hand during a night incident. What is the right response?
- Audit questions: authorized, tested, approved before production, duties separated, urgent changes reviewed.
- Start from the transport, find its one feature, then read history, requirement and test runs.
- Approval timestamps must precede production import dates.
- Imports outside Cloud ALM break the trail; route urgent imports through features too.
Check your understanding · not graded
Lesson check
1. Why is the one-transport-one-feature rule valuable for audit?
2. Which comparison proves a change was approved before production?
3. What breaks the audit trail most directly?