Compliance is Easy to Measure. Intent is Harder to Inherit.
Recently, a new IT Operations leader at one of our long‑standing customers inherited an Azure environment shaped by years of trade‑offs and risk acceptance. They needed to understand it quickly, and not just what existed, but why, because compliance data alone couldn’t explain the intent behind those decisions.
We reviewed architecture diagrams and historical reports, but one question kept surfacing: “What’s as-built, and what’s intentional?”
That distinction is vital. A public IP on a VM might be an unmanaged risk, or a consciously accepted exception. A relaxed backup policy might be the result of drift or a deliberate business decision. The customer didn’t need a new tool; they needed a way to see which parts of their environment reflected deliberate intent.
Moving Beyond “We’ll Get Back to You”
Over years of service reviews and incidents, we jointly make hundreds of governance decisions. These are rarely binary:
- A public IP retained for a specific integration.
- Backup configurations adjusted for application constraints.
- Resources temporarily excluded from a standard control.
Historically, the reasoning for these trade-offs lived in meeting notes or tickets, not in the compliance reports themselves. When questions arose, the common refrain was, “We’ll take that away and come back to you.” For a leader newly accountable for an environment, that friction is a major gap.
A Clear View of Compliance Data, With Context Built In
The new Compliance View in the Codify Portal was built to address this exact requirement.
It provides a single, consolidated view of compliance across your Azure environment. Not just the status, but the reasoning behind it.
At a glance, you can now see:
- The overall compliance state for a category
- How many checks are passed, ignored, or failed
- Which Azure resources a control applies to
- A direct link to the service ticket where a compliance posture was agreed
What started as a response to one customer’s operational need has now been rolled out to all of our Managed Azure customers, and it has been very well received.
Compliance With Memory, Not Just Metrics
Let’s look at a practical example.
Within the Compliance View, you might see a backup compliance category where several resources are marked as ignored. On the surface, that could look concerning.
The difference is that each ignored item is backed by context.
Selecting a resource shows:
- The specific Azure resource
- The compliance check applied
- A reference to the service ticket where the exception was discussed
- The explanation and risk context agreed at the time
Instead of guessing whether something was forgotten or misconfigured, you can see clearly that the decision was intentional, documented, and understood.
From Static Reports to Operational Rhythm
These compliance data reports are not designed to be generated once and filed away.
They now feed directly into:
- Our weekly internal team meetings
- Ongoing customer service reviews
- Proactive discussions about Well-Architected alignment
Rather than debating whether something is “wrong”, the conversation shifts to:
- Does this still align with your intent?
- Has the risk profile changed?
- Is this exception still appropriate today?
That is a far more productive governance conversation and for customers who undergo external audits, this information is particularly valuable.
Auditors want to know why an exception exists. Instead of reconstructing history under pressure, the evidence is already there. The status, the justification, and the linked ticket provide a complete audit trail instantly.
Why This Is Not Just Azure Policy in Disguise
You might question if this could all be achieved using Azure Policy exceptions.
Azure Policy does allow exceptions to be created when a resource needs to deviate from a standard. From a technical standpoint, you can mark something as exempt and move on. The issue for many is that the problem is not the mechanism for tracking exceptions, but rather the context as to why the exemption is required.
When an Azure Policy exception is created, the explanation is usually a short note attached to the exemption. That note is often entered after the fact, and frequently by someone other than the person who made the decision. In many cases, it represents second or thirdhand information captured after a conversation, meeting, email, or chat.
Our approach treats exceptions as governance decisions, not technical artifacts. By linking directly to the original service ticket, we preserve the full conversation, the constraints, the stakeholders, and the agreed-upon mitigations.
Governance Reflects Intent
Good governance isn’t about chasing green ticks; it’s about making and recording deliberate decisions. Compliance without context is just noise.
The Compliance View is now available to all Codify Managed Azure customers.
If you’re responsible for an environment, especially one you’ve inherited, and want to see how this fits into your governance model
Reach out for a walkthrough of our solution.