Contact us
  1. Home
  2. Modules
  3. SAP GRC

SAP GRC: who can do what in SAP, and the proof

SAP GRC is how companies decide who may do what in SAP, catch the combinations of access that could hide fraud, and prove all of it to their auditors. This guide shows SAP Access Control the way the authorizations team sees it: the rule set, the firefighter logs, the background jobs behind every clean report, and the settings that quietly change what that report shows.

  • SAP Access Control 12.0
  • SAP GRC for SAP HANA
  • SAP Cloud IAG
  • GRAC_EAM

By · Updated

What SAP GRC is

Not one product: a family

GRC stands for governance, risk and compliance: who sets the rules, what could go wrong, and the evidence that the rules were followed. SAP sells it as a set of solutions. Most SAP users only ever meet one of them, SAP Access Control, because it sits between them and their authorizations. That one is the focus of this page.

Access governance

  • SAP Access Control 12.0

    This page

    Finds segregation-of-duties and critical-access risks across SAP and non-SAP systems. Also runs access requests, access reviews and emergency access.

  • SAP Cloud Identity Access Governance

    The cloud service: access analysis, role design, access request, access certification and privileged access management.

  • SAP Cloud Identity Services

    Identity Authentication, Identity Provisioning, Identity Directory and Authorization Management. SAP calls it the center of its identity strategy.

  • SAP Identity Management 8.0

    Ending

    On-premise identity lifecycle. Mainstream maintenance ends on 31 December 2027, with no successor release.

Risk, controls and audit

  • SAP Process Control 12.0

    Internal control management, with automated and continuous control monitoring.

  • SAP Risk Management 12.0

    Enterprise risk management: identify, assess, analyze and monitor risks.

  • SAP Audit Management

    Automates internal audit work. Sold with Process Control and Risk Management as SAP’s solutions for the three lines of defense.

Fraud and trade

  • SAP Business Integrity Screening

    Formerly SAP Fraud Management. Flags unusual transactions and screens business partners against sanctions lists.

  • SAP Global Trade Services, edition for SAP HANA

    Trade compliance and customs. Maintenance for the older GTS 11.0 ended on 31 December 2025.

Insider facts

Twelve things almost nobody outside the authorizations team knows

Each one has decided an audit somewhere. Most are a single parameter, job or log that nobody looked at until the day it mattered.

The rule set

Anatomy of an access risk

Every finding in a risk report climbs down the same six levels, from the rule set to a single authorization value. Pick a level to see what it holds, using one risk as the example all the way down.

Level 1 of 6

Rule set

Holds every risk the analysis checks. SAP delivers rule content as BC sets, activated in SCPR20, for SAP S/4HANA, SAP ERP, SAP CRM and the SAP HANA database. Treat it as a starting point: tailor it to your processes and keep your own risks in the Z namespace, so a new BC set can be imported without overwriting them.

In the example

The company’s rule set, copied from SAP’s S/4HANA content and tailored.

  • SCPR20
  • BC sets
  • Z namespace

Level 2 of 6

Business process

Procure to pay, record to report, order to cash. Business processes group risks and functions for reporting, and give the workflows something to route on, such as the owner of that process.

In the example

Procure to pay.

  • Procure to pay
  • Record to report

Level 3 of 6

Access risk

A segregation-of-duties risk combines two or more functions. A critical action or critical permission risk has a single function that is dangerous on its own. Each risk has a level and an owner. After changing risks or functions, generate the rules, or the analysis keeps using the old ones.

In the example

Create a vendor and pay it: segregation of duties.

  • Segregation of duties
  • Critical action
  • Critical permission
  • GRAC_GENERATE_RULES

Level 4 of 6

Function

A task as the business sees it. A function lists the actions and permissions that let a user perform it, and an analysis scope: single system, or cross system when the two halves of a risk can sit in different systems.

In the example

Maintain vendor master, and Run payments.

  • Single system
  • Cross system

Level 5 of 6

Action

A transaction code, a Web Dynpro application, an SAP Fiori app or an OData service. In the rule set, SAP Fiori apps carry the prefix [FAPP], OData services [SVC] and Web Dynpro applications [WDY].

In the example

BP for vendors on SAP S/4HANA; F110 for the payment run.

  • BP
  • F110
  • [FAPP]
  • [SVC]
  • [WDY]

Level 6 of 6

Permission

An authorization object with its field values, taken from the SU24 proposals. Permission-level analysis checks that the user really holds the values that make the action work, which removes many false positives. Parameter 1023 sets the default report type.

In the example

B_BUPA_RLT with a vendor role category; F_REGU_BUK for payments by company code.

  • B_BUPA_RLT
  • F_REGU_BUK
  • SU24
  • 1023

Four things that change the result without touching a risk

  • Organizational rules

    Remove false positives caused by org levels, such as one person paying in company code A and creating vendors only in B. Create them only for the functions that need them: they slow the analysis.

    Company code

  • Supplementary rules

    Include or leave out users by their attributes, such as user type or user group, read from tables like USR02. Switched on with parameter 1037.

    1037

  • Critical roles and profiles

    Defined apart from the rule set, for objects like SAP_ALL. Parameter 1031 decides whether they are ignored in the analysis.

    1031

  • Mitigating controls

    A documented compensating control, with an owner, an approver and a monitor. The risk stays in the report, shown as mitigated, until the assignment expires.

    Mitigated users

Try it

Give one person these tasks. What could go wrong?

This is what a segregation-of-duties check does, in plain words. Switch business tasks on and off, or load a typical profile, and watch the conflicts appear.

Business tasks

No conflicts

Clean

No pair in this selection lets one person start and finish a sensitive process alone. In a real system, check the critical actions too: some tasks are risky on their own.

  • Create a vendor and pay itMaintain vendor masterRun paymentsOne person could invent a supplier and send it money. Auditors rank vendor master plus payments among the most critical pairs in purchase to pay.Typical mitigating control: review of every new or changed vendor that was paid in the period.
  • Create a vendor and invoice itMaintain vendor masterPost vendor invoicesA fictitious supplier gets a real invoice in the books, ready for the next payment run.Typical mitigating control: review of invoices posted to vendors created in the last 90 days.
  • Change bank details and payChange vendor bank detailsRun paymentsA real supplier’s bank account is swapped for another just before the payment run. SAP’s dual control on sensitive vendor fields can hold the payment until a different user confirms the change.Typical mitigating control: dual control on bank fields, confirmed by someone outside payables.
  • Enter an invoice and pay itPost vendor invoicesRun paymentsAn invoice that should be questioned is booked and paid by the same person, with nobody else seeing it.Typical mitigating control: approval of the payment proposal by a second person before the run.
  • Order goods and confirm receiptCreate purchase ordersPost goods receiptsA purchase can be confirmed as received without anyone checking that the goods arrived. Three-way match then pays it.Typical mitigating control: warehouse sign-off on goods receipts above a value threshold.
  • Create a vendor and order from itMaintain vendor masterCreate purchase ordersPurchases can be steered to a supplier set up by the same person.Typical mitigating control: review of purchase orders placed with newly created vendors.
  • Create a G/L account and post to itMaintain G/L accountsPost journal entriesA new account can hide postings that nobody expects to look at. SAP’s rule content describes it as maintaining a fictitious G/L account and hiding activity through postings.Typical mitigating control: monthly review of new G/L accounts and their balances.
  • Reopen a period and post to itOpen and close periodsPost journal entriesResults that were already closed and reported can change afterwards.Typical mitigating control: review of postings made in closed periods, and of every OB52 change.

Segregation of duties

These are examples of the kind of risks a rule set holds, written in plain words. In SAP Access Control each one is an access risk between two functions, and each function lists the transactions, SAP Fiori apps and authorization values that grant it. Your company’s rule set will name, group and rate them its own way. The fix is always one of two: remove one of the tasks (remediation) or keep both and document a compensating control (mitigation).

SAP Access Control

The five tools inside SAP Access Control

One product, five jobs. Each tab says what the tool does, who works in it, and the detail people usually learn the hard way.

ARA

Access Risk Analysis

Who could do what they should not.

Checks users, roles, profiles and HR objects against the rule set. Run it ad hoc, simulate a change before it is made, see which risks are mitigated, and follow the trend on dashboards fed by the batch risk analysis.

Who works in it: The security team, risk owners and auditors.

Where:
  • NWBC
  • SAP Fiori launchpad
  • GRAC_BATCH_RISK_ANALYSIS

The detail people miss

There are two kinds of results. Ad hoc analysis and access requests read the live data. Dashboards and offline reports read the last batch run. When the two disagree, check when the batch ran.

ARM

Access Request Management

Asking for access, with the risk check built in.

Users request new or changed access; the request runs through the MSMP workflow to managers and role owners. Approvers see the conflicts on a risk violations tab and can mitigate there. Once approved, the access is provisioned to the target system automatically.

Who works in it: Everyone who needs access, their managers and the role owners.

Where:
  • Access Request
  • Work Inbox
  • SAP_GRAC_ACCESS_REQUEST

The detail people miss

Parameter 1071 decides whether risk analysis runs when the request is submitted, and 1072 whether critical risks must be mitigated before anyone can approve. Two lines of configuration change what every approver sees.

EAM

Emergency Access Management

More access for a few hours, with evidence.

Gives temporary elevated access through firefighter IDs or firefighter roles. The owner decides who may use each ID; the controller reviews the log of every session.

Who works in it: Support teams, firefighter owners and controllers.

Where:
  • GRAC_EAM
  • /GRCPI/GRIA_EAM
  • Consolidated Log Report

The detail people miss

Parameter 4000 sets one model for the whole landscape: ID-based or role-based, never both. The same person can never be firefighter and controller for the same ID.

BRM

Business Role Management

Roles built with a method, not by habit.

A standard path for creating and changing roles: definition, authorization maintenance, risk analysis, approval, generation and test cases. Date-driven role reaffirmation and certification keep roles in check after they go live.

Who works in it: Role designers and role owners.

Where:
  • NWBC
  • SAP_GRAC_ROLE_APPR
  • PFCG

The detail people miss

Risk analysis runs on the role before it reaches production. Fixing a conflict there costs one role change; after go-live, every user of the role needs a fix or a mitigation.

UAR

User Access Review and SoD Review

Once a year, someone confirms it is still right.

Workflow-driven reviews: managers or role owners confirm or remove each user’s access, while coordinators follow progress. The SoD review asks managers or risk owners to confirm or remediate each conflict.

Who works in it: Managers, role owners, risk owners and review coordinators.

Where:
  • GRAC_UAR_REQUEST_GEN
  • Request Review
  • Manage Coordinators

The detail people miss

The SoD review works from the batch risk analysis results, so an old batch run means an old review. Parameter 2008 caps the line items per review request, from 1 to 9,999.

Emergency access

A firefighter session, start to finish

Production is down at 2 a.m. and someone needs more access than their roles allow. Emergency Access Management gives it for a few hours and keeps the evidence. Follow the six steps.

Step 1 of 6 · Owner

Assign

The firefighter owner assigns a firefighter ID to a person, with validity dates. In role-based firefighting the person receives firefighter roles instead. Parameter 4000 sets which model the landscape uses, and parameter 4010 names the role that marks a user as a firefighter ID.

  • 4000
  • 4010
  • SAP_GRAC_SPM_FFID

Step 2 of 6 · Firefighter

Log on

The firefighter opens the launch pad, picks the ID, a reason code and writes what they will do. Central firefighting uses GRAC_EAM in the GRC system. Decentralized firefighting uses /GRCPI/GRIA_EAM on the target system and keeps working if GRC is down.

  • GRAC_EAM
  • /GRCPI/GRIA_EAM
  • 4015

Step 3 of 6 · Target system

Work

Everything happens in the target system, under the firefighter ID. GRC does not watch the screen. It relies on what that system records: statistics, change documents, the system log, the Security Audit Log and OS commands.

  • STAD
  • CDHDR/CDPOS
  • SM20
  • SM21
  • SM49

Step 4 of 6 · Background job

Collect

GRAC_SPM_LOG_SYNC_UPDATE pulls the logs into GRC. Teams run it from every 10 minutes to every hour. Workload statistics keep about 48 hours by default; if the job falls behind, GRAC_EAM_LOG_SYNC_TIMEBASED can recover only what still exists on the target.

  • GRAC_SPM_LOG_SYNC_UPDATE
  • GRAC_EAM_LOG_SYNC_TIMEBASED

Step 5 of 6 · Background job

Notify

GRAC_SPM_WORKFLOW_SYNC starts the log review workflow and its notifications. The controller can be reached by e-mail, by workflow item, or only through the log display.

  • GRAC_SPM_WORKFLOW_SYNC
  • SAP_GRAC_FIREFIGHT_LOG_REPORT

Step 6 of 6 · Controller

Review

The controller reviews and signs off each session. A BRFplus decision table can set the review due date by criticality. Auditors expect evidence of review for every session; a missing review control is a classic audit finding.

  • GRAC_BRFP_SPM_SLA
  • BRFPLUS

The five logs behind the report

GRC can only collect what the target system recorded.

  • STADTransactions executed, from the workload statistics
  • CDHDR/CDPOSChange documents: what data changed, old and new values
  • SM21System log, which records debugging with replace
  • SM20Security Audit Log
  • SM49Operating system commands

Not in the report: table logging (SCU3).

Before you trust the log

  • The Security Audit Log is active on the target (rsau/enable = 1, set up in SM19 or RSAU_CONFIG).
  • The RFC user that GRC uses can read the workload statistics.
  • GRC and the target system run in the same time zone.
  • Firefighter IDs cannot log on directly with SAP GUI (SAP Note 1545511).
  • The log collection job runs well inside the statistics retention window.

ID-based firefighting

  • The person logs on as a separate firefighter ID, a service user.
  • Logs show the firefighter ID, linked to the person who used it.
  • One person at a time per ID; a reason code for every session.

Role-based firefighting

  • The person keeps their own user ID.
  • Firefighter roles are flagged for firefighting in Business Role Management.
  • Logs show the person’s own user.

For consultants

The consultant toolbox

The background jobs, parameters, workflow steps and transactions that decide whether SAP Access Control tells the truth. Names as in SAP Access Control 12.0.

TransactionProgramWhat it doesIf it stops
GRAC_AUTH_SYNCGRAC_PFCG_AUTHORIZATION_SYNCBrings authorization data from the target systems, including SU24 changes.Permission-level analysis uses old values.
GRAC_REP_OBJ_SYNCGRAC_REPOSITORY_OBJECT_SYNCBrings users, roles and profiles into GRC. A full sync reads everything; an incremental one, the changes since the last run.New users and roles are invisible to the analysis.
GRAC_USER_SYNCGRAC_ROLEREP_USER_SYNCSynchronizes users only.User data in reports is out of date.
GRAC_ACT_USAGE_SYNCGRAC_ACTION_USAGE_SYNCCollects which transactions and apps each user ran.Usage that has aged out of the target statistics cannot be collected.
GRAC_ROLE_USAGE_SYNCGRAC_ROLE_USAGE_SYNCWorks out which single roles are used. Run it after action usage.Role clean-up decisions rest on wrong data.
GRAC_BATCH_RAGRAC_BATCH_RISK_ANALYSISOffline risk results for reports, dashboards and the SoD review.Reports show an old picture.
GRAC_ALERT_GENERATEGRAC_ALERT_GENERATIONAlerts when conflicting or critical actions are executed, and when control monitors miss their tasks.Executed conflicts raise no alert.
GRAC_SPM_LOG_SYNCGRAC_SPM_LOG_SYNC_UPDATECollects the firefighter logs.Sessions without logs, and data lost on the target.
GRAC_SPM_WF_SYNCGRAC_SPM_WORKFLOW_SYNCStarts the firefighter log review workflow and notifications.Controllers never receive the logs.
—GRAC_UAR_REQUEST_GENGenerates the user access review requests.The review never starts.
SPROGRAC_GENERATE_RULESGenerates the rules after risks or functions change.The analysis keeps using the old rules.

SAP does not publish one official order. A sequence many teams use: authorization sync, repository sync, action usage, role usage, then batch risk analysis. Action usage goes before role usage.

IDParameterWhy it matters
1023Default report type for risk analysisAction level or permission level. Permission level removes many false positives.
1027Enable offline risk analysisLets reports and dashboards read the batch results.
1028Include expired usersIf not, expired users never show a conflict.
1029Include locked usersIf not, locked users never show a conflict until someone unlocks them.
1031Ignore critical roles and profilesYes removes every critical role and profile, such as SAP_ALL, from the analysis.
1037Supplementary rulesSwitches on the rules that include or exclude users by attribute.
1038Consider firefighter assignments in risk analysisWhether access a user can reach through firefighter assignments counts in the analysis.
1071Enable risk analysis on form submissionRuns the check the moment a request is submitted.
1072Mitigation of critical risk required before approvingApprovers cannot approve a critical conflict until it is mitigated.
1073Enable SoD violations detour on risks from existing rolesRoutes requests to a detour path when the conflict comes from roles the user already has.
2008Number of line items per UAR requestSplits large reviews into requests of 1 to 9,999 lines.
2019SoD review admin stageAdds an administrator stage to the SoD review.
4000Application typeID-based or role-based firefighting, one only.
4007Send log report execution notification immediatelyControllers hear about a session as soon as its log is collected.
4010Firefighter ID role nameThe role that marks a user as a firefighter ID.
4015Enable decentralized firefightingAllows firefighting from the target system through /GRCPI/GRIA_EAM.
4020Notification for sessions with no activityDecides whether empty sessions produce notifications, which tend to raise auditor questions.

Where: SPRO › Governance, Risk and Compliance › Access Control › Maintain Configuration Settings. The target systems have their own plug-in settings, under Governance, Risk and Compliance (Plug-In).

The seven configuration steps

Multi-Stage Multi-Path (MSMP) is the workflow engine behind every request, review and log approval. Transaction GRFNMW_CONFIGURE_WD.

  1. 1Process global settings
  2. 2Maintain rules
  3. 3Maintain agents
  4. 4Variables and templates
  5. 5Maintain paths
  6. 6Maintain route mapping
  7. 7Generate versions

Nothing goes live before step 7. Generate Versions saves and activates every change; until then the old workflow keeps running.

Three kinds of rules

  • Initiator rule: One per process. It picks the path a new request starts on.
  • Agent rules: Who approves at each stage, from PFCG roles, user groups, named users or BRFplus logic.
  • Routing rules: Detour a request mid-way, for example to a risk owner when a conflict appears.

The process IDs

  • SAP_GRAC_ACCESS_REQUEST
  • SAP_GRAC_ROLE_APPR
  • SAP_GRAC_FIREFIGHT_LOG_REPORT
  • SAP_GRAC_USER_ACCESS_REVIEW
  • SAP_GRAC_SOD_RISK_REVIEW
  • SAP_GRAC_CONTROL_ASGN
  • SAP_GRAC_CONTROL_MAINT
  • SAP_GRAC_FUNC_APPR
  • SAP_GRAC_RISK_APPR
  • SAP_GRAC_FFID_REVIEW

SAP knowledge base article 2618928 lists them. When a request goes to the wrong approver, GRFNMW_DBGMONITOR_WD shows how it was routed.

Transaction or reportUse it to
GRAC_EAMOpen the central firefighter launch pad (also GRAC_SPM).
/GRCPI/GRIA_EAMOpen the decentralized launch pad on the target system.
NWBCOpen SAP Business Client with the full GRC menu.
GRFNMW_CONFIGURE_WDConfigure MSMP workflows.
GRFNMW_DEV_RULESGenerate the BRFplus rules that MSMP uses.
GRFNMW_GEN_VERSIONGenerate workflow versions outside the configuration screen.
GRFNMW_DBGMONITOR_WDSee how a request was routed, stage by stage.
BRFPLUSMaintain agent, initiator, routing and SLA rules.
SCPR20Activate SAP-delivered BC sets, such as rule content and MSMP content.
SU24Maintain authorization proposals, the source of the permissions in functions.
STAUTHTRACETrace authorization checks on all application servers, filtered by user.
SU53Show the last failed authorization check. Only the last one.
RSAU_CONFIGSet up the Security Audit Log that feeds the firefighter log.
GRAC_RULE_CONVERT_TO_EXTOBJMove rule data to the extended tables for case-sensitive SAP Fiori app IDs.

SAP S/4HANA and SAP Fiori

What changes for access risk on SAP S/4HANA

A rule set written for transaction codes misses part of an SAP S/4HANA system. Users now reach the same data through SAP Fiori apps, OData services and the Business Partner transaction.

  • 01

    SAP Fiori apps are actions too

    Access Risk Analysis covers SAP Fiori apps and OData services from Access Control 12.0 SP03 (10.1 SP22). In the rule set, apps carry the prefix [FAPP] and OData services [SVC].

    • [FAPP]
    • [SVC]
    • KBA 2876899
  • 02

    An app holds no authorizations

    A SAP Fiori app has no permissions of its own: they sit on its OData service. Run the authorization sync on SAP S/4HANA for the services and on the front-end server for the apps. A separate front-end server is a subsequent connector of the SAP S/4HANA connector.

    • S_SERVICE
    • USOBHASH
  • 03

    App IDs are case-sensitive

    Rules for apps and services are stored in extended tables such as GRACFUNCACTEXT. Report GRAC_RULE_CONVERT_TO_EXTOBJ moves existing rule data there.

    • GRACFUNCACTEXT
    • Note 2805767
  • 04

    BP replaced the vendor transactions

    XK01, XD01 and their siblings redirect to BP in dialog but still run in batch input. Inside BP, vendor and customer access is split by role category and field group, so the rules must look at permissions, not just the transaction.

    • B_BUPA_RLT
    • B_BUPA_FDG
    • FLVN00
  • 05

    An ECC rule set misses risks

    A rule set carried over from SAP ERP lacks the new SAP S/4HANA transactions and every SAP Fiori app. SAP delivers separate rule content for SAP S/4HANA as a BC set.

    • GRAC_RA_RULESET_S4HANA_ALL
  • 06

    Blank app fields hide risks

    On Access Control 12.0 with SAP S/4HANA 2023, functions with empty app or service fields can suppress risks (KBA 3748662). Check functions after loading new rule content.

    • KBA 3748662

Roles, profiles and the authorization checks behind every function are explained on PFCG. Shortcuts and launchpad tools are on SAP Fiori.

Tips by role

Where do you sit?

Everyone touches SAP GRC from a different side. Pick yours.

  • 01

    Ask for the role, not the transaction

    Request the business role your team uses. Single transactions are harder to approve and often bring conflicts the role was designed to avoid.

  • 02

    Write a justification someone can approve

    Say which task, for how long, and why your current roles are not enough. Approvers reject vague requests first.

  • 03

    Ask for an end date

    If you need access for a project or a month-end, ask for a validity end date. For a one-off emergency, ask for firefighter access instead.

  • 04

    Run SU53 straight after the error

    It shows only the last failed authorization check. Send a screenshot taken before you click anything else.

  • 05

    A conflict is not an accusation

    It means two of your tasks should be split or watched. Your manager can propose a mitigating control.

  • 01

    You approve the risk, not just the access

    Open the risk violations tab before approving. A conflict you approve becomes yours to explain to the auditors.

  • 02

    Mitigate only with a real control

    A mitigating control needs an owner and a monitor who actually does the check. Without one it is a signature, not a control.

  • 03

    Prefer an end date

    Time-limited access and time-limited mitigation expire on their own, so nobody has to remember to remove them.

  • 04

    Your system may force mitigation first

    With parameter 1072 on, critical risks must be mitigated before you can approve. That is a setting, not a system error.

  • 05

    Reject with a reason

    The requester sees it. A clear reason saves a second request with the same problem.

  • 01

    Emergencies only

    SAP describes Emergency Access Management as tracking users for emergency tasks. Routine support work belongs in normal roles.

  • 02

    One session, one task

    Write the reason and activity in plain words. The controller reads them next to every transaction you ran.

  • 03

    Everything is logged

    Transactions, changed fields with old and new values, debugging with replace and OS commands all reach the controller.

  • 04

    Log off when done

    An abandoned session stays open on your name. A background job can force logout, but the log still shows the idle time.

  • 05

    Never share the ID

    ID-based firefighting allows one person per ID at a time, so the log can say who did it.

  • 01

    Sync before you analyze

    Authorization, repository, action usage and role usage syncs first, then batch risk analysis. Otherwise you analyze yesterday.

  • 02

    Generate twice

    Rules after rule set changes (GRAC_GENERATE_RULES), versions after workflow changes (Generate Versions). Both fail silently.

  • 03

    Keep your risks in Z

    Custom risks and functions in the Z namespace survive a new import of SAP’s BC sets.

  • 04

    Trace with STAUTHTRACE

    It covers every application server and filters by user. ST01 works only on the server where the transaction runs.

  • 05

    Prove the firefighter log is complete

    Security Audit Log active, RFC user allowed to read statistics, same time zone, log job inside the retention window.

  • 01

    Ask for parameters 1031, 1028 and 1029

    Before trusting a clean report, check that critical profiles, expired users and locked users are not left out.

  • 02

    Ask when the batch ran

    Offline reports show the last batch risk analysis. A clean report from a stale batch proves little.

  • 03

    Evidence per session

    Every firefighter session should have a review on file. A 2018 audit of a public transit operator found a firefighter process with no review control.

  • 04

    Test direct logon

    Check that firefighter IDs cannot log on directly with SAP GUI, outside the launch pad (SAP Note 1545511).

  • 05

    Read the mitigations

    Look for expired assignments, controls without monitors and monitors who never ran a check.

History and roadmap

From a Silicon Valley start-up to SAP GRC for SAP HANA

The names inside SAP Access Control still carry the history. Old hands say “Firefighter” because that was the product’s name before SAP bought it.

  1. 1996Fremont, CaliforniaJasvir Gill founds Virsa Systems.
  2. 2005MarchSAP starts reselling Virsa Compliance Calibrator.
  3. 2006AprilSAP announces it is buying Virsa. Compliance Calibrator, Access Enforcer, Role Expert and Firefighter become RAR, CUP, ERM and SPM.
  4. 5.3The last Java releaseOn SAP NetWeaver AS Java 7.0. Maintenance ended on 31 December 2015.
  5. 2011Release 10.0Access Control is rewritten in ABAP. The components get the names used today: ARA, ARM, BRM and EAM. Release 10.1 follows.
  6. 2018Release 12.0Access Control 12.0, on SAP NetWeaver 7.52.
  7. 2024FebruarySAP names Microsoft Entra ID as the path for SAP Identity Management customers.
  8. 20266 MarchSAP GRC for SAP HANA, the successor of Access Control, Process Control and Risk Management 12.0, is released to customers.
  9. 202731 DecemberMainstream maintenance ends for the 12.0 solutions and for SAP Identity Management 8.0. Extended maintenance runs to 2030.

Maintenance, at a glance

Planning a move?

SAP GRC for SAP HANA replaces Access Control, Process Control and Risk Management 12.0 in one release. It runs only on SAP HANA, so customers on another database face a migration, not a support-package upgrade. Check the Product Availability Matrix and SAP Note 3326989 for the current dates.

Myths

Six things people get wrong about SAP GRC

  • MythA mitigated risk is a solved risk.

    FactMitigation documents a compensating control and keeps the risk in the report. Only remediation, removing one side of the conflict, solves it.

  • MythA clean risk report means nobody has critical access.

    FactCheck parameters 1031, 1028 and 1029 and the date of the last batch risk analysis. Each can make real access disappear from the report.

  • MythSAP’s delivered rule set is ready to use.

    FactIt is a starting point. It needs your processes, your custom transactions and your SAP Fiori apps, and your own risks in the Z namespace.

  • MythFirefighter is a faster way to get support done.

    FactIt is for emergencies. Routine work through firefighter IDs floods controllers with logs and auditors with questions.

  • MythGRC records what the firefighter did.

    FactGRC collects what the target system recorded. Without the Security Audit Log, or with statistics deleted before collection, parts of the session are missing.

  • MythXK01 is gone in SAP S/4HANA, so the old vendor risks are gone.

    FactBP took over in dialog, but the old transactions still run in batch input, and BP itself needs permission-level rules to separate vendors from customers.

Frequently asked questions

What is SAP GRC?

SAP GRC is SAP’s family of governance, risk and compliance solutions. The best known is SAP Access Control, which finds segregation-of-duties and critical-access risks, runs access requests and reviews, and controls emergency access. The family also includes SAP Process Control, SAP Risk Management, SAP Audit Management, SAP Business Integrity Screening and SAP Global Trade Services. SAP Cloud Identity Access Governance is the cloud service for access governance.

What is segregation of duties (SoD)?

Splitting a sensitive process so that no single person can start and finish it alone, such as creating a vendor and paying it. The 1992 COSO internal control framework lists segregation of functions as a control activity. The Sarbanes-Oxley Act of 2002 does not use the term, but its Section 404 requires companies to test internal controls, which put SoD on every SAP audit plan.

What is a firefighter ID?

A user with broad access, kept for emergencies. In ID-based firefighting a person borrows the firefighter ID for a session through Emergency Access Management, gives a reason code, and every transaction, change and audit log entry of that session goes to a controller for review. In role-based firefighting the person keeps their own user and receives firefighter roles for the session.

When does SAP Access Control 12.0 maintenance end, and what replaces it?

Mainstream maintenance for SAP Access Control, Process Control and Risk Management 12.0 ends on 31 December 2027, with extended maintenance to 2030. The successor, SAP GRC for SAP HANA, was released to customers on 6 March 2026. It runs only on SAP HANA, on premise or in a private cloud. SAP’s 2025 planning named SAP S/4HANA 2025 or SAP S/4HANA Foundation 2025 as the platform. Check the Product Availability Matrix for the current status before planning.

What is the difference between SAP Access Control and SAP Cloud Identity Access Governance?

SAP Access Control is installed software. SAP Cloud Identity Access Governance (IAG) is a cloud service with access analysis, role design, access request, access certification and privileged access management. SAP calls IAG its strategic solution for access governance in the cloud. In the bridge scenario, Access Control keeps the requests and risk checks while IAG provisions to cloud applications; one Access Control system connects to one IAG.

SAP Identity Management ends in 2027. What does that mean for GRC?

Mainstream maintenance for SAP Identity Management 8.0 ends on 31 December 2027, with paid extended maintenance to 2030, and there is no successor release. SAP and Microsoft point customers to Microsoft Entra ID, working with SAP Cloud Identity Services. Landscapes where SAP IdM and Access Control share the user lifecycle need a new design; Microsoft’s documentation says its integration with Access Control is still evolving.

Why does a user with SAP_ALL look clean in the risk report?

Usually because parameter 1031, Ignore Critical Roles and Profiles, is set to Yes and SAP_ALL is maintained as a critical profile. Then it drops out of the analysis. Also check whether the report reads offline data from an old batch risk analysis, and whether locked or expired users are excluded (parameters 1028 and 1029).

References

Checked in October 2026. SAP Notes and knowledge base articles need an SAP for Me login.