Most segregation-of-duties policies were written for the ERP: who can create a vendor and who can pay one. Oracle EPM does not look like that, so the GRC tool often has no rules for it at all, and the audit team sends back conflicts after the fact as a file to approve. The fix is not a hundred rules. It is six conflicts that cover most of what an auditor will raise in Planning, FCCS, ARCS and EDMCS, written as pairs of Oracle roles so they can be checked on every pull.
How to write a conflict so it can be tested
A conflict is two capabilities held by one person in the same application. To test it you need each side mapped to the roles Oracle actually assigns: the four predefined roles (Service Administrator, Power User, User, Viewer) and the application roles underneath them, which in FCCS and ARCS are granular enough to be useful. Write each conflict as role A plus role B, map A and B to your groups, and the check becomes a join over the role-assignment export instead of a judgment call.
| Conflict | Side A | Side B | Why it matters |
|---|---|---|---|
| 1. Metadata change versus approval | Changes dimensions and hierarchies: Service Administrator in Planning or FCCS; EDMCS request submitters | Approves the numbers those structures produce: FCCS journal approver, Task Manager approver, Planning approvals owner | A hierarchy change moves balances without a journal |
| 2. Rule development versus production execution | Writes business rules in Calculation Manager (test) | Runs rules on production data as Service Administrator | Untested logic reaches reported numbers with no second person |
| 3. Journal creation versus journal approval (FCCS) | Consolidation Journals: Create, Submit | Consolidation Journals: Approve, Post, Un-Post, Manage Periods | One person books and approves a consolidation entry |
| 4. Preparer versus reviewer (ARCS) | Reconciliation: Preparer on a reconciliation | Reconciliation: Reviewer on the same reconciliation; Profiles and Reconciliations: Manage | One person prepares, approves or reassigns the same account |
| 5. Access provisioning versus the control it protects | Assigns roles: identity domain administrator; Access Control: Manage | Any preparer, approver or journal role in the same application | Whoever grants access can grant it to themselves |
| 6. Developer versus promoter | Builds in test | Migrates to production: Migrations: Administer, LCM | Changes reach production without an independent step |
1. Metadata change versus approval
In Planning and FCCS, the person who can edit dimensions is a Service Administrator; in EDMCS it is whoever can submit and approve requests. A change to an entity hierarchy or an account roll-up changes consolidated results without touching a journal. If that same person approves journals, signs off Task Manager close tasks or owns the Planning approval hierarchy, there is no independent check on the structure the numbers depend on. Start by listing who holds both, then decide which side they keep.
2. Rule development versus production execution
Business rules are written by administrators, usually in the test environment, and run in production by administrators, usually the same ones. The conflict is not that one person does both; small teams have to. It is that nothing independent sits between writing the logic and running it on reported data. The mitigation is a promotion step with evidence (conflict 6) and a regression compare after each change, so that the rule that reaches production is the one that was tested, and someone other than its author saw the results.
3. Journal creation versus journal approval
FCCS makes this one easy to see because the consolidation journal roles are granular: Create, Submit, Approve, Post, Un-Post, Auto-Post After Approval and Manage Periods, assigned directly to users or groups. Oracle will not let the person who submitted a journal approve it, but that protection exists only when the Consolidation Journal Workflow was enabled when the application was created, and Oracle's documentation is explicit that it does not apply to Service Administrators. With the workflow off, a Working journal can be posted directly: Create plus Post is a one-person journal. Keep Create and Submit on one side, Approve and Post on the other, treat Un-Post and Manage Periods as administrative roles with their own review, and count every Service Administrator as holding both sides.
4. Preparer versus reviewer
In ARCS the roles are Reconciliation: Preparer and Reconciliation: Reviewer, assigned per reconciliation, often through teams. Teams are where this breaks: a team assigned as both preparer and reviewer on a profile lets any member do both. The second thing to watch is Profiles and Reconciliations: Manage, which lets a power user reassign the workflow. Check preparer-reviewer pairs at the reconciliation level, not the user level, and include the manage role on the reviewer side.
5. Access provisioning versus the control it protects
The identity domain administrator and anyone with Access Control: Manage can assign roles, including to themselves. If they also hold a preparer, approver or journal role, the access review is reviewing its own author. The usual pattern in small teams is that the EPM administrator holds everything. Separate at least this: the people who provision do not hold the operational roles in SOX-scope applications, and the administrators and native accounts are reviewed each quarter by someone who is not one of them.
6. Developer versus promoter
Migration between test and production, through Migration in the application or LCM snapshots, is the step that turns a change into a production change. The person who built the change should not be the person who promotes it, or at minimum the promotion should carry a ticket and a second person's approval, with the migration log as evidence. This is also where Oracle's own monthly update belongs: a change you did not make, promoted on Oracle's schedule, with your test results as the control.
Making the six work
Export role assignments from each application's Access Control reports and from the identity domain, join them by user, and look for the pairs. Each hit gets one of three outcomes: remove one side; keep both with a named mitigating control, such as a monthly review of what that person did; or an exception with an expiry date and a re-certification. The GRC tool stays the system of record for the policy; the check runs where the roles live. Six rules, checked on every pull, will find more than a hundred rules checked once a year.
What to do this quarter
- Run the Role Assignment report in each SOX-scope application and the group export from the identity domain.
- Map the six conflicts to your own groups and application roles; write them down as pairs.
- Resolve each hit: remove, mitigate with a named control, or except with an expiry.
- Switch the FCCS journal workflow on if it is off, and review who holds Manage Periods and Un-Post.
EPM Auditor imports the policies from your GRC tool, maps them to Oracle roles and groups, and checks every user on every pull. About EPM Auditor.