🔐 What is Segregation of Duties?
Segregation of Duties (SoD) in SAP is a security concept that ensures no single user has full control over an entire business process. In simple language — SoD means that no one person should be able to start a risky process AND finish it all by themselves with no checks in between. If creating a vendor and paying that vendor both need to happen, two different people should be responsible for each step. That way, one person cannot do both secretly and no fraud or mistake can happen without at least one other person being involved.
The One-Line Definition: Segregation of Duties means splitting risky tasks between different people so that no single person can commit fraud or make a serious error without someone else being involved. In SAP, this means making sure the same user ID cannot both create a vendor AND approve payments to that vendor — or both enter an invoice AND release the payment block on it.
The Four Key Concepts Behind SoD
🏛️ Governance
Governance means having clear rules about who is allowed to do what in your business. In SAP, this means deciding which roles exist, who gets which transactions, and who is responsible for approving new access. Good governance means these decisions are written down and followed consistently — not decided informally based on who asks.
⚠️ Risk
Risk is the chance that something goes wrong — a fraud, a mistake, or a compliance failure. In SAP, risk means identifying the combinations of access that, if given to one person, could enable them to do something harmful. A user who can both create vendors and pay vendors is a HIGH RISK combination.
📋 Compliance
Compliance means following the rules — your own internal policies, your country's tax laws, stock exchange regulations, and international standards like SOX (Sarbanes-Oxley Act) for companies listed on US exchanges. SoD is often a legal requirement, not just a good idea.
✂️ Separation
Separation is the practical action — making sure that two conflicting tasks are never assigned to the same person. In a well-designed SAP system, the person who creates a vendor cannot also approve payment to that vendor. The person who enters a purchase order cannot also approve it. Separation is how you make SoD real.
🏭 Why SAP Systems Need Segregation of Duties
SAP is a very powerful system. A well-trained user with the right access can do incredible things — post financial documents, create purchase orders, run payment programs, and maintain master data for thousands of vendors and customers. That power is exactly why SoD matters so much in SAP. The same power that makes SAP useful also makes a poorly-controlled SAP system dangerous. One person with too much access can cause enormous damage — either through deliberate fraud or through honest mistakes.
Think about what SAP controls in a typical Indian manufacturing company. It manages the entire procure-to-pay cycle — from deciding what to buy, to choosing which vendor to buy from, to paying that vendor. It manages the order-to-cash cycle — from receiving a customer order, to shipping goods, to collecting payment. It manages the financial books — journal entries, account balances, financial statements. Every single one of these processes has steps that should be done by different people, with appropriate checks at each stage. Without SoD, one person can short-circuit the entire process.
| Business Area | The Risk Without SoD | Who Gets Hurt | Real World Impact |
|---|---|---|---|
| Accounts Payable | Same person creates vendor AND approves payments — can create fake vendors and pay them | The company | Fictitious vendor fraud. One person controls the entire payment cycle with no second check. |
| Purchasing | Same person creates purchase order AND goods receipt — can approve receipt of goods that never arrived | The company | Overpayment to suppliers for phantom deliveries. Collusion between buyer and vendor. |
| Accounts Receivable | Same person creates customer AND posts credit notes — can reduce customer outstanding balance without approval | The company | Salesperson gives unauthorized discounts to preferred customers, reducing company revenue. |
| General Ledger | Same person posts journal entries AND approves them — can hide transactions or manipulate balances | Shareholders and tax authorities | Financial statements can be falsified. Tax evasion risk. SOX violation for listed companies. |
| User Administration | Same person creates SAP users AND assigns roles — can create ghost users with broad access | The company | Ghost user accounts used for unauthorized transactions. Access given to former employees. |
| Master Data | Same person creates AND changes bank details for vendors — can redirect payments to wrong accounts | The company | Bank detail fraud — attacker changes vendor bank details, legitimate payments diverted to wrong account. |
SoD is Not Just About Fraud: Many people think SoD is only about preventing deliberate fraud. But it is equally important for preventing honest mistakes. When two different people are involved in a transaction — one who enters it and one who approves it — there is a natural double-check. The approver might notice something the enterer missed. SoD creates quality control as a side effect of the security control. Both benefits are real and both are valuable.
⚙️ How SoD Works Inside SAP — Roles, Authorisations, and Access
In SAP, access is controlled through a system of roles. A role is like a job description for the SAP system — it contains a list of transactions a person is allowed to run, and the specific parameters they can use within those transactions. For example, a role called Z_FI_AP_INVOICE might contain transactions MIRO (post vendor invoice), MIR4 (display invoice), and FBL1N (vendor line item report). A user assigned this role can do all three of these things but nothing else.
Segregation of Duties works by making sure that two conflicting roles are never assigned to the same user at the same time. The conflict is defined by your company's risk rules — which combinations of transactions are dangerous if one person has both. SAP GRC is the tool that automates this check. Every time someone requests a new role in SAP, GRC scans the user's existing roles and checks whether adding the new role would create a known SoD conflict.
The Role Hierarchy — From Authorisation Object to User Assignment
How SAP Builds Access — Four Levels from Object to User
Think of an authorisation object as a single, very specific permission. For example: "This user can post to Financial Accounting documents in company code 1000 with document type SA." Each object has fields — company code, document type, posting key — and the exact values those fields are allowed to have. When a user tries to run any transaction, SAP silently checks in the background whether they have the right authorisation object with the right field values. If not, the transaction is blocked immediately with a red authorisation error. Most users never see these objects — they are the engine running under the surface of every SAP transaction.
View authorisation objects: SU21 · Check failed auth after error: SU53A single role is a package of authorisation objects grouped together under a name that describes a job function. Z_FI_AP_INVOICE gives access to accounts payable invoice posting. Z_MM_VENDOR_MASTER gives access to vendor master maintenance. A well-designed single role does exactly one thing — it covers one business function and nothing more. This clean design makes SoD analysis straightforward: if you know what each role does, you can immediately see which combinations create a conflict. Poor role design — one role containing 400 transactions across three modules — makes SoD almost impossible to manage.
Create and manage roles: PFCG · Display role: PFCG → enter role nameA composite role is a bundle that contains several single roles inside it. Companies use composite roles to make user administration easier — instead of assigning five separate single roles to a new AP Executive, you assign one composite role Z_AP_EXECUTIVE that contains all five. This is where an important SoD risk hides: any conflict that exists between the single roles inside a composite role is automatically given to every user who receives that composite role. SAP GRC must look inside the composite role to find conflicts at the single-role level. Many SoD problems in real implementations come from composite roles that were built without checking the SoD implications of the single roles they contain.
PFCG → Roles tab (to create composite) · GRC must analyse inside composite roles for accurate SoD checkThe last step is assigning a role to a specific user with a validity period. In companies with SAP GRC, this should never be done directly in SU01 — every role assignment must go through the GRC access request workflow so there is an approval, a risk analysis, and a permanent audit trail. In companies without GRC, a Basis administrator does this in SU01, which means there is no automatic SoD check. The risk here is gradual over-assignment — a well-meaning admin gives someone "what they need for the project" without realising the combination creates a serious SoD conflict that nobody will catch until the next external audit.
Direct assignment (avoid this): SU01 · Correct method: GRC access request workflow via NWBC portalThe Most Important Rule About Roles: A well-designed SAP role does ONE thing. It covers exactly one business function for exactly one job title in exactly one part of the organisation. When roles are designed this way, SoD conflicts are easy to see and easy to control. When roles are designed poorly — containing hundreds of transactions for multiple job functions — SoD becomes almost impossible to manage because you cannot tell what each role actually does without reading through hundreds of authorisation objects one by one.
⚔️ Three Real SoD Conflicts Every Beginner Must Know
These are not made-up textbook examples. These are the three most common SoD conflicts that real SAP audit teams find in real companies during real access reviews. Each one involves specific SAP transactions and creates a specific type of risk. Understanding these conflicts clearly — with the actual T-codes — is what shows an interviewer or auditor that you genuinely understand SoD, not just the definition.
Create Vendor and Approve Vendor Payments — The Classic Fraud Combination
Post Vendor Invoice and Release the Payment Block — Hidden Double Bypass
Create Customer and Issue Credit Notes — Revenue Manipulation Risk
The Four Options for Handling Any SoD Conflict
When SAP GRC finds an SoD conflict, there are exactly four choices. Only the first two actually eliminate the risk — the others manage it while it continues to exist.
🛡️ SAP GRC Access Control — The Tool That Enforces SoD Automatically
SAP GRC stands for Governance, Risk, and Compliance. It is a separate product from SAP ECC or S/4HANA — a suite of tools that sits alongside your SAP system and manages access, risk, and compliance in an automated, auditable way. Think of it as an intelligent gatekeeper. Every time someone wants new access in SAP, instead of just giving it to them, the request goes through GRC first. GRC checks whether the new access would create an SoD conflict with what the person already has. If it does, the request is flagged or blocked — and the human approver must decide what to do about the conflict before the access is granted.
Before GRC, companies typically managed SoD through manual spreadsheets — someone would periodically extract the user-role table from SAP, compare it against a list of known conflicts, and email findings to managers. This process was slow, error-prone, and always behind the current state of the system. GRC does all of this automatically, in real time, every time a role is requested or changed. It also maintains a complete audit trail — every access request, every approval, every conflict that was found and how it was handled — all stored permanently for auditors to review.
The GRC Access Request Workflow — Step by Step
Submits
Request
Risk
Analysis
Reviews
Risk
Reviews &
Provisions
Assigned
in SAP
How a New Access Request Moves Through SAP GRC Access Control
When someone needs new SAP access — a new joiner, a job change, a project requirement — the request starts in the GRC portal (accessed through NWBC, the web browser interface for GRC). The manager selects the user, chooses the role or roles being requested, sets a validity period (start and end date), and writes a business justification explaining why this access is needed. The request is assigned a unique reference number and enters the workflow queue. Nothing has been assigned to the user yet — this is just the application.
Access: NWBC → Access Management → New Request · Not SAP GUI — GRC uses a web browser portalThe moment the request is submitted, GRC's risk engine runs automatically. It looks at the authorisation objects inside every role the user currently has, plus the authorisation objects inside every role being requested. It compares all of these against the company's risk ruleset — the list of known SoD conflicts. If any combination matches a conflict, GRC immediately flags the request with the risk ID, the risk level (Critical, High, Medium, or Low), and a clear description of exactly which two functions are conflicting. This entire analysis takes just a few seconds.
GRC risk engine → compares against risk ruleset → conflict found: risk ID + level + description shown immediatelyThe manager who submitted the request receives a notification. They see the requested role AND any SoD risks GRC found. If there is a Critical or High risk, the manager cannot simply approve and move on — they must either modify the request to remove the conflicting role, or provide a formal written justification for why the conflict is acceptable in this specific case. This step forces a human being to make a deliberate, documented decision about every risky access request. There is no way to silently slip a Critical SoD conflict into the system.
GRC → email/NWBC inbox notification → manager logs in → reviews risk → modifies request OR provides justificationOnce the manager has approved the request (with any modifications needed to address SoD conflicts), it moves to the Security team for final review and technical provisioning. The Security team confirms the role contents match the business justification and that no other concerns exist. When they confirm, GRC automatically assigns the role to the user in SAP with the correct validity period. The entire workflow — from the first request to the final assignment — is permanently recorded in GRC: who requested it, what risks were found, who made what decision, and when the access was granted.
GRC automatic provisioning → role assigned via SU01 in background · Full audit trail stored permanentlyThe Audit Trail is the Real Value of GRC: People often think the main purpose of GRC is the approval step — getting a manager to say yes. That is important, but the permanent audit trail is actually more valuable. When an external auditor asks "why does this user have these two roles, and who approved it?" — that answer is in GRC in two clicks. It shows the original request, the risk analysis result, the manager's decision and justification, and the exact date the access was granted. Without GRC, finding that answer means digging through old emails — if they still exist.
🏭 How GRC Catches an SoD Risk — Arjun Industries Example
Pooja Sharma has just joined Arjun Industries Ltd as their new Accounts Payable Executive. Her manager, Suresh Zha, opens the GRC portal and submits an access request for her. He selects two roles that seem completely reasonable: Z_FI_AP_INVOICE (for posting vendor invoices in MIRO) and Z_MM_VENDOR_MASTER (for maintaining vendor master records in FK01/FK02 when vendors send new bank details). From a functional point of view, both roles make sense for an AP role. From an SoD point of view, this combination is a Critical risk — and GRC catches it immediately.
Arjun Industries — How GRC Caught a Critical SoD Risk Before It Reached Production
Suresh submits request GRC-REQ-2026-00445 for user PSHARM001 with roles Z_FI_AP_INVOICE and Z_MM_VENDOR_MASTER, validity 10-April-2026 to 31-March-2027, justification: "New AP Executive — needs vendor invoice posting and vendor master maintenance for daily operations." From a job description perspective, this is completely reasonable. Suresh has no idea that this combination is flagged in the GRC risk ruleset as Critical.
GRC Request: GRC-REQ-2026-00445 · User: PSHARM001 · Roles: Z_FI_AP_INVOICE + Z_MM_VENDOR_MASTERThe GRC risk engine analyses the request instantly. It finds that Z_FI_AP_INVOICE contains authorisation objects for MIRO (post vendor invoice) and Z_MM_VENDOR_MASTER contains authorisation objects for FK01/FK02 (create and change vendor master including bank details). This matches Risk Rule FI-MM-001: "Vendor Master Maintenance and Vendor Payment Processing" — rated Critical. GRC escalates the request to the Security team and sends Suresh a notification explaining exactly what the risk is and why it is dangerous.
Risk found: FI-MM-001 · Level: CRITICAL · Auto-flagged · Security team escalated · Suresh notified immediatelySuresh reads the GRC notification. It explains clearly: if Pooja can both change vendor bank details AND post invoices for payment, she could (in theory) change a real vendor's bank account to one she controls, post an invoice for that vendor, and the payment would go to the wrong account. Suresh consults the Finance Controller. They decide: Pooja gets Z_FI_AP_INVOICE for invoice posting only. Vendor master changes will be handled separately by a senior AP executive who has no payment access. Suresh removes Z_MM_VENDOR_MASTER from the request.
Manager action: NWBC inbox → review risk → modify request → remove Z_MM_VENDOR_MASTER → resubmitSuresh resubmits with only Z_FI_AP_INVOICE. GRC runs the risk analysis again. No conflicts found. The request goes through the standard approval workflow — manager approval, security team review, automatic provisioning. Pooja gets her access on day one with no SoD conflicts. Without GRC, Suresh would have submitted both roles directly to the Basis team who would have assigned them in SU01 with no SoD check at all — and the Critical risk would have existed silently in the system until the next external audit, perhaps a year later.
Re-analysis: No SoD conflicts · Z_FI_AP_INVOICE only · Auto-provisioned to PSHARM001 · Full audit trail in GRCThe Most Important Lesson from This Example: Suresh did not do anything wrong. He made a completely reasonable access request based on the job function description. GRC caught the risk automatically — not because Suresh failed, but because the risk was not obvious without looking at the underlying authorisation objects inside each role. This is exactly what GRC is designed to do: catch the risks that well-meaning people create accidentally, not just the ones created with bad intentions.
📋 Access Certification — Why Access Must Be Reviewed Regularly
Getting the initial access right when someone joins the company is important. But access does not stay correct by itself over time. People change jobs, get promoted, move between departments, join projects and leave them. Every time this happens, they gain new access for their new responsibilities. Very rarely does anyone systematically remove the old access they no longer need.
This gradual accumulation of unnecessary access makes SoD worse even in companies that started with clean, controlled access. A user who had no conflicts when they joined might develop a Critical SoD conflict two years later simply because they have held four different roles across three different job functions and nobody cleared out the ones they no longer use. Access certification is the scheduled, formal review that fixes this — usually done every quarter or every year — where managers go through every SAP role currently assigned to their team members and confirm whether each one is still appropriate.
| Stage | What Happens | Who is Responsible |
|---|---|---|
| Launch | GRC automatically starts a certification campaign on the scheduled date. It generates a review list for every manager showing all SAP roles currently assigned to each of their team members, along with any SoD conflicts those role combinations create. | GRC Administrator — sets the campaign schedule and confirms all managers are correctly mapped to their team members in the system. |
| Review | Each manager works through their list. For each role they see, they have two choices: Certify (this person still needs this access) or Revoke (this person no longer needs this — remove it). If an SoD conflict appears, the manager must also decide whether to keep or remediate it. | Line managers — they are responsible for knowing what their team members actually need to do their jobs. Only they can make the informed decision about whether a specific role is still appropriate. |
| Action | Roles that managers mark as Revoke are automatically removed by GRC when the campaign closes. Any role that the manager simply did not review within the deadline is treated as Revoke and removed automatically. This is the key enforcement mechanism. | GRC system executes removals automatically. Security team handles escalated SoD conflicts. The automatic removal of unreviewed roles is what gives certification its teeth. |
| Evidence | The completed certification campaign is stored permanently in GRC as audit evidence. It shows who reviewed what, when each decision was made, what was revoked, and how SoD conflicts were handled. This is presented directly to external auditors. | GRC Administrator exports and presents the certification report. Internal and external auditors review it as proof that the company actively manages its access controls. |
The Biggest Certification Mistake: The most common mistake is treating certification as a checkbox exercise — managers mark everything as Certify without reading through the list, just to clear their inbox notification. When this happens, the certification generates audit evidence but provides no real control. The roles that should have been removed stay in place, and the SoD risk that should have been caught remains in the system. For certification to work as a real control, managers must genuinely engage with it — and the company must track completion quality, not just completion rate.
🎯 SoD Interview Questions — What Gets Asked and How to Answer
These are the real questions you will be asked in SAP security, GRC administrator, and internal audit interviews. The answers below are written at a level that shows genuine understanding — with real SAP transaction codes and practical reasoning — not just memorised definitions.
| Question | Strong Answer |
|---|---|
| What is Segregation of Duties and why does SAP need it? | SoD means that no single person should be able to perform two or more conflicting activities that, together, could enable fraud or serious error without being detected. SAP needs it because SAP gives users enormous transactional power — one user with the right combination of access can create vendors, post invoices, and approve payments. Without SoD controls, that combination allows the entire AP process to be controlled by one person with no checks. The classic example: FK01 (create vendor) combined with F110 (run payment program) allows a user to set up a vendor with their own bank account and pay themselves. |
| Can you name three real SoD conflicts in SAP with their transaction codes? | Three common ones: (1) Critical — FK01/XK01 (create vendor) combined with F110/F-53 (approve payment) — fictitious vendor fraud. (2) High — MIRO (post vendor invoice) combined with FBRA (release payment block) — the person who posts the invoice can bypass the payment approval control. (3) Medium — VD01 (create customer) combined with VF01 (create billing document or credit note) — revenue manipulation risk. All three appear in SAP GRC's standard risk ruleset and should never be assigned to the same user. |
| What are the four ways to handle an SoD conflict? | (1) Remove the access — take one of the conflicting roles away from the user. Cleanest solution, no ongoing risk. (2) Redesign the roles — split the conflicting transactions into separate roles that are never combined. (3) Accept with a compensating control — keep both accesses but add a detective control such as a monthly exception report reviewed by a senior manager. Risk remains but is monitored. (4) Formally accept the risk — document that the business accepts this conflict with a written justification signed by the right level of management. Only options 1 and 2 eliminate the risk. Options 3 and 4 manage it. |
| What is the difference between a single role and a composite role in SAP? | A single role contains a set of authorisation objects that together give access to one specific business function — Z_FI_AP_INVOICE contains the objects for MIRO, MIR4, FBL1N — everything for AP invoice posting. A composite role is a container that holds multiple single roles. Z_AP_EXECUTIVE might contain Z_FI_AP_INVOICE, Z_FI_AP_DISPLAY, and Z_FI_REPORTS. When doing SoD analysis in GRC, you must look inside composite roles to find the underlying single-role authorisation objects — SoD conflicts often exist at that level and are invisible if you only look at the composite role name. |
| What is access certification and why does it matter? | Access certification is a periodic review — typically quarterly or annual — where managers review all SAP roles assigned to their team members and confirm whether each one is still needed. Roles marked as unnecessary are automatically removed by GRC. It matters because access accumulates over time — people change jobs but keep their old roles, project access is never removed. Without certification, the SoD risk in a system gets progressively worse even when initial access was clean. Certification is the maintenance process that prevents this drift. The completed campaign also provides evidence for auditors that the company actively reviews its access controls. |
| What is a compensating control and when would you use one? | A compensating control is a detective measure — usually a regular management review — that monitors an existing SoD conflict when the conflict cannot be completely removed. For example, if a small company has only one AP person who must both post invoices and have some payment visibility, a compensating control might be a monthly report showing every invoice posted and every payment block released by the same user, reviewed and signed off by the Finance Manager. The conflict still exists, but a senior person is regularly checking whether it was misused. Compensating controls must be consistently applied and the review evidence must be kept for auditors. |
The Interview Answer That Gets You Hired: Most candidates say something like "SoD means no single person should do two conflicting tasks." That is accurate but forgettable. The answer that wins the interview names a specific conflict — FK01 plus F110, and explains exactly why that combination is dangerous. It describes how GRC's risk ruleset flags it automatically. It connects SoD to a real business consequence. Specificity is what separates a candidate who has actually worked with SAP access from one who has only read about it.
📋 Master Reference — Everything You Need in One Table
| Term / T-Code | Type | What It Is | Where You Use It |
|---|---|---|---|
| SoD | Concept | Segregation of Duties — no single person should have access to complete a harmful or fraudulent process without another person being involved at a key checkpoint | The foundation principle behind all SAP GRC Access Control and every access review |
| GRC | SAP Product | Governance, Risk, and Compliance — SAP's suite of tools for managing access requests, SoD checking, risk analysis, and access certification in an automated, auditable way | Every GRC conversation, security interview, and SAP access management project |
| Access Control | GRC Component | The GRC component that manages SoD checks, access requests, Firefighter IDs, and access certification — the most commonly implemented GRC component | The starting point for any SAP GRC implementation or security assessment |
| Risk Ruleset | GRC Config | The library of SoD conflict rules — defines which pairs of functions or transactions are incompatible when assigned to the same user. SAP ships a standard ruleset that companies customise. | GRC implementation. Must be tuned to your business — remove rules that do not apply to your industry to avoid false positives |
| PFCG | T-Code | Role Maintenance — create, edit, and view SAP single and composite roles and their underlying authorisation objects | Any work involving role design, troubleshooting access errors, or building new roles during an implementation |
| SU01 | T-Code | User Maintenance — create, change, display SAP user accounts including their role assignments and validity dates | User administration. In GRC environments, direct SU01 role changes should be minimised — use GRC workflow instead |
| SU53 | T-Code | Display last failed authorisation check — shows exactly which authorisation object was missing when a user received a red access error | Troubleshooting access errors — run this immediately after an authorisation failure to find the missing permission |
| SU21 | T-Code | Authorisation Object Maintenance — display any authorisation object and understand what fields and activities it controls | Understanding what a specific authorisation object does and why a particular role gives certain access |
| NWBC | Interface | NetWeaver Business Client — the web browser interface used to access SAP GRC. Not the traditional SAP GUI — GRC runs in a browser. | Every GRC user — managers submitting requests, security team reviewing risks, managers completing access certifications |
| FK01 / XK01 | T-Code | Create Vendor in FI (FK01) or in MM (XK01) — highly sensitive, always the first transaction checked against payment access in SoD analysis | Central to every AP-related SoD discussion. Never combine with F110 or F-53 on the same user |
| F110 | T-Code | Automatic Payment Program — runs batch payments to vendors. One of the most sensitive transactions in FI. Always part of vendor payment SoD rules. | Must always be separated from vendor master creation, changes, and invoice posting access |
| MIRO | T-Code | Post Vendor Invoice — used for three-way match invoice entry in MM/FI. Check against FBRA for the classic invoice/payment-block SoD conflict | AP invoice entry. Should never be combined with payment release, vendor master change, or payment approval access |
| FBRA | T-Code | Reset Cleared Items and Release Payment Block — removes payment holds set on vendor documents pending review | Should never be assigned to the same user as MIRO — combining both removes the payment approval control entirely |
| VD01 | T-Code | Create Customer Master Record. Sensitive in SD because it controls who is recognised as a legitimate customer in the system | SD-related SoD discussions. Should not be combined with billing document creation or credit note issuance (VF01) |
| VF01 | T-Code | Create Billing Document or Credit Note in SD. Directly affects revenue and receivables. | SD billing and credit note processing. Check against VD01 for the customer creation + billing SoD conflict |
| AGR_USERS | Table | Role-to-User Assignment — maps which roles are currently assigned to which users with start and end date validity | GRC reads this for all risk analysis. Core data source for SoD reporting and access certification |
| AGR_1251 | Table | Role Authorisation Values — stores the actual authorisation object values inside each role. The raw data GRC uses to determine what a role actually allows. | Detailed SoD analysis when you need to know exactly what a role contains at the authorisation object level |
| Access Certification | GRC Process | Periodic formal review where managers confirm whether each SAP role assigned to their team members is still needed. Revoked roles are removed automatically. | Quarterly or annual compliance reviews. Mandatory for SOX-compliant companies. Generates audit evidence. |
| Compensating Control | Concept | A detective measure — usually a regular management report — that monitors an existing SoD conflict that cannot be completely removed | When SoD conflicts must be accepted due to small team size or business requirements. Always requires documented sign-off |
| Critical Risk | GRC Level | Highest SoD risk level — requires immediate action. No exceptions without CFO-level approval and formal documented justification | FK01+F110 type conflicts. Never accept without senior management written approval and formal risk acceptance document |
📘 Related SAP Tutorials
SAP Audit Trail- Real Scenario
How SAP tracks every change across all modules- CDHDR, CDPOS, FI document trail, HR infotype log, and QM e-signatures.
Read TutorialSAP Real Business Scenarios
End-to-end business process walkthroughs- Procure-to-Pay, Order-to-Cash, Hire-to-Retire with full T-codes and table flows.
Read TutorialSAP All Tables List
Complete reference to 100+ SAP database tables across all modules with key fields, descriptions, and primary keys.
Read Tutorial