Segregation of duties is normally treated as a risk-and-controls question owned by internal audit and the GRC team. The licensing dimension is overlooked. When SAP measures the buyer environment, the same user roles that internal audit is flagging for SoD risk are the roles that drive named-user classification: a user with both vendor-create authority and invoice-post authority is not just an SoD finding, that user is being measured into a higher-tier named-user category. The two views are looking at the same authorisations from different ends. Monitoring SoD against the license model is the practice of looking at both ends at once.
Why SoD and licensing are the same data
The SAP user master, the role assignments, and the transaction-code histories drive both the SoD analysis and the named-user classification. The GRC suite runs a ruleset that looks for risk combinations: create-and-approve, post-and-pay, master-data-and-transaction. The USMM and engine-measurement runs look for classification triggers: the transactions that lift a user from a Limited Professional bucket to a Professional bucket. The underlying tables are the same. The two analyses just read different columns out of them.
The recurring failure mode in SAP estates is that the two analyses are siloed. The GRC team mitigates SoD findings by adding compensating controls or by accepting risk — both of which leave the underlying authorisation in place. The SAM team measures the named-user classification afterwards and inherits the cost of the authorisation. The buyer pays for the risk twice: once as audit-cycle remediation work and once as elevated licensing cost. A short discussion of the recurring patterns appears in our role mapping for license compliance article.
The three-axis monitoring view
The monitoring posture that closes both gaps reads SoD, risk-acceptance, and named-user classification on the same dashboard. The three axes are aligned by user, by role, and by transaction.
Axis one: SoD finding
The first axis is the GRC ruleset output. Every user with a finding is identified and the finding category is recorded. The output is the standard GRC report, structured by risk level.
Axis two: license-classification trigger
The second axis is the named-user-classification trigger map. For each transaction code or authorisation object that lifts a user’s classification, the affected users are identified. The trigger map is built from SAP’s named-user matrix and the named-user classification guide we publish.
Axis three: business justification
The third axis is the business-side justification for the authorisation. Why does this user have this combination? Is the justification still active? Has the role-holder changed jobs? The third axis is what allows the buyer to move from monitoring to action.
How the three axes compose
The three axes compose into four user populations. Users with no SoD finding and no classification trigger are below the line: no action needed. Users with an SoD finding but no classification trigger are inside the GRC remediation workstream as normal. Users with a classification trigger but no SoD finding are inside the licensing optimisation workstream — possibly recategorisable into a lower bucket once the authorisation is reviewed. Users with both an SoD finding and a classification trigger are the population where the same remediation closes two problems at once. The fourth population is small and high-value. Across our engagements we have seen the fourth population deliver the largest per-user savings when addressed correctly.
The monitoring cadence
The monitoring view runs monthly. The cadence is not arbitrary. SAP’s USMM runs are normally annual, but the named-user composition shifts continuously as users join, change roles, leave, and acquire new authorisations through ad-hoc requests. A monthly snapshot allows the SAM team to catch composition drift before it becomes the audit baseline. A quarterly cadence is too coarse; a weekly cadence is too noisy. Monthly is the cadence we recommend across all our compliance-assessment engagements.
The monthly output is a short report that captures composition, the four populations described above, and the trend lines for each. The trend lines are what management acts on. A growing population of high-tier classifications in a stable headcount is the early warning signal that role drift is accelerating.
What the GRC team and the SAM team share
The monitoring posture requires the GRC and SAM teams to share a small set of artefacts. The shared artefacts are: the named-user classification rule map, the SoD ruleset (versioned and dated), the user master extract, and the role assignment table. The artefacts are refreshed monthly and stored in a single repository accessible to both teams.
The shared repository is not a new system. It is a folder structure with version control and a known ownership for each artefact. The buyers that build the repository as a system inflate the cost of monitoring without changing the outcome. The artefacts are simple. The discipline is what matters.
What the monitoring view changes in an audit
When SAP’s audit team reaches the named-user-classification section, the buyer that runs the three-axis view has a defensive baseline. Every classification is supported by the role assignment, the business justification, and the SoD posture. The audit team can dispute classifications, but it cannot dispute the methodology, because the methodology is the same one their own measurement runs against. The dispute reduces to specific user cases rather than the whole classification scheme.
Buyers without the monitoring view typically lose the methodology argument and reduce on user-by-user case work, which is more expensive both in elapsed time and in settlement value. The insurer reclassification case file documents an engagement where the three-axis view shifted nineteen per cent of a user population to a lower bucket inside the audit window. The companion named-user buckets article covers the underlying bucket structure.
What does not work
Two recurring approaches we see and recommend against. The first is the “classification audit” run only at the SAM end — without the SoD axis, the SAM team does not see the structural reasons for the higher-tier classifications and the reductions are smaller and less durable. The second is the “GRC remediation as licensing” run only at the GRC end — without the classification trigger map, the GRC team does not see which remediations also reduce the licensing tier, and the durable savings are missed.
Neither team can do this alone. The monitoring view is the artefact that makes the joint work explicit and the savings durable. The SAP ECC topic page covers the related authorisation-model considerations in classical ECC estates; the patterns transfer broadly to S/4HANA.
What to look for in the first run
On the first run of the three-axis view, three signals tell the SAM team where the largest wins are. A growing high-tier population in a stable headcount indicates role drift. A high overlap between the GRC remediation backlog and the high-tier population indicates dual-savings remediations. A large gap between the classification headline and the active-use evidence indicates inactive users in high-tier slots — the population that the dormant-user purge article addresses directly.
SoD and licensing are looking at the same authorisation data from different ends. The monitoring posture that reads both ends is what turns one remediation effort into two outcomes.
If you are running an SoD remediation programme without the licensing axis, the most efficient next step is a single-period overlay: take the most recent GRC findings, lay the classification triggers over them, and look at the overlap. We work alongside in-house GRC and SAM teams to build the overlay and to act on it. The first conversation is at no cost.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.