Governance that depends on humans reviewing every resource is not governance. It is scheduled optimism.Enterprise Azure governance at scale requires mechanisms that enforce the security baseline without a security architect reviewing every deployment. The organizations that maintain good posture over time have automated their baseline, measured their compliance continuously, and created clear ownership for every finding. The governance model that makes this work has three planes operating simultaneously. Most organizations only build one of them. The architecture that connects all three — and why DORA made the third one mandatory:
The Three Governance Planes
Management plane: Azure Policy encodes the security baseline as code. Controls are enforced automatically at resource creation and remediated automatically when configuration drifts. This plane scales without human review.
Compliance plane: Defender for Cloud measures adherence to the baseline continuously, not at audit time. The compliance score and recommendation list are the operational dashboard of the security baseline’s health.
Operational plane: humans own findings, act on them within defined SLAs, and review the overall posture on a defined schedule. This plane requires ownership — without it, the first two planes generate data that nobody acts on.
The Management Plane: Azure Policy Architecture
The management group hierarchy reflects security boundaries. Root management group policies apply universally without exception: allowed regions, minimum TLS version, mandatory diagnostic logging. These are non-negotiable controls that apply to every subscription in the tenant regardless of workload type.
The platform management group contains connectivity, identity, and management subscriptions. Policies here cover hub VNET configuration, central monitoring, and shared service security baselines.
The landing zone management group contains workload subscriptions, divided into production (strict deny for non-negotiable controls) and non-production (audit with fewer restrictions to avoid blocking development velocity).
Policy initiatives group related controls by compliance standard. A DORA initiative includes: diagnostic settings deployment (DeployIfNotExists), Defender plan enablement (DeployIfNotExists), minimum TLS enforcement (Deny), access review requirements (Audit), and backup policy enforcement (Audit). Assigning one initiative maps all its controls to the compliance dashboard automatically.
DORA Mapping to Azure Policy
DORA Article 5 (ICT risk management framework): map to Defender for Cloud secure score tracking and Policy compliance reporting.
DORA Article 17 (ICT-related incident management): map to Sentinel incident classification rules and defined escalation paths.
DORA Article 24-25 (digital operational resilience testing): map to Azure Site Recovery test failover records and Chaos Studio scenario logs.
DORA Article 28-30 (third-party risk): map to Enterprise Agreement DPA provisions, sub-outsourcing register, and concentration risk documentation.
The Compliance Plane: Continuous Measurement
The Defender for Cloud regulatory compliance view should be reviewed weekly, not at audit time. Assign the relevant standards: CIS Microsoft Azure Foundations Benchmark, ISO 27001, NIST SP 800-53, and the custom DORA initiative. The compliance score for each standard shows which controls are met, which have open findings, and the trend over time.
A workbook that pulls from the compliance view and formats the results as a weekly management report eliminates the manual reporting effort. The data already exists in Log Analytics. The workbook makes it presentable.
The Operational Plane: Ownership and SLA
Every finding needs a named owner and a resolution SLA. High-severity findings: 72-hour SLA. Medium: two-week SLA. Low: monthly batch review. Without SLAs, findings accumulate indefinitely because no finding is ever formally overdue.
A Sentinel automation rule routes new Defender for Cloud findings to the owner of the affected resource based on a tag. A workbook tracks finding age against SLA. A weekly review meeting reviews findings that have exceeded their SLA. This is the operational plane in practice.
Preventing Finding Accumulation — The Most Important Control
Finding accumulation is the most common and most expensive governance failure. It happens when findings are created faster than they are resolved and when no finding is ever formally overdue. The controls that prevent it: automatic routing to a named owner, SLA tracking that surfaces overdue items in the weekly review, and escalation to leadership when a critical finding exceeds 72 hours without resolution.
Governance is not a technology problem. The technology exists. It is an organizational design problem. Ownership, accountability, and cadence are the design elements.
For more details, I highly suggest checking out the Microsoft Learn link below:
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/govern
#AzureGovernance #DORA #AzurePolicy #CloudGovernance #LandingZone
Be the first to comment
Leave a Comment
💡 Comments are reviewed before publishing.