Azure Policy as Code and Cloud Governance Guardrails

An inventory of your existing Azure Policy assignments, exemptions and compliance state; a design workshop that agrees the guardrail set and the effect, scope and enforcement date for each item; a Git repository holding the policy definitions, initiatives, assignments and exemptions; a GitHub Actions or Azure Pipelines pipeline that plans on a pull request and deploys on merge, using workload identity federation instead of stored secrets; an audit-then-deny rollout; an exemptions workflow where every exception has an owner, a justification and an expiry date; one agreed remediation batch; compliance and drift reporting through Azure Policy and Azure Resource Graph; and documentation plus a live handover. Fixed price of $3,950 per project, about 2 weeks.

It depends on your estate and your team, and the decision is part of the engagement rather than an assumption. Enterprise Policy as Code (EPAC) is the stronger fit when you want the whole policy surface — definitions, initiatives, assignments, exemptions and the role assignments policies need — managed as one desired state across several environments, and it ships starter pipelines for Azure DevOps, GitHub Actions and GitLab. Bicep with the Azure Landing Zones Library fits teams already committed to Bicep and Azure Verified Modules, particularly where the same repository deploys platform infrastructure; the library now keeps policy data separate from deployment logic so the two can be refreshed on different cycles. We put the recommendation in writing at kickoff with the operational consequences of each, and implement the one you choose.

No, and that distinction matters. EPAC is open source published in Microsoft's Azure organization on GitHub, and Microsoft's Azure infrastructure blog has profiled it as a governance-automation pattern — but it is not a Microsoft product and it is not covered by a Microsoft support contract. Its own support policy limits support to GitHub issues. In practice that is fine for a well-run platform team: the toolchain is PowerShell, the state lives in your repository and in Azure, and nothing about your policies becomes unreadable if the project stalls. But it is a decision to take deliberately, which is why we surface it at kickoff instead of after go-live. If that support model is unacceptable to you, we implement the Bicep and Azure Landing Zones Library path instead.

No — that is the whole point of the rollout sequence. Guardrails intended as deny rules are assigned first in audit or DoNotEnforce mode, which records what would have been blocked without blocking anything and without writing deny entries to the activity log. We let the compliance data accumulate, trigger on-demand scans to speed it up, and then review the results with you guardrail by guardrail: this rule would have stopped these existing resources and this deployment pipeline. Only the guardrails you approve get promoted to deny, on dates you set. Some organizations promote everything in week two; others promote three rules and keep the rest in audit for a quarter. Both are legitimate outcomes of this engagement.

The set is agreed in the design workshop, but the common core is: required tags on resource groups with tag inheritance down to resources through Modify policies; allowed regions for resources and resource groups, so nothing lands somewhere you cannot answer a data-residency question about; allowed SKUs or VM sizes where cost or capability control is wanted; diagnostic settings deployed automatically to a Log Analytics workspace you nominate; a security baseline initiative such as the Microsoft cloud security benchmark; and deny rules for the exposures you specifically choose to close — typically public network access on PaaS services, public blob access on storage accounts, and unmanaged disks. We do not assign a maximal built-in initiative and leave you to sort out the noise.

An exemption is a file in the repository, not a click in the portal. It carries an exemption category — mitigated, where the intent is met another way, or waiver, where non-compliance is temporarily accepted — plus a justification, a named owner, the assignment or specific policies it applies to, and an expiry date. It reaches Azure only through a reviewed pull request, so the plan output shows the approver exactly what is being exempted and for how long. The important detail is what Azure does at expiry: it preserves the exemption object for the record and stops honoring it, rather than deleting it or alerting anyone. The resource simply becomes non-compliant again. The review cadence we hand over is keyed to those expiry dates, which is the difference between an exemption process and a permanent hole with a note attached.

No, and any fixed price that promised to would be a fiction. One agreed remediation batch is included: we create the managed identities and role assignments the Modify and deployIfNotExists policies need, then run the remediation tasks across the in-scope subscriptions — typically tag inheritance and diagnostic settings, which are the two that remediate safely at scale. Everything else is delivered as a prioritized backlog: what is non-compliant, at which scope, why it matters, and what fixing it would involve. Some items are a five-minute change; some mean re-architecting an application's networking. Those go to your team or to a separately scoped engagement, with our honest view of which is which.

A landing zone builds the foundation — management groups, subscriptions, identity, network topology, platform services — and includes a baseline of Azure Policy as part of that build. This service assumes the foundation exists, however it came to exist, and adds the thing landing-zone projects usually stop short of: an operating practice for policy. Version control, a review path, an audit-then-deny rollout, an exemptions workflow with expiry dates, drift detection and a documented handover. If you have no hierarchy yet, buy the Azure Landing Zone and Cloud Adoption Framework Implementation first. If you have a landing zone that has drifted for two years, this is the service that puts it back under control.

Defender for Cloud tells you what is wrong; Azure Policy stops the next one from being created. Defender scores your posture against the Microsoft cloud security benchmark and regulatory standards, protects workloads with its plans, and produces a recommendation list — that is Microsoft Defender for Cloud — Cloud Security Posture Management. Azure Policy is the enforcement mechanism underneath. They overlap in one specific way worth planning for: Defender for Cloud creates and maintains its own policy assignments, and a desired-state policy-as-code tool will happily delete them if nobody decided otherwise. Part of this engagement is making that decision explicitly and configuring the toolchain to match, rather than discovering the interaction on a Friday afternoon.

It covers one Azure tenant, one management-group hierarchy, up to 10 in-scope subscriptions, one guardrail initiative built from built-in definitions plus up to five custom definitions, one pipeline platform, the exemptions workflow, one agreed remediation batch, the compliance and drift reporting, and documentation with handover — about 2 weeks. Quoted separately: larger or multi-tenant estates, additional custom policy authoring, Kubernetes admission control beyond one audit-only assignment, machine-configuration policies, AWS or Google Cloud policy, working the remediation backlog, and ongoing governance operations. Azure consumption and pipeline platform licensing are always your costs, billed to you by Microsoft and GitHub.

At the deployment root scope — usually a management group — we need to create the pipeline's deployment identity and grant it Resource Policy Contributor, to manage policy objects, and Role Based Access Control Administrator, because policies with Modify and deployIfNotExists effects need managed identities with their own role assignments. Granting that requires Owner or User Access Administrator rights, which is why either your team creates the identity or approves our request for time-bound delegated access. The plan identity is read-only. We ask for granular, time-bound admin access that you approve rather than standing global rights, and after handover the pipeline identity is the only thing that needs to keep those permissions.

No. Guardrails support a compliance program; they are not a compliance program, and nothing in this service is a guarantee of regulatory compliance. What it does give an auditor is genuinely useful: a versioned history of who changed which control and when, evidence that exceptions were approved by a named person with an expiry date, and a compliance report that maps resources to policies. Azure Policy also carries built-in regulatory compliance initiatives that we can assign in audit mode so you can see where you stand against a named framework — reading that honestly is a different exercise from passing an audit, and we will say so.

Three ways, all handed over. The Azure Policy compliance view in the portal gives per-assignment and per-resource state, refreshed on the standard evaluation cycle of about every 24 hours. An Azure Resource Graph workbook queries the policy data directly so you can slice non-compliant resources by subscription, owner tag or policy without waiting for a report. And drift in the as-code sense — someone changing an assignment in the portal — is caught by running the pipeline's plan step on a schedule against production: the toolchain is idempotent, so a plan that proposes changes when nobody committed anything means the estate moved underneath you. That scheduled plan is part of what we deliver.

You need one of them, or another CI/CD system able to run PowerShell if you go the EPAC route — starter pipelines ship for Azure DevOps, GitHub Actions and GitLab. If you already run one, we use it; if you run both, we put the governance repository where your platform team lives rather than where your developers do, because these are different audiences with different review cadences. If you have no delivery platform at all, that is a separate build — Azure DevOps and GitHub CI/CD Pipeline Implementation — and it should happen before this engagement rather than inside it.

About 2 weeks. The delays are almost never technical. The common ones are the design workshop slipping because the security owner and the platform owner cannot be in the same room, and the deny-promotion decision waiting on an application team that does not want its pipeline touched. Access and pipeline-platform readiness at kickoff remove most of the rest. Client-side delay extends the calendar without changing the fixed price, and any deny promotions scheduled after the engagement ends are documented so your team can execute them without us.

Your team owns the practice, and the handover is designed for that: the runbook, the generated policy documentation and the review cadence are written so that adding a guardrail or approving an exemption does not require us. If you want help anyway, ongoing governance operations, monthly compliance reporting and backlog remediation are available as optional extra-cost add-ons through IT Partner's NOC and support partnerships, and Azure Resource Monitoring and Maintenance Service covers the operational side of the same estate. There is no lock-in in either direction: the repository is yours, the policies are standard Azure objects, and you can stop using our services at any point.