Lesson 5 of 5
Evidence and retest
10 min
Role tests are among the few tests that auditors routinely ask to see, often years after go-live. They want to know that access was designed deliberately, tested before use, and kept under control as it changed. This lesson covers the record that answers those questions, and the triggers for retesting.
What auditors look for
A role test record
| Field | Example |
|---|---|
| Role and version | Contoso billing clerk role; transport released on the role change date |
| System and client | QAS, client 100 |
| Test user | BILL-TEST-01, holding only this role plus the baseline role |
| Test ID and type | NEG-BIL-02, negative, org restriction |
| Steps and expected result | Attempt to bill a delivery from another sales organization; expected: not selectable |
| Actual result and evidence | Delivery not offered; screen capture of the empty selection with filter values; trace extract if needed |
| Tester, date, status | Maria; date; passed |
| Defects | None, or defect ID and retest result |
Fields of a role test record.
For negative tests, the evidence is the refusal: the authorization message, the missing action, the filtered list, or a trace showing the failed check. Capture it with the user ID visible where possible, so it is clear the test user (and not a broader user) saw it. For positive tests, the business document numbers prove the task was completed.
When to retest
- Did a role change (apps, catalogs, authorizations or org values)?Yes → rerun that role's positive and negative tests and its SoD tests · No → next question
- Was a user given an additional role?Yes → rerun the SoD analysis and SoD tests for that combination · No → next question
- Was there an SAP upgrade, feature pack or catalog update?Yes → rerun positive tests for key tasks and negative tests for high-risk actions · No → next question
- Did the organization change (new plant, sales organization, company code)?Yes → rerun org-restriction tests with the new values · No → periodic review only
Upgrades deserve special attention. SAP can deliver new apps, change business catalogs and adjust the authorizations an app checks. In Public Edition, SAP updates delivered content with each release, and administrators review the effect on business roles; in private cloud and on-premise, the security team adjusts roles when SAP content changes during an upgrade project. Either way, an upgrade can quietly add access to a catalog you already granted, or remove an authorization a task needs.
Emergency access deserves a word too. Many companies give support staff temporary, elevated access for incidents, with every action logged and reviewed afterwards. If your company uses such a process, test it like a control: request access, perform an allowed action, and confirm the log and the review reach the right owner.
Building a reusable role regression pack
- Keep the positive and negative tests per role as scenarios in the regression library, with their test users.
- Keep test users alive in the quality system, with exactly their target roles, and review them after each refresh.
- Tag tests by risk: SoD and financial posting tests run every time; low-risk display tests on a sample basis.
- Record the role version each run used, so results can be matched to changes.
- Go-liveBaselineFull positive, negative and SoD tests; approved by process owners
- Each role changeTargeted retestAffected role's tests plus SoD for combinations
- Each upgradeRegressionKey tasks and high-risk negatives for all roles
- PeriodicallyAccess reviewManagers confirm users still need their roles
What would you do?
After an upgrade, the security team reports that SAP added new apps to a business catalog used by Contoso's AP accountant role. Grace asks if any testing is needed, since "we didn't change the role". What is the best answer?
- Auditors want design, build, test, approval and ongoing control, with evidence.
- Record role version, test user, test type, expected and actual result, tester, date.
- Negative evidence is the refusal itself, captured with the test user visible.
- Retest after role changes, new role combinations, upgrades and org changes.
- Keep role tests and test users as a regression pack.
Check your understanding · not graded
Lesson check
1. Which evidence best proves a negative test passed?
2. A user receives an extra role. What must be rerun?
3. Why record the role version used in each test run?
4. Why can an upgrade change a role's access without anyone editing the role?