Lesson 5 of 5
Documentation
9 min
Listen to this lesson
Every role change is a change to the control environment. External auditors testing Contoso's IT general controls will pick a sample of role changes from the year and ask three questions: who asked for it, who approved it, and how do you know it worked and did not grant too much? If the answers live only in someone's inbox, the change is a finding even when it was correct.
What to record for each fix
| Record | Example from Ana's invoice defect | Why auditors care |
|---|---|---|
| Symptom and reproduction | Posting supplier invoice for 1710 refused, CMQ client 100, test case AP-014 step 5 | Shows a real need, not a speculative grant |
| Diagnosis evidence | SU53 output: F_BKPF_BUK, activity 01, company code 1710 missing | Links the change to a specific check |
| Design reference | AP clerk role design allows posting for 1710 | Shows the change matches approved intent |
| Change made | Activity 01 added to F_BKPF_BUK in the AP master role, transport CMDK9xxxxx | Makes the change traceable to the system |
| Approval | Role owner (Dan's delegate) approved in the change record | Proves authorization of the change itself |
| Risk check | Risk analysis on the changed role: no new SoD conflicts | Shows the fix did not create a conflict |
| Test evidence | Positive retest passed; negative test for 1810 still refused | Proves it works and is not too wide |
Seven items per authorization fix. Most fit in a defect record and a change record that reference each other.
- DefectTester logs the failure with SU53 or trace evidence in SAP Cloud ALM.
- DiagnosisSecurity confirms the gap and the design reference.
- ApprovalThe role owner approves the change.
- Build and transportRole changed in CMD, risk-checked, transported to CMQ.
- RetestPositive and negative tests with the role-based user.
- CloseDefect closed with links to the transport and test results.
Where the evidence comes from
The system keeps part of the story itself. Role changes create change documents, and the User Information System can display changes to roles and to users' authorization profiles. Transports record who released what and when. What the system does not know is the why and the who approved, and that is what the defect and change records must add. On Contoso's program, test defects live in SAP Cloud ALM, and changes to production follow the program's change process; after go-live, the same discipline applies under the operations change process.
Emergency fixes in production
Sometimes a user is blocked in production and the business cannot wait for the normal cycle. The emergency path may be faster, but it is not lighter: the same evidence is needed, just collected afterwards within an agreed time. Common practice is to grant elevated access for a defined task through the emergency access process, which logs every action, rather than changing a production role in a hurry. The role fix then follows the normal path.
- Hour 0User blockedTicket with SU53 captured by the service desk.
- Hour 1Emergency access, if justifiedLogged, time-boxed access for the blocked task, approved by the owner.
- Day 1–3Normal role fixDesign check, approval, CMD change, risk check, test in CMQ.
- Day 3–5ReviewThe emergency session log is reviewed; the defect record is completed.
What would you do?
During an internal audit walkthrough, the auditor picks a role change from Contoso's cycle 3: activity 01 added to the AP master role. The transport and change documents exist, but there is no record of who approved it or any test. Nadia remembers Dan approving it in a meeting. What is the best response?
- Auditors ask who requested, who approved, and how you know it worked and did not over-grant.
- Record symptom, diagnosis evidence, design reference, change and transport, approval, risk check and tests.
- Change documents and transports show what changed; defect and change records add why and who approved.
- Emergency fixes collect the same evidence, afterwards and within an agreed time.
Check your understanding · not graded
Lesson check
1. Which piece of evidence shows that a role fix did not widen access too far?
2. What can the system's change documents and transport records not tell an auditor?
3. In an urgent production block, what is usually safer than widening a production role on the spot?
4. Why does a design reference belong in the record of an authorization fix?