SAP Access Risk Analysis

Authorization-level SoD and critical access detection: fast, portable, on-premise.

Access risk analysis evaluates SAP user permissions and authorization objects against a risk ruleset to detect segregation of duties (SoD) violations, critical access exposure, over-privileged users, and organizational scope breaches. It is a core SOX/ITGC control, and it is the capability MTC Skopos is built around: authorization-object depth, a full 10,000-user analysis in under 2 minutes, on-premise.

Most SAP access risk problems aren't "we don't know what to do." They're "we can't get answers fast enough to act on them." Enterprise GRC suites take hours to run an analysis, and by the time the report lands the role catalog has already moved. MTC Skopos was built to close that gap.

What is SAP Access Risk Analysis?

Access risk analysis (ARA) in SAP is the systematic evaluation of user permissions to identify access-related risks. It answers four questions:

  1. Who can violate segregation of duties? Which users hold combinations of authorizations that let them perform two conflicting business functions?
  2. Who has critical access? Which users can execute sensitive transactions (SU01, SE38, SCC4, SM59, debug, table maintenance) where a single action carries high risk?
  3. Who is over-privileged? Which users have access they never use, the privilege accumulation that creates audit exposure and license cost?
  4. Are organizational scopes respected? Are users acting outside their assigned company codes, plants, profit centers, or purchasing organizations?

A complete access risk analysis tool answers all four. A SoD-only tool answers only the first.

Authorization-Level vs Transaction-Level Analysis

ApproachWhat it checksCatches
Transaction-levelWhether a user can launch a transaction code (e.g., FB60)Coarse access
Authorization-levelThe full authorization object check (e.g., F_BKPF_BES with BUKRS, ACTVT)Real effective access

Transaction-level analysis is fast but noisy. A user who can launch FB60 may be locked out at object level for the company codes that actually matter, so the conflict was never real. Authorization-level analysis evaluates the actual SAP check logic, so the conflicts it surfaces are the ones a fraudster could exploit. MTC Skopos does this natively, which is why the result is a short list of real conflicts instead of a pile of false positives.

What MTC Skopos Detects

Segregation of Duties Violations

Users who can perform two or more incompatible business functions. Detection runs against your ruleset (or the included Skopos template ruleset with 350+ SoD risks, 700+ critical access checks, and 100+ authorization quality checks) and produces conflict lists at user, role, and risk level.

Critical Access Exposure

Users with access to sensitive single transactions where one action carries audit or fraud risk. Examples: user master maintenance, ABAP debug, RFC destination configuration, client copy.

Over-Privileged Users

Users holding authorizations they have never used. Comparing what each user can do against what they actually did separates theoretical risk from realized risk. Execution counts come from ST03N/STAD; did-do analysis reads the change documents in CDHDR/CDPOS to confirm whether the user changed data or merely opened the transaction.

Organizational Scope Violations

Cross-company-code, cross-plant, cross-profit-center, and cross-purchasing-org access where authorization values exceed the user's assigned organizational scope.

Did-Do Evidence

Which conflicts were actually executed vs which remain dormant. Critical for prioritizing remediation: a SoD pair capable of fraud is different from one active in fraud.

Conflicts Built Into Roles

Roles analysis ignores who holds a role and asks whether the role itself grants two conflicting functions. A conflict found there is a design defect that every new assignment reproduces, which is why fixing users while leaving the role untouched means doing the work again next quarter.

Read the access risk report deep dive →

Which accounts does the analysis cover?

Every user in the extract, people and technical accounts alike. The analysis runs on any SAP user type (Dialog, System, Communication, Service), so the same ruleset applies to the service, interface and RPA accounts that most programmes leave out, or to Dialog users only when technical accounts would drown the critical access findings. In the 2026 SoD survey, 38% of organisations excluded non-human accounts without compensating controls or had never assessed them (survey findings).

How do you prove what an analysis covered?

Every run writes an Ed25519-signed execution log next to its reports. It records the criteria, the user types and systems in scope, a checksum of the ruleset version used, and a checksum and row count for every table analyzed. A report without that log is a spreadsheet; with it, an auditor can verify that the result was produced by MTC Skopos, from those exact tables, with that exact ruleset, and has not been edited since. The same record makes progress measurable. Up to ten analyses can be compared side by side: each conflict is marked new, resolved, persisting or intermittent, and the comparison warns when the ruleset was edited between runs or the scope differs, so a drop in conflicts cannot come from a quietly narrowed analysis.

Why Specialized Access Risk Analysis Beats GRC Suites for Detection

Enterprise GRC suites (SAP GRC Access Control, Pathlock) bundle access risk analysis with provisioning, firefighter management, and access request workflows. If you need those workflow capabilities, a specialized tool will not replace them.

For detection specifically, specialized access risk analysis tools have real structural advantages:

  • Speed. A typical 2,500-user system analyzes in under 10 seconds* and a full 10,000-user run completes in under 2 minutes on a standard laptop, against hours for a GRC suite batch run. Iterative remediation becomes practical.
  • Depth. Authorization-object-level analysis is the default, not an upgrade.
  • Portability. Desktop deployment means consultants, auditors, and security teams can analyze any SAP system without provisioning a GRC server.

* Benchmark: 150+ high and critical SoD risks in scope.

For access risk detectionMTC SkoposEnterprise GRC suiteSpreadsheet / manual
Analysis depthAuthorization-object levelAuthorization-object levelTransaction level at best
Time per full runUnder 2 min for 10,000 usersHoursDays
DeploymentPortable desktop, no serverGRC server or cloud projectNone, but does not scale
Did-do evidenceBuilt inAdd-on or limitedManual
Best fitFast detection, ruleset dev, auditsProvisioning and workflowOne-off checks

Many organizations run both: Skopos for fast detection, ruleset development, and S/4HANA migration prep, and SAP GRC for production provisioning. The Skopos ruleset converts to SAP GRC format, so the work is not duplicated. See Planning SAP GRC or Pathlock? Start With MTC Skopos for the full integration playbook.

Access Risk Analysis Workflow with MTC Skopos

  1. Export SAP authorization data. Standard tables: USR02, AGR_USERS, AGR_1251, AGR_1252, AGR_AGRS, AGR_DEFINE, and UST04/UST12 where profiles are assigned directly. Plus transaction-usage statistics (ST03N/STAD) and the change documents (CDHDR/CDPOS) that did-do analysis relies on. The export takes 5 to 10 minutes manually, or 1 to 5 minutes via RFC.
  2. Load into Skopos. No server, no agent, no upload. The desktop application reads the export directly.
  3. Run analysis. A 10,000-user environment is scanned in under 2 minutes against your ruleset; a single-user check returns in under a second.
  4. Review findings. SoD conflicts, critical access, over-privilege, scope violations, and did-do evidence in one consolidated view. The Overview dashboard gives the executive summary of the run: total conflicts against users in scope (your conflicts-per-user ratio), mitigated against unmitigated conflicts by control type, risks ranked by the number of times they are triggered, users ranked by conflict count, and a drill-down from a risk into the actions behind it, before any export.
  5. Remediate. The Advanced Remediation engine generates concrete steps (remove role X from user Y, split role Z, reassign users), prioritized by least disruption.
  6. Export to BI. CSV, JSON, Parquet outputs feed Power BI, Tableau, or any reporting layer for ongoing monitoring.

Beyond SAP: Multi-ERP Access Risk Analysis

Modern landscapes are rarely single-ERP. Cross-application access risk (a user who creates a vendor in SAP and approves the payment in Oracle) is invisible to single-system tools. MTC Skopos supports SAP access risk analysis natively, including S/4HANA Public Cloud tenants on their IAM app and restriction model, and extends to Oracle, Microsoft Dynamics, NetSuite, Odoo, and custom systems through generic data-source connectors. You define the ruleset once and run a single analysis across all of them; cross-system rules are an optional add-on module. The multi-ERP SoD analysis page covers the full setup.

Pricing

Transparent flat-rate licensing: €5,736/year base + €555 per additional seat (EUR). No per-user fees, no per-system fees, no per-transaction charges. The price does not scale with the size of your SAP landscape.

Get Started

See your real SAP access risk landscape in under an hour. Export your authorization data, run Skopos against it, and review the findings. No installation, no commitment.

Try MTC Skopos for Access Risk Analysis

Authorization-level SoD and critical access detection. 10,000 users in under 2 minutes. Runs on your laptop.

Start Free Trial Compare All Tools

Frequently Asked Questions

What is access risk analysis in SAP?

Access risk analysis (ARA) is the process of evaluating SAP user permissions, role assignments, and authorization objects against a risk ruleset to identify segregation of duties (SoD) conflicts, critical access exposure, over-privileged users, and organizational scope violations. It is the foundation of access governance and a core SOX/ITGC control. Tools like SAP GRC Access Control, Pathlock, and MTC Skopos automate ARA at scale.

What is the difference between access risk analysis and SoD analysis?

SoD analysis is a subset of access risk analysis. SoD analysis focuses specifically on detecting toxic combinations where one user can perform two conflicting business functions (e.g., create vendor + approve payment). Access risk analysis is broader: it adds critical access detection (sensitive single transactions like SU01, SE38), over-privilege detection, organizational scope violations, and did-do execution evidence.

What is the best access risk analysis tool for SAP?

The best SAP access risk analysis tool depends on whether you need provisioning workflows. SAP GRC Access Control is the enterprise incumbent with built-in provisioning. Pathlock covers multiple ERPs from the cloud. MTC Skopos is the fastest specialized analyzer: authorization-object-level depth, a full 10,000-user analysis in under 2 minutes, a 1,150+ check template ruleset included, on-premise deployment, and transparent flat pricing from €5,736/year.

How does authorization-level access risk analysis differ from transaction-level?

Transaction-level analysis only checks which SAP transaction codes (SE38, FB60, etc.) a user can launch. Authorization-level analysis goes deeper: it evaluates the full authorization object check (e.g., M_BEST_EKO with EKORG values, F_BKPF_BES with BUKRS values), so it catches risks that transaction-level analysis misses, like a user who has FB60 but only for a specific company code. MTC Skopos performs authorization-level analysis natively.

Can I run SAP access risk analysis without installing a server?

Yes. MTC Skopos runs as a portable desktop application: no server, no agent in your SAP system, no cloud upload. Export your authorization tables (USR02, AGR_USERS, AGR_1251, AGR_1252, AGR_AGRS, AGR_DEFINE) and run the analysis locally. Same-day operational, useful for consultants and auditors working across multiple client environments.

How often should I run access risk analysis?

Monthly at minimum for privileged and technical accounts, and quarterly for the full user base to match most SOX and audit cycles. Run it again after every role catalog change, S/4HANA migration step, onboarding wave or reorganisation. Many programmes analyze far less often: in the 2026 SoD survey, 37% review their ruleset only annually and 19% never do. When a full run takes minutes rather than a batch window, the cadence is set by the business, not by the tool.