SAP GRC explained: governance, risk, compliance
SAP GRC (Governance, Risk and Compliance) is the SAP area that decides who may do what, scores the access combinations that are dangerous together, and produces the evidence a company shows its auditors. It is a product family — Access Control, Process Control, Risk Management, Audit Management — running on its own system and reaching connected SAP systems through plug-ins.
The products behind the acronym
- Access Control
- What most people mean by GRC. Access Risk Analysis (ARA) scores users and roles against a segregation-of-duties ruleset, Access Request Management (ARM) routes requests through that check, Business Role Management (BRM) keeps role definitions under change control, Emergency Access Management (EAM) issues firefighter IDs against a logged reason.
- Process Control
- The control catalogue: controls with named owners, test campaigns, and monitoring that queries the system instead of asking a person.
- Risk Management
- The risk register — assessments, responses, indicators — facing the board rather than the auditor.
- Audit Management
- Internal audit's own workspace: audit plan, working papers, findings tracked to closure.
Hybrid landscapes add Cloud Identity Access Governance for access the on-premise system cannot see.
The ruleset, and what tuning it means
The ruleset is the list of risks the system scores against: combinations of access that are dangerous held together, written as the transactions and authorization objects behind each one. SAP delivers one; nobody runs it as delivered.
Tuning it is a workshop with process owners: which delivered risks apply here, which are noise against this process design, and what mitigating control covers a risk that has to stay because nobody can split the duty.
The project shape decides what you inherit: a greenfield tunes the delivered ruleset while the process design is still moving, a conversion arrives with a violation backlog nobody cleared, a rollout re-scores it against new organisational levels.
How does a violation get closed?
A violation closes in one of three ways: remediate the role so the combination disappears, mitigate it with a named control somebody tests on a schedule, or accept it in writing with an owner against it.
The first full risk analysis returns a list nobody wants, and the weeks after are triage — rarely a technical argument, mostly about who gives up access and who signs for the risk instead. Alongside it runs the build: connectors, approval paths (MSMP) and the rules that route them (BRF+), firefighter IDs with controllers named before emergency access works.
Cutover wants a clean baseline report and the sign-off pack the auditor asks for. After go-live the backlog becomes a cycle of firefighter log reviews, access review campaigns and control testing — support work paced by the audit calendar rather than the release plan.
Who crosses in, and what proves you have done it
- From security — the shortest crossing: security and authorizations builds the roles GRC judges, and role knowledge makes a ruleset argument credible.
- From audit and internal control — controls and findings are already your vocabulary; what is new is that a control must be configured as something the system tests itself, and a finding closes in a workflow, not a report.
- From Basis — the GRC system and the plug-ins in every connected system already belong to Basis; operating them teaches the application from underneath.
- From a functional area — an FI or MM consultant can propose the mitigating control, not just judge the risk.
What gets you hired is named work: a ruleset you tuned rather than accepted, a remediation campaign you drove to sign-off, an audit where you handed over the evidence. Interviews probe there: remediation versus mitigation, and who owns a mitigating control (what interviews test).
Every risk is written in another area's vocabulary
FI supplies the classic pair — whoever maintains a vendor must not also run the payment; MM adds the ordering and goods-receipt half; MDG governs who may create that master data. Regulated industry solutions raise the stakes, where the specialism clusters (which combinations work).
Related reading
- The SAP security and authorizations consultant
Roles, profiles, segregation of duties and audits — the specialism projects remember too late.
- SAP FI explained: finance in SAP
General ledger, payables, receivables, assets and the close — the books of record.
- SAP Master Data Governance (MDG) explained
One truth for materials, partners and finance data — and its careers.
- SAP area combinations that work well together
The process-adjacent pairs, cross-cutting seconds and techno-functional bridges the market rewards.
Work with SAP?
Join to get your public SAP profile. Your city appears on the map once 5 professionals are mapped there.