Governance Operating Model
A landing zone does not end at deployment. It is operated, reviewed, and corrected continuously, or it drifts. The difference between a platform that stays healthy and one that quietly rots is an operating model: who owns what, and how often it is reviewed.
Purpose
This page turns the platform into an operating model. It defines ownership across the platform, security, workload, and finance functions, and the recurring rhythm that keeps the platform aligned with its design.
Design Reasoning
A working operating model connects technical controls to an operational rhythm. The platform needs recurring reviews for policy assignments and exemptions, RBAC and privileged access, cost and budgets, security posture, monitoring coverage, documentation, change management, and workload onboarding quality.
Without that rhythm, even a well-designed landing zone drifts: exemptions become permanent, role assignments accumulate, costs grow unexplained, and the documentation stops matching reality.
Ownership before process
Every review below needs a named owner. A cadence with no owner is a meeting that gets cancelled; an owner with no cadence is a person who never gets to the review. You need both.
Architecture Decision Record
| Decision | Choice | Rationale |
|---|---|---|
| Operating model | Explicit RACI plus fixed review cadences | Makes ownership and rhythm unambiguous, so governance happens by default rather than by escalation. |
| Change management | Platform changes go through IaC and review | Keeps the deployed platform matching its documented, version-controlled design. |
Tradeoff: Fixed cadences and a RACI add process overhead. The alternative — ad hoc governance — is cheaper until the first audit, cost surprise, or access incident, at which point it is far more expensive.
Recommended Configuration
A RACI for the core governance activities (R = Responsible, A = Accountable, C = Consulted, I = Informed):
| Activity | Platform team | Security | Workload team | Finance |
|---|---|---|---|---|
| Management group and policy design | A / R | C | I | I |
| Policy exemptions | R | A / C | C | I |
| RBAC review | R | C | C | I |
| Defender for Cloud review | C | A / R | C | I |
| Budget review | C | I | C | A / R |
| Diagnostics and alerts | A / R | C | C | I |
| Workload onboarding | A / R | C | R | I |
| Documentation ownership | A / R | C | C | I |
Example Implementation
A practical review cadence:
| Cadence | Review |
|---|---|
| Weekly | Failed alerts, failed remediations, security incidents |
| Monthly | Policy exemptions, Defender coverage, new role assignments |
| Quarterly | Management group structure, built-in policy versions, product-line portfolio |
| Semi-annually | Network addressing, logging costs, access-model cleanup |
Exception management is a first-class process, not a side effect of policy: every exemption has a reason, an owner, and an expiry, and the monthly review is where expired ones are closed or renewed deliberately.
Validation Steps
# All role assignments across scopes (input to the RBAC review)az role assignment list --all --output table
# Exemptions at the intermediate root (input to the exemption review)az policy exemption list \ --scope /providers/Microsoft.Management/managementGroups/contoso
# Budgets for a subscription (input to the budget review)az consumption budget list --scope /subscriptions/<subscription-id>Common Mistakes
- No formal exemption review, so exceptions silently become permanent.
- No access review, so role assignments only ever grow.
- No documentation owner, so the docs and the environment diverge.
- Direct portal changes outside IaC, which reintroduce drift.
- No recurring cost review, and no owner for security recommendations.
- No review of built-in policy changes, and no cleanup of decommissioned subscriptions.