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

Why ownership of cloud service availability should not be spread across every team

Accountability matters because cloud service and region choices are not just technical preferences. They determine where workloads can run, which recovery paths remain usable, and how much exposure the organisation accepts if a service degrades or a region becomes unavailable. If each product team can decide independently, availability decisions become inconsistent, exceptions are hard to audit, and cost or resilience trade-offs are often made without a full view of dependency and control impact. Central accountability also makes it possible to apply a single approval standard for sensitive changes. For a control-oriented view of this kind of governance, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point. In practice, many organisations only discover the weakness in their ownership model after a region or service decision has already created an availability gap.

How cloud service and region ownership works in practice

The practical answer is usually a shared model with a single accountable owner. Platform or operations should own the policy for which services and regions remain approved, because they can balance availability, resilience, cost, compliance, and supportability across the estate. That owner does not need to make every decision alone, but it should control the rules of the decision, the approval path, and the exceptions process. Developers, product owners, and security teams should be able to request a service or region, but the final call should stay with the function that can see the full operational picture.

This model works best when the owner defines three things clearly: what is allowed by default, what requires review, and what is prohibited unless an exception is granted. The review should consider service maturity, incident history, data residency constraints, failover readiness, and whether the region is actually needed for a business outcome. It should also document whether a service is approved for production, non-production, or both, because those use cases often carry different tolerance for risk. Where cloud services are used to support identity, keys, secrets, or other sensitive control points, the approval bar should be higher, not lower.

The strongest implementations maintain a living catalogue of approved services and regions, along with the business rationale for each one. That catalogue becomes the reference point for provisioning, procurement, and incident response. It also prevents teams from treating availability decisions as one-off preferences. If the organisation cannot explain why a service or region is approved, it has not really governed it.

For organisations building a control baseline around approvals, service boundaries, and exceptions, the underlying control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant, especially where centralised authorisation and policy enforcement are required. Where this guidance breaks down is in highly decentralised engineering models that lack a stable platform function to own the approval process.

Where accountability gets blurred in multi-cloud and regional exception decisions

Tighter approval control often increases coordination overhead, so organisations need to balance speed against consistency and resilience. The hard part is not naming an owner, but deciding how much delegated authority that owner can safely give to teams that need rapid delivery.

One common edge case is a federated cloud model where different business units buy and operate their own services. In that setting, a central policy owner may still set the minimum standard, but it will need local delegates who can validate operational need and enforce exceptions. Another edge case is emergency failover or incident recovery, where a region that is normally disallowed may need to be opened quickly. That should be treated as a controlled exception, not a permanent policy change.

Another nuance is that some services are technically available but operationally unacceptable because they cannot meet logging, support, sovereignty, or recovery expectations. Guidance vs consensus matters here: there is broad agreement that ownership should be centralised enough to enforce standards, but there is no single consensus structure that fits every company. The right model depends on how much autonomy the business can absorb without losing control of availability, cost, and risk.

Accountability should therefore rest with the team that can answer for the policy, not just the team that can click the console. When ownership and approval authority are split without clear rules, exceptions multiply faster than the organisation can track them.

Practitioner Guidance

What to prioritise: Assign a single accountable owner for the approved cloud service and region catalogue before delegating request handling. If no one owns the policy, exception drift is almost guaranteed.

What to verify: Check that the owner can enforce default deny, approve temporary exceptions, and explain why each approved service or region exists. If that rationale is missing, the approval is not well governed.

Practitioner takeaway: The key decision is not who can request access, but who can be held responsible when availability, resilience, or exposure changes because a cloud service or region was kept open.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• Who is accountable when JIT access is used across cloud services, pipelines, and admins?
• Who is accountable when a cloud identity breach spreads across multiple services?