Who is accountable for cloud access in an EBS on OCI deployment?

Accountability should sit with the system owner for application entitlements, the cloud platform owner for OCI controls, and the security team for lifecycle and monitoring standards. If those lines are not explicit, ownership gaps appear during incidents, audits, and offboarding.

Why This Matters for Security Teams

Accountability for cloud access in an EBS on OCI deployment is not just an ownership chart issue. It determines who can approve entitlements, who can explain OCI guardrails, and who must prove that access is revoked when the workload, environment, or administrator changes. In NHI terms, this is the difference between controlled access and an orphaned identity path. The Ultimate Guide to NHIs frames this as a governance problem, not merely a configuration problem.

This matters because cloud access in enterprise workloads often crosses team boundaries. Application owners understand the EBS entitlement model, cloud platform teams control OCI policy and tenancy-level access, and security teams define review, logging, and exception handling. When those lines are vague, incidents become disputes about who should have stopped a risky grant, and audits reveal that no one can defend the decision trail. Current guidance in the OWASP Non-Human Identity Top 10 treats this as a recurring failure mode: the identity exists, but accountability is distributed loosely enough that no single owner can be held to task. In practice, many security teams encounter the gap only after an access review, incident, or offboarding event exposes it.

How It Works in Practice

The cleanest operating model is to split accountability by decision type. The system owner is accountable for application entitlements, meaning which EBS users, service accounts, or integrations should have access and why. The cloud platform owner is accountable for OCI controls, including tenancy policies, compartment boundaries, IAM role construction, and any conditional access enforced at the platform layer. The security team is accountable for lifecycle standards, monitoring, detection, and review cadence. That division is consistent with the governance approach described in the Ultimate Guide to NHIs — Key Challenges and Risks.

In practice, the accountable owner should be able to answer four questions without escalation: who requested access, what business purpose justified it, which OCI controls were applied, and when the access will be removed or revalidated. That means using named owners in the CMDB or access register, pairing each entitlement with a review period, and tying exceptions to an explicit approver. For cloud access in OCI, real-world controls often include least privilege, compartment scoping, strong separation between platform administration and application administration, and logging that allows the security team to validate drift.

• System owner: approves application entitlement needs and business justification.
• Cloud platform owner: implements OCI IAM policy, tenancy guardrails, and network or compartment boundaries.
• Security team: sets review standards, monitors access changes, and escalates unresolved exceptions.

That operating model aligns with the OWASP Non-Human Identity Top 10 because it reduces ambiguous ownership around non-human access paths and makes reviewable accountability possible. These controls tend to break down when EBS is integrated with multiple OCI compartments and shared admin groups because the approval path becomes split across too many teams to enforce consistently.

Common Variations and Edge Cases

Tighter ownership rules often increase coordination overhead, so organisations must balance clear accountability against administrative friction. That tradeoff becomes sharper in hybrid estates, delegated admin models, or managed service arrangements where EBS access is brokered through platform engineering rather than directly by the application team.

There is no universal standard for this yet, but current guidance suggests the following exceptions should be documented, not assumed. If a third-party manages the OCI tenant, the platform owner still remains accountable internally for control assurance, even if execution is outsourced. If access is ephemeral or just-in-time, the security team still owns the lifecycle rule set, while the system owner remains accountable for the business need. If the same person serves as system owner and platform owner, that dual role should be recorded explicitly to avoid false separation of duties.

One practical risk is inherited access. In OCI, inherited policies or broad compartment grants can outlive the original justification, especially during migrations or emergency changes. That is why access reviews should focus on both direct entitlements and effective access. The 52 NHI Breaches Analysis illustrates how unclear ownership and long-lived access paths frequently show up together in real incidents. The right answer is not just naming an owner, but making that owner responsible for a reviewable decision trail.

Related resources from NHI Mgmt Group

• Who is accountable when cloud access expires on paper but persists in practice?
• Who should be accountable for cloud PAM when human, machine, and AI identities all have access?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?