There is a recurring gap between the people who define what good looks like and the people who have to make a cloud platform actually behave that way. I sit on both sides of it. I review ISACA’s IT Audit Framework and serve on its IT Audit and Assurance Advisory Group, and I hold deployment-approval authority over infrastructure at internet scale. The framework tells you which control objectives matter. It does not tell you how to enforce them on a platform that changes thousands of times a day. This post is about closing that gap on Microsoft Azure.
Why a framework is not a control
The IT Audit Framework gives you assurance objectives: access should be least privilege, changes should be authorized, data should be classified and protected, evidence should be retained. Those are outcomes. An auditor can confirm them after the fact. What an auditor cannot do is keep them true between assessments. On a cloud platform, the time between “compliant at audit” and “drifted in production” is measured in hours, not quarters. So the real engineering question is not “can we prove the control existed,” it is “can we make the control run continuously and produce its own evidence.”
That reframing is the whole point. An audit objective becomes useful in the cloud only when it is expressed as a control that executes automatically and emits a record every time it runs.
Mapping objectives to Azure mechanisms
On Azure, three services carry most of that load, and each maps to a different kind of assurance objective.
Azure Policy is where configuration and change objectives become enforcement. A policy with a deny effect refuses a non-compliant resource at creation, which is the cloud equivalent of a preventive control. A policy with a deployIfNotExists or modify effect remediates drift automatically, which is a detective control that also corrects. Grouping policies into an initiative lets you express a whole control domain at once, and Azure Policy’s own compliance state becomes the evidence that the control is in force across every subscription it touches.
Microsoft Defender for Cloud is where posture and risk objectives live. Its Regulatory Compliance dashboard maps your environment against control baselines and shows pass or fail per control with the affected resources named, which is exactly the artifact an assurance objective needs. Secure Score turns posture into a trend you can govern over time, and attack-path analysis answers the question auditors increasingly ask, which is not “is this setting wrong” but “can this combination of settings be exploited.”
Microsoft Purview is where data-governance and evidence-retention objectives land. Classification and sensitivity labeling operationalize the “know and protect your data” objective, and unified audit and data lifecycle controls give you the retention and traceability that audit objectives assume but rarely get.
Designing for the auditor and the engineer at once
The discipline I apply is to write every control so it satisfies both readers. The engineer needs a control that runs in the platform and fails closed. The auditor needs the control to leave a record that is durable and queryable without anyone assembling it by hand. Azure Policy compliance state, Defender for Cloud’s compliance dashboard, and Purview’s audit trail are all machine-generated, which means the evidence is a byproduct of enforcement rather than a separate project. That is the property that lets a control scale: nobody has to remember to collect proof, because producing proof is what the control does.
A practical sequence that works: take one ITAF control domain, express its preventive objectives as Azure Policy deny effects, express its detective objectives as Defender for Cloud recommendations tracked in Secure Score, point its data objectives at Purview, and then confirm that each produces an artifact you would be comfortable handing to an external assessor. Repeat per domain. You end up with a control plane where the audit report is a view over live enforcement, not a snapshot someone reconstructed the week before the assessment.
The takeaway
A framework like ITAF is a map of what to assure. Azure Policy, Defender for Cloud, and Purview are the terrain where assurance either happens or does not. The work that matters, and the work most organizations skip, is the translation between them: turning each control objective into a mechanism that runs continuously and proves itself as it runs. Do that, and compliance stops being a periodic scramble and becomes a property of the platform.