Glossary — SAP GRC Security & Fiori Terms Explained, TIB Systems

Start here

The Absolute Basics

If you only read five definitions on this page, read these. Everything else on this site assumes you know what these five mean.

SAP

The world's most widely used enterprise software. When people in this industry say "SAP," they usually mean the system a company runs its finance, HR, and supply chain through — one system, instead of a dozen disconnected ones.

ERP Enterprise Resource Planning

The category of software SAP belongs to. One shared database running the parts of a business that used to live in separate spreadsheets and separate departments.

GRC Governance, Risk & Compliance

The discipline of making sure a company actually runs the way it says it runs — the right people have the right access, changes get approved before they go live, and the numbers can be trusted. Also the name of SAP's own GRC platform (see below) — and this course's focus is the access half of that platform.

Segregation of Duties SoD

The rule that no one person should be able to both create and approve the same transaction — create a vendor and pay that vendor, for example. An "SoD conflict" is when one person's access lets them do both, and most of what this course trains you to catch.

Access Risk

The exposure created by what a user's access actually allows them to do — independent of whether they'd ever misuse it. Managing access risk means keeping that exposure mapped, current, and small enough to explain.

Access & security

Access & Security Terms

The vocabulary of the lab — what you're building, what you found, and how it gets fixed.

Ruleset

The set of rules a GRC system uses to define which access combinations count as an SoD conflict. A ruleset only catches what its function definitions are actually watching for — which is exactly what Book 1 is built around.

Function / Risk ID

The building blocks of a ruleset: a function is a group of related transactions or Fiori apps, and a risk pairs two functions that shouldn't both be assigned to the same person.

Mitigating Control

A compensating review assigned when an SoD conflict can't be removed by changing access — typically a periodic management review. Assigning one in the system is the start of an operating control, not the end of the finding.

Role

A named bundle of authorizations assigned to a user in PFCG. Splitting a role along the wrong boundary — transaction codes instead of authorization objects — is a common way a "fix" quietly recreates the risk it was meant to close.

Authorization Object

The actual technical unit of access control inside SAP — finer-grained than a transaction code. Two roles can split a transaction list cleanly and still share (or both lose) an authorization object neither role owner notices.

Firefighter ID Emergency Access

Temporary, logged, elevated access granted for emergencies — meant to be individually assigned, time-boxed, and reviewed afterward. Shared use and un-evidenced review are the two most common ways this control quietly stops working.

Population

Every user, role, or access combination that fits a specific test's criteria — the full set you'd sample from, not just the ones you happen to notice first.

Lab Conclusion

The written record of a test: what you tested, what you found, and your reasoning. What you write in your own words before ever seeing the model answer — and what this course grades you on.

Planning Card

TIB's own tool for slowing you down before you touch SAP: state the risk, the control objective, the population, and the evidence plan first. The habit the whole course is built around.

Reference User

A shortcut in the Access Request form that copies an existing user's roles onto a new request. Convenient, and only as safe as the reference user's own current access — which nothing checks by default.

Provisioning

The process of granting a user the access their job requires, whether built role-by-role or copied from a reference user. Where access drift most often gets introduced, not just discovered.

Reasonable Assurance

The standard controls are actually held to — not perfect, not zero risk, but a level of confidence a reasonable person would find credible. Controls manage risk; they don't eliminate it.

Inside the system

SAP System Terms

The words that describe the system itself — what version, what screen, what path a change takes to go live.

S/4HANA

SAP's current-generation ERP, built on its in-memory HANA database. The direction almost every large SAP customer is migrating toward — and the live system you'll get access to in this course.

ECC ERP Central Component

SAP's previous-generation ERP. Still running inside many companies that are mid-migration to S/4HANA — you'll likely encounter both in your career.

Fiori

SAP's modern web and mobile interface, layered on top of S/4HANA. It introduces its own authorization objects that don't exist in the classic screens — a common blind spot in access testing.

T-code Transaction Code

The short code typed into SAP to open a specific screen or function — PFCG for role maintenance, for example. SAP's version of a keyboard shortcut.

Transport

The mechanism SAP uses to move a change from a development environment into production, through a controlled, approved path — rather than someone editing the live system directly.

DEV / QAS / PRD

The three-environment path most SAP changes travel: Development, Quality Assurance (testing), and Production (live). Every hands-on build in this course happens in a dedicated training role or ruleset — never a live production object.

Basis

The technical infrastructure layer of SAP — and the team responsible for keeping the system running, patched, backed up, and available.

Display-only Access

Read access with no ability to change anything. The standard way to explore a live SAP system without risking a real change — used for investigation steps in this course, before you move into your own practice namespace to build the fix.

SU24

The table (and transaction) that defines a transaction's default authorization-object proposal for PFCG. Left unmaintained on a custom transaction, every role builder afterward guesses independently — the failure pattern Book 6 is built around.

MSMP Multi-Step Multi-Process

The workflow engine behind GRC Access Control's approval routing. Its agent-determination and escalation rules decide what happens when an approver doesn't respond — sometimes escalating to a person, sometimes quietly auto-approving instead.

Fiori Launchpad, Catalog & Space

The layers that control what a user sees (Launchpad), which tiles are grouped together (Catalog), and which catalogs a role gets (Space). Tile visibility is cosmetic — the backend authorization comes from the role tied to the space regardless of what's shown.

Who's involved

Roles & Stakeholders

The people and teams that make access risk a real job with real stakeholders, not just an internal exercise.

Basis Team

The technical infrastructure team responsible for keeping SAP running, patched, and available — and the team that owns transports, release schedules, and often the pushback when a fix touches production timing.

Business Process Owner

The person accountable for a specific business process (accounts payable, procurement) whose team's access a role change actually affects. The one who should test a role split before go-live, not just after something breaks.

Control Owner

The person accountable for actually performing a mitigating control's review — not just the name attached to it in the system. A mitigation with no engaged control owner is a finding waiting to be found.

Big 4

The four largest global audit and advisory firms — Deloitte, EY, KPMG, and PwC. Firms that hire heavily for both SOX/ITGC and GRC/Security specialists, often onto the same engagements.

Internal Audit

The team inside a company that tests its own controls year-round, including access controls — often the first place an SAP-fluent GRC/Security specialist gets hired.

External Audit

The independent audit firm hired to opine on whether a company's financial statements and controls — including the access controls behind them — can be trusted.

The platform itself

GRC Platform Terms

"GRC" also refers to a specific set of SAP modules — this is what each one actually does.

SAP GRC Access Control

The SAP module that manages who has access to what, screens for Segregation of Duties conflicts, and handles Firefighter access requests.

SAP GRC Emergency Access Management EAM

The part of GRC Access Control that manages Firefighter ID assignment and log review — individual assignment and evidenced review are the two things that make it a real control rather than a rubber stamp.

IAG Identity Access Governance

SAP's cloud-based evolution of GRC Access Control, built for companies running a mix of on-premise and cloud systems.

BRF+ Business Rule Framework plus

SAP's rules engine, often used behind MSMP to decide workflow routing — including the agent-determination and escalation logic that can quietly turn a timeout into an auto-approval if nobody checks it.

Access Risk Analysis

The GRC function that scans a user's assigned access for Segregation of Duties conflicts, before or after that access is granted.

Quick reference

Common T-Codes You'll See in This Course

You don't need to memorize these before you start — they're introduced as you meet them. This is just a place to look one up.

T-Code	What it opens
GRAC_SPM	Access Risk Analysis and Firefighter/EAM — the core GRC Access Control workbench
PFCG	Role maintenance — where SAP roles and authorizations are built and assigned
SUIM	User information system — the audit trail for who has what access
SU01	User maintenance — creating, changing, and locking user accounts
SU24	Authorization default maintenance — the proposal PFCG pulls from when you add a transaction to a role
SU25	SU24 upgrade/initialization tool — used when bringing default proposals current after a system change
SE01 / STMS	Transport organizer and transport management — tracking and approving a change as it moves DEV → QAS → PRD
/UI2/FLPD_CUST	Fiori Launchpad Designer — where catalogs, tiles, and spaces are configured
SWI1	Workflow log — tracing an MSMP approval or escalation, who acted and when
SM21 / SM20	System log and security audit log — the record of what happened on the system itself