Governator Has Grown Beyond Compliance, and the Data Model Is Why

In this article

• The architecture changed before the interface did
• An attack path shows the model working
• FinOps is where it paid off
• Where Cost Management stops
• Identity and security work the same way
• Compliance did not get demoted
• The interface had to catch up
• A real demo against a synthetic tenant
• What comes next

Governator started from a narrow problem. Azure already held nearly everything we needed for security and compliance work: Defender for Cloud had the recommendations and the posture score, Resource Graph had the inventory, Azure Policy had the enforcement state, RBAC had the access, and the Activity Log had the changes. Finding data was never the hard part.

Joining it was. An auditor’s questions cut across all five sources at once. Which resource is affected, which control the finding touches, who owns it, whether anything moved since the last assessment, whether the finding is open or fixed or accepted, and what proves any of it. Answering that meant somebody with a spreadsheet stitching exports together by hand, every audit.

So we built Governator to do the stitching and produce CyFun and NIS2 evidence that would survive an audit. What we did not expect was that the control mapping would turn out to be the less valuable half. The useful part was the model underneath it.

The architecture changed before the interface did

Azure gives you a great deal of operational information, and every service describes the environment in its own terms. Resource Graph talks about resources and properties. Defender works in recommendations, assessments and posture. Cost Management works in meters, billing dimensions and subscription identifiers. RBAC has principals, role definitions, scopes and assignments. The network services add more representations again: firewall rules, WAF policies, public endpoints, routing.

Every one of those is a correct view of the same environment. None of them agree on what a resource is, and none were designed to be joined to the others.

Governator became the layer that does the joining. Rather than each feature calling its own API and keeping its own shape, we normalise the facts we need into one representation Governator owns.

Resource Graph   \
Defender          |
Cost Management   |
RBAC              +--> Governator model --> resources, ownership, identities,
Activity Log      |                         costs, findings, relationships,
Network config    |                         evidence, history
Policy           /

That changes what the platform can answer. A security issue is no longer only a Defender recommendation. It arrives with the resource, the owner and the history attached, and so does a cost line or a role assignment. Once all three point at the same resources and the same scopes, you can ask questions across them.

An attack path shows the model working

A public IP is a networking fact. A role assignment is an identity fact. A reachable Key Vault is a resource fact. Azure records all three accurately, in three different services, and none of them is wrong about its own piece. What none of them holds is the line between them.

Governator traces that line. It starts at a public IP, follows the NSG rule that leaves management ports open to the internet, reaches the VM, crosses a VNet peering, and ends at the Key Vault and storage accounts the VM’s own identity can read. Then it attaches what each step means: the risk factors along the way, the blast radius of the identity involved, and the fixes that would break the chain, each one naming the CyFun control it satisfies and what it does to the score.

Defender knows the recommendation. RBAC knows the assignment. The network configuration knows the rule. Only something holding all three in one representation can say that together they form a path from the internet to production secrets, and then name the single change that severs it.

Building that needed nothing new from Azure. It needed the facts Azure already had, in one shape. That is the case that convinced us the model was worth more than the mapping built on top of it.

FinOps is where it paid off

Cost was the obvious next domain. Azure Cost Management stays the system of record for what Azure charged, and we have no interest in replacing it. The trouble is that the questions organisations actually ask do not stop at what a subscription cost.

They go on: which team should be paying for this, how much of it is shared and how the shared part gets split, what moved since last month, whether the increase is structural or a one-off, which resource caused it, whether that resource is tagged correctly, whether the allocation model still matches what is running, whether the commitments are being used, and whether the budget sits with whoever owns the workload.

Those questions live between billing, platform ownership and governance. That is exactly where one shared model earns its keep.

The FinOps module does not begin with more cost charts. It starts at the billing data, makes it line up, ties it to the resources we already know about, and publishes a governed view of cost. A closed billing period is checked against the invoice and published as final, with its history kept. The current period stays provisional until the real invoice arrives.

That separation does real work. It stops a live estimate and a closed invoice becoming the same kind of number on the same chart.

Where Cost Management stops

The clearest way to describe the relationship is as a division of labour.

Azure Cost Management	Governator FinOps
System of record for Azure charges	The operating model around those charges
Subscription, resource group and resource views	Business ownership and allocation views
Azure budgets	Budgets tied to named accountability
Tag-based analysis	Tags checked against who is actually responsible
Cost trends	Cost trends with resource and ownership context
Reservation and commitment data	Commitment usage read in the wider environment
Azure billing dimensions	Drill-down into resource, owner, governance and history

None of that is a gap in Azure Cost Management. It answers a different question and answers it well. Governator takes those facts and puts them inside the model it already uses for governance, security and compliance.

The difference shows up in what you can say out loud. Instead of “AI platform spend went up”, you get: spend went up, these subscriptions and resources account for most of the change, they belong to this ownership group, these tags disagree with each other, and here is how the total sits against the budget and the allocation model. Much of the waste we find in cost reviews is invisible at the subscription level and obvious once the resource and its owner are attached.

The drill-down is the part that counts. A number on an executive dashboard should always be traceable back to the resources and the source data that produced it.

Identity and security work the same way

A cost anomaly and an over-broad role assignment look like unrelated problems. Operationally they need the same chain: the fact, then its context, then who owns it, then what it looked like before, then a decision.

Take a role assignment. Whether it exists is rarely the interesting part. Who the principal is, what scope it covers, which resources inherit it, whether the role is wider than the job needs, whether anyone has used it in months, which team owns the affected environment, whether it combines with something else into a path like the one above, and whether someone already accepted the risk. Those are the questions, and none of them can be answered from the assignment alone.

The same holds for a firewall rule, a WAF finding or a Defender recommendation. Each becomes useful at the point where you can attach the workload it affects, the owner, the history and the evidence.

Compliance did not get demoted

Broadening the platform did not make the compliance work less important, and the original line still holds. Defender tells you what is wrong. Governator tells you what it means for CyFun or NIS2, who owns it, what changed since the last assessment, and what evidence proves it. That is still the deepest part of the product.

What changed is that compliance stopped being its own island. The resource model behind FinOps, RBAC and security is the same one the controls hang off, so a control now connects to a fuller picture of whatever implements it.

Continuous assurance is where that pays off. The yearly report was never the hard part. Keeping enough history and evidence to explain how the picture moved between two assessments is: what was observed, what backed it up, what changed, which findings stayed open, which were fixed, and which still need somebody to make a call.

The interface had to catch up

For a while the architecture ran ahead of the interface. The old navigation came from the compliance-only days, and every domain we added made it look more arbitrary. FinOps buried under Operations. Identity reading like a footnote to security. Compliance deep enough that everything else looked secondary.

The current interface gives the main domains their own place: the cross-domain overview, FinOps, security, identity and RBAC, compliance and assurance, and governance. They are six ways into one model. A platform team starts at resource health, a security engineer at exposure, finance at cost, an auditor at controls and evidence, and all four end up at the same underlying facts.

A real demo against a synthetic tenant

The demo runs against a synthetic organisation we call Fictive Corp rather than anyone’s real tenant. Its subscriptions, resources, findings and eighteen months of FinOps history are generated for the purpose.

The data is synthetic. The processing is the real thing. The FinOps figures are ingested, checked against the synthetic invoices and published through the same pipeline the product uses, rather than written straight into dashboard tables.

That makes the demo worth more than a set of screenshots. It gives us somewhere repeatable to exercise the interface, the model and the cross-domain behaviour together, without pointing any of it at a customer environment. You can open the current Fictive Corp environment in the live Governator demo.

What comes next

A shared model gets more useful with every domain attached to it, but only while provenance, tenant isolation and drill-down hold up. So the next round is less about new dashboards and more about the relationships between what is already there: better ownership models, more cross-domain analysis, longer history, clearer next actions, and tighter links between an executive number and the technical evidence sitting under it.

Governator began as a way to make Azure compliance evidence defensible, and that job has not gone away. Building the model it needed exposed a larger one. Cost, security, identity, governance and compliance are all describing the same Azure environment from different angles, and operating that environment well means treating them as one description instead of five.