Who should be accountable for deciding which cloud services and regions stay available?

Why This Matters for Security Teams

Deciding which cloud services and regions stay available is not a routine access question. It is an availability and risk decision that affects blast radius, data residency, incident response, and cost governance at the same time. When ownership is vague, teams tend to open regions or services ad hoc, and those exceptions quickly become the real operating model. NIST SP 800-53 Rev. 5 treats system availability, configuration control, and authorization as governance responsibilities, not developer preferences.

This is why central accountability belongs with the platform or operations owner, while developers retain a fast request path for legitimate needs. A recent NHIMG review of the The 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which is a strong signal that decentralised decisions do not scale. In practice, many security teams discover overexposure only after a region, key, or service has already been used in ways nobody formally approved.

How It Works in Practice

Operational ownership works best when the platform or operations team defines the default deny baseline, maintains the approved cloud service and region catalog, and enforces exception handling through policy. Developers should not be blocked from requesting change, but they should not be able to self-authorise availability scopes that affect production resilience or regulatory posture.

The practical pattern is: a team submits a request, the platform owner evaluates the business need, security impact, and data handling constraints, and the approval is translated into policy-as-code so the decision is enforceable rather than tribal knowledge. That aligns well with NIST SP 800-53 Rev. 5 controls on configuration management and access restrictions, and it also matches the way NHIs and workloads behave when cloud boundaries are widened unexpectedly. NHIMG’s Azure Key Vault privilege escalation exposure and 230M AWS environment compromise research both reinforce the same operational lesson: broad availability decisions often become privilege and exposure decisions.

• Keep one authoritative list of approved regions, services, and exception owners.
• Require every exception to have an expiry date, rationale, and review cadence.
• Use change control to bind availability decisions to policy, not ticket commentary.
• Log who approved the scope, who implemented it, and when it must be revalidated.

These controls tend to break down in multi-account or multi-cloud environments where teams can deploy outside the central landing zone because shadow provisioning bypasses the approval path.

Common Variations and Edge Cases

Tighter central control often increases approval overhead, requiring organisations to balance faster delivery against stronger guardrails. That tradeoff is real, especially for global platforms where region availability affects latency, sovereignty, and disaster recovery. Current guidance suggests that the right answer is not permanent central bottlenecking, but central accountability with delegated execution and time-bound exceptions.

There is no universal standard for this yet, but mature teams usually split decision rights by risk. Low-risk sandbox services may be pre-approved within a constrained catalog, while production services, sensitive data flows, and regulated regions require platform owner sign-off. This is especially important when availability choices indirectly determine where secrets live, where logs replicate, and which NHIs can reach which services. The DeepSeek breach and Snowflake breach case studies are useful reminders that seemingly administrative decisions can become exposure paths when access scope is too broad or poorly governed.

Where teams work across jurisdictions, the platform owner should also coordinate with legal, privacy, and risk functions before opening a region. That avoids treating residency, sanctions, and backup replication as after-the-fact surprises. The best outcome is a documented decision model that is easy to request, hard to bypass, and simple to revoke.

Related resources from NHI Mgmt Group

• Who should be accountable when sensitive cloud permissions are added to production services?
• Who is accountable when a red team compromise exposes both endpoint and cloud identity gaps?
• Who is accountable for access governance when ERP cloud controls fail an audit?
• Who should stay accountable when AI drafts incident summaries and escalation messages?