Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 6 of 6

Role regression after changes and upgrades

7 min

Listen to this lesson

0:00 / 8:35

Roles are not built once. They change when the business reorganizes, when a new plant like Chicago 1720 opens, when a Fiori app replaces a transaction, and when SAP delivers an upgrade or feature pack that adds authorization checks or new apps. Every one of those changes can break a role that worked last month. Role regression is the repeatable set of positive and negative tests you run to prove nothing broke.

Triggers for role regression

  • Role changes: a new transaction or app added, an org value changed, a composite role restructured.
  • Assignment changes: users gain or lose roles in a reorganization.
  • SAP upgrades and feature packs: new or changed authorization checks, new default values for apps, replaced or deprecated apps and transactions.
  • New content: business catalogs and launchpad content that change which tiles appear.
  • Custom development: new custom apps or programs that add their own checks.

What happens to roles in an upgrade

SAP maintains default authorization values for transactions and services (the proposals that security can adjust in SU24). After an upgrade, security runs the role adjustment steps in SU25, which compare SAP's new defaults with the customer's adjusted values and list roles that need regeneration. Some checks are added automatically, and some need manual decisions. Transactions that SAP S/4HANA replaced or removed must be mapped to their successors. Any of these steps can add access nobody intended, or drop access a user needs.

  1. Upgrade sandboxAdjustSecurity runs role adjustment and records decisions in a transport
  2. DevelopmentRegenerateRoles regenerated; changed and new apps mapped to roles
  3. QASRole regressionPositive and negative pack per business role with production-like test users
  4. QASRisk analysisAccess risk analysis rerun on changed roles
  5. Pre-go-liveSign-offResults and remaining defects reviewed by security and process owners
Role regression in an upgrade timeline.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-207

Building a role regression pack

Take the role-to-process matrix and choose, per business role, a small set of tests that would detect most breakages: one or two positive tests for the role's core job, the org-level negative, and the top SoD negatives. For Contoso that might be 4–6 tests per role, across roughly 30 roles, which is a manageable pack that can run every release. Because the tests are stable and repetitive, they are good candidates for automation with test users and fixed data.

Store each test's expected outcome with it: "saved, document number returned" for a positive test, "refused with an authorization message" for a negative one. A negative test that suddenly passes, meaning the action succeeds, is the most important result in the pack, because it means a role now grants something it should not. Make sure your reporting highlights it rather than burying it as a green tick in the wrong column.

Positive test refusedRole defect: the user cannot do their job. Fix the missing object or org value.
Positive test succeededPass: saved with a document number returned.
Negative test refusedPass: the denial is the expected result. Keep the evidence.
Negative test succeededMost important finding: the role now grants something it should not. Report it first.
Reading role regression results: a negative test that succeeds is the result to escalate, not a green tick.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-207
RoleRegression testsType
Sales clerk (1710)Create and save a standard order; try to create an order in another sales org; try to change a credit limitPositive, org negative, SoD negative
Buyer (Chicago)Create and save a PO for plant 1720; try plant 1710; try a goods receiptPositive, org negative, SoD negative
AP clerk (1710)Post a supplier invoice; try to change supplier bank details; try to release a payment proposal if not in the matrixPositive, SoD negative, sensitive-action negative

Extract of Contoso's role regression pack.

  1. Is it an SAP upgrade or feature pack?Yes → full regression pack for every business role, then rerun access risk analysis · No → next question
  2. Is it a change to a single role?Yes → pack for that role, every composite containing it and every role sharing a changed org value · No → next question
  3. Is it an assignment change?Yes → test the new user combinations and rerun SoD analysis on them · No → next question
  4. Is it new launchpad content or a custom app?Yes → visibility tests plus positive and direct-start negative tests for the new function · No → no role regression needed
Scoping role regression to what actually changed.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-207

What would you do?

Security adds the new Manage Purchase Requisitions app to Contoso's buyer role and transports it to QAS. What regression testing is appropriate?

Key points
  • Role changes, assignment changes, upgrades, new content and custom development all trigger role regression.
  • Upgrades require role adjustment (SU24 proposals, SU25 steps), which can add or drop access.
  • A regression pack has a few positive and negative tests per business role and suits automation.
  • Scope by what changed, and rerun access risk analysis on changed roles.

Check your understanding · not graded

Lesson check

  1. 1. Which transaction does security use for role adjustment steps after an upgrade?

  2. 2. Which is a typical set of regression tests for one business role?

  3. 3. A single role changes. What should the regression scope include?

  4. 4. Why are role regression tests good candidates for automation?