The Oracle EPM Cloud security model is the layered access control system that governs every aspect of user access to EPM applications — authentication (who can log in), application access (which applications a user can open), feature access (which actions a user can perform within an application), and data access (which dimension members and data intersections a user can read or write). Each layer is implemented through a different mechanism, and a complete security design must address all four layers. A security model that is rigorous at the application level but permissive at the data level leaves financial data exposed in ways that the application-level restriction gives no indication of.
Security Layer Architecture
| Layer | Mechanism | Where Configured |
|---|---|---|
| Authentication | Oracle IDCS — SSO, MFA, password policy | IDCS console; integrated with enterprise IdP via SAML |
| Application access | EPM Cloud predefined roles — Service Administrator, Power User, User, Viewer | EPM Cloud User Management; provisioned through IDCS groups |
| Feature access | Planning application roles assigned per application — what forms, rules, task lists a user can access | Planning application security administration |
| Data access | Security filters on Essbase dimensions — restricting which members a user can read or write | Planning application security filters and data access grants |
The data access layer is the most granular and most critical for finance applications. Security filters define which members in the Entity dimension a subsidiary finance team member can access, which Scenario members a budget preparer can write versus read, and which Account members a FP&A analyst can see but not write. A user who has a Planning User role can theoretically access all data in the application; security filters restrict that access to the appropriate subset. Without security filters, a Planning User role grants access to all data — which is rarely the intended configuration in an enterprise finance environment.
Design Considerations
Security filter design at scale requires a decision about the filter architecture: individual filters per user (granular but high maintenance overhead), group-based filters (filters assigned to groups, users assigned to groups — more maintainable), or dynamic security (filters that use the logged-in user’s identity to resolve their data access at runtime from a security mapping table, rather than assigning static filters). Dynamic security is the most maintainable approach for environments with frequent user access changes — adding a new entity to a user’s access requires a data change in the security mapping table, not a filter configuration change in the Planning application.
What Goes Wrong in Practice
The specific EPM Cloud security failure that most frequently creates audit and compliance exposure is assigning the Service Administrator predefined role to functional users for troubleshooting purposes and failing to remove the elevated access after the troubleshooting is complete. The Service Administrator role in Oracle EPM Cloud bypasses all application-level and data-level security restrictions — a Service Administrator can read and write all data in all applications in the environment. When troubleshooting access is granted as Service Administrator and the access is not revoked on a defined schedule, the effective security model of the production environment diverges from the designed model — and the divergence is invisible to application-level security reports, because Service Administrator access appears as a role assignment rather than as a security filter exception.
How Loop Wise Solutions Handles This
We implement a security model governance process for every EPM production environment — quarterly access reviews using the EPM Cloud user and role reports, a defined maximum duration for any temporary elevated access grants, and a change log for all security modifications. Service Administrator role assignments to non-system-administrator users are flagged as exceptions in the access review, with mandatory documentation of the business justification and a defined expiry date for the elevated access.
