Cloud operations governance

Cloud operations governance keeps decisions and recurring work accountable after deployment. Record who approves changes, who operates each workload, what evidence shows essential work was done and who resolves gaps. Update those assignments as services and suppliers change.

Start with a usable register

Create an entry for each cloud account, subscription or project and connect it to the workloads it supports. One billing boundary may contain several applications; one application may also use resources across boundaries. Show both relationships.

Keep a named decision owner and a contact route that works during an absence. A resource tag can help locate a team, but the register should explain its responsibility and decision rights.

Define what ownership means

Before recording an owner, define what ownership implies for each resource type. Ownership can mean who owns the risk, who oversees changes, who supports the resource during troubleshooting, or who is financially or administratively accountable.

Specify owners by name, contact information, organisation and team. Accounts should have a single owner where possible. Populate alternate account contacts so notifications reach someone when the primary owner is unavailable.

Use company-owned email addresses, phone numbers and group inboxes rather than individual details, so contact routes survive staff departures. Create separate distribution lists for billing, operations and security and configure them as the corresponding account contacts.

Separate authority from daily work

A workload owner may approve operating requirements without applying every change. Identify who proposes a change, approves its business impact, performs it and checks the result. Clarify incident and recovery decisions in the same way. When a supplier operates the service, name the internal person who accepts its work and can arrange a replacement.

Shared services need an explicit arrangement. If several workloads depend on one identity service, network or backup platform, name its operator and the workload contacts who need notice of a material change. Give an ownership dispute a decision owner and date.

Choose an operating model

A cloud operating model defines how the organisation manages cloud resources, team responsibilities and collaboration. In a centralised model, a single team is responsible for governance, security and operations across the entire cloud estate and all workloads. This gives consistent policy enforcement and suits small organisations, start-ups or highly regulated industries, but it can become a bottleneck as adoption scales.

In a shared management model, responsibilities are divided between platform teams and workload teams. Platform teams deliver a standardised set of platform products used across the organisation, enforce baseline governance policies and maintain the platform landing zone for shared services such as connectivity, identity and management.

Set operating rules that can be checked

Choose rules for known risks: an owner for new resources, approval for production changes, a recovery procedure for critical workloads and a review when supplier access changes. State which environments each rule covers and who may approve an exception.

Record each exception's reason, affected workload, temporary control, owner and review date. A review should decide whether to close, renew or change it.

Review evidence and decide

Set the review cadence according to workload criticality and change risk: review higher-risk workloads more often, and revisit the cadence after material changes. At each review, compare the register with current accounts and workloads. Investigate unknown owners, overdue exceptions, alerts without a response owner and recovery evidence that no longer covers the live service. Record the decision, action owner and next date.

A successful backup job shows that a job ran. A restore exercise shows what was recovered under the conditions exercised. Review the workload's recovery requirement against the exercise record; keep the detailed test procedure with the workload.

Keep the record current through change

Update ownership when staff move, accounts are reorganised, workloads retire or a supplier's role changes. Keep procedures, contact routes and access records available to an authorised replacement operator. Before an external provider leaves, arrange a transfer of the service inventory, open work, procedures and access control.

For organisations handling personal information, the privacy owner should assess the actual supplier arrangement.

Under the Privacy Act 1988, reasonable steps to secure personal information include technical and organisational measures (APP 11.3). APP 11.3 applies to personal information held after 11 December 2024, regardless of whether it was acquired or created before or after that date.

Entities covered include organisations, agencies, credit reporting bodies, credit providers and tax file number recipients. Reasonable steps include protecting personal information from misuse, interference, loss, unauthorised access, modification or disclosure, and destroying or de-identifying it when no longer needed unless an exception applies.