Notifications
Clear all
Topic starter
23/06/2026 9:04 pm
TL;DR: Oracle Risk Management Cloud can identify Segregation of Duties conflicts, but it cannot independently prove that mitigating controls operated or that elevated access did not translate into materialized risk over time, according to SafePaaS. For IAM and NHI practitioners, the control question shifts from access assignment to continuous evidence of monitored use and defensible outcomes.
NHIMG editorial — based on content published by SafePaaS: The Two Control Gaps Oracle Risk Management Cloud Can’t Provide
Questions worth separating out
Q: How should teams handle accepted SoD conflicts in Oracle ERP environments?
A: Treat accepted SoD conflicts as monitored risks, not static exceptions.
Q: Why do native ERP reports often fall short for audit-ready risk proof?
A: Native ERP reports usually prove assignment, not execution.
Q: What breaks when mitigation controls are only tracked in spreadsheets?
A: Spreadsheets create a record of intent, but they do not reliably prove that a control ran for every user and every period.
Practitioner guidance
- Map accepted Oracle conflicts to named compensating controls Create a control register that links each accepted SoD conflict or elevated role to a specific reconciliation, approval workflow, or detective report.
- Test mitigation execution for every user and period Move beyond sample-based review and verify that each mitigating control ran for every applicable user, close cycle, and emergency access window.
- Correlate access with upstream and downstream evidence Join Oracle entitlements with tickets, approvals, exceptions, and transaction records so you can prove whether elevated access matched the approved pattern.
With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, practitioners should expect stronger pressure for independently reconstructable control evidence?
👉 Read SafePaaS's analysis of Oracle RMC control gaps and materialized-risk detection →
Explore further
25/06/2026 2:11 am
Accepted risk is now a governance object, not a cleanup task. When Oracle SoD conflicts are structurally necessary, the security question shifts to whether each conflict has a living mitigation with provable execution. Static exception logs do not satisfy that requirement because they do not show the control firing over time. The practical conclusion is that teams should treat accepted risk as something to monitor continuously, not something to document once and file away.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How can security teams prove elevated access did not become materialized risk?
A: Correlate elevated access with approvals, tickets, and transaction logs during the exact period of elevation. Then test whether any actions exceeded the approved pattern or crossed materiality thresholds. The answer should show both what the user could do and what they actually did.
👉 Read our full editorial: Oracle RMC control gaps: mitigation and materialized-risk detection
