> For the complete documentation index, see [llms.txt](https://docs.balkan.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.balkan.id/iam-risk-analyzer/segregation-of-duties-iam-risk-analyzer/iam-risk-analysis-oracle-ebs.md).

# IAM Risk Analysis  - Oracle EBS

### Overview

This section outlines how Segregation of Duties (SoD) policies across Oracle E-Business Suite are implemented, configured, validated, and operationalized within BalkanID IAM Risk Analyzer.

The objective is to transition from static SoD reporting to a continuous, measurable governance program that integrates detection, review, and remediation into the organization’s access management lifecycle.

### Implementation

**Phase 1:** Policy Definition & Baseline Establishment

Objective: Define and validate SoD policy scope across Oracle EBS modules.

Activities include:

* Identify financial and operational modules in scope (AP, AR, GL, PO, OM, HRMS, System Administration)
* Define baseline toxic combinations aligned to industry best practices
* Categorize SoD rules by risk severity (MEDIUM, LOW, HIGH, CRITICAL)
* Validate rule logic against seeded and custom responsibilities

Outcome:\
A formally approved SoD policy library ready for configuration in BalkanID.

**Phase 2:** Rule Configuration in BalkanID IAM Risk Analyzer - Finding Rule for SoD   detection \
\
User-Generated Insights can be used for writing SoD Rules and can be aggregated into a finding for actionable risk alerts. Findings provide a broader risk context and are used to trigger automated workflows.<br>

Example: Inquiry Based SoD&#x20;

Inquiry-level access conflicts represent situations where users hold read-only visibility across multiple sensitive financial modules without direct transaction execution authority.

While these conflicts do not typically enable fraud execution, they introduce:

* Confidential data aggregation risk
* Insider intelligence risk
* Financial reporting visibility beyond job necessity
* Competitive and supplier sensitivity exposure

IAM Risk Analyzer classifies Inquiry-only SoD conflicts as LOW risk by default, with the ability to elevate to LOW–MEDIUM in highly regulated or publicly traded environments.

***Use Case 1*****:** Payables vs Receivables Inquiry

Oracle EBS authorization is menu- and responsibility-based. Inquiry menus often expose:

* Full transaction histories
* Customer and vendor master data
* Credit limits and balances
* Pricing, procurement, and payment information

When inquiry access spans multiple financial domains (e.g., AR + AP), the cumulative visibility may exceed least-privilege boundaries.

This increases risk in the following areas:

* Insider trading exposure (public companies)
* Competitive procurement sensitivity
* Revenue and cash flow visibility leakage
* Confidential vendor and customer relationship data

<figure><img src="/files/iqz1BaCsCkQG2hspgXFL" alt=""><figcaption></figcaption></figure>

SoD Detection:<br>

<figure><img src="/files/hqyhkeqkzEhcifoq8H23" alt=""><figcaption></figcaption></figure>

***Use Case 2:***  Sales Operations vs Credit / Refund Processing\
\
Users involved in sales transaction management may also possess authority to issue customer credits or refunds.

Without proper segregation, a single user could manipulate both revenue transactions and financial adjustments.

Risk Impact

* Improper revenue adjustments
* Fraud risk through unauthorized credits
* Financial reporting inaccuracies

<figure><img src="/files/tT1jjx3V0hGVOfub79XN" alt=""><figcaption></figcaption></figure>

SoD Detection:\ <br>

### Baseline SoD Rule Library&#x20;

| **Rules**                                            | **Category**                                                                                                                     |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| SoD Inquiry - Receivable vs Payable                  | <p></p><ul><li>Segregation of Duties</li><li>Financial Data Aggregation Risk</li><li>Confidential Information Exposure</li></ul> |
| SoD - Purchasing Inquiry vs Payables Inquiry         | <p></p><ul><li>Segregation of Duties</li><li>Procurement Transparency Risk</li><li>Vendor Information Exposure</li></ul>         |
| SoD- Order Management Inquiry vs Receivables Inquiry | <p></p><ul><li>Segregation of Duties</li><li>Sensitive Financial Data Exposure</li><li>Revenue Visibility Risk</li></ul>         |

### Control Mapping

| Framework      | Control ID | Control Title                    |
| -------------- | ---------- | -------------------------------- |
| SOC 2          | CC6.2      | Logical Access Controls          |
| SOC 2          | CC6.6      | Least Privilege                  |
| SOX            | 404 ICFR   | Financial System Access Controls |
| ISO/IEC 27001  | A.5.3      | Segregation of Duties            |
| ISO/IEC 27001  | A.5.15     | Access Control                   |
| ISO/IEC 27001  | A.5.18     | Access Rights                    |
| NIST SP 800-53 | AC-5       | Separation of Duties             |
| NIST SP 800-53 | AC-6       | Least Privilege                  |
| NIST SP 800-53 | AC-2       | Account Management               |
| NIST SP 800-53 | AU-2       | Audit Events                     |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.balkan.id/iam-risk-analyzer/segregation-of-duties-iam-risk-analyzer/iam-risk-analysis-oracle-ebs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
