A Cloud Ops operating model keeps decision rights, risk acceptance, and service ownership internal. It shares scarce engineering depth and sources repeatable work under runbooks and tested escalation. Answer that role by role, not once for the whole function. This article covers accountability design. Closing a capability shortage is a separate decision, covered in the Cloud Ops skills gap decision.
Quick Answer
Design the model as three layers: internal control roles that own outcomes and risk, shared engineering roles that build the platform, and provider-run execution roles that operate it. Write decision rights before the statement of work, then set governance forums, a severity model with named incident command, and exit controls. A provider can run a service well. It cannot decide what it is worth.
Table of Contents
- Which capabilities does the estate need?
- What does the team topology look like?
- Who decides what under pressure?
- Which governance forums keep it honest?
- How should 24×7 coverage work?
- How do you transition in and keep an exit?
- How can Resolve Tech Solutions help?
- Frequently Asked Questions
Which capabilities does the estate need?
Start with capabilities, not headcount. A baseline for a brownfield hybrid estate across AWS, Microsoft Azure, Google Cloud, SAP, and on-premises systems includes six capabilities, each behaving differently under sourcing pressure.
| Capability | What it owns | Sourcing boundary |
|---|---|---|
| Service ownership | Criticality, recovery objectives, windows | Always internal |
| Platform engineering | Landing zones, identity, network boundaries | Internal authority, shared build |
| SRE | Service levels, error budgets, reliability work | Internal policy, shared leadership |
| Cloud security | Control baseline, access, risk acceptance | Internal authority, provider monitoring |
| FinOps | Allocation, forecast and commitment approval | Internal decisions, shared analysis |
| 24×7 operations | Triage, runbooks, first-line restoration | Provider-run within written limits |
The right column is not a ranking. It marks where the accountability line sits, and that line is the operating model.
What does the team topology look like?
Use three groups with written boundaries.
Internal control roles: service owners per business service, a platform architecture owner, a security and risk owner, and a FinOps owner. None can be delegated to a queue, a shared mailbox, or a vendor account manager. If a service has no named owner, its sourcing decision is already wrong, and no contract repairs that.
Shared engineering roles build landing zones, pipelines, telemetry, and automation. Internal engineers set the pattern. Outside specialists add depth in identity, container platforms, or SAP infrastructure, working inside that architecture rather than beside it.
Provider-run execution roles cover monitoring, triage, runbook execution, patch and backup work, and after-hours coverage. Measure them on adherence, evidence, and handoff quality, not on judgment calls they were never given. For customer-managed workloads such as Amazon EC2, configuration, identity, guest operating systems, and application controls stay a customer responsibility under the AWS shared responsibility model.
Who decides what under pressure?
A RACI must cover contested decisions.
| Decision | Responsible | Accountable | Consulted |
|---|---|---|---|
| Severity-one response | Provider ops lead | Internal incident commander | Service owner, security |
| Landing-zone change | Platform engineering | Platform architect | Security, service owners |
| Cost exception | FinOps analyst | FinOps owner | Finance, service owner, platform |
| Risk acceptance | Security engineering | Security and risk owner | Service owner, compliance |
| Service acceptance | Provider transition lead | Service owner | SRE, security, FinOps |
Incident command stays internal even when the provider does the hands-on work, because command decides tradeoffs such as failing over during a fiscal close. Risk acceptance stays internal because a supplier accepting risk for you is not transfer. It is paperwork.
Which governance forums keep it honest?
Operating models rarely fail on the org chart. They fail on the calendar, because no forum has authority to say no.
| Forum | Cadence | Decision rights |
|---|---|---|
| Service review | Monthly | Service levels, coverage, acceptance |
| Platform and change board | Weekly | Landing-zone changes, standards, exceptions |
| Security and risk council | Monthly | Control baseline, access, risk acceptance |
| Cost review | Monthly | Allocation rules, exceptions, commitments |
| Major incident review | Five business days | Corrective actions, severity changes |
The Govern function in the NIST Cybersecurity Framework 2.0 exists for this reason: oversight has to be staffed, not assumed. Error budget policy works the same way. As Google's SRE guidance describes, the policy is agreed in advance and names what happens once the budget is spent, so reliability is not negotiated mid-outage.
How should 24×7 coverage work?
Define severity by business consequence, not by the alerting tool. Severity one means a business process is down or unsafe. Severity two means degraded service with a workaround. Severity three and below run business hours.
Follow-the-sun handoffs need a written record: open incidents, actions taken, actions not taken, current stop points, and the commander on duty. A handoff without a stated stop point is where brownfield estates get hurt, because these workloads carry consequences the console does not show.
- SAP: an interface backlog can be diagnosed at any hour, but restarting a production connector during period close or a settlement window requires the service owner.
- Industrial and operational technology: systems that need independent safe control must not depend on cloud reachability. Their change windows follow turnarounds and dispatch peaks, not the release calendar.
- Field-connected systems: when links are intermittent, the design can queue and replay transactions. The provider preserves the queue. It does not decide whether to discard it.
Every alert routed after hours needs an approved runbook, a stop point, and an escalation path with names and numbers. Alerts without runbooks should be fixed or suppressed, not forwarded.
How do you transition in and keep an exit?
Treat transition as three states with acceptance gates, not a go-live date.
- Days 0 to 30: inventory services, interfaces, and dependencies. Name owners and criticality tiers. Baseline incident volume, alert quality, and coverage gaps. Agree severity definitions and the RACI.
- Days 31 to 60: stand up tooling access, ticket and telemetry integration, and the on-call roster. Approve runbooks for the top alert classes. Run the forums with quorum and minutes.
- Days 61 to 90: pilot two or three services. Rehearse a severity one, including provider escalation and an after-hours security event. Fix the handover record, then extend coverage.
Exit-readiness controls belong in the design, not in a contract afterthought. Keep runbooks, automation code, telemetry configuration, and log data in enterprise repositories and accounts. Require a service catalog, define a reversal period, and test whether a new operator can pick up a runbook cold. If the provider is the only party who knows how the estate runs, you have a dependency, not a model.
The honest limit: an MSP cannot fix unclear service ownership, and it cannot accept business risk. Settle ownership first, or outsourcing just formalizes the confusion and adds an invoice.
How can Resolve Tech Solutions help?
Resolve Tech Solutions works on the accountability design and the run state together. The team can assess coverage and escalation practice, map service ownership and decision rights across a hybrid AWS, Azure, Google Cloud, SAP, and on-premises estate, establish governance forums and a control baseline, and operate defined run-state scopes.
Resolve Tech Solutions' guide to managed cloud services for hybrid environments shows how an operating scope can span platforms without transferring business accountability. Managed IT services then run inside those controls, with severity definitions, stop points, and acceptance gates agreed in advance. If your estate has outgrown its operating model, talk with Resolve Tech Solutions about coverage, ownership mapping, and run-state scope.
Frequently Asked Questions
What is a Cloud Ops operating model?
It is the written design naming which capabilities the enterprise needs, who holds each decision right, which forums meet on what cadence, how coverage and escalation work, and what happens at transition and exit. It is broader than an org chart and narrower than a strategy document. Without it, sourcing gets decided one incident at a time.
Can you outsource Cloud Ops and stay accountable?
Yes, if accountability is written down first. Service ownership, incident command, risk acceptance, and cost decisions stay internal while a provider executes monitoring, triage, and runbook work within stated limits. The failure mode is not outsourcing execution. It is outsourcing judgment nobody wrote down.
What belongs in a Cloud Ops RACI?
Cover the contested decisions: severity-one response, landing-zone changes, cost exceptions above a threshold, risk acceptance for unremediated findings, and service acceptance into run state. Name one accountable person per row. Two names means none.
How do you handle escalation for SAP and industrial workloads?
Give the after-hours team diagnostic authority and explicit stop points tied to business events such as period close, settlement windows, turnarounds, and dispatch peaks. For systems that need independent safe local control, keep that control independent of cloud reachability. Then rehearse the escalation with the service owner before it counts.