Governance Assessment¶

How the platform team finds out what governance an organisation needs, turns it into an enforced baseline, and checks every month that the baseline holds, including the financial risks of cloud use. It describes two things:

the assessment: a repeatable method to find the current governance state and the wanted future state, including regulatory requirements;
the implementation: the baseline that the platform ships as Azure Policy initiatives, configured with the answers of the assessment.

For who decides what, see Governance and decision making. For handling policies day to day, see Policy assignments and Policies and exemptions.

Method: the Cloud Adoption Framework governance cycle¶

The method follows the Microsoft Cloud Adoption Framework Govern methodology. Governance is a continuous cycle: build a cloud governance team once, then repeat assess, document, enforce and monitor, so governance stays current as risks and requirements change.

flowchart LR
    T["1. Governance team"] --> A["2. Assess risks<br/>(workshop)"]
    A --> D["3. Document policies<br/>(initiatives as code)"]
    D --> E["4. Enforce<br/>(deployed with the platform)"]
    E --> M["5. Monitor compliance and cost<br/>(monthly check)"]
    M --> A

Step	Activity on the platform	Cadence
Build a governance team	A team that owns the baseline and talks to the organisation about it (see Roles)	Continuous
Assess risks	A discovery or design workshop during implementation	At onboarding and on every change in requirements
Document policies	Policy definitions and initiatives as infrastructure as code	Versioned, per release
Enforce policies	Initiatives assigned by the platform deployment	Every deployment
Monitor compliance	The monthly health check and the service review	Monthly
Monitor cost and financial risk	A monthly cost review	Monthly

1. The governance team¶

Someone has to own the baseline: the policy definitions, the initiatives, and the standards they follow. In the managed model this is a team at the managing party that owns the baseline for all its customers, while the customer's own security and architecture functions keep ownership of the decisions (Operating models). In the self-managed model it is a role inside your organisation.

2. Assess the requirements¶

Every implementation starts with a structured workshop. It is deliberately the same for every organisation:

a discovery workshop when the standard platform is taken as is;
a design workshop when there are custom requirements. Its outcome is a written high-level design.

The workshop records the current state (existing Azure footprint, billing set-up, management groups, connectivity, identity, and any environment that will be taken over) and the desired state across the domains the platform deploys: identity, network and connectivity, security baseline, data protection and retention, resource organisation and naming, monitoring, and cost management.

Record the answers in a structured questionnaire. Each answer maps to a platform setting, for example the log retention in days, the Key Vault soft delete retention, DDoS protection, the firewall SKU, the WAF policy, VPN or ExpressRoute connectivity and Bastion. The assessment is then traceable: for every deployed governance setting you can point to the question and the answer that produced it.

Regulatory and compliance requirements are part of the assessment. The organisation's obligations decide which standards you assign and report on. The platform assigns by default the CIS Microsoft Azure Foundations Benchmark, the Microsoft cloud security benchmark and ISO 27001, and you can extend the set (Platform overview). Treat the risks you find like any other risk: record them in a risk list and give each an owner.

Repeat the assessment when the requirements change, and deliver the result as a change to the platform configuration (Change workflow).

3. Document the policies: the baseline ships with the platform¶

The governance baseline is part of the platform. It is not a document that every organisation has to implement itself, and it is not configured by hand per customer.

Policy definitions and initiatives belong to the foundation layer. Policy assignments belong to the postdeployment layer (Deployment layers).
Everything is infrastructure as code, deployed by pipelines. The baseline is versioned, reviewed by a second person and repeatable. Improving it once improves it for every platform on the code.
The initiatives are based on recognised standards, not on self-invented rules.
Where you offer templates, validate them against the same standards, by deploying the template and evaluating Azure Policy. Lock values that policies check to compliant values inside the module where possible.

Because the baseline is part of the product, a new platform has a governance minimum from day one. The answers of the assessment are applied on top of it as configuration.

4. Enforce the policies¶

Policies are enforced, not advisory. Initiatives use Deny and DeployIfNotExists effects where fitting, so a non-compliant resource is blocked at deployment time or fixed automatically, instead of only being flagged afterwards. Exceptions are explicit Azure Policy exemptions in the deployed configuration, so an exemption is a visible, reviewed decision and not a silent gap (Exemptions).

The assignments and their effect are visible in the Azure portal, under Azure Policy and in the Microsoft Defender for Cloud regulatory compliance view.

5. Monitor compliance and act on it¶

Compliance is evaluated every month in the monthly health check and reported to the customer or the stakeholders. A scheduled run on the first days of the month can collect the data. The data comes from Azure Resource Graph policy states: per subscription, how many controls of each assigned benchmark are compliant and non-compliant, with the names of the non-compliant controls. The report also holds the secure score and the security recommendations.

Because the report has the same format every month, the reader sees the trend and can check whether the posture improves.

5b. Monitor cost and financial risk¶

Cost is a governance discipline, not only a commercial topic. Uncontrolled spend, unused or oversized resources and unexpected consumption are risks, and you identify and treat them like any other risk. Where the platform team has access to the consumption data, run a monthly cost review next to the compliance check:

analyse consumption for anomalies and unexpected growth, unused or oversized resources, and missed reservation or savings plan opportunities;
validate the generated report and discuss the findings, so a financial risk leads to a decision like a compliance finding does;
decide when a deeper cost assessment is warranted.

See Cost and reservations. Because the review runs every month on the same data, cost movements show early and not at the end of a contract year. The hub layers do not deploy budgets (Operating responsibilities).

Follow-up actions¶

The report is the input for a decision, not the end of the process. Review the results with the stakeholders and agree follow-up:

Finding	Handled as
The platform team can resolve it	A work item in the backlog, picked up in a sprint
It needs a decision or action of the organisation	Discussed in the service review or the steering group (Meetings)
A financial risk	The same review, with a proposed optimisation or a deeper cost assessment
A structural finding	A change to the baseline itself, which benefits every platform on the code

This closes the cycle: monitoring feeds the next assessment.

How the cycle looks in practice¶

The method is the same everywhere. The conversation differs:

Where the organisation has its own cloud team or cloud centre of excellence, requirements are agreed with that team and reviewed in the recurring service meetings. The baseline can be extended with templates that are validated against the same standards.
Where the platform is delivered together with an internal platform team, the requirements are set with that team and revisited as its platform evolves.

In both cases the chain is traceable end to end: the workshop output that produced the configuration, the deployed policy assignments in the portal, and a series of monthly reports with the trend and the follow-up taken.

Roles and responsibilities¶

Role	Responsibility
Owner of the baseline (solution lead)	The policy definitions, initiatives and the standards they follow
Service manager	The governance assessment and the monthly review with the organisation
Delivery or cost owner	The monthly cost review, and reporting of financial risks
Technical direction (architect)	The technical direction of the baseline
Platform engineers	Execute the follow-up actions from the monthly report

Control¶

Compliance against the assigned initiatives is verified monthly and recorded where the stakeholders can read it. Financial risk is verified monthly where consumption data is available. The baseline itself is reviewed whenever the underlying standards change and whenever an assessment produces a new requirement.