The Sense and Nonsense of Azure Compliance Frameworks

Everyone who works with Microsoft Defender for Cloud knows the feeling. You open the dashboard, see a score of 62%, and wonder what on earth you have been doing for the past month. Nothing changed. No new deployments, no configuration drift. Yet the score dropped again.

Welcome to the world of Azure compliance frameworks, where green does not always mean secure, and a falling score does not always mean something went wrong.

What Compliance Frameworks Promise

On paper, compliance frameworks like CIS, ISO 27001, and NL BIO Cloud Theme offer something valuable: a structured, auditable way to demonstrate that your cloud environment meets a defined security baseline. Assign an initiative, measure your posture, remediate findings, repeat. Simple, right?

The promise is:

• Insight into your security posture at a glance
• A shared language between engineers, management, and auditors
• Continuous measurement so drift gets caught early

In theory, that is exactly what you want when managing multiple Azure environments.

What You Actually Get

In practice, the experience looks quite different.

Scores That Move Without You

Azure Policy evaluates resources on a 24-hour cycle, and built-in initiatives are updated by Microsoft without prior notice. A new control gets added to an initiative, and suddenly your score drops five points. You did not change anything. Your environment did not change. Microsoft just decided the bar moved.

Combine that with the fact that every new resource deployed by a client immediately gets evaluated, and you have a score that is in constant motion. A single storage account without a private endpoint can drop your score before the deployment pipeline has even finished.

The Same Finding, Five Times

Most organisations that take compliance seriously end up with multiple initiatives assigned: MCSB as a baseline, CIS for hardening, ISO 27001 if there is a certification track, and sometimes NL BIO for public sector clients. The result is the same finding appearing in four different places, worded slightly differently, each counting against a different score. Engineers spend more time navigating overlapping findings than actually fixing them.

This is not a theoretical problem. It is the daily reality in any multi-framework Azure environment.

Recommendations Without Priority

Defender for Cloud treats “Enable MFA for all users” and “SQL servers should have vulnerability assessment enabled” as peers. Both appear in the same list, with similar visual weight. There is no signal telling you which one is genuinely critical and which one is a nice-to-have that happens to be part of an initiative.

Without that context, teams either try to fix everything (impossible) or start picking off easy wins to move the score (counterproductive).

The Exemption Spiral

When a policy fires on something that is legitimately not applicable, the correct response is an exemption. But exemptions in Azure Policy are a blunt instrument. You pick a category (Waiver or Mitigated), optionally add a description that nobody will read, set an expiry date that will silently pass, and move on.

Six months later, nobody remembers why the exemption exists. In an MSP environment with dozens of subscriptions and hundreds of resources, exemption lists grow faster than they get reviewed. At some point, your compliance score is green not because the environment is secure, but because everything inconvenient has been exempted away.

BIO: A Special Kind of Frustrating

The NL BIO Cloud Theme deserves its own paragraph, because it represents everything that can go wrong with compliance frameworks in Azure.

BIO Thema-uitwerking Clouddiensten is a Dutch government framework designed for public sector organisations consuming cloud services. It introduces controls that genuinely do not exist in CIS or ISO 27001: exit strategies, CSP transparency requirements, cloud security strategy as a formal policy document, and explicit ties to Dutch legislation like the AVG.

These are real, meaningful controls. The problem is that most of them are organisational and procedural, not technical. Azure Policy cannot audit whether your organisation has a documented exit strategy. It cannot verify that your cloud provider is contractually obligated to give you insight into their security measures. So the Azure Policy initiative maps these controls to generic technical policies, many of which already appear in MCSB or ISO, and calls it a day.

The result is an initiative that generates a lot of non-compliance noise, overlaps heavily with other frameworks, and still does not actually measure the things that make BIO unique.

In practice, I have never seen a client reach meaningful BIO compliance through Azure Policy alone, and that is not a failing of the client. It is a failing of the mapping.

Security Theater

There is a term for what happens when compliance becomes the goal rather than the means: security theater. Everything looks right from the outside, the score is green, the dashboard looks clean, but the underlying posture has not improved.

The most common form of security theater in Azure is the exemption-everything approach. Assign a comprehensive initiative, exempt every control that causes friction, watch the score climb. At the end of the exercise, you have a well-documented set of reasons why your environment does not need to comply with anything, wrapped in a green dashboard.

A genuinely red score on a small, well-chosen set of meaningful policies tells you more than a green score on four overlapping initiatives with three hundred exemptions.

What Actually Works

After working with multiple Azure environments across different clients, the approach that holds up looks something like this:

Pick one framework and own it. MCSB is a reasonable default because it is always on and covers the technical basics. Add CIS if there is appetite for active hardening. Add ISO only if a certification track is real and funded. Avoid stacking frameworks for the sake of completeness.

Keep the initiative small. A custom initiative with twenty well-chosen policies on Deny is more valuable than a built-in initiative with four hundred policies on Audit. If you cannot enforce it, it is just noise.

Do not exempt, fix. An exemption should be a last resort with a documented compensating control, not a way to make inconvenient findings disappear. If your exemption list is longer than your policy list, something has gone wrong.

Separate the score from the story. The compliance score is a metric, not a verdict. Report to clients on specific, meaningful controls rather than a single number that fluctuates for reasons outside your control.

Run Audit before Deny. In any existing environment, run new policies on Audit for at least a month before switching to Deny. Understand what is actually happening before you start blocking it.

InitiativeMerger: One Initiative to Rule Them All

The duplicate-findings problem described above is not just annoying — it is architectural. Azure Policy evaluates each assigned initiative independently, meaning the same policyDefinitionId appearing in both MCSB and CIS gets evaluated twice and counts twice against your compliance score. Stack four frameworks and you are not measuring compliance four times more precisely; you are generating four times the noise.

InitiativeMerger is an open-source .NET tool that solves this directly. It takes your chosen frameworks — MCSB, CIS, ISO 27001, NIST, BIO, or your own custom initiatives — and merges them into a single deduplicated initiative. Each unique policy appears exactly once, parameter conflicts between frameworks are resolved using configurable strategies (prefer the most restrictive, prefer the first, fail loudly, or use the framework default), and the result can be deployed directly to Azure or exported as JSON for your own pipeline.

The practical result: one initiative assigned instead of five, one compliance score that actually reflects your environment, and a findings list where every entry is distinct and actionable.

It ships as a CLI for CI/CD pipelines, a Blazor web UI for interactive use, and a REST API if you want to integrate it into existing tooling.

If the multi-framework overlap problem sounds familiar, it is worth a look.

The Uncomfortable Truth About Microsoft

Microsoft has little incentive to simplify this. A complex compliance landscape keeps customers engaged with Defender for Cloud. Recommendations that can be resolved by upgrading to a higher Defender plan are not a coincidence. And the feedback from engineers who deal with this daily moves slowly through UserVoice and GitHub issues before it reaches product teams.

That does not mean the tools are without value. It means you need to use them deliberately, with your own structure imposed on top, rather than accepting the default configuration and hoping for a green score.

Conclusion

Compliance frameworks in Azure are useful when they reflect a deliberate choice about what you want to enforce and why. They become counterproductive when the goal shifts from security to score management.

A score of 75% with twenty enforced, meaningful policies is a stronger security posture than a score of 95% built on exemptions and overlapping initiatives that nobody reads.

The question worth asking is not “how do we get to green?” but “what are we actually willing to enforce?”

That is a harder question, but it is the right one.