Skip to content
Beta

Operating Model and Governance

Last updated on

Purpose

Section titled “Purpose”

The operating model ensures Security and Compliance are embedded in all migration decisions, not handled as a final approval step.

Why shared review is mandatory

Section titled “Why shared review is mandatory”
  • Cross-domain impact: Identity, network, logging, and workload controls affect each other.
  • Regulatory continuity: Compliance requirements must be reflected consistently across architecture and operations.
  • Delivery reliability: Early review avoids late redesign and go-live delays.
Section titled “Recommended governance structure”
  • Platform team: Owns shared controls and technical guardrails.
  • Security team: Owns control requirements, threat scenarios, and assurance criteria.
  • Compliance and risk: Owns regulatory interpretation, control mapping, and audit requirements.
  • Application teams: Own workload-specific implementation and operational adherence.

Suggested checkpoints by phase

Section titled “Suggested checkpoints by phase”
  • Design checkpoint: Validate architecture approach, trust boundaries, and mandatory controls.
  • Build checkpoint: Validate policy enforcement and baseline implementation.
  • Pre-go-live checkpoint: Validate evidence completeness, exception handling, and incident readiness.
  • Run checkpoint: Validate recurring control verification and reporting cadence.

Key artifacts

Section titled “Key artifacts”
  • RACI matrix: Decision and approval ownership across domains.
  • Control ownership map: Mapping of each control to accountable owners.
  • Exception workflow: Risk acceptance criteria, expiry dates, and remediation tracking.
  • Review cadence: Recurring governance and control-review sessions.
Section titled “Related Target Operating Model guidance”

Target Operating Model provides the cross-domain operating model. Its Governance and Decision Making and Roles and Responsibilities pages connect control ownership to platform, workload, FinOps, and service-management responsibilities.

Anti-patterns to avoid

Section titled “Anti-patterns to avoid”
  • Security as ticket queue: Review is requested only at the end of implementation.
  • Undefined risk ownership: Exceptions are granted without named accountability.
  • No run-phase governance: Controls are approved once but not verified continuously.